[SOLVED] Correct way to remove particle emitter without instant particles disappear

Troubleshooting effects
1

What am I doing:

  1. create arrow node
  2. create projectile geometry (fire arrow sprite in my case)
  3. attach it to arrow node
  4. create particle emitter (red ascending squares - flame in retro style)
  5. attach it to the arrow node.
  6. attach arrow node
  7. move this node every frame towards the target
  8. when arrow reaches the target, detach arrow node from the scene

Looks nice, but all particles that in air at the movent of node detach disappears instantly.

How to only stop their generation and let existing particles disappear in natural way?

PS: solution with deferred emitter detaching by timer and another workarounds are known. I’m looking for a better way.

2

Assuming you’re using com.jme3.effect.ParticleEmitter, try emitter.setParticlesPerSec(0f);.

1 Like
3

That’s not going to fix the problem.

Simplified version of the question: “when I remove a node from the scene, I can’t see the children anymore”

So either separate the children from the node (always or at the end) or don’t remove the node from the scene until you are ready for the children to be gone.

Those are the only options… the trick is only in making it look like you want.

1 Like
4

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.

5

Sure, it will help to enhance my straight-forward solution with workaround that keeps emitters aside of projectiles. But I tried to avoid it.

6

But an important one.

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.

2 Likes
7

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.

2 Likes
8

why not just detach it after some time? (time of particle life max)

and stop throw new particles ofc, when it trigger

9

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 :slight_smile: 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.

10

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.

11

im just used to make some wrapper over engine anyway. its like using LWJGL itself is not enough, here seems similar. Provided lower API still (except if you use community Simsillica/etc).

Most things can be done in ECS, but things like this one are exceptions.

Well, it have advantages, because like Paul said, it allow freedom if you want make some crazy own solutions.

12

Or like popup text in the HUD, when we move the object we want the text to move in the HUD… but wait, that can’t work. It has to be in a separate hierarchy. Just like particles.

Your quibble is the fact that the emitter and the geometry are the same. If they are different it becomes tricky to setup… who adds the geometry? To where?

My point is that if you want the emission to follow the arrow and still be separate geometry in the scene then it’s only a few lines of code:

myParticles.addControl(new AbstractControl() {
    public void controlUpdate( float tpf ) {
        spatial.setLocalTranslation(myArrow.getLocalTranslation());
    }
});

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.

1 Like
13

I think the whole gist of the situation is that if you remove a particle emitter you also remove the particles.

If you approach the situation differently and use the particle as an effect that removes itself you won’t have the issue.

1 Like
14

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.

15

thanks for hint!