[no bug] Alpha channel texturing problem

[matgaw]

Seems to be a bug since Irrlicht 1.5, fixed in 1.5.1, still existing in 1.6-SVN

Screenshot:


The problem is this blue frame around the tree.

Texture: http://89.171.200.74/tree29zz.bmp
Test model: http://89.171.200.74/model.3ds

Test code:

Code: Select all

Mesh=device->getSceneManager()->getMesh(file.c_str())->getMesh(0);
Node=device->getSceneManager()->addMeshSceneNode(Mesh);
Node->setMaterialFlag(EMF_LIGHTING,true);
for (u8 i=0;i<Node->getMaterialCount();i++)
    Node->getMaterial(i).Shininess=0;

file="3d/objects/static/";file+=MeshFile;file+="/";file+=TextureFile;

Node->setMaterialType(EMT_TRANSPARENT_ALPHA_CHANNEL);

Texture=device->getVideoDriver()->getTexture(file.c_str());
device->getVideoDriver()->makeColorKeyTexture(Texture,position2d<s32>(0,0));
Texture->regenerateMipMapLevels();
Node->setMaterialTexture(0,Texture);

The blue frame shows on every distance, both OpenGL and DirectX, and - as I mentioned - it seems to be fixed in 1.5.1 but not in SVN.

[matgaw]

@Up

Problem still existing in Irrlicht 1.6 final.

[matgaw]

Seems to be a bug since Irrlicht 1.5, fixed in 1.5.1, still existing in 1.6-SVN

Screenshot:


The problem is this blue, one-pixel frame around the tree (which should be transparent because it's transparent color)

Texture: http://89.171.200.74/tree29zz.bmp
Test model: http://89.171.200.74/model.3ds

Test code:

Code: Select all

Mesh=device->getSceneManager()->getMesh(file.c_str())->getMesh(0);
Node=device->getSceneManager()->addMeshSceneNode(Mesh);
Node->setMaterialFlag(EMF_LIGHTING,true);
for (u8 i=0;i<Node->getMaterialCount();i++)
    Node->getMaterial(i).Shininess=0;

file="3d/objects/static/";file+=MeshFile;file+="/";file+=TextureFile;

Node->setMaterialType(EMT_TRANSPARENT_ALPHA_CHANNEL);

Texture=device->getVideoDriver()->getTexture(file.c_str());
device->getVideoDriver()->makeColorKeyTexture(Texture,position2d<s32>(0,0));
Texture->regenerateMipMapLevels();
Node->setMaterialTexture(0,Texture);

The blue frame shows on every distance, both OpenGL and DirectX, and - as I mentioned - it seems to be fixed in 1.5.1 but not in SVN.

[Virion]

i think that's probably the texture problem. the blue edge is not the blue color that you keyed out.

[matgaw]

No, it is not. I checked that out earlier in MSPaint.

Besides, these textures rendered fine until Irrlicht 1.4.2. The problem appeared in 1.5, seemed to be fixed in 1.5.1, but still appears in 1.6

P.S. Found out that IVideoDriver::findTexture() doesn't work anymore with incomplete paths (returns false). I think that this should be corrected too. But this still didn't solve my problem (I thought that multiple calls to makeColorKeyTexture may have done this, but - not).

[B@z]

its ordering problem
the clear color is that blue, and your map doesnt render behing it.

well i made a topic in this forum, but couldnt get any solution for that...

but in your case, you can use TRANSPARENT_ALPHA_CHANNEL_REF

Node->setMaterialType(EMT_TRANSPARENT_ALPHA_CHANNEL_REF);

and if i remember correctly, you have to set up the parameter too
Node->getMaterial()->MaterialParam1 = 128
if i remember correctly...

anyway it works like, its fully transparent at alpha value more than 128, and not transparent, below that.
it works good with leaves.

[bitplane]

Looks like a problem with makeColorKeyTexture and mipmaps. The problem is that OpenGL and Direct3D blend nearby pixels together, but makeColorKeyTexture doesn't clear the colour value. This means that where you have "fully transparent blue" and "fully solid green" pixels next to each other, they blend into "half transparent blue-green" at the next mipmap up.

Either set the material param lower (not 0 though), use a 32-bit image with transparent green background (ie PNG), disable mipmaps and have nasty artifacts and bad performance, or hack Irrlicht to allow a user-specified transparent colour.

[pankajnagarkoti86]

No, it is not. I checked that out earlier in MSPaint

[B@z]

have you tried out what i said?

[matgaw]

Either set the material param lower (not 0 though)

This solved the problem. But why the same code, without setting material param, did work in Irrlicht < 1.5. Some makeColorKeyTexture behavior change? Better fix it back...

[hybrid]

The re-interpretation of the 0 in MaterialTypeParam has been removed. Now, 0 means that no early cut-off is done. Before, this value had been re-interpreted as being 0.5, which means that much of the transparency border is automatically cut off. Just try this out by setting the value to 0.01 in an earlier version of Irrlicht, or by setting it to 0.5 in the recent versions. Should look the same then.