Noise particle cloud following and orbiting a path

repro: https://playground.babylonjs.com/#R1JWLA#33

Hi, I’m trying to make a dust cloud that follows a path, like a nebula, I think? The dust cloud should orbit (I think?) around the path as well. I’m not sure I’m describing it well. :confused: How can I access the noise texture data in the updateFunction and use it to set the particle position/direction ? Or am I going about it the wrong way ?

I would prefer not having to use updateFunction if there is a built-in method. But I don’t see anything in the docs so far. Any help would be much appreciated.

Here is one possible way https://playground.babylonjs.com/#R1JWLA#34 you will need to play with the parameters.

2 Likes

Yes, @JohnK
This is in essence the method I have used in my scene’s new year’s event:

Project Snowball alpha (0.8.2.5.4a R.12312020)

Press '< T > to start fireworks. '< T > to cycle through fireworks effect
Press '< Z > to start the stars animation fireworks. '< Z > to cycle through stars effects.

Conclusion: Move your emitter (with an anim or registerBeforeRender or both), move it to your points (or pointmap). Play with the values of emit rate and duration (and others) to fine tune the effect. It works, it definitely works.

Hang on, I think I have an even better example for your case. Let me see if I can find. I recall that if the emitter object follows a path you can make the particles follow even better… it’s from the PG examples somewhere… it’s likely to use registerBeforeRender…

yup got it, check this one:

https://playground.babylonjs.com/#36UHXZ#34

3 Likes

Hey guys, thanks for all the help. But its not what I need (I was afraid of this as I’m bad at describing the problem). I don’t want the emitter to move, rather it should just spew out the particles and the particles itself will move around the path. Think of it as diffusion/brownian motion/asteroid belt ?

Maybe it is possible to use updatable SPS inside the given shape?

1 Like

Except I don’t need solid particles, 2d is fine.

I got half of it right, I think:
https://playground.babylonjs.com/#R1JWLA#35

But switching tabs will foul up the updates, I wonder why? hrmmm…

That’s because you update the position of the particle based on the direction on the curve, but when switching tab you will get a big value for this._scaledUpdateSpeed (depending on the time you spent on the other tab) which will break the computation.

One way to deal with this problem is to not allow this._scaledUpdateSpeed to become too big. For eg, you can limit its value to 1/10:

https://playground.babylonjs.com/#R1JWLA#37

Another solution would be to update the position of the particle by lerping between the two closest points of the curve. This way, you are sure the particles will stick to the curve. To keep the initial distribution of the particles, you can store the difference of the starting position of the particle with the first point of the curve and apply this difference after you compute the new particle position:

https://playground.babylonjs.com/#R1JWLA#36

Nice effect by the way!

3 Likes

Awesome and thanks ! After some testing, I found the 2nd method will cause breaks in the particle stream when switching tabs b4 1 revolution is completed.

Question: is this._scaledUpdateSpeed equal to the updateSpeed property of the particle system ? If so, I can simply reset it. I suspect there is accumulation of the updateFunction every frame resulting in sudden large values of _scaledUpdateSpeed when switching tabs…hmm.

Also, when I tested switching tabs in PGs from the doc (eg: https://playground.babylonjs.com/#V07WF8#10), I don’t see large changes in position (perhaps I need to log), hmm…

_scaledUpdateSpeed is computed as:

this._scaledUpdateSpeed = this.updateSpeed *
  (preWarmOnly ? this.preWarmStepOffset : this._scene?.getAnimationRatio() || 1);

animationRatio is computed as the ratio between the default fps (which is 60) and the current fps. The problem when you switch tab is that the current fps computed when you switch back to the first tab is very low, because from the engine standpoint a lot of time has spent since the last frame (it’s the time you spent on the other tab) because the browser “freezes” the javascript code when a tab is not visible.

To help in this matter, there’s a maximum deltaTime between two frames that is set by default to 1000 through the Scene.MaxDeltaTime constant. It explains why you don’t really see a difference in the doc PG (that and the fact the particle system is slow, so the particles don’t travel a lot of space in 1s).

If you set a bigger value for Scene.MaxDeltaTime you will see some artifacts when switching to another tab for several secondes and coming back:

https://playground.babylonjs.com/#V07WF8#25

So, another mean to fix your PG is to set a Scene.MaxDeltaTime lower than 1000:

https://playground.babylonjs.com/#R1JWLA#38

5 Likes

I understand now. From a user standpoint, I think changing Scene.MaxDeltaTime will impact virtually everything in the scene which might lead to unforeseen consequences. I think its best to limit this._scaledUpdateSpeed to particle system updateSpeed to bypass the chk against getAnimationRatio. Its an elegant fix that doesn’t break stuff.

Thks again for all the help and clear explanation, you rock ! :slight_smile:

1 Like