'disk' emitter, radiusSpread, angles

[stemkoski]

• Included disk-shaped emitter
• now able to randomize radius size for sphere/disk emitter
• particles can have an angle, angle can be randomized or aligned to velocity direction
• fixed _resetParticle velocity direction issue
• TODO: incorporate angleVelocity for rotating particles

[squarefeet]

I've not had a chance to have a look at this in action yet, but had a look at the code on the bus whilst on my way to work this morning - looks awesome; thanks as well for using the same code-style, makes a huge difference :)

From what I could garner from looking at the code earlier though, I'm wondering if the 'disk' type is redundant - doesn't this just mirror the radiusScale property should this property be set to new THREE.Vector3(1, 1, 0)? I could be wrong since I've not seen it in action yet...

[stemkoski]

I initially thought along the same lines, but multiplying the z-radius by 0
only flattens the sphere after the points have been selected on the surface
of the sphere, so if one wants a disk shape with an empty center, this
approach will fail.

On Sep 6, 2013 6:20 AM, "Luke Moody" notifications@github.com wrote:

I've not had a chance to have a look at this in action yet, but had a
look at the code on the bus whilst on my way to work this morning - looks
awesome; thanks as well for using the same code-style, makes a huge
difference :)

From what I could garner from looking at the code earlier though, I'm
wondering if the 'disk' type is redundant - doesn't this just mirror the
radiusScale property should this property be set to new THREE.Vector3(1, 1,
0)? I could be wrong since I've not seen it in action yet...

—
Reply to this email directly or view it on GitHub.

[squarefeet]

Ah yeah, I didn't think of that, good point.

I've merged your pull reqs and discovered that in ShaderParticleEmitter#_randomizeExistingVector3OnDisk() you were setting v to a new Vector3 instance. Sadly, when one sets the value of a function's argument within the function, it doesn't alter the original value. I made this gist as an example, since it's hard to explain succinctly in English!

To get around the problem, I just used v.copy(), or v.set() instead, depending on the function. But that did all sorts of weird things (angles were out of alignment, etc.) After a bit of digging, I realised that the velocity shader attribute was never getting marked as needing to be updated in ShaderParticleGroup#_flagUpdate(). Adding a new flag for this fixed the issue. It's also made sphere emitters look much nicer, so there's a nice bonus.

I've pushed these changes to a new branch called dev so you can check them out, before we decide what version to bump to, etc. etc.

As a little aside, I'm so disappointed that a particle's angle only works in 2d space. I remember being as disappointed when I first discovered this a while ago (there went my hope for using bullet-shaped particles in my game). Techically, one could squash the textures to reflect the z-rotation, but get them travelling on the same plane as the camera and they'd be invisible. Oh well!

[stemkoski]

I think that there is a mathematical solution to this problem -- the angle of the sprites needs to take the position of the camera into account. Initially, the camera is looking along the negative z-axis, so using the x and y components of velocity to calculate the angle of rotation for the sprites makes sense. In general, however, we would want to project the velocity vector into the plane perpendicular to the vector along which the camera is looking, and if the projection has coordinates (v_1, v_2), then the angle of rotation for displaying the sprites should be Math.atan(v_2, v_1).

[squarefeet]

That's a good idea. My maths is a bit shaky (I'm technically an English Lit grad!), but could we use the vertex shader's modelviewmatrix to project the velocity vector onto? If so, we could add a new bool/int uniform to the vertex shader (and a new varying to pass the projected vector onto the fragment shader) to signal whether to align the sprite to the velocity?

I might experiment with this tonight and see if I make any headway...