Alpha transparency not working after switching to 1.9

[MolokoTheMole]

Hey all!
I just switched from 1.8.4 to 1.9 and there's a big visual glitch.

http://prntscr.com/jopm7l

Basically it seems alpha transparency is not working. I searched the forums and tried to enable blending but all fails.

I tried EMT_TRANSPARENT_ALPHA_CHANNEL and this, but BOTH don't work.

Code: Select all

 
Material.MaterialType = EMT_SOLID;
Material.MaterialTypeParam = 1.f / 255.f;
Material.BlendOperation = EBO_ADD;
u32 alphaSource = EAS_TEXTURE | EAS_VERTEX_COLOR;
Material.BlendFactor = pack_textureBlendFunc(EBF_SRC_ALPHA, EBF_ONE_MINUS_SRC_ALPHA, EMFN_MODULATE_1X, alphaSource);
 

[CuteAlien]

Do you read back from any of the textures used here (using ITexture::lock())? There is currently a problem with that.
To check add the following at the start of your app:

Code: Select all

 
Driver->setTextureCreationFlag(video::ETCF_ALLOW_MEMORY_COPY, true);
 

This switches texture-memory handling back to old style (keeping copies in main memory instead of reading it always back from graphic card).

[MolokoTheMole]

Awesome! That fixed it.

There's one more problem.
http://prntscr.com/joy1pq

Sprites that use blending render as black boxes
Irrelevant of what the blending function is, just black...

Code: Select all

 
    material.ZWriteEnable = true;
    material.MaterialType = EMT_ONETEXTURE_BLEND;
    material.BlendOperation = EBO_ADD;
    material.MaterialTypeParam = 1.f / 255.f;
    u32 alphaSource = EAS_TEXTURE | EAS_VERTEX_COLOR;
    material.BlendFactor = irr::video::pack_textureBlendFunc(EBF_SRC_ALPHA, EBF_ONE, EMFN_MODULATE_4X, alphaSource);
 

[CuteAlien]

I need a little bit more info. How do you draw your sprites? Are those mapped to polygons? Or are you using draw2DImage functions and working with Material2D? And which driver is this?

[MolokoTheMole]

Yes, two polygons.
It's SMaterial and OpenGL.

[CuteAlien]

Set material.MaterialTypeParam = material.BlendFactor;
This is currently badly documented (minor comment in SMaterial...) and maybe should be rewritten anyway. From what I can see someone tried to keep EMT_ONETEXTURE_BLEND downward compatible when adding new BlendFactor parameter. But that doesn't work anyway as in other places BlendFactor is used.

I'll probably change it as well in code so always BlendFactor is used (at least when it's > 0 ...guess I can keep using MaterialTypeParam when that is not the case (as 0 will always be wrong).

But for now - set both parameters to same value.

edit:*sigh* seems someone needed blending for materials other than EMT_ONETEXTURE_BLEND - and just hacked it in so it worked for his case. Not even serialization got added and some more problems. F**k! I have to move this for now on my todo list.

[MolokoTheMole]

OK blending works, but alpha channel doesn't work
http://prntscr.com/jpft1e

Is there still something I need to do or are these bugs?

[CuteAlien]

Did you try without EAS_VERTEX_COLOR? As this seems to be only about textures.
I'm not familiar with EMT_ONETEXTURE_BLEND (I got away with EMT_TRANSPARENT_ADD_COLOR in the past, so it's also just try&error for me.

A quick test with example 08 (Special effects) where I added those lines worked for me.
Around // attach billboard to light
After the line: node->setMaterialTexture(0, driver->getTexture(mediaPath + "particlewhite.bmp"));

Code: Select all

 
video::SMaterial& material = node->getMaterial(0);
material.ZWriteEnable = true;
material.MaterialType = video::EMT_ONETEXTURE_BLEND;
material.BlendOperation = video::EBO_ADD;
u32 alphaSource = video::EAS_TEXTURE | video::EAS_VERTEX_COLOR;
material.BlendFactor = irr::video::pack_textureBlendFunc(video::EBF_SRC_ALPHA, video::EBF_ONE, video::EMFN_MODULATE_4X, alphaSource);
material.MaterialTypeParam = material.BlendFactor;
 

Looks better when using video::EMFN_MODULATE_1X in this case, but aside from that it seems to be fine. So can't say what is wrong in your case without some example. Might be textures, might be code.

And it's hard to tell if the thing with the BlendFactor is a bug. It's a lazy implementation which can be improved I suppose.

[MolokoTheMole]

Sorry my mistake with the alpha channel. It's good now.
http://prntscr.com/jpg85i

Still having an issue with Z-sorting, cause it renders in different order than it was.

http://prntscr.com/jpg940 (how it was in Irr18)
(the white modulated sprite is rendered behind a normal one, that's why I use this effect)
(and the tree branches are all in different order)

[CuteAlien]

I don't remember any change about z-sorting. If z values are close enough to each other there can always be z-fighting certainly which can result in pretty random results. Thought for this kind of game you often don't need z-Buffer. Render nodes in order from back to front with z-buffer checks disabled.

So again - I need more information. How do you set z-values? How do you set your camera? How are your nodes drawn - do you add them all to a scenegraph and then call drawAll()?

If you have an example it would be even better :-)

[MartinVee]

Z-Sorting and orthogonal camera?

It definitely reminds me of something...

[devsh]

Sorting should be done by distance from the camera, not Z-value, eliminates popping when rotating the camera around.

Also billboards should face towards camera, not along Z+ (openGL convention Z+, d3d Z-)

[CuteAlien]

Well, the point here is that nothing since 1.8 should have changed about that.