Handle particle opacity in shader, instead of duplicating in sprite sheet

[jonathanolson]

It seems cleaner to generate a sprite sheet with only a single full-opacity copy of each type of particle, and then add opacity as a 3rd vertex attribute for the shader. Opacity would be passed through per-vertex, but would be the same for each vertex of a particle, and would be applied in the fragment shader.

A proposal for the changes to the shaders would be:

Added to the vertex shader:

attribute float aOpacity;
varying vec2 opacity;

void main() {
  ...
  opacity = aOpacity;
  ...
}

Added to the fragment shader:

varying vec2 opacity;

void main() {
  ...
  // for textures
  vec4 texLookup = texture2D( uTexture, texCoord );
  gl_FragColor = vec4( texLookup, opacity * texLookup.a );
  ...
}

This would need to be added to the existing buffer, or as a new buffer.

I'm available for help and collaboration on this issue, just let me know.

[jonathanolson]

For the code review: #29

[AshrafSharf]

This would make the code cleaner but would slightly cause change in the desired appearance.

Passing opacity value to the shader will apply the opacity to the entire particle portion of the specific tile enclosed by the texture coordinates.This would include both Stroke as well as the Fill of the shape. Doing so makes the particle appear more dull than needed.

So in our case the opacity of the particle is applied as it is to the fill but the stroke opacity is only proportional to the actual opacity and not the exact same value as fill .The tiles in the sprite sheet are generated accordingly.

This is a particle with opacity of 0.5

As we can see the stroke opacity is higher than the fill.This is done to get the particle appearance as close as to the original Java version.

I can go ahead and make changes but would like to know your suggestion based on aforementioned issue

[jonathanolson]

I'd say either leave it as-is, or consider separating the stroke and fill into two sections of the sprite map so that opacity can be correctly applied.

@AshrafSharf, what would you prefer?

[AshrafSharf]

For now,I would prefer leaving it as it is
@jonathanolson, when you have time, it would be helpful if you could throw a bit more detail on the approach of separate sections for fill and stroke on the texture map so I can revisit this issue.

[samreid]

We decided that this solution is great for now, and we can re-evaluate in the future once scenery has broader webgl support. Closing.