Train windows opacity does not work correctly

Bug #1085675 reported by Carlo Santucci
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Open Rails
Fix Released
Wishlist
manjushree

Bug Description

Train windows opacity seems not to work correctly. Take as an example the swiss ETR610 high speed tilting train, that can be downloaded from here: http://www.trainsimhobby.net/infusions/pro_download_panel/file.php?did=985&file_id=1011
Referring to external view every carriage of the train has two shapes: the first element of the train has as shape SBB_CFF_FFS_Etr610-106.s plus a second shape, that appears in the .eng file as FreightAnim, and has as name SBB_CFF_FFS_InterniP1.s .
The two shapes are "superimposed" The window openings are transparent in the first shape and have an alpha-channel in the second one. In the annexed .zip you see in file ETR610_Shapeviewer.jpg how the first element of the train shows up in Shape viewer, after having loaded the two shapes. In MSTS the result is more or less the same. In ORTS however the windows appear completely opaque, as can be seen in file ETR610_ORTS.jpg (also contained in the annexed .zip file).
The opacity is controlled by file vetro.ace . I have tried to reduce opacity. Up to a certain degree of reduction nothing changes in ORTS (in Shape Viewer the transparency of course increases). If the opacity is reduced below a certain threshold the windows begin appearing completely transparent.
So only two states seem to appear in ORTS: either completely opaque or completely transparent.
Same happens in other trainsets.

Tags: graphics
Revision history for this message
Carlo Santucci (carlosanit1) wrote :
Revision history for this message
James Ross (twpol) wrote :

My guess is that the material flags for the windows with the alpha blending texture only have "alpha masking" enabled, not blending; whether that's a mistake in the shape file or OR's interpretation of it will have to wait for someone to inspect the shape file.

Revision history for this message
Carlo Santucci (carlosanit1) wrote :

To ease your analysis I annex here the SBB_CFF_FFS_Interni1.s shape file managing the alpha glass window. As already stated, the related .ace file is vetro.ace .

Revision history for this message
James Ross (twpol) wrote :

The shape file defines the windows to be rendered with the BlendATexDiff shader (alpha blending and diffuse lighting) AND sets the alpha-test flag. In OR, setting alpha-test overrides alpha blending (alpha testing is significantly faster and preferred for cut-out shapes over alpha blending).

It's not clear whether the intention of the shape file with this combination is to enable both features at once (possible but just wastes resources) or if it's just a mistake/error in an exporter. I might have a scan through all my downloaded content to see if this crops up elsewhere before making any changes.

Changed in or:
status: New → Confirmed
Revision history for this message
Wayne Campbell (wayneinbc) wrote :

Generally in 3D rendering, special handling must be provided when an alpha'd object is rendered behind a second alpha'd object. Or in other words if one alpha object occludes another alpha object. The alpha'd objects must be drawn in order starting with the farthest from the camera.

Since the camera can move from frame to frame, this requires an expensive 'per frame' sort be done on the alpha'd primitives.

.S files have a flag in the subobject header to indicate when such alpha sorting is required.

However not every alpha poly needs to be sorted. The .s file may omit the sort flag for alpha poly's under certain conditions ( ie if the builder is certain the alpha poly will be backed by an opaque poly included in the same model ) For these alpha poly's marked as unsorted, MSTS relies on the drawing order of the primitives to ensure proper rendering.

OR currently has two shortcomings in rendering wrt matching MSTS's appearance:

1. Unsorted alpha'd poly's are not rendered in the same primitive order as MSTS would render them.

2. We don't check the sort flag and have no sorting mechanism for alpha'd poly's ( other than drawing them all last, but in random order ).

Revision history for this message
James Ross (twpol) wrote :

Fixed in V1373.

Changed in or:
assignee: nobody → James Ross (twpol)
status: Confirmed → Fix Committed
milestone: none → 0.9
Revision history for this message
James Ross (twpol) wrote :

Unfixed in V1403 as this change causes massive performance degradation elsewhere by classifying much more scenery as blended (slower code path), sorry.

We'll continue to look at ways to fix this but it might just have to be fixed in the model.

Changed in or:
status: Fix Committed → Triaged
importance: Undecided → Wishlist
milestone: 0.9 → none
Revision history for this message
Carlo Santucci (carlosanit1) wrote :

Sigh... could you kindly give me a hint on what I have to edit in the .s file to be compatible with this way of alpha-management?

Revision history for this message
James Ross (twpol) wrote :

The window primitives in the shape have the alpha-test flag set, but they actually want alpha blending. Disabling this flag will enable blending (because it is using a blended-enabled shader). I can explain exactly where this is in the shape file format but can't tell you how to fix this in any tooling/editors.

Revision history for this message
Carlo Santucci (carlosanit1) wrote :

Thanks James,
if you explain me where the alpha-test flag is within the .s file structure this is enough for me.

Revision history for this message
James Ross (twpol) wrote :

Inside the shape, there are four prim_state blocks (inside prim_states, inside shape). These have a bunch of values but the interesting one is last-but-two - this is the alpha test flag. The two prim_state blocks called "Vetro_TransBright" and "Vetro_TransNorm" use the alpha blending shader (this is identified by the second value in the block, a '1' in this case) but also enable alpha test with a '1' in the last-but-two position. The data I see here is:

prim_state "Vetro_TransBright" ( 0 1 tex_idxs ( 1 0 ) 0 0 1 0 1 )
prim_state "Vetro_TransNorm" ( 0 1 tex_idxs ( 1 1 ) 0 1 1 0 1 )

and you want to change it too:

prim_state "Vetro_TransBright" ( 0 1 tex_idxs ( 1 0 ) 0 0 0 0 1 )
prim_state "Vetro_TransNorm" ( 0 1 tex_idxs ( 1 1 ) 0 1 0 0 1 )

Hope that helps.

Revision history for this message
Carlo Santucci (carlosanit1) wrote :

Thanks James,
that's the info I needed. I will try it.

Regards

Carlo

Revision history for this message
Carlo Santucci (carlosanit1) wrote :

hi James,
that works, thank you.

Carlo

James Ross (twpol)
Changed in or:
assignee: James Ross (twpol) → nobody
James Ross (twpol)
tags: added: graphics
removed: alpha channel opacity
Revision history for this message
Peter Gulyas (pzgulyas) wrote :

Carlo,

Is this bug still valid? This might have been fixed by Wayne's alpha bits checking code. I don't remember the release, but please see code in Materials.cs SceneryMaterial.GetBlending(), from line 715.

Revision history for this message
Carlo Santucci (carlosanit1) wrote :

Peter,
in fact the bug has disappeared. I returned to the original .s files and got the transparency working as required. Thank you.

Revision history for this message
James Ross (twpol) wrote :

Glad we got this sorted out.

Changed in or:
status: Triaged → Fix Committed
milestone: none → 0.9
James Ross (twpol)
Changed in or:
status: Fix Committed → Fix Released
Changed in or:
assignee: nobody → manjushree (ganekall123456)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.