Incorrect transparency rendering in CAnimatedMeshSceneNode

[robmar]

I've checked through CAnimatedMeshSceneNode::Render and the code is wrong to handle transparency:-

Code: Select all

video::IMaterialRenderer* rnd = driver->getMaterialRenderer(Materials[i].MaterialType);
            bool transparent = (rnd && rnd->isTransparent());
 
            // only render transparent buffer if this is the transparent render pass
            // and solid only in solid pass
            if (transparent == isTransparentPass)
            {

The line "if (transparent == isTransparentPass)" will execute if transparent and if not transparent, whereas it needs to render non transparent first.

As it is, Irrlicht is rendering transparent materials if they exist at material index 0 before solid background materials, which with antialias, is causing incorrect blending.

There is not a transparent render pass call, just the single call to render the nodes.

There is sorting on solid and transparent nodes, but not on materials.

Anyone aware of this issue?

[CuteAlien]

There are render() calls in every pass for which the scenenode registered itself. The corresponding CurrentRenderPass is set in CSceneManager.

There are some problems with this. Like that sorting is per node instead of per meshbuffer. And that it's not exactly the cheapest way to do rendering sometimes. But solid passes are rendered before transparent passes and only the solid/transparent meshbuffers render in their own pass. If there are problems it's more often because a solid meshbuffer ends up thinking it's transparent (distinguishing that can be tricky at time).

edit: Just to clarify - rnd variable in that code is per material - so it skips those it doesn't need in current render() call. Thought the code looks a bit different by now in the svn trunk version of Irrlicht it still does more or less the same.

[robmar]

Thanks for sharing that, I think the problem might be that if an extra shader is used that isn't recognized by Irrlicht as transparent, it will render it in the solid pass.

I take a look in the render code to see where it checks the shader type, and see if that fixes it.

[CuteAlien]

Yeah... I think that's the main reason why it's a bit different now in svn trunk.