[superheatedsteam]

I have found a problem with OR v1.4 and MG v123 not displaying 8-bit alpha translucency consistently in a 3D cabview. If the camera view is not within approximately 1.3 metres of origin point of the object that has the texture applied, then the alpha channel is drawn as if it was a 1-bit alpha (completely transparent). The problem does not occur in OR v1.3 so this may have something to do with the change in graphics engine that OR v1.4 and MG share.

When starting in the 3D cabview, you will see the 'Right Side Front' and 'Right Side Rear' windows as well as the 'Front and rear windows' are drawn with a translucent alpha (8-bit). These windows have their origin points within 1.3 metres of the starting camera position where the drivers head would be. Rotate the view to the left of the cab and observe the 'Left side rear' and 'Left side front' as well as the 'Left front door' windows are drawn completely transparent as one would expect with a 1-bit alpha.



The image below has lines pointing to the origin points for the respective objects in Blender.



To view the problem, use the ALT + left cursor key to move the camera view towards the left side of the cab. When the camera position is within the 1.3 metres of the origin points for the respective left hand side windows, they will change from displaying as transparent to showing with translucency. Rotate the camera to view the the drivers side and the drivers side windows are now displaying as transparent. Moving the camera left and right will show the change in window transparency.

I have confirmed that it is the distance of the origin point for the object from the camera location that controls is the window is drawn as translucent or transparent. I did this by moving the origin point for the left side windows within 1.3 metres of the driver sitting position. That resolves the issue for the side windows but cannot be done for the front door as moving the origin point affects the rotation point for the door open/close animation.

Oddly if you move the camera view outside the left side of the cab the translucency remains on the front and rear windows when beyond the 1.3 metre distance yet disappears when the camera view is moved outside the right hand side of the cabview.

I have a attached a locomotive with the 3D cabview to demonstrate the issue. Excuse the crudeness of the models, they are a work in progress.

 AU_HI_SD50S.zip (26.81MB)
Number of downloads: 217

This may or may not be related to the following reported issues:

http://www.elvastowe...ow-alpha-issue/

http://www.elvastowe...aphical-issues/

Cheers,

Marek.

[superheatedsteam]

In addition to the above I have been testing another issue in the experimental version U2022.05.07-1836. It is not obvious when stationary, but when moving there was considerable Z fighting between closely located, but not co-planer geometry in this cab view.

This is most apparent on the labels on the control stand. This has been resolved by increasing the minimum gap between geometry to 1mm. Note that this Z fighting does not occur on the v1.4 release version.

The above reported 8-bit alpha display issue remains in the experimental version as well.

Cheers,

Marek.

[ErickC]

Unfortunately I haven't even had luck with moving the pivot close to the eye point. I am at my wits end with this problem. I have tried duplicating everything I did with my GP7/GP9 cab (which works fine) to no avail. I duplicated the material and hierarchy setup pretty precisely. It seems like OR is extremely capricious about exactly what alignment of the stars causes a shape to have properly working alpha channels in the cab.

Pretty much the only workaround that consistently works is separating the cab walls from the controls and making the cab walls a freight shape only visible in the 3D cab. It's just way more work than it ought to be.

[superheatedsteam]

Have a look at the following thread where Hamza97 found a workaround which also resolved the issue in my cab view.

http://www.elvastowe...passenger-view/

Cheers,

Marek.

[Jonatan]

Like Erick I still have these issues. I also followed the advice in that thread with no success.

[ErickC]

I actually finally got it to work after a few more tests. The main thing that I was missing is that the alpha parts need to have a whole separate material, not just a separate image in a multi-material (previously was using a single multi-material). Because everything in the 70-tonner cab is on a single image, what ended up working was exporting with a dummy texture in the second material, then editing the texture entries in the shape file so that both entries point to the same image.

So with 3D cabs, it makes sense to only use multi-materials on parts where a single part needs to have several different materials applied and doesn't have alpha transparency. This still feels unnecessary and it should be addressed someday, but at least we have a workable solution for now.

So the material setup I will likely use on the final model will be to have the cab walls use one material and the controls use a different material. One image will just be a copy of the main one but with a different filename to preserve the multiple entries. On export, since I have to edit the wiper animation length, animated part names, texture paths, and texture extensions anyway, I will change the dummy entry to point to the main image. Problem solved.

[Jonatan]

I use an alpha texture for my window planes, which are separate parts linked to the cab and with their own material and texture. Still no luck. I'm using Gmax.

The last resort would be to export the window planes as an FA and see if it works that way, an animated fire FA seems to show up in the cabview..

[ErickC]

Do you want the 70-tonner test export scene and exported model as an example? I could Dropbox 'em for ya.

[akioyamamura]

ErickC, on 11 November 2022 - 09:36 PM, said:

Do you want the 70-tonner test export scene and exported model as an example? I could Dropbox 'em for ya.

Please, if you could send me too I would be grateful. I tried everything too solve this problem unsuccessfully.

[ErickC]

Unfortunately the more I test the more I realize that the problem as it stands is unsolvable, especially as cabs become more functional. I can get the windows to work right if the camera is in a very specific spot and if the condition of the switches in the cab is very specific. But if I turn the gauge lighting on (which uses the cab light switch), the distance needed for parts to display correctly decreases significantly and we're back to 1-bit alpha for everything outside that narrow radius. The solution would be to move the pivots so they're all within a short distance of the seat at all times, sure, but OR was designed to allow us to move around the cab - so what's the point of even having a 3D cab if you have to constrict the seat position and the camera movement?

I think the reality is that TS20xx, for all its faults, is starting to look pretty good right now.