ONE_TEXTURE_BLEND in svn

[Lonesome Ducky]

Not sure if this is actually a bug or just new behavior, but the pack_textureBlendFunc and EMT_ONE_TEXTURE_BLEND combination I used in the 2d drawing snippet here is no longer functioning. It was written and worked perfectly in 1.7.2, and I moved to 1.8 for the fixed ms3d loader but I also need this blending to work. Is this a bug or is there something new that has been implemented for this?

EDIT: Alright, after some digging, I found the new SMaterial attribute "BlendOperation" and set it to EBO_ADD. Is this the correct way of fixing the problem? This could be moved to Beginner's Help now I suppose.

[CuteAlien]

I think it's correct - at least I solved a similar problem already also by setting EBO_ADD explicitly. And I know we're not the only ones run into this already, so I start wondering if we should maybe make EBO_ADD default - it's even said to be default in the comment to that enum. If I understood it correct the new default is faster in certain situations (probably when no blending is needed), but EBO_ADD as default seems to be more obvious to me and people could still set EBO_NONE if they need the optimization.

[hybrid]

The comment is wrong - well merely outdated. This flag was at first intended for just the blend operation state, without enabling/disabling blending. Which means that EBO_ADD is default, as that's the usual blend operation. However, it is also used to enable/disable blending completely. So default is now EBO_NONE. And only if blending is enabled, it should be set to the blend operation intended to use. The speed difference should be significant, and moreover, the rendering would change notably if blending is always enabled. The problem is that all SMaterial flags are publicly changeable. We have no way to become notified and, e.g., change the blend state according to the material. So for now you have to set the blend state in order to enable blending. In most cases it works correctly with or without, but e.g. for 2d drawing you need to adjust this on your own.

[CuteAlien]

Ok, I see - so it changes no matter which default we set now. I think I run into this when I tried figuring out why some alphas no longer worked. Is the EMF_BLEND_OPERATION flag still needed the way BlendOperation is now used? If we have some way avoiding to have 2 flag depend on each other it would probably be better.

[hybrid]

There's only one flag (or which other one did you mean?). If set to EBO_NONE, blend is off. Otherwise, the selected blend mode is operating.

[CuteAlien]

OK, I got confused because you can set EMF_BLEND_OPERATION as boolean flag, but I see now that it does set BlendOperation to EBO_ADD when you do that.

So the problem is that the MaterialType and BlendOperation are independent? Or when exactly must users set EBO_ADD? When a material should support the alpha channel? Or for materials which have 2 textures one of which has an alpha channel?

I run into that when EMT_TRANSPARENT_VERTEX_ALPHA material no longer worked for me. But I think Yoran also run into it before me already once and as far as I can see we are by default setting EBO_ADD always by now. And I don't know right now in which case I wouldn't want to have that enabled. So probably missing out on some optimization...

edit: Wasn't that also the reason why in 08.SpecialFX the alphas of the particles are now all black in Direct3D9?

[hybrid]

Yes, some materials require the blend being enabled. The default is EBO_NONE, though. The comment also just says that EBO_ADD is the default blending operation, not the default init state for the flag. The extra blend operations are just very special, and are not that often used. I think we need a fully encapsulated SMaterial without any public members. But due to the strong API change, it's also more for Irrlicht 2.0
Changing to EBO_ADD as default will lead to material changes which make many materials act more like TRANSPARENT_ADD in the future. And if not, it might be slower if the driver does not recognize the non-effect of the blend operation. In those cases, the frame buffer would be read before written for each pixel. In case of slow systems, this would become quite a burden.
The transparent materials are not all black, but only from certain angles and lighting situations. This has been a problem for a short time with wrong default values for the blend operation, or missing EBO_ADD. But the current problem is more likely caused by a general change in the material renderer a longer time ago. Still not sure, though.

[CuteAlien]

Ok, thanks. Fully encapsulated material would also help with texture reference-counting :-)

[aanderse]

Ok, thanks. Fully encapsulated material would also help with texture reference-counting

on that note, even if it is irrlicht 2.0 did anyone have any thoughts on texture reference counting?
a fully encapsulated material class is a huge change, has anyone started thinking about how that would happen?

just curious

[CuteAlien]

Ok, thanks. Fully encapsulated material would also help with texture reference-counting :-)

a fully encapsulated material class is a huge change, has anyone started thinking about how that would happen?

First step - add getter and setter functions to SMaterial. Second step - make member variables private. Done :-)

[hybrid]

For textures we even have those getters and setters. So changing the public feature of textures would be an easy thing. But use and usage of SMatrial and its members are so wide spread and vital to every Irrlicht app, that we won't change that underneath.

[aanderse]

First step - add getter and setter functions to SMaterial. Second step - make member variables private. Done

well the assignment operator for the material class is constantly being used in the engine
i just thought all that ref'ing and unref'ing on the texture might not be desirable and maybe something else was going to be planned

[CuteAlien]

I don't think this has a noticeable cost in release (referencing isn't expensive), although it would get slower in debug because of function calls.