The alpha ref material is hardcoded at 0.5

[hendu]

Could be useful to let the MaterialTypeParam set the threshold, like in the alpha material.

Sure, it would break programs that have the default of 0, unless 0 was made a magic value meaning 0.5. I see nothing wrong with that, as enabling alpha test and setting it to 0 is pointless.

[CuteAlien]

It seems it was like that in the past and that had caused some troubles. So it was changed in r2055 (somewhere in Irrlicht 1.5) by Rogerborg based on this thread here: http://irrlicht.sourceforge.net/forum// ... p?p=182554

[hendu]

That issue was due to the _removal_ of the special condition. Fixing it by always hardcoding at 0.5 is dubious at best.

[CuteAlien]

Ah, so there was more than one change to this? Didn't search further... I'll look again at it tomorrow. (Unless there's a problem with it - which the test should show then anyway - I also think the material param should be used)

[hybrid]

Seems that rev 2055/2056 fixed this value to 127, but the test does neither check the parameter nor the other drivers, that work correctly. I was not aware of this change, I only remembered the problem with the sepcial case of the 0 (also interpreted as 127). This caused many questions why suddenly things re-appear when fading out. And it was even no case of backward compatibility - it had been ever since with this special case. So it was removed. Fixing to only one value does not make sense and has no reason due to problems or render requirements. I only wonder why it was not recognized before?!

[CuteAlien]

Phew. Ok, so if I get that right - the check for 0 was removed to allow better fading. And then because 0 was the default this one didn't work anymore. So the lazy solution of removing all flexibility was chosen.

And because MaterialTypeParam is used in other materials as well we can't just change the default value. Although probably mainly the ParallaxMapRenderer (does 0 make sense there?).

So possible solutions:
1. We get back to the old solution - using a special case for 0
2. We change the default and parallaxmaprenderer changes then
3. We ignore it and keep it inflexible as now (aka no change - everything is fine - move along people!)
4. We get back to the old solution without a special case for 0, but have then trouble because of defaults.
5. We break downward compatibility and just give alpha's their own value instead of using MaterialTypeParam which is then defaulted to 0.5
6. ...
7. Profit?

Any preferences?

edit: My preference is 1 by the way. Least changes, least breaks. And when we change SMaterial really I would prefer doing more changes (like making alpha really based on an own settings and no longer on materialtype because right now we have there some trouble with Shaders as they can only set their basematerial once an therefore fail when they need different shaderstages, aka need to switch between transparent and non-transparent as they can't change the materialtype nor the basetype)

[hendu]

8. Use the unused MaterialTypeParam2 field to determine whether 0 is special or not

[CuteAlien]

Ok, that is another one. Though maybe we could make it choice 6, then I can use my software architecture by dice-throw technique!

[hendu]

Damn, that's a breaking ground technique. Got a whitepaper on it, with statistics proving how it's superior to everything else?

[CuteAlien]

I guess I could prove that this technique is on average better than the worst choice even if you don't know which choice is good or bad and that it takes little time in the decision phase ;-)

Anyway - unless Hybrid (or anyone else) objects I'm going with your solution 8. It's a little strange with 2 params, but who cares, shouldn't break anything and allows doing everything. MaterialTypeParam2 0 => MaterialTypeParam 0 is 0.5 and MaterialTypeParam2 1 => MaterialTypeParam is just used. That way the least code should break I think.

[hybrid]

I'd prefer to simply remove the special case and disregard backward compatibility. This may cause some render slowdown, but no obvious problems such as render artifacts. It simplifies the whole situation and gives parameters a little more sense. And it's easy to fix in apps.

[CuteAlien]

Would that mean it would not work by default with our default value of 0? And not that easy to fix as that is usually set by the loaders I guess. It's not only about backward compatibility, but that this original exception made some sense (at least as far as it makes sense not giving alpha's just their own parameter).

[hybrid]

My undertsnading was that the default value of 0 means that we have a perfect alpha blending, while 0.5 means that all pixels below 50% alpha value are simply discarded, rest is alpha blended. Which gives a perfectly working solution for value 0, only that we have much more pixel processing.
We could also do a reinterpretation of the value as signed number, giving 0 the middle. We just have to shift the value then by 127 or whatever range we have internally.

[hendu]

No, this is only about REF, not about the normal alpha blending. The normal one works fine.

There is no blending, REF only sets the discard threshold.

[CuteAlien]

Ok, I just made a test and it's like I mentioned above. Default 0 would then mean it doesn't work by default which I see as a bad default. Changing the range to -0.5 to 0.5 would be a solution but also breaking downward compatibility which I hate doing for parameters. So I still think the best solution is using 0-1 and making an exception for 0 (setting it to 0.5) and well... controlling that exception maybe with MaterialTypeParam2. It does look ugly in code but it should break nothing for nearly all people and is more flexible than the current solution. And if we break downward compatibility again one day we should do so by adding new parameters - not by redefining the meaning of existing parameters imho.