Hello! I am new to Babylon and am making some very simple particle systems. I can’t figure out how to have my particles inherit the velocity of their emitters. I read that is possible for sub-emitters to inherit the velocity of their parent emitters, but I can’t figure out how to do that for regular particle systems.
Secondly, I am curious about prevening stepping in the simulation. Traditionally, I would band-aid that up by emitting ALONG the velocity of the emitter for the previous frame so that particles are emitted along the entire path of the emitter over DeltaT. But I don’t see that option here.
Another, more heavy-handed approach I’ve used is to substep the simulation so that the particle solver runs N times per frame, each time over DeltaT/N instead of just once over DeltaT. Is this possible in Babylon?
Thanks for putting up with these beginner questions, I couldn’t find them addressed anywhere else. Here is a representative basic particle system that I would like to use those techniques on:
Hey there! The clone does not work in your PG because there is a PerlinNoise (which is not cloned if you not ask for it) in ps1.
You have to call clone that way (third parameter to true):
const ps2 = ps1.clone("ps2", sphere2, true);
Regarding inheriting velocity, what do you mean? The emitter has not really a velocity property, you are moving it manually per frame,so I’m not sure to grasp what is your ask
As you move the emitter, you can change the sphereEmitter.direction1 and direction2 to point toward the direction vector of your emitter. This way the particles will be emitted toward that direction
So you want to run more particle simulation than rendering frames right? It is technically feasible by calling update but only on CPU particles. GPUParticleSystem are running fully on the GPU so you cannot force the update without a render.
I wonder why you would want more update though? What is your use case?
Great, I was suspecting that might be the solve for inheriting the emitters velocity.
Yes, more simulation frames than rendering frames for the case of very fast moving emitters where the timestep is too big and leaves gaps.
I am still wondering about emitting ALONG the velocity (so imagine that instead of emitting exactly at the sphere every frame we emit along it’s path from Frame N to Frame N+1, thus filling in those gaps (albiet linearlly). I see there is a functoin I can override that calculates the position of the emitted particles, perhaps I can use your oldSphere1Position trick in there to scatter points along the trail.
(As an aside, I also realized that since the motion is analytical (pos = sin(t)) I can actually take the true derivative (vel = pos’ = sin(t)’ = cos(t)) instead of doing a linear approximation… I THINK… but I highly doubt it will make that much of a difference! I just tried your sandbox with the linear approximation to velocity and it feels and looks great once I crank up power. (I’m still learning the difference between power and direction, seems like they are both unnormalized so I should just sum them).
Thanks! Gonna investigate that startPositionFunction(), looks like it works for GPU systems… I think if I get in there and grab this frame’s sphere position and grab last frame’s sphere position and scatter my points along that line segment it should help a lot with hiding the stepping in my simulation.