I've been making some tests with Irrlicht, and the alpha channel usage/ZWrite enable. And i've noticed something. When the "Allow Zwrite on transparent" feature is enabled, the additive blending becomes messy.
I think this trouble can be corrected easily if the aditive blending was done in the last part of the render, that, is, if the render was split into "solid/transparent/additive blending" because, in fact, the aditive blending doesn't need to write information to the ZBuffer, It needs the Zbuffer to cull pixels that are covered by other triangles, but it really doesn't need to write the ZBuffer because it is a transparent object, and it only adds color to the existing pixels, don't blend with them the same as the alpha blending, that is, the operation is Source color + Source color, the alpha chhannel is really of no use in this case.
But the render of aditive blending objects, as it is right now, it is mixed with all the other transparent objects, and thus, the rendering order affects the ZBuffer, and causes the elimination of incorrect parts of aditive blended polygons, or otherwise, the aditive blending, as a transparent object, causes incorrects writes to the ZBuffer, which causes that transparent (alpha blended) objects rendered behind them become invisible.
What do you think? Could it be posible that this isue was corrected in another release of Irrlicht?
With regard the Additive blending
With regard the Additive blending
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
problem case; semi-transparent black object (maybe a screen fade) in front of an additive white object (maybe a particle);
the background additive white object will not render because it sees that an object is already in front of it.
Any render order will have problems when transparency is involved unless the objects are sorted by z-depth first, which is slow.
So I think it should stay as it is. It's always possible to change the order manually anyway.
the background additive white object will not render because it sees that an object is already in front of it.
Any render order will have problems when transparency is involved unless the objects are sorted by z-depth first, which is slow.
So I think it should stay as it is. It's always possible to change the order manually anyway.