TX2D 3.1.5 Beta - Particles not properly rendered
by Giuseppe De Francesco · in Torque X 2D · 06/07/2010 (11:53 am) · 7 replies
Build: 3.1.5 Beta
Platform: any
Target: runtime
Issues: When a particle emitter is off camera the generated particles are not rendered even if they are supposed to be in the camera range. When the camera reaches the emitter then all of the sudden all the particles appear on screen: quite a bad effect indeed.
Steps to Repeat:
1. Create a level featuring a wide scrolling area (Geometry War style)
2. Put the player spawning point in the center of the screen and mount the camera on it
3. Create off camera a particle effect with a wide range so that the resulting particles should also invade the camera area without moving the player.
4. Run the game. No particles are rendered. Now move the player toward the particle emitter and see what happens when the emitter is within the camera range.
Suggested Fix: See Commit Revision 26 on my SVN repository for existing fix.
Platform: any
Target: runtime
Issues: When a particle emitter is off camera the generated particles are not rendered even if they are supposed to be in the camera range. When the camera reaches the emitter then all of the sudden all the particles appear on screen: quite a bad effect indeed.
Steps to Repeat:
1. Create a level featuring a wide scrolling area (Geometry War style)
2. Put the player spawning point in the center of the screen and mount the camera on it
3. Create off camera a particle effect with a wide range so that the resulting particles should also invade the camera area without moving the player.
4. Run the game. No particles are rendered. Now move the player toward the particle emitter and see what happens when the emitter is within the camera range.
Suggested Fix: See Commit Revision 26 on my SVN repository for existing fix.
About the author
In the software eng. field since 1981, in charge of R&D during last 10 years. IEEE Senior Member (and volunteer).
#2
What is not in for sure: Commit 26 (this bug) and all the replacement of the "foreach" loops with "for" loops.
Maybe Derek might be more accurate, I'm still checking ;)
06/07/2010 (1:54 pm)
@ Henry: I'd say most of it, almost all till Commit 25 I think, but I've just checked at random. What is not in for sure: Commit 26 (this bug) and all the replacement of the "foreach" loops with "for" loops.
Maybe Derek might be more accurate, I'm still checking ;)
#3
06/25/2010 (9:56 am)
This is still a bug in the new beta. 
#4
06/25/2010 (3:43 pm)
Logged as TQA-432. 
#5
So this is not a bug... the engine is working as intended.
The current recommended way to fix this issue is to set the T2DParticleEffect.Size big enough to cover the area that the particle effect will emit particles.
@Pino
I saw your fix and by what i saw your fix does the same sort of thing i suggest above, but does it at the T2DSceneGraph level. Your doing a second cull of the scene using an inflated rectangle larger than the screen to capture particles that might have been culled.
IMO this fix is less useful than just setting the the size of the T2DParticleEffect.
The only other feature we could use here is a flag on the T2DParticleEffect which makes it optionally recalculate its size automatically based on the actual particles emitted. It would be alot more expensive than setting a fixed size, but might be useful for a few emitters in an scene.
07/02/2010 (10:36 am)
Hey guys.So this is not a bug... the engine is working as intended.
The current recommended way to fix this issue is to set the T2DParticleEffect.Size big enough to cover the area that the particle effect will emit particles.
@Pino
I saw your fix and by what i saw your fix does the same sort of thing i suggest above, but does it at the T2DSceneGraph level. Your doing a second cull of the scene using an inflated rectangle larger than the screen to capture particles that might have been culled.
IMO this fix is less useful than just setting the the size of the T2DParticleEffect.
The only other feature we could use here is a flag on the T2DParticleEffect which makes it optionally recalculate its size automatically based on the actual particles emitted. It would be alot more expensive than setting a fixed size, but might be useful for a few emitters in an scene.
#6
Actually there is a difference which makes the resizing of the T2DParticleEffect not viable: one can prepare an effect where the particles are generated all over the Area (Area mode instead of Point mode) this because i.e. there is a surface in flames. But the life (thus the distance covered) of the particles is way bigger than the size of the Area Effect, still we need to render those particles even if the actual effect is not in the camera range.
Because of the above use case (and many others) IMO this is a bug and it need a fix allowing the particles to be rendered outside of the related scene object, all over the particles' life and speed.
~Pino
07/02/2010 (11:57 am)
@Tom:Actually there is a difference which makes the resizing of the T2DParticleEffect not viable: one can prepare an effect where the particles are generated all over the Area (Area mode instead of Point mode) this because i.e. there is a surface in flames. But the life (thus the distance covered) of the particles is way bigger than the size of the Area Effect, still we need to render those particles even if the actual effect is not in the camera range.
Because of the above use case (and many others) IMO this is a bug and it need a fix allowing the particles to be rendered outside of the related scene object, all over the particles' life and speed.
~Pino
#7
I used to lead the fx team at Turbine before I became a designer so have tons of experience with various particle systems.
My demo if your curious: http://www.mhoesterey.com/demo/Demo.AVI
Most of the particle systems I have used in a real time environment calculate the bounds of the particle at build time when the particle system is saved.
Ie... (Life + maxLifeVarience) * maxPossibleSpeed = maxDistance;
Emitter.DrawSize = new Vector2(maxDistance, maxDistance);
Having this calculation done during a build or save process would be ideal. As pino says though the draw distance of the particle needs to be decoupled from size due to the way you have implemented area particles.
Regardless of what the solution is I know I need it to be efficient due to tight performance restrictions.
Please whatever solution fixes this problem it can not make the performance any worse, or I at least will not be able to use it.
Right now particles have two major performance issues.
1) adding persistent emitters vastly increases load time. I don't know exactly why but I found that adding around 12 persistent particle emitters will quadruple my load time. (though I think this has to do with the particle system performance)
2) Particle systems are much more costly then I would expect. MMO's have crazy performance restrictions. Even so our particle budget on the last MMO I worked on allowed for 150 particles per effect with a worst case of 30 emitters on screen. (4500 total particles at 30+ batches + all characters and environments) TorqueX currently chokes on number far below that. In fact Torque tends to choke at around 800 particles.
I have ripped out 90% of the persistent emitters in my game and toned most of the fx back to use between 10-25 particles on average and still the particle systems eat up a huge part of my processor time. So I ask that when searching for a solution you guys take a look at whats there and see if any performance gains can be had :)
Thanks. Its nice to see so much work being done on TorqueX :).
07/04/2010 (9:41 am)
@Tom. I used to lead the fx team at Turbine before I became a designer so have tons of experience with various particle systems.
My demo if your curious: http://www.mhoesterey.com/demo/Demo.AVI
Most of the particle systems I have used in a real time environment calculate the bounds of the particle at build time when the particle system is saved.
Ie... (Life + maxLifeVarience) * maxPossibleSpeed = maxDistance;
Emitter.DrawSize = new Vector2(maxDistance, maxDistance);
Having this calculation done during a build or save process would be ideal. As pino says though the draw distance of the particle needs to be decoupled from size due to the way you have implemented area particles.
Regardless of what the solution is I know I need it to be efficient due to tight performance restrictions.
Please whatever solution fixes this problem it can not make the performance any worse, or I at least will not be able to use it.
Right now particles have two major performance issues.
1) adding persistent emitters vastly increases load time. I don't know exactly why but I found that adding around 12 persistent particle emitters will quadruple my load time. (though I think this has to do with the particle system performance)
2) Particle systems are much more costly then I would expect. MMO's have crazy performance restrictions. Even so our particle budget on the last MMO I worked on allowed for 150 particles per effect with a worst case of 30 emitters on screen. (4500 total particles at 30+ batches + all characters and environments) TorqueX currently chokes on number far below that. In fact Torque tends to choke at around 800 particles.
I have ripped out 90% of the persistent emitters in my game and toned most of the fx back to use between 10-25 particles on average and still the particle systems eat up a huge part of my processor time. So I ask that when searching for a solution you guys take a look at whats there and see if any performance gains can be had :)
Thanks. Its nice to see so much work being done on TorqueX :).
Torque 3D Owner Henry Shilling
Smokin Skull