EMF_TRANSPARENT_ALPHA rendering problem

[mongoose7]

I performed some tests and Irrlicht transparency actually does not work. The OpenGL setup invokes the texture combiner. Probably the easiest thing would be to use EMT_ONETEXTURE_BLEND instead of the transparent base material types.

@CuteAlien: While it is generally true that transparent objects rendered first appear slightly darker than similar objects rendered later, it makes no difference in the current case, because the transparent objects have the same colour and transparency. For example, if the background colour is B and object one's colour and alpha are C1 and A1, and similarly for object two, then the resultant colour would be (B(1 - A1) + C1A1)(1 - A2) + C2A2 = B(1 - A1)(1 - A2) + C1A1(1 - A2) + C2A2. If C1 = C2 and A1 = A2, this is just B(1 - A)(1 - A) + CA. Rendering more objects just darkens the background (and solid objects) but it doesn't change the apparent colour of the transparent objects.

[CuteAlien]

mongoose7: No idea what you mean. I work with several transparent materials and all of them work. Just not in this case.

[mongoose7]

Can I see the test code? You do know we are using shaders? But it would be interesting to see your code in any case.

[CuteAlien]

It's not test-code but code used in my projects (and in projects I did for customers). I'll open-source one of them soon (supposed I'll get through to the end of it ... starting to seriously regretting by now I've ever started NDK development). But unless the shader code is not handling transparency it doesn't really matter, my current project works with shaders on GLES2 and with without shaders on OpenGL. The shaders in the GLES branch did handle that even by default (thought mine look a little different now as I kicked out some stuff).

But particles in example 08 have for example some transparency.

[hendu]

I can only vouch for my 1.7 fork, but shaders + transparency works fully there. Could be broken in trunk or 1.8.

edit:

then the resultant colour would be (B(1 - A1) + C1A1)(1 - A2) + C2A2 = B(1 - A1)(1 - A2) + C1A1(1 - A2) + C2A2. If C1 = C2 and A1 = A2,

Correct up to this point.

this is just B(1 - A)(1 - A) + CA.

The final simplification is wrong. It would be B(1 - A)(1 - A) + CA(1 - A) + CA -> B(1 - A)(1 - A) + 2CA - CA^2

Code: Select all

#include <irrlicht/irrlicht.h>
 
using namespace irr;
using namespace core;
using namespace scene;
using namespace video;
using namespace io;
 
static const char ftex[] =
    "void main() {"
        "gl_FragColor = vec4(1.0, 0.0, 0.0, 0.5);"
    "}";
 
int main() {
 
    IrrlichtDevice *dev = createDevice(EDT_OPENGL);
    if (!dev) return 1;
 
    IVideoDriver *drv = dev->getVideoDriver();
    ISceneManager* smgr = dev->getSceneManager();
 
    IMeshSceneNode *n = smgr->addCubeSceneNode();
    IMeshSceneNode *n2 = smgr->addCubeSceneNode();
    smgr->addCameraSceneNode(0, vector3df(0, 0, 20), vector3df(0));
 
    int shader = drv->getGPUProgrammingServices()->addHighLevelShaderMaterial(
                0, ftex, (IShaderConstantSetCallBack*) 0,
                EMT_TRANSPARENT_ALPHA_CHANNEL);
    if (shader < 0) return 1;
 
    SMaterial &cubemat = n->getMesh()->getMeshBuffer(0)->getMaterial();
    cubemat.Lighting = false;
    cubemat.MaterialType = (E_MATERIAL_TYPE) shader;
 
    SMaterial &cubemat2 = n2->getMesh()->getMeshBuffer(0)->getMaterial();
    cubemat2.Lighting = false;
    cubemat2.MaterialType = (E_MATERIAL_TYPE) shader;
 
    while (dev->run()) {
        drv->beginScene();
 
        smgr->drawAll();
 
        drv->endScene();
    }
 
    dev->drop();
 
    return 0;
}

On my 1.7 thing, the result is correctly 0.75 red.

[mongoose7]

I tried a few examples myself and, as you say, they all work. I think I was mistaken and I really need to draw the objects from far to near. Here is the picture.

It looked to me as if the quarter panels were modulating the white of the rear window. But of course it can just be that they are drawn last . The interior, being solid, would be drawn first. Sorry for the bother. So the rule really is, draw transparent objects from far to near.

[Harch]

The OpenGL setup invokes the texture combiner. Probably the easiest thing would be to use EMT_ONETEXTURE_BLEND instead of the transparent base material types.

I did so. And selects the type of blending. Or not very nice or similar artifacts.

(B(1 - A1) + C1A1)(1 - A2) + C2A2 = B(1 - A1)(1 - A2) + C1A1(1 - A2) + C2A2

This formula is dependent on the order of drawing triangles

The final simplification is wrong. It would be B(1 - A)(1 - A) + CA(1 - A) + CA -> B(1 - A)(1 - A) + 2CA - CA^2

You set EMF_BLEND_OPERATION "true"?

So, there is no solution to the problem? This engine bug?

[hendu]

(B(1 - A1) + C1A1)(1 - A2) + C2A2 = B(1 - A1)(1 - A2) + C1A1(1 - A2) + C2A2

This formula is dependent on the order of drawing triangles

Yes, GL blending is order dependent in most of its equations. That is not a bug, it is by design.

So, there is no solution to the problem? This engine bug?

I have no idea what your bug is, or if it's even a bug. I refuse to watch online videos, I value my time more than that.

[Harch]

Video is 1 minute ...

Okay, can we organize polygons by the engine, using as a z-buffer? And it does not use it to cut off?

[mongoose7]

Transparent objects do not write to the Z-buffer. If you write to the Z-buffer then you must render from back to front. So you still end up having to render from back to front.

[Harch]

It turns out there EMT_TRANSPARENT_ALPHA is senseless thing, since it requires the correct order of rendering, which is not provided by irrlicht?

[CuteAlien]

As I wrote - Irrlicht does per node ordering. It does not per mesh ordering.

[Harch]

But then it turns out that transparent objects must be very small and with simple geometry?

[CuteAlien]

Yeah, that or you have to write your own custom nodes which do their own sorting I guess.

[Harch]

Maybe someone has a ready code? If not, you can throw a link to the description of the right sort please?