What does _scaledDirection actually mean in a particle system?

I’m reading through here:

The code mentions these two lines which intrigue me:

particle.direction.scaleToRef(this._scaledUpdateSpeed, this._scaledDirection);

The naming is what confuses me. What does _scaledDirection represent, if it’s being multiplied by a scaled value once more? It almost seems like a sort of “_scaledScaledDirection

Initially, I figured that some _direction property would be normalized, then scaled by _scaledUpdateSpeed to scale it, perhaps resulting in _scaledDirection.

But then, it’s scaled again by _scaledUpdateSpeed before it’s added to the particle position, which I do not understand.

What’s going on here?

The code quoted in the doc is quite old, it is now much more complicated:

Oh wow, interesting! I’ve been looking into using updateFunction to make particles travel in a whirlpool-type formation, or to use it as a means to apply force fields to particles (like lorenz attractors and such). I’m trying to not overwhelm myself with too much information at once: Where should I best look, when it comes to parsing this and then using it?

The examples I’ve found are so built-up that it’s been kinda hard to make sense of the basics.

cc @PatrickRyan who might have some advice on the best way to create particle systems, as I’m pretty dumb about it myself!

Note that you can experiment with the inspector (it’s probably easier than doing it by code!).

1 Like

Very true! I have been messing around with many of the properties via the inspector, and it’s been working out very well. However, I believe that what I’m looking for in position updates for the particles exceeds the options available by default, so I’m looking to parse the mid-lifetime update function of the particles to see if I can feed in additional data from there. However, there may be certain inspector (and particle) abilities that I’m still unaware of :smiley: so I’m definitely willing to learn some easier way if one exists.

@rascheln, it seems like you would prefer to have more control over the particle system behavior, so I think your best bet would be to use a solid particle system. You can pass any mesh you like to the system, so you could still use a quad to behave like the standard particle systems. You get to create all of the behaviors on the particles themselves, so if you are looking to prescribe a particular motion, this is probably best. You will still get the benefits of batching all of the meshes into one draw call, but you are free to do whatever you like with the particles. Hope this helps point you in the right direction.

1 Like

Thanks for this suggestion! That’s indeed what I was looking to do. The update behavior for solid particle systems is much easier to parse and understand.