Looks like there's some wonky maths going on in the velocity shader (possibly position shader too) when calculating the spherical distribution for the velocity.

If an emitter's position is at the origin, it calculates it okay for the first little while. If it's not, it looks all sorts of wrong.

BoxDistribution seems fine, so I'm assuming it's an issue with spherical distribution only.

An attractor modifier is the first modifier that can have multiple "instances". I.e. you can have more than one attractor per Emitter.

In order to pack multiple attractor values into a single uniform, let's start off by using a Matrix4. This will allow for 4 attractors to be added to each Emitter, with each attractor having a vec3 position and a float force.

The Emitter class is currently not that great to adjust. It's a product of hacking away on something to get it working, and now is the time to think about end-user experience.

Requirements:

1. Ease of Emitter construction
2. Post-construction attribute modification

Possible avenues of exploration:

1. Configuration object passed to constructor.
2. A JSON configuration object being used to construct an Emitter (e.g. via Emitter.from( ... ))
3. Helper methods on the Emitter's prototype to set attributes (initial value and distribution, modifiers, etc.)
4. Separate Spawn, Position, and Velocity classes to define these attributes that are then passed to the Emitter

Currently, velocity calculations are altered by changing the velocity texture's fragment shader. This needs to be made much more user-friendly.

Modifiers will be force definitions that are passed to the velocity shader and will be added to an Emitter via something akin to addModifier.

Questions:

1. Can I use bitmasks to tell the velocity fragment shader which modifiers are active for which emitter?
   • emitter.mask = ...
   • Frag shader: uniform float modifierBitMask[n];

There are very few. Add more.