New Particle Engine?
by Melv May · in Torque Game Engine · 08/23/2002 (2:54 am) · 34 replies
Everyone,
I've started this thread because I'm interested in hearing peoples' thoughts about the current particle engine. I'm doing this because I've not used it much and rather than wade through the code I thought I would get the info from the people who are using it.
I previously coded a particle engine for WildTangent which you can see here (Screenshots / fxExplosion) and I was wondering if these kind of features would be helpful here e.g. shaped particle emitters, motion blur, particle collision-detection blah blah blah.
It would be most helpful if you would let loose all the good, bad and ugly things about it e.g. What neat features should it have? What existing features are not needed? etc.
Thanks in advance,
- Melv.
I've started this thread because I'm interested in hearing peoples' thoughts about the current particle engine. I'm doing this because I've not used it much and rather than wade through the code I thought I would get the info from the people who are using it.
I previously coded a particle engine for WildTangent which you can see here (Screenshots / fxExplosion) and I was wondering if these kind of features would be helpful here e.g. shaped particle emitters, motion blur, particle collision-detection blah blah blah.
It would be most helpful if you would let loose all the good, bad and ugly things about it e.g. What neat features should it have? What existing features are not needed? etc.
Thanks in advance,
- Melv.
About the author
#2
--KallDrexx
08/23/2002 (3:58 am)
jeez melv, you work yourself too much hehe. Heh not sure what shaped emitters would be really. Motion blur might be a cool effect, and collision detection on them might be really good to have for some things i'll be doing on them, however I would think it would be slow no?--KallDrexx
#3
By shaped emitters I mean being able to control the emitter directions so that you can have an emitter than spawns particles in a ring shape, fan, sphere, hemi-sphere etc.
Here are a few examples...
Explosion#1
Explosion#2
Explosion#3
Explosion#4
In my previous engine you could set the emitter to emit in either point or area mode so that particles appeared over a defined volume (for bubbles in liquids) or at a specific point (for torches). You could also control the direction they were emitted.
Explosions were omni-directional, torches where hemi-spheres, weapon explosions were rings etc.
- Melv.
08/23/2002 (6:27 am)
Matthew,By shaped emitters I mean being able to control the emitter directions so that you can have an emitter than spawns particles in a ring shape, fan, sphere, hemi-sphere etc.
Here are a few examples...
Explosion#1
Explosion#2
Explosion#3
Explosion#4
In my previous engine you could set the emitter to emit in either point or area mode so that particles appeared over a defined volume (for bubbles in liquids) or at a specific point (for torches). You could also control the direction they were emitted.
Explosions were omni-directional, torches where hemi-spheres, weapon explosions were rings etc.
- Melv.
#4
08/23/2002 (6:33 am)
The ability to have shaped emitters like in those shots would be kick-ass! Just think of the beautiful explosions...ah, explosions...
#5
I am sure the PE falls under this broad umbrella I speak of, so any improvement would be good improvement ;)
08/23/2002 (6:50 am)
I have not looked at the PE code myself, but I have seen several areas where the code could use a face lift to use more modern techniques as well as newer technology (take advantage or other OGL/DirectX features etc.)I am sure the PE falls under this broad umbrella I speak of, so any improvement would be good improvement ;)
#6
Vic-D
08/27/2002 (12:52 pm)
Melv, I tried out that particle emitter in WildTangent when they first came out. Was that you early on? I was pretty impressed by it. It had the one key element that dumbasses such as myself need in order to use a tool: It was really easy to learn and use. Vic-D
#7
That one was mine Victor! 8) I was actually quite pleased with the way it performed. It had a simple interface that hid alot of flexibility and power.
I got offered a job (well an interview to be accurate) at Wildtangent just before they pulled the plug on the C++ support. I lost interest in the API and the company round about then. ;)
I think it's the current editor interface that let's Torque down, certainly for beginners (I hate the term newbies). By simply adding a grouping facility such as the WT editor had it becomes much easier to organise fields within an object. Even though the WT editor was (is?) poor it was very approachable. Also, standardisation across object hierarchies becomes obvious with neat little boxes that appear when editing across similar objects.
Perhaps this is something I should tackle next instead of simply doing another fx?
- Melv.
08/27/2002 (12:58 pm)
Yeah,That one was mine Victor! 8) I was actually quite pleased with the way it performed. It had a simple interface that hid alot of flexibility and power.
I got offered a job (well an interview to be accurate) at Wildtangent just before they pulled the plug on the C++ support. I lost interest in the API and the company round about then. ;)
I think it's the current editor interface that let's Torque down, certainly for beginners (I hate the term newbies). By simply adding a grouping facility such as the WT editor had it becomes much easier to organise fields within an object. Even though the WT editor was (is?) poor it was very approachable. Also, standardisation across object hierarchies becomes obvious with neat little boxes that appear when editing across similar objects.
Perhaps this is something I should tackle next instead of simply doing another fx?
- Melv.
#8
Personally, I think moving a lot of the functions into easily accessible buttons would be a big step. I don't like having to dig through menu's when I'm on a roll.
Might as well throw this out there while I'm at it... anyone know how big of a change it would be to put interior editing functionality into the engine?
Anyway, I'm going to continue working my way back through all of those programs, so it will probably be a week or two before I finish the document. Let me know if you would like to see it, currently the plan is to pass it off to a programming friend of mine, but he's stuck without a computer at the moment, so won't be getting much done for an undefined period.
Vic-D
08/27/2002 (4:13 pm)
Melv, I personally think the editor could use a revamp. In fact, I've been putting together a little doc with my ideal work environment in mind. The past few days I've been running through the various programs that are similar (UnrealEd, Hammer, MAX4, even NWN's editor (note: REAL NICE)) and figuring out what worked for each. Personally, I think moving a lot of the functions into easily accessible buttons would be a big step. I don't like having to dig through menu's when I'm on a roll.
Might as well throw this out there while I'm at it... anyone know how big of a change it would be to put interior editing functionality into the engine?
Anyway, I'm going to continue working my way back through all of those programs, so it will probably be a week or two before I finish the document. Let me know if you would like to see it, currently the plan is to pass it off to a programming friend of mine, but he's stuck without a computer at the moment, so won't be getting much done for an undefined period.
Vic-D
#9
The particles are very good for weapons e.t.c but they don't feel verya, i'm not quite sure, flexible is probably the closest I can think of, perhaps a rewrite would be pretty good, especially looking at what you did for wildtangent.
08/27/2002 (4:52 pm)
I've done quite a bit of work with the particle engine and it's not bad, but it isn't really all that complex.The particles are very good for weapons e.t.c but they don't feel verya, i'm not quite sure, flexible is probably the closest I can think of, perhaps a rewrite would be pretty good, especially looking at what you did for wildtangent.
#10
The biggest problem I think I had was that if you stand in the direct middle of most of my explosions you'd get 2fps for framerate (this is with gf4).
In fact, now that I think of it, T2's particle engine had another major problem with culling/not showing particles. The basic idea it used was "if you can't see the emitter, you can't see the particles", which didn't work at all for my 300-500m (in-game scale, same scale as torque) nuclear mushroom cloud.... blah.
Ah forgot my idea!
I was wondering if it would be possible to do particle GRAPHS. As in, plot points on a graph but put particles at the coordinates. Imagine a flat 2d plane with the velocity of a projectile as the z (vertical) axis. Then plot a circle (time-delayed) with sin/cos so you would basically have a railgun-like effect. There was a wierd hack you could do with negative phiVariances in T2 that could cause this, but it wasn't very good...
08/27/2002 (8:47 pm)
I've done some amazing thing with Tribes 2's particles/explosions/shockwaves (currently working with a shockwave effect and a cone effect for torque, hehe). I admit it is missing some things like collisions, but using the phi and theta constraints and multiple emitters you could make an explosion with a ring along the ground and a rising fireball/smoke cloud, which looked pretty realistic if you threw in a shockwave and some explosion shapes.The biggest problem I think I had was that if you stand in the direct middle of most of my explosions you'd get 2fps for framerate (this is with gf4).
In fact, now that I think of it, T2's particle engine had another major problem with culling/not showing particles. The basic idea it used was "if you can't see the emitter, you can't see the particles", which didn't work at all for my 300-500m (in-game scale, same scale as torque) nuclear mushroom cloud.... blah.
Ah forgot my idea!
I was wondering if it would be possible to do particle GRAPHS. As in, plot points on a graph but put particles at the coordinates. Imagine a flat 2d plane with the velocity of a projectile as the z (vertical) axis. Then plot a circle (time-delayed) with sin/cos so you would basically have a railgun-like effect. There was a wierd hack you could do with negative phiVariances in T2 that could cause this, but it wasn't very good...
#11
I dunno if your raising this question in response to a question I asked you earlier in one of your other threads, can't remember now, but here are my thoughts on the subject.
One of my major concerns with the existing particle engine in Torque is that it can be a real performance hog in certain situations. These situations are more noticeable in Tribes 2, since its currently the only completed game for the engine -- even though the engine code for Torque may be vastly improved over the one in Tribes 2 I have a feeling that the two versions of the engine still share some of the same pitfalls in performance. We identified one of those pitfalls, static object rendering, which are taking care of extremely well with your foliage rendering. Another area I think needs great attention is, in fact, the particle engine.
In Tribes 2, one of the more noticeable performance eaters is zooming up on particles. This has the potential to drag even some of the greatest systems out there, and I am willing to bet that most of this is because of fillrate limitations of the graphics card. I don't think the Torque particle engine takes this into consideration very well.
There are various other performance problems regarding the particle engine that even I don't know about, but just have a chat with any creditable Tribes 2 player and they'll be able to help you out further in that department.
As far as features I would like to see for a particle engine in Torque is collision detection, both with itself and with other objects, such as players and vehicles. I don't necessarily know how Unreal 2003 is handling their particle collision but here is how I would do it.
My implimentation would consist of interaction
'volumes' of particles and that collisions are done with these 'volumes' instead of each individual particle(which would be a major memory hog right there). A particle emitter firsts emits a 'volume' in which a certain amount, pX, of particles are emitted into, taking up random space within that volume. Once a volumes pX limit is reached that volume is released from the emitter and the emitter creates another volume. These volumes can be used in several other ways other than just collision bodies. For instance, a fairly simple culling algorythm could be implimented so that instead of updating every particle in the scene we only have to test each volume in the scene, and if necessary test the particles within that volume. Another use of these volumes would be in particle management, because we then have a way to delete pX number of particles all at once just by removing the volume. And further, we can create even more interesting animations with particles by both animating the particles within the volume, if necessary, and animating the volume itself, either by moving the volume as a whole or even modifying the bounds of the volume such as stretching or shrinking it.
Just a couple of thoughts. I wouldn't mind discussing my ideas in more detail if need be.
P.S. Just for kicks I call my idea Volumetric Particle Rendering ;p
08/27/2002 (9:33 pm)
Melv,I dunno if your raising this question in response to a question I asked you earlier in one of your other threads, can't remember now, but here are my thoughts on the subject.
One of my major concerns with the existing particle engine in Torque is that it can be a real performance hog in certain situations. These situations are more noticeable in Tribes 2, since its currently the only completed game for the engine -- even though the engine code for Torque may be vastly improved over the one in Tribes 2 I have a feeling that the two versions of the engine still share some of the same pitfalls in performance. We identified one of those pitfalls, static object rendering, which are taking care of extremely well with your foliage rendering. Another area I think needs great attention is, in fact, the particle engine.
In Tribes 2, one of the more noticeable performance eaters is zooming up on particles. This has the potential to drag even some of the greatest systems out there, and I am willing to bet that most of this is because of fillrate limitations of the graphics card. I don't think the Torque particle engine takes this into consideration very well.
There are various other performance problems regarding the particle engine that even I don't know about, but just have a chat with any creditable Tribes 2 player and they'll be able to help you out further in that department.
As far as features I would like to see for a particle engine in Torque is collision detection, both with itself and with other objects, such as players and vehicles. I don't necessarily know how Unreal 2003 is handling their particle collision but here is how I would do it.
My implimentation would consist of interaction
'volumes' of particles and that collisions are done with these 'volumes' instead of each individual particle(which would be a major memory hog right there). A particle emitter firsts emits a 'volume' in which a certain amount, pX, of particles are emitted into, taking up random space within that volume. Once a volumes pX limit is reached that volume is released from the emitter and the emitter creates another volume. These volumes can be used in several other ways other than just collision bodies. For instance, a fairly simple culling algorythm could be implimented so that instead of updating every particle in the scene we only have to test each volume in the scene, and if necessary test the particles within that volume. Another use of these volumes would be in particle management, because we then have a way to delete pX number of particles all at once just by removing the volume. And further, we can create even more interesting animations with particles by both animating the particles within the volume, if necessary, and animating the volume itself, either by moving the volume as a whole or even modifying the bounds of the volume such as stretching or shrinking it.
Just a couple of thoughts. I wouldn't mind discussing my ideas in more detail if need be.
P.S. Just for kicks I call my idea Volumetric Particle Rendering ;p
#12
That volume idea would be a lot better than the existing way Torque does culling (whole emitter). It might be tough making sure particles going in similar directions are stuck in a volume together. Perhaps you could make like 4 volumes for the directions particles could go in (x,y,-x,-y,-x,y,x,-y) or maybe 8 if you wanted to factor in z too, and then as they are emitted throw them in the volumes? Something like that. Also, considering the fact that most particles would be in dense clouds, you would probably also want the particle to try to join another volume before creating its own.
08/28/2002 (8:58 pm)
Zooming in on particles causes insane lag. Having any particle fill your screen causes lag. Also, look at T2 forcefields. Place 12 in one area, and you instantly can barely move. Could the main reason be the slowness of torque at blending the non-100% alpha textures on top of the whole image?That volume idea would be a lot better than the existing way Torque does culling (whole emitter). It might be tough making sure particles going in similar directions are stuck in a volume together. Perhaps you could make like 4 volumes for the directions particles could go in (x,y,-x,-y,-x,y,x,-y) or maybe 8 if you wanted to factor in z too, and then as they are emitted throw them in the volumes? Something like that. Also, considering the fact that most particles would be in dense clouds, you would probably also want the particle to try to join another volume before creating its own.
#13
If I understand your post correctly, you're simply trying to reduce the number of collision calls made by doing collision tests on larger volumes? I've been looking at the collision systems and how they work so I'll be sure to let you know what my investigations turn up. In my WT particle engine, every particle had collisions detection with a nominal bounding box encapsulating each and it went like a bat out of hell.
@Max: If your FPS drops drastically when close-up to particles then it's definately fill-rate as the processing of particles stays the same, normally. There are various techniques to reduce this like occlusion culling but most wouldn't work well here because most of the time particles are blended together and don't actually occlude each other.
There are certainly various LOD algorithms that could be applied to reduce the effect. Capping the maximum screen-space size would be one coupled with capping the upper limit of 'large' particles rendered would be another.
I'm looking at the collision detection code to see if shortcuts can be made or already are.
- Melv.
08/29/2002 (3:15 am)
@Robert: Yes, I did create this thread directly after speaking to you about the particle engine.If I understand your post correctly, you're simply trying to reduce the number of collision calls made by doing collision tests on larger volumes? I've been looking at the collision systems and how they work so I'll be sure to let you know what my investigations turn up. In my WT particle engine, every particle had collisions detection with a nominal bounding box encapsulating each and it went like a bat out of hell.
@Max: If your FPS drops drastically when close-up to particles then it's definately fill-rate as the processing of particles stays the same, normally. There are various techniques to reduce this like occlusion culling but most wouldn't work well here because most of the time particles are blended together and don't actually occlude each other.
There are certainly various LOD algorithms that could be applied to reduce the effect. Capping the maximum screen-space size would be one coupled with capping the upper limit of 'large' particles rendered would be another.
I'm looking at the collision detection code to see if shortcuts can be made or already are.
- Melv.
#14
08/29/2002 (9:35 pm)
Also another thing I'd like to see is water affecting particles. It always bugged me when a particle from a fireball or something would sink underwater, etc. What would be nice is to be able to set both an underwater particle that the particle itself switches to if it goes underwater (this could be set to just delete the particle too) and a alternate particle for the emitter to spawn if underwater (or tell it not to spawn underwater). Using a combination of these 2 you could get your particles working with the water really nicely.
#15
I hope you guys are sending yours in too.aren't ya?/*
Zoom-
08/29/2002 (11:41 pm)
*/So melv, how do you make your money aside from our donations?I hope you guys are sending yours in too.aren't ya?/*
Zoom-
#16
If you want the "HOLY GRAIL" of particle engines, I think you simply must look at Max Payne's, get a copy of the game, install the editors, then load the particle editor, its INSANE! its got spline paths for almost all attributes, time scrubbing etc.
Its used for making thier funky slow motion muzzle flash thingy..
Basically, its the most complete particle engine Ive seen.
Do that melv! do that!!! :)
Phil.
08/30/2002 (12:35 am)
The current PE is pretty dumb. Its missing LOTS of things I'd like, like path following for emitters, attaching emitters to objects in a simple way etc.If you want the "HOLY GRAIL" of particle engines, I think you simply must look at Max Payne's, get a copy of the game, install the editors, then load the particle editor, its INSANE! its got spline paths for almost all attributes, time scrubbing etc.
Its used for making thier funky slow motion muzzle flash thingy..
Basically, its the most complete particle engine Ive seen.
Do that melv! do that!!! :)
Phil.
#17
I love the fact there are different particles for different material surfaces.
Freedom Force is another game with cool particle effects.
08/30/2002 (1:14 am)
Ill second Max Payne has having one of the best particle effects ever.I love the fact there are different particles for different material surfaces.
Freedom Force is another game with cool particle effects.
#18
@Phil: I've got Max Payne but I've never played with the editors, thanks for that tip. Oooh, a challenge, now you've done it. I god damn thrive on those. ;)
Thanks to everyone for participating in this thread, keep coming on those thoughts.
- Melv.
08/30/2002 (2:29 am)
@Alexander: I think those donations are going to the wrong address. Better start sending them to my work address instead. I'll get my penny jar ready on my desk there. ;)@Phil: I've got Max Payne but I've never played with the editors, thanks for that tip. Oooh, a challenge, now you've done it. I god damn thrive on those. ;)
Thanks to everyone for participating in this thread, keep coming on those thoughts.
- Melv.
#19
08/30/2002 (9:08 am)
hmmmm is freedom force out? i thought it was still on hold
#20
I have yet to try it out, still to bussy playing the game ;)
08/30/2002 (9:10 am)
I heard that NWN had a wicked smooth PE in its DM editor.I have yet to try it out, still to bussy playing the game ;)
Torque 3D Owner Frank Bignone
Darkhand Studio
- shape (small triangle)
- collision detection
- physics (i.e. for the collision detection in order to bounce the particle, be attracted by a force field, ...)
- rotation of shape + motion blur (i.e car headlights)
I should add that i did not play a lot with the current particle engine, so maybe this can already be done :)