xEmitter PT_Beam-like functionality with normal Unreal Emitters?

[oneirotekt]

Sorry if the topic name is incomprehensible, but that's exactly what I'm looking for. In UT2003 xEmitters can do a lot of cool things, but the one thing I've found that they can do that is absolutely impossible with normal Emitters (which is all we have in the Runtime) is draw 3D beams and trails through space (the ParticleType is PT_Beam for anyone who's used them).

With Emitters you can do a BeamEmitter that is basically a linear segment drawn from one point to another and textured with multiple rotated sheets, but that doesn't come close to offering the same range of visual effects possible with xEmitter PT_Beams. With those you can attach a trail to a moving object and it will draw a line segment through 3D space, etc etc.

My question is (and I have the feeling I already know the answer), has anyone found a way to accomplish this sort of effect with normal Emitters? If no, will there be any new features for normal Emitters in future versions of the Runtime, like the post-UT2004 one that's supposed to come out eventually?

Edit: if Epic doesn't have any plans to expand upon Emitters, is there any chance in hell I could add this myself with native code? From my understanding you can't add functionality to stuff that's already in the engine with the headers, but maybe there's some way to build it in as an all-new piece of tech?

 

[oneirotekt]

Hmm, okay I did some snooping around in the Runtime code and found an un-implemented flavor of ParticleEmitter called TrailEmitter. Looks like the UnrealWiki guys found it as well (scroll down to the bottom of that page). These things are interesting, they basically map a texture onto what's normally just a line segment in the SpriteEmitter:

Neat, but it's not the trails effect I'm after.

I also remember seeing something on the licensee section of UDN (heh, this is back when I worked for a licensee company) called a RibbonEmitter, which some other developer had come up with as a way of getting weapon trails to happen - because, as I've said, there's no way to do that in the stock engine / runtime.

It would be really, really nice if Epic could implement something like this, something that's not a half-finished experiment like TrailEmitters, into the stock engine. Either that, or make Digital Extremes' excellent XEmitter tech part of the engine. Is there any chance at all that we might see something like this with the post-UT2004 version of the Runtime?

The visual effect toolkit this engine provides is really great, but it's lacking in the one area that would be most useful to my particular project. With a good trails emitter I think there would be very little in the way of visual effects you couldn't pull off in this engine.

Thanks in advance for your time, Epic, and for releasing and supporting the Runtime in the first place.

 

[oneirotekt]

The latest in the Saga No One But Me Seems to Care About:

Edit: new screenshot, with some tweaking and new particle art for a "pencil sketch" effect.

I figured out a way, via egregious hack, to get a pseudo-quasi-trails-like effect. Basically it's a custom version of BeamEmitter, with "DetermineEndPointBy" set to "PTEP_Offset", which means a beam will be drawn from the emitter location to the offset point. My code sets BeamEndPoints[0] to the location (Min and Max are the same in the Offset range vector) the emitter was a split second (timer() increment) ago.

The problems should be apparent in the screenshot - BeamEmitters just draw a line from one point in space to another, with no curvature or accounting for what other, older beam particles are doing. The Beam Branch and Beam Noise capabilities don't really help anything in this case.

Just thought I'd share the result with people, the visual style of the trails fits okay with my project (though hardly ideal) but I don't imagine it'd be useful for anything "realistic". As I've said before it would still be really, really nice if there was an ParticleEmitter type dedicated to trails in some future version of the engine / runtime.

 

[ttl]

Obviously you would be better off with native code, but it should be possible to create something similar with a skeletal mesh and just setting the positions, rotations and perhaps scales of the bones manually and apply the shader of your choice? Of course this may not provide you with the effect that you are looking for, its just an idea.

 

[oneirotekt]

should be possible to create something similar with a skeletal mesh and just setting the positions, rotations and perhaps scales of the bones manually

How would I do that exactly? I wasn't aware you could create skeletal meshes dynamically and add / change bones in real time...

 

[ttl]

Well you don’t create the skeletal mesh in the actual game, you would make a dummy one in milkshape, maya, 3ds max or some other 3d program that can export to psk. You would then import it the normal way.

When you're actually making the dummy mesh you have to decide how you are going to implement this thing as it will effect how you lay out the bone structure (remember also that UV mapping is going to be important especially since you'll probably be wanting to join multiple skeletal meshes almost seamlessly, again it will depend on how exactly you want to implement it). Back to the bone structure, you could assign every vertex to its own bone ... however you might want to add some dummy bones as roots to every so many of these bones so as to make manipulating them a bit easier. Also remember when you're making the bone structure that you will want to have names that you can calculate in your code, after defining how many segments etc (ie. so you can change the LOD and just to make the code simpler and less of a mess).

The bone functions you will be using most are:
GetBoneCoords
GetBoneRotation
SetBoneScale
SetBoneDirection
SetBoneLocation
SetBoneRotation

There are more and you probably won’t even use all that are listed above, again it depends on your bone structure.

If you were to assign a bone to each vertex, it would be much like manipulating a vertex buffer. Which is basically what they would be doing to create their beam effect (of course they’d probably be using a index buffer as well).

As for performance, it will obvious be no where near as fast as doing it using vertex and index buffers and you would have to be crazy to attempt this if you had access to native code. If you can increase the number of vertices per bone (thus decreasing the number of bones) you will increase performance. To find out how it actually runs you will of course have to implement it, I imagine there will be a sweet spot which involves the number of vertices, number of bones and how "long" your mesh is so to speak (ie. how long before you attach the next mesh "seamlessly")... due to the overhead involved and other normal performance restrictions.

Back to the bone structure again, you will probably want to have a master root bone along with a few other "semi-root" bones so you can manipulate it without having to change the locations of all the bones.

Of course if you're doing a non-game, non-commercial product you might want to contact epic and try and get the headers, because it would be A LOT more efficient to do this natively.