Particle System Entity Fixes


I think we’re confusing two points here:

  1. Alezia’s particles are green because her spread value has a red value of 255.

  2. I agree that interpolating in RGB space isn’t ideal, but it’s not causing the green particles. Maybe we can add an option to do the interpolation in HSL space instead. Not everyone understands the particulars (heh) of color spaces :smiley:

As for the start/end properties, the main value (color in this case) is used as the middle value for the bezier interpolation. If the start or end values are unset, they match that middle value.


Maybe I don’t understand the “spread” thing.
I saw that as a mid-floor between StartColor and Color.

Maybe you can try to explain it?
(To get green instead of Red it must be definitely something else)


Hmm… what does start of 255 and end of 255 with spread of 0 if color is 128?

I’ve used other particle systems but… I don’t remember them being like this.


ok let’s say then
Hue 30 degree to Hue 60 degree, the spread could be Hue 45 degree (the short) or Hue 225 degree (the long)


And yes… I do somewhat understand color spaces. I guess I didn’t realise that particles used the same shading as other things here now. So… nm (but better docs would be nice).


This behavior is all documented in the API reference :slight_smile:

It looks like there’s a typo in there (acceleration instead of color), but hopefully it clears things up. The spread is essentially an offset. It has nothing to do with which way we’re interpolating. Does that make sense?


The spread in color that each particle is given. If color == {red: 100, green: 100, blue: 100} and colorSpread == {red: 10, green: 25, blue: 50}, each particle will have an acceleration (a color?) in the range {red: 90, green: 75, blue: 50} – {red: 110, green: 125, blue: 150}.

Indeed very not intuitive. I have to Set the Color in the middle of the range I want, and set the Spread on one of the 2 color that border the range.
(Assuming that it truly based on RGB… I will need to validate that. )


Was it intentional to allow speedSpread to create negative particle velocities? When you can not even create negative emitSpeed?
If you set emitSpeed to 1 and speedSpread to 2 the range of velocities will be from 3 to -1 for the particles.


Negative speed would have been interesting to support by the way.


I’ve been able to make a fix for my product.
Now that it’s more clear that is it an offset vector.

Thanks for you help.

I think the first thing that should should be consider, is to remove the color picker from the colorSpead field to keep a simple vector (This is probably why it is confusing, because the offset is not a color. Not have the color picker would help to figure that it’s other thing.)

I have also explored a bit more how that offset is applied over the color. it’s definitely limited because it is applied on the RGB chanel. There are ranges that we can’t do because it’s RGB.


using: Clipboard.exportEntities(file,UUID)
emitterShouldTrail isn’t making it into the resulting JSON file
So particles that use this wont look correct on import.


Hi Alezia,

I have tracked this internally. Please let me know if you have any other suggestions for the tooling around this.


I filed a bug report for this, thank you BrainStormer.


Just an update, there are some more fixes going into 71:

  • Particles don’t roll with your head anymore
  • Particles have “Spin” values that let you control their roll
  • emitterShouldTrail is fixed for real this time
  • negative emitSpeed is supported


Any plan to "versionate’ the algo?


For the roll or the color stuff we were talking about before? We can try to provide versions for future changes, but in general I’d like to keep the API as simple as possible.