OldUnreal / Unreal-testing

OU 227 testing
Other
27 stars 0 forks source link

AlphaBlend surface property: Strange behavior on stock textures #87

Open ividyon opened 3 years ago

ividyon commented 3 years ago

There are some weird behaviors surrounding the AlphaBlend surface polyflag.

For this test, we're using Mine.utx stock textures from the Deco group.

I made a box, hollowed it out, and put a sheet on one of its sides.

Download map:

AlphaBlendTransparency.zip

image

Now, I set this surface to AlphaBlend. (This might seem like it makes no sense, but apparently it's useful for letting light through a surface while keeping it visually opaque.)

D3D9 behavior: This surface will now always render as "transparent". The inside of the box can be seen.

image

XOpenGL behavior:

When viewed up close, this surface will now be transparent like in D3D9. image

With more distance to the surface, it becomes opaque: image

This behavior is the same with all textures under Mine.utx -> Deco, EXCEPT for one: image

This texture will always be opaque! This is not the case in D3D9, it's still transparent there.

Expected behavior:

In previous builds, the surface would just be fully opaque with the AlphaBlend flag on, as the texture has no alpha channel data.

ividyon commented 3 years ago

ADDENDUM:

On XOpenGL, this behavior is due to Detail Textures. If you remove the DetailTexture from the box texture, it becomes fully opaque. The wires texture worked because it never had a detail texture in the first place.

However, on D3D9 the texture continues to act "transparent".

Smirftsch commented 3 years ago

This behavior is explainable, XOpenGL method to apply detail textures differs entirely from the older versions, hence this result. The detail texture doesn't know about the AlphaBlend and acts as if it wouldn't be set.

Question is, what is wanted behavior there (for detail textures)? Without having it checked yet it very much looks as if older rendevs plain ignore detail textures in this case.

ividyon commented 3 years ago

This behavior is explainable, XOpenGL method to apply detail textures differs entirely from the older versions, hence this result. The detail texture doesn't know about the AlphaBlend and acts as if it wouldn't be set.

The issue is also present in D3D9 and doesn't seem to depend on detail textures there (unless they have a longer fade distance in that renderer). In D3D9 it's always transparent when it should be opaque.

Question is, what is wanted behavior there (for detail textures)? Without having it checked yet it very much looks as if older rendevs plain ignore detail textures in this case.

The wanted behavior is that the texture is fully opaque, because it is set to "Alpha Blend", but has no alpha channel. Under no circumstance, in any renderer, should the texture look transparent because of detail textures, since they're supposed to be on top of the surface, and never influence its visibility or transparency.

As for the detail texture, the wanted behavior would be that it acts the same as with Masked textures. If Detail Textures apply to the opaque parts of masked textures, then they should apply over the visible parts of an AlphaBlend texture too, and not on the invisible parts. The difficulty would be in fading the detail texture along with the diffuse alpha. If masked textures don't support detail textures, it's also fine for AlphaBlend textures to not support detail textures.

It would also be fine to handle the issue in two stages, if properly implementing detail texture for alphablend is difficult: 1) first, ensure the diffuse stays opaque in the above cases. Can ignore detail textures entirely for this. 2) put "making detail textures work with alphablend" in a later ticket for another build.

Smirftsch commented 3 years ago

regarding to your suggestion, I made it now (in XOpenGL) to be fully opaque unless "Alpha" value is set in texture which can make it transparent even without having an alphablend channel in the texture. DetailTexture does respect "Alpha" value from main texture (takes it over) - perhaps it would be an idea to have it use its own value here but I doubt it's worth the hassle.

 > 1.00 -> fully opaque
 < 0.01 -> fully invisible

You can try this behavior in next build :)