I have a feeling I’m doing something kind of stupid (almost constantly) but specifically, I am having two problems
Is it possible to change the Z layer of particles to be behind some game objects, and in front of others? I believe it isn’t.
I have a particle fx shooting downwards. When I animate its GO to fly up, the particle FX start to shoot up. I have checked by slowing down the movement a lot, but even very slow, it happens ver clearly. Can anyone tell me why this is, and how to get the particles to always fire in the same direction?
I believe the second problem was cause by setting the emitting space to “world”.
I am now on to my next question. Is it possible to change the “initial size” of a particle emitter dynamically? I understand it’s possible to change the tint using particlefx.set_constant. But are the other settings changable?
Regarding the first question, the reason that the particles are rendered on top of the sprites, is that the particle material is using the render tag “particle”, and if you check your render script, you’ll see that the particles are rendered after the “tile” tag (which is used by the sprite material etc).
So, if you create a copy of the particle material, into your project, and change the render tag to “tile”, and use that material instead of the default one, you should get the particles rendered “in between” the sprites.
As for what properties you can change, I’m afraid you cannot change those settings at runtime. You can however set the spread of the value.
What effect are you trying to achieve?
The effect is that the jet pack is hovering, and then it accelerates very quickly as the player shoots into space. So, I’d like a different kind of size/speed/particle life depending on whether the player is hovering or shooting into space. Spread would actually be very useful for another part of my game when the player lands, so that would be cool.
Tomorrow I will investigate what you have suggested re: materials. Would that mean I could control the Z layer by changing the Z co-ordinate of the emitter? That would be perfect.
Be aware that you can easily lose the performance possible with keeping ParticleFX in its own render predicate the more particles you have. ParticleFX is really good for certain kinds of pretty and impressive effects but not for more dynamic systems like what you seem to want.
For your use case, I would code a simple particle system based on GOs with sprites attached as the particle images. You would need a particle system manager to keep track of the particles, then re-position the particles based on the kind of behavior you want. Keep the GOs in a queue to recycle as particles hide / are created. Recycle the oldest living particles when you want to “generate a new particle” but already have the max particles you want alive at once alive. Then you can impact the behavior of individual particles based on what they are being emitted from. I suggest you attempt to implement a particle system like this first completely on your own, and then look up other solutions to learn from. Start simple, then you can implement more features found in other particle systems. If you put any game dev tool/language together + particle system in search you can find endless implementations. I have one for Defold projects but have not released it yet.
Interestingly, in the factory docs (all the way at the bottom), they specifically say not to recycle objects, as opposed to deleting and respawning them, for performance reasons. That surprised me, but I assume they have some basis for writing that.
I have yet to actually test this for real still but have been wanting to to see real effects of recycling vs creating/destroying at a large scale. The pooling is a general practice used in other tools which do not pre-generate things in advance. You set the upper limits in your game.project, but there are hard upper limits too, and you may want to lower the values depending on project. Anyone who has tested this can for sure say results? Anyone on engine team can explain the technical reasons behind performance argument to not pool at all? I’d guess because of destroying (but not actually destroying) you can then have less objects to loop over vs keeping them alive? Even if they do not have scripts attached they still have some performance impact?
Because Defold prepares everything in advance it maybe is not an issue to create/destroy as needed, but you’ll still need to work within the upper limits of what’s maximum allowed, performance you want.
Still you should keep a max number of particles allowed alive at once in your custom particle system, and remove from being active oldest particles in a group when you are at your set limit and need to spawn more so that your particle systems do not disrupt GO generation of other parts of your game.
@ross.grams The basis would be that when you delete and respawn, we recycle under the hood (native code, native memory, etc). The housekeeping needed for recycling in the lua layer is not guaranteed to give you a perf gain, but could even be a perf loss.
I did a small test where I either created or reused 2500 game objects containing a single sprite each.
When creating: factory.create() and go.animate(id, …)
When reusing: msg.post(id, “enable”), go.set_position(pos, id) and go.animate(id, …) + Lua table operation
I measured (using socket.gettime()) from time of creation to the update a couple of frames later. There was hardly any difference at all even with the extreme case of creating/reusing 2500 game objects in a single frame.
@britzl that’s great news, I appreciate that you did that and posted your results. I’ll investigate changing the material when i get a chance. My jetpack actually uses relatively few particles (I believe around 30 on screen at once) so i expect that will work for me.
Pkeod thank you for your contribuciones. I spent quite a long time learning about the particle.fx and by the time I had realised about the rendering, I was fatigued.
So, if you create a copy of the particle material, into your project, and change the render tag to “tile”, and use that material instead of the default one, you should get the particles rendered “in between” the sprites.
I’m trying this within a GUI but it’s not working. Tried changing the tag to -gui- and -tile- but still the particles are being drawn on top.