Thank you so much, @Deltakosh for fixing/incorporating the blendMode property for the SpriteManager! I just this morning finally went to make the changes you suggested, and saw that you had already done it!
However, the blend modes do not behave as expected, unfortunately. I guess that may mean removing the feature before 4.1, but if we can make it work, it would be incredible.
Here is the look we had achieved before using particles and a little circular fire sprite:
The sprite
The look we had with particles
We were using the ONEONE mode to add the particles over one another and the terrain below, so that the fire gets brighter where the particles were denser. When they are animated, the result is very pleasing. We moved to sprites because they solved performance problems, but as you can see in the playground below, the sprites block one another despite the blend mode.
It will indeed work with a picture that has a real alpha channel, but only up to a point (the alpha test is a hard test, everything above the cutoff value will still write in the zbuffer):
In hindsight, it still wonāt work as @IIerpos would like, because the colors wonāt add up as the zbuffer will prevent the farer sprites to contribute. The zbuffer should really be disabled when rendering geometries with alpha enabled.
Then just drop the alpha of the png down globally in your image editing program, to make them more transparent, make sure each pixel has an alpha value under 1, then you can take advantage of the color.a on the sprite to drop its global opacity.
https://www.babylonjs-playground.com/#9RI8CG#114
The glitches you are seeing here are where the sprite has a 1 alpha on the texture I believe. Needs to be like 0.998 or something if its āopaqueā and still be able to use the color.alpha channel. That is because it is a scalar and if its 1 it wont do any scalingā¦
The rendering with the current code depends on the order with which the sprites are drawn.
When a sprite has been drawn, all other sprites that are farer than this sprite wonāt contribute to the final color (because of the zbuffer rejection), and all that are nearer will. So, the final color depends on the current view and the corresponding sprite rendering order (sprites are not sorted before rendering).
Ok, thereās no sorting but the alpha cutoff value is a hard value set to 0.95 in the sprite fragment shader, thatās why setting an alpha value lower than 0.95 does work (no zbuffer update), and values above that one makes the sprite to render into the zbuffer.
So, I suppose it all boils down to know if supporting pictures without an alpha channel should be supported by the blendMode parameter in the sprite manager or not.
Note @Pryme8: thereās a console.log in _makePacked, not sure it is intended?