default blending settings for transparency about three-d HOT 4 CLOSED

I had to think a bit before I remembered, but yes it is actually on purpose. The only difference is how the alpha value is computed and since the destination alpha is not used for blending the colors are the same. The reason is that on web the rendered image must end up having an alpha value of one in all pixels otherwise it may look weird on some browsers since it then blends with whatever is behind the canvas. Actually wasn't it you that had a problem with this in the fireworks example? 🙂 Anyway if you find that it's not working in some case then please let me know!

from three-d.

Yeah, it was me: it took me a few minutes to remember the context.

We're just talking about a default value, so maybe it isn't worth too much more time, but let me make a case for returning it to

source_alpha_multiplier: BlendMultiplierType::One,
destination_alpha_multiplier: BlendMultiplierType::Zero,

I think you're right that it won't matter in examples/fireworks, because blending operations never use the destination alpha channel as an input. In this case, the preexisting destination alpha (1.0) is preserved through the entire buffer and prevents the weird browser transparency bug. (FYI: examples/fireworks does not actually use the default BlendParameters value, but examples/fog does)

However, the "traditional" equation will have the expected behavior in a case where buffer alpha is important. For (a contrived) example, consider the creation of a picture of fireworks in a RenderTarget, to be drawn multiple times in a scene with transparency:

• the RenderTarget would initially be filled with rgba=(0,0,0,0)
• some (non-overlapping) fireworks sprites would be rendered into the RenderTarget, writing their own alpha values into it
• this RenderTarget can then be used as a texture in the main scene with correct transparency

If the source_ and destination_ alpha_multipliers are reversed, this RenderTarget buffer would have 0 alpha and could not be rendered in the main scene. Obviously there are lots of things that the traditional default can't do, but if there's a default, it may as well be as unsurprising as possible.

The way I fixed the browser transparency bug was to use the code in #60 (comment) after all rendering had been completed: this simply sets the alpha buffer to what browsers need, with no ramifications for the prior rendering process.

Sorry for resurrecting this issue: I don't remember even looking at the commit when it was made, so I should have made this comment back then.

from three-d.

That is a really good point. I will revert the default transparency back to what it was and then just not use the default in the examples where it causes problems 👍

from three-d.

And I am glad you brought it up again, so it can be fixed, so no worries 🙂

from three-d.