[mrmosky]

I have noticed that there is a difference between how transparent textures are displayed between the stable version, and the testing or MG version.

Here is an example. In the picture I have a control handle, this is made up of two objects, one has the main texture on it, and the other one has a texture that is mainly transparent except where I have added highlights, or shadow. The transparent object is placed just in front of the main object, so that the highlights are added to the object. In the first picture, this displays correctly in the stable version of OR, whereas in the second picture, taken when using unstable version (X1.3.1-124-g5037f814 ), the transparent texture does not display.






Is this a bug?


Geoff

[Csantucci]

Hi Geoff,
I don't think I'm able to solve your problem, but only for clarification:
You're writing "in the second picture, taken when using unstable version (X1.3.1-124-g5037f814 )". That version ID refers to the testing version, and not to the unstable version. Are you confirming that you get the problem also with such testing version?

[mrmosky]

Hi Carlo,

Yes, the problem is the same with the testing version, and also the most recent MG version too.
Geoff

[mrmosky]

Just some clarification of this problem. If the transparency has solid areas of colour, then it displays, but if it has semi-transparent colours, like a tinted window, for instance, then that will display as if it was clear. Could this be something to do with shaders? I'm guessing as I don't know how these things work.

Geoff

[Csantucci]

You can easily check whether this is a problem due to differences in .fx files (that is shader files).
Go into the Content folder of the stable and of the testing version of OR, and swap the .fx files. Don't do the same with the Unstable version, because the Monogame-based versions have .fx files that are incompatible with the preceding ones.
If you won't find differences, that does not fully exclude shader problems, because preparation for shader data is done within the main OR code.

[mrmosky]

Hi Carlo,

I swapped the .fx files, but that did not make any difference.

I may try using re-shade to see what effect that has.

Geoff

[mrmosky]

I am still experiencing this graphics problem. In my model, I have a window glass transparency that is shaded grey with some dirt marks around the edges. This is done with a TGA alpha texture.


In the Stable release it looks like this, which is what I intended:



In the MG version Rev 65, and the Testing version X1.3.1-124-G5037F814, it looks like this:


Should I report this as a bug?

Geoff

[vince]

I seem to remember the same problem with a texture edging, wanting a 'soft' edge on a transfer texture.
I traced the problem to the type of compression I used on the texture texture.ace file. And I'm sorry, no, I don't recall which compression method caused the problem.

regards,
vince

[mrmosky]

I have also tried this texture as a .dds file. The results were the same. The stable version displays correctly, while the testing and MG versions do not. That leads me to believe that the texture is not the problem, but something in the way it is displayed.

Geoff

[ErickC]

Since v1.2, 8-bit alpha channels in the 3D cab are kind of difficult and erratic to manage. Any part with transparency needs to be a totally separate drawcall, i.e. a separate part from the top node. Attempting to merge all static parts into one mesh will cause 8-bit alpha channels to render as 1-bit. Curiously, you can use the same shape that renders improperly in the 3D cab as a passenger view and it will render fine.

If you have a freight shape that is tagged to display in the 3D cab view, with an 8-bit alpha channel applied, if any part of it renders within the boundaries of the 3D cab, then its alpha channels will render as 1-bit as well.

As we all know, shadows don't render in 3D cabs the way they do in passenger views. I really don't understand why the passenger view and 3D cab follow completely different sets of rules for how they render, but they do.

I hesitated to bring up anything involving alpha channels because I was worried that, if any modifications to the way that OR renders alpha channels were to be done, some well-meaning programmer might attempt to reintroduce the MSTS alpha sorting, which is a horrendously bad idea. I think that we should all make note of the fix for this problem, then delete this thread to minimize the risk of that happening.