I’m removing only emitter from scene. not particles.
The fact that particles are rendered by emitter is just an implementation detail.
I do not understand why you position this limitation as some some logical, explicit and desired, because it’s very common to leave particles disappear naturally in games (actually I cannot remember any game where some trail of rocket disappears instantly after rocket explosion or something similar - such things always looks like a bug).
So it’s fair to expect out-of-box support of such feature from game engine and ask authors about it before implementing workaround with “pool of emitters” and “somehow sync emitter position with arrow position” or somthing similar.
Note that I do not complain that engine doesn’t have such feature - it’s ok to have some limitations, especially for enthusiastic driven software. I just against positioning limitations as features.
Let’s say we implemented as you suggest, there would be an Emitter and an EmitterGeometry. So the emitter spews the particles and the emitter geometry holds the mesh with the particles in it. All the emitter is doing then is controlling where the particles start and all of the actual work has been moved to EmitterGeometry.
…then we are back to where we started as the emitter serves little purpose and if you remove the EmitterGeometry then all of the particles still go away. So if you made the mistake of attaching EmitterGeometry to a node that gets removed then we’d still be back to a post like this.
JME works at a lower level than that. These are the primitives you use to build up the visualiztions of your game objects. They aren’t your game objects. Spatials are not game objects. We are not operating a high level like “engines” like Unity where all you get are game objects, essentially. JME does not define your game objects for you which gives you the freedom to use POJOs or an entity system (recommend) or whatever else.
So if you want your particles to exist in the “World” despite the state of some other spatial then the world is the parent of the particle emitter. Move the emitter when the game object moves. If your game object also has a model then so be it… move that spatial with the game object, too. The life cycle of the two can be controlled however you want at that point.
And if you really want to continue thinking of Spatials as game objects then you can do that, too. But the particle geometry should still be parented to world… then in five seconds you can add a control that gets it to follow your arrow.
I solve this issue in my project by creating a custom class called AfterEffect for managing lingering particles effects - this class has a method to pass over any number of particle emitters which are stored in a list, and the class has methods for fading the emitters out smoothly in its update loop, either by shrinking them or reducing the alpha value of both the start and end color until they are fully transparent, and then it waits to detach the emitter from the rootNode until it is no longer visible.
thanks for explanation of your vision. actually, I haven’t suggested exactly this solution. I believe it would be implemented in explicit and non-error-prone way (I do not demand it - I just asked and received enogh answer, from this point this discussion is just threoretical discussion).
I do not think about spatials as about game world objects Actually I do not think so even about GameObjects in Unity. Spatials in jME, GameObjects in Unity - that’s just a way to organize scene in hierarchical way with cascade transformations and convenient structural manipulations. Game world model is better to keep separate and I keep it separate.
when we want some object to inherit transformation of some object - we attach it to it, if not - we attach it to upper level node. the same with structural manipulations.
According this logic, emitter surely may be intended to inherit both transformation and structure - when we move hand with torch, source of flame should be moved too.
But we can’t say the same about particles - they use emitter only as an initial point and do not expected to inherit its transformation dynamiically. So visually it behaves like emitter is an object that just influences to some geometry that is not managed by this scene branch and it’s very inconsistent with the fact that all particles disappear instantly with detach of emitter.
because it’s more code. and this behavior is almost completely the same in all games. It’s fair to expect that it may be implemented in engine and it’s fair to ask authors (after reading docs) before doing it by hands.
Now, if you want to complain about how there is no control that will automatically have one node follow another like this then I’m all ears. I think it’s missing… I’ve just never needed it because in an entity-system based games, these are all totally separate anyway.
If I put popup at the same scene branch as button, it will not move with cursor (or another popup aligning source) automatically and it will be obvious.
But particles, unlike popups, will visually behave like they are not at the same scene branch automatically even if they are at the same branch.
that’s not eough because we also need to manage lifecycle of emitter and arrow separately.
I’m using some sort of ECS (my vision of this concept) in my game too. Could you please poke me to the code of your game where you use particles (link to repo and class name would be enough). It’s very interesting to know how it may be done in different manner.
PS: I see, in Zay-ES there are particles in example, so I’ll watch it there. No more need in code pointers.