particle effects introduce great lag into the game
by Pascal Stiefel · in Torque Game Builder · 07/29/2011 (2:25 pm) · 8 replies
I've been learning about particle effects and placed a few heavy smoke effects around the level
I noticed this slowed the entire game down to be next to unplayable.
Also even when they're far offscreen the lag remains the same meaning they're still calculated.
How can i increase performance of particle effects
and how can i make it so they dont get calculated when off screen ?
I noticed this slowed the entire game down to be next to unplayable.
Also even when they're far offscreen the lag remains the same meaning they're still calculated.
How can i increase performance of particle effects
and how can i make it so they dont get calculated when off screen ?
#2
So im trying to make a game with Torque 2D and Platformer kit, im placing a smoke effect next to a camp fire at the beginning of the level.
This makes the entire level lag and stutter, it would be fine when it would just happen when the effect is actually onscreen but it effects the ENTIRE level from start to finish.
It simply doesnt make sense that they use so much processing power when the camera doesnt even see them and im 1000 miles away from the actual effect.
This is not good, this is BAD.
It would be like as if a 3D engine would try to draw all poygons of a level at once.
What's this doing in a professional engine like Torque2D ?
I would really like to disable them when the camera does not see particle effects.
07/30/2011 (9:51 am)
Thanks for the tips about enhancing performance of particle effects.So im trying to make a game with Torque 2D and Platformer kit, im placing a smoke effect next to a camp fire at the beginning of the level.
This makes the entire level lag and stutter, it would be fine when it would just happen when the effect is actually onscreen but it effects the ENTIRE level from start to finish.
It simply doesnt make sense that they use so much processing power when the camera doesnt even see them and im 1000 miles away from the actual effect.
This is not good, this is BAD.
It would be like as if a 3D engine would try to draw all poygons of a level at once.
What's this doing in a professional engine like Torque2D ?
I would really like to disable them when the camera does not see particle effects.
#3
07/30/2011 (10:52 am)
@Pascal - I haven't used the base Torque 2D engine in a while, so I will have to see if that functionality is exposed. If not, then I can provide C++ source code that will provide the culling of particle effects outside of the camera view. This will require you to recompile the engine, but it should be very simple if you copy and paste what I provide. How does that sound?
#4
I'm looking forward to this.
07/30/2011 (11:40 am)
That would be awesome =)! It's a little too overwhelming to write such a system by yourself as a Torque beginner. Not being able to use particle effects would be sad as they look quite nice indeed. I'm looking forward to this.
#5
TGB, just like any other program, is stupid and have no idea of what you're trying to accomplish. That's what script programmers are for, to tell what and when engine should do. You've ordered the game to create particle effect, so it is there and will stay until you give an order to remove it.
07/30/2011 (11:43 am)
@Pascal You just have to disable effects (and everything else) when you don't need them.TGB, just like any other program, is stupid and have no idea of what you're trying to accomplish. That's what script programmers are for, to tell what and when engine should do. You've ordered the game to create particle effect, so it is there and will stay until you give an order to remove it.
#6
And unless the effect keeps track of the bounding volume of its particles, the culling might also be quite inaccurate.
One way of the other, you may end up with "disappear/respawn" artifacts if the player keeps moving left/right.
I'd say as Rpahut... the engine provides functionalities, but only the user can actually describe the logic of what is expected.
Say you have a fire with a big smoke effect drifting to the right ; if the player stands on the right of the fire, sufficiently far away from the source emitter so that it is not in the camera view but the particles are... What do you expect to happen to the particles ?
- the particles continue to spawn ; as the volume of the effect is in your view. (in which case the culling logic needs to be slightly more complex)
- the particles disappear, because the emitter is outside the view ?
- the exising particles continue to fade but new ones aren't generated as the emitter is outside the view ?
Now, if you go right until the whole effect is outside the view, and come back, in a perfect world you should be able to see the particles before the emitter is in the view. Is this what you would expect ?
Basically, there's no perfect answer to this question, as the logic needs to be define on a case by case. If you look carefully at commercial games, you will notice that most AAA 3D titles have very similar issues. It's all about defining the balance that is right for your game.
In this situation, the simplest approach would by to use a trigger zone to manually control when the effects should be enabled/disabled, to minimise the artifacts while keeping the resource/cpu usage to a decent level.
I don't know how things work in Torque ('haven't used that module yet :) ), but when programming my own effects I usually use the particle bounding volume + safe zone as culling test. I then freeze the existing particles, and when they need to reactived, I do a quick discard (lifetime & elapsed time), start a time-sliced advance (fast forward for existing particles to catch up), and a cheap approximate re-pop of the volume. This prevents most artifacts from being visible by the player, while not consuming much resources.
Nevertheless, I wouldn't expect Torque or any other engine to support this logic straight out-of-the-box, as this is very specific to *my* needs. As long as the core functionalities are there, and something similar can be achieved with script/code, it should cover everything people need.
07/31/2011 (12:31 pm)
Additionally, and depending on your game, you may NOT want to disable a particle system when the emitter is not in the camera view (e.g. system used a background effect).And unless the effect keeps track of the bounding volume of its particles, the culling might also be quite inaccurate.
One way of the other, you may end up with "disappear/respawn" artifacts if the player keeps moving left/right.
I'd say as Rpahut... the engine provides functionalities, but only the user can actually describe the logic of what is expected.
Say you have a fire with a big smoke effect drifting to the right ; if the player stands on the right of the fire, sufficiently far away from the source emitter so that it is not in the camera view but the particles are... What do you expect to happen to the particles ?
- the particles continue to spawn ; as the volume of the effect is in your view. (in which case the culling logic needs to be slightly more complex)
- the particles disappear, because the emitter is outside the view ?
- the exising particles continue to fade but new ones aren't generated as the emitter is outside the view ?
Now, if you go right until the whole effect is outside the view, and come back, in a perfect world you should be able to see the particles before the emitter is in the view. Is this what you would expect ?
Basically, there's no perfect answer to this question, as the logic needs to be define on a case by case. If you look carefully at commercial games, you will notice that most AAA 3D titles have very similar issues. It's all about defining the balance that is right for your game.
In this situation, the simplest approach would by to use a trigger zone to manually control when the effects should be enabled/disabled, to minimise the artifacts while keeping the resource/cpu usage to a decent level.
I don't know how things work in Torque ('haven't used that module yet :) ), but when programming my own effects I usually use the particle bounding volume + safe zone as culling test. I then freeze the existing particles, and when they need to reactived, I do a quick discard (lifetime & elapsed time), start a time-sliced advance (fast forward for existing particles to catch up), and a cheap approximate re-pop of the volume. This prevents most artifacts from being visible by the player, while not consuming much resources.
Nevertheless, I wouldn't expect Torque or any other engine to support this logic straight out-of-the-box, as this is very specific to *my* needs. As long as the core functionalities are there, and something similar can be achieved with script/code, it should cover everything people need.
#7
I think it's possible to counter the visual artifacts problem by making the box which determines the automatic cullling much larger than the actual camera, so the particle effects get loaded and unloaded about 5 seconds before the player gets to see them.
I beleive that an engine that calls itself the most advanced 2d game making engine on the market should include a system that optimizes this out of the box. It's not exactly user friendly when one has to hire a script programmer just to be able to use particle effects.
So basically i would have to set up a vertical trigger area, reaching from ground to sky, one for on and one for off that checks wether the player passes through it and if so it will enable/disable a particle effect via %object.setEnabled(0) ?
I see this working beautifully in theory but i'm unable to programm something like this with my current torque programming skill.
08/01/2011 (7:01 am)
I can see that an automatic particle culling function might produce visual artifacts. Its still better than having the entire level be nearly unplayable because of the lag introduced by one particle effect.I think it's possible to counter the visual artifacts problem by making the box which determines the automatic cullling much larger than the actual camera, so the particle effects get loaded and unloaded about 5 seconds before the player gets to see them.
I beleive that an engine that calls itself the most advanced 2d game making engine on the market should include a system that optimizes this out of the box. It's not exactly user friendly when one has to hire a script programmer just to be able to use particle effects.
So basically i would have to set up a vertical trigger area, reaching from ground to sky, one for on and one for off that checks wether the player passes through it and if so it will enable/disable a particle effect via %object.setEnabled(0) ?
I see this working beautifully in theory but i'm unable to programm something like this with my current torque programming skill.
#8
As a programmer I tend to put my additional stuff and logic in the engine, so I'm not too familiar with the script side of things and can't really comment on that, but that's definitely the kind of simple approach I would consider for your problem.
Maybe an abstract scene-object, with a rectangular shape and a physics callback to check when the players enter the zone (I'm saying physics to benefit from the broadphase, but there may be more optimal ways ? With the groups set properly so that it checks only for the player, the cost should be negligible) would do what you need ? You then only a line in your script callback to enable or disable the effects.
I would recommend looking at the scripting tutorials related to platform games and physics, surely checking that an object is in a zone is something very common and trivial to do !
Someone more familiar with the scripts and scene objects can surely be more helpful than I am :)
Good luck with your particle effect ! If it's non-trivial with your current torque programming skills, I'd say focus on the gameplay first ; by the time you have a functional prototype of your game, you'll surely have learnt enough to come back to these smaller things and solve them with ease.
08/02/2011 (11:36 am)
Hi there !As a programmer I tend to put my additional stuff and logic in the engine, so I'm not too familiar with the script side of things and can't really comment on that, but that's definitely the kind of simple approach I would consider for your problem.
Maybe an abstract scene-object, with a rectangular shape and a physics callback to check when the players enter the zone (I'm saying physics to benefit from the broadphase, but there may be more optimal ways ? With the groups set properly so that it checks only for the player, the cost should be negligible) would do what you need ? You then only a line in your script callback to enable or disable the effects.
I would recommend looking at the scripting tutorials related to platform games and physics, surely checking that an object is in a zone is something very common and trivial to do !
Someone more familiar with the scripts and scene objects can surely be more helpful than I am :)
Good luck with your particle effect ! If it's non-trivial with your current torque programming skills, I'd say focus on the gameplay first ; by the time you have a functional prototype of your game, you'll surely have learnt enough to come back to these smaller things and solve them with ease.
Employee Michael Perry
ZombieShortbus
If you know the object ID, you can enable and disable it at will using %object.setEnabled(0). The tricky part is knowing when to do this. We have this as an "optimization" in iTorque 2D, but it's not fully implemented.