It depends on the usage. Lua itself is very slow, so it is impossible to handle each single particle on the cpu (as the engine it does), instead it uses static display lists and runs a shader on it. So a modern GPU (~7600) is able to render >70k particles in realtime. The only problem is when you create many effects, each would be handled seperatly in lua (more cpu work) and slows down the whole rendering. Additional, LUPS doesn't z-sort the effects yet, instead it has a layer tag, so you need 2-3 layers for a fire effect (i.e. one for the core, one for the corona/flame and one for the black smoke).smoth wrote:would you say that this newer lua based method is more fps efficient?
In the case of fire it depends on the emitter, if it is static (doesn't change its pos like buildings) and its target doesn't move (i.e. it doesn't try to target a moving unit) I can write a special (self-repeating) class, which would be use only 2-3 effects per unit (more than one 'cos you still need multiple layers).
In the case of moving units (as the current fire effect in CA), you would have to update the emiter pos. But 'cos LUPS uses a display list you can't emit a new particle from a different point (you only can move the whole effect). To do so you would need to save all particle's positions somewhere accessable from the shader (-> float texture), this is what the "100k particles engine" did. But we don't have something like that in LUPS, so we have to emit new effects in any interval (->remember, LUPS becomes slower the more effects you use).
Finally, LUPS isn't ideal to render fire effects atm, but it supports a lot of things the engine doesn't and some most haves for fire effects (particle/effect rotation, runs unsynced, you don't need to restart spring if you want to test a modified effect, a lot of sphere and bursts classes, santa hats
, ..).
