Objects using alpha transparency not properly displayed.

Distance sorting of alpha blended objects is the ultimate solution although with an associated performance penalty. However improved results can be obtained if alpha testing is used more agressively to eliminate most of the blended pixels. Also, many objects that specify an alpha blended material, don't actually have a multibit alpha channel in their ace file. I propose to force alpha testing in this situation.

Fix candidate completed at SVN 1463.

See improved screenshot attached.

Could you attach the patch or describe the change more precisely please? I have mentioned previously about using ACE channel information to overriding / augment the material choice but I didn't think we had the information available.

I extended reader.dll to provide this info via the texture.tag mechanism in the returned XNA Texture2D.

I had planned to provide the full channel info, but unfortunately I have no means to read the channels when an ACE file contains a DXT1 texture. As such I am only providing a boolean to indicate if a multibit alpha channels exists or not which I can determine from the available data.

SVN 1463 contains the changes.

On further testing I found a case where this fix causes problems. ie a compressed texture with 1 bit alpha, but where alpha testing wasn't specified in the shader.

.... Further fixes coming.

I'm very-very far from being expert in this question, so I dare only just ask a little question: Why not using the

clip(color.a - ReferenceAlpha);

method for alpha testing in HLSL shader rather than using the alpha test function in XNA 3.1? It would be good to remove that from XNA code anyway, because XNA 4.0 no longer supports that...

Peter, thats a good comment. We are unlikely to ever go to XNA 4.0 so that won't be an issue.

I wonder if using clip(..) in the shader could result in a performance improvement by providing an early exit from the remainder of the shader code? Have you seen and info on this?

Wayne, just for a test I attach a diff file with SceneryShader.fx modified to use clip() function for alpha testing, and also Shaders.cs and Materials.cs modified accordingly. (Though I am unable to compile RunActivity now because of the modified Reader.dll, so I cannot currently make real tests. I'm investigating the problem.)

I'm sorry, a correction in side note: I am able to compile, but unable to start game because of a NullReferenceException in GetBlending()

It sounds like you don't have the latest Reader.dll. It was updated at SVN 1465. Download the latest from SVN and let me know if this resolves the problem.

I have that, otherwise I couldn't have compiled the most recent source code. :-) But now I realized that I can start most of the routes with all rolling stock, so a certain scenery element must cause the problem, but I couldn't locate it yet. (I attached the log file, though it doesn't help to track back the problem, I think.)

I think I see the problem. I'll get back to you with a fix.

Due to a program bug introduced at SVN1463, a missing texture would cause a program abort. It should be substituted with a default blank texture. I posted a fix candidate at SVN 1466.

Thank you Wayne, the exception disappeared, the program now runs normally!

Solves this issue: http://www.elvastower.com/forums/index.php?/topic/19692-more-than-one-layer-of-translucency-no-longer-allowed/

I hope this fix can stay in OR.

Thanks!