[Eldorado.Railroad]

Preamble: I will have to make comparisons with MSTS/MSTS Bin here. Although it has been expressed elsewhere that OR is designed to be an improvement over the original sim, it is important in this persons view that at least some things correspond with the older sim. With that idea expressed, if there are paradigm shifts where there are clear improvements, however painful to accept initially, I am not the one to stand in the way of such progress. This exercise might be a complete waste of time, because James will tell me that it is a bug and it has been fixed for the next release!

As I recall/observed, v360 had half-bright and bright "correctly" translated WRT MSTS. Namely, when the sun went down you could still see those parts of the model that had those materials. I also noted for v360 that darkshade was not working properly in that version (v677 has fixed darkshade, thanks!).

v677 displays or doesn't display half-bright/bright the same way as v360 or MSTS. I think I can say that half-bright does not work at all and that bright looks more the way half-bright looks in MSTS. This is very noticeable at night in the sim. Whereas half-bright in MSTS would show a nice dim quality at night (eg: number boards, etc) v677 just goes black. Bright seems to work better in OR v677, but still looks pretty dim compared to MSTS. With those observations expressed, I am not enamoured of the MSTS way of displaying half-bright or bright, but there are clearly somethings that have been broken. Some modellers use those materials for internal cab use which look very nice at night, but are completely lost in OR. At the moment, I am working with a models number board. The bright material works from day to night, but unlike MSTS cannot be seen if there is an alpha translucent material over it (I.E. glass).

If OR is designed that way, I think it is useful that there be some ambient light response for half-bright and bright as it appears to be more "natural" But fading to black should not happen, if there is to be compatibilty with MSTS' models. If anything I am sure that the model maker would love to see more materials available to him/her to work with. I hope that an upcoming release of OR will now include some OR specific data/ini/shape files that will release us from the shackles of MSTS.

thank you for your time and effort,

Eldorado

[James Ross]

The intention has always been - and continues to be - to as closely match MSTS(Bin) as is reasonably possible. The biggest problems are that there is no detailed spec on what that actually is and running MSTS(Bin) to test things is painful at best (and doesn't currently run at all on my machine).

The following represents what V677 and the current development versions do (it hasn't changed):



Unless and until someone can properly specify what the behaviours should be, I cannot make any improvements (and they must be specified in absolutes, not "what X does in version Y").

[Eldorado.Railroad]

James Ross, on 23 July 2011 - 06:34 AM, said:

The intention has always been - and continues to be - to as closely match MSTS(Bin) as is reasonably possible. The biggest problems are that there is no detailed spec on what that actually is and running MSTS(Bin) to test things is painful at best (and doesn't currently run at all on my machine).

The following represents what V677 and the current development versions do (it hasn't changed):

orts_811.jpeg

Unless and until someone can properly specify what the behaviours should be, I cannot make any improvements (and they must be specified in absolutes, not "what X does in version Y").

What does happen in MSTS Bin for half-bright and full bright is:

1) Visible day and night with their respective brightness.

2) Visible behind transparent or translucent material. In the case of translucent material it is a given that the brightness seen is governed by the opacity created by the alpha channel.

3) Does not have any specular/shadow response, but that "would be a nice" to have in OR. This is an enhancement that does not kill any compatibility with MSTS models.


WRT to the table you have kindly provided I don't see a clear relation to the MSTS, normal, loshine, hishine, and I assume that vegetation is correlated with CRCform.

thanks for your time and interest in this subject,

Eldorado

[James Ross]

Eldorado.Railroad, on 27 July 2011 - 11:29 AM, said:

1) Visible day and night with their respective brightness.

Sounds like I need to put 0 in the Day/Night column for half/full-bright then. Any idea if overcast should be applied to them or not? (Currently it is, per the table.)

Eldorado.Railroad, on 27 July 2011 - 11:29 AM, said:

2) Visible behind transparent or translucent material. In the case of translucent material it is a given that the brightness seen is governed by the opacity created by the alpha channel.

Alpha masking and alpha blending are unrelated to the material types in this topic; we do have problems always rendering alpha blended items in the correct order (which can make some things that should be visible behind them invisible when looking through the alpha blending) but it's not because of a specific material type.

Eldorado.Railroad, on 27 July 2011 - 11:29 AM, said:

3) Does not have any specular/shadow response, but that "would be a nice" to have in OR. This is an enhancement that does not kill any compatibility with MSTS models.

I'll have to see how this looks, but you may well be right that it won't be a big issue.

Eldorado.Railroad, on 27 July 2011 - 11:29 AM, said:

WRT to the table you have kindly provided I don't see a clear relation to the MSTS, normal, loshine, hishine, and I assume that vegetation is correlated with CRCform.

The table is the internal OR names for the shaders, sorry.

• Image: The default scenery shader which is used unless one of the others applies (used for e.g. water too).
  
• Terrain: The terrain patches all use this.
  
• Vegetation: Used for any cruciform scenery, including forests.
  
• Dark Shade: Used for lighting model "DarkShade".
  
• Half Bright: Used for lighting model "OptHalfBright".
  
• Full Bright: Used for lighting model "OptFullBright".

And the lighting models OR knowns about have the following values in shape files (I'm no expert on shape files so I hope these values are recognisable):

• DarkShade: -12
  
• OptHalfBright: -11
  
• CruciformLong: -10
  
• Cruciform: -9
  
• OptFullBright: -8
  
• OptSpecular750: -7
  
• OptSpecular25: -6
  
• OptSpecular0: -5

[Eldorado.Railroad]

James Ross, on 29 July 2011 - 10:31 AM, said:

Sounds like I need to put 0 in the Day/Night column for half/full-bright then. Any idea if overcast should be applied to them or not? (Currently it is, per the table.)

You have me at a disadvantage here because although I know exactly what this is:

• DarkShade: -12
  
• OptHalfBright: -11
  
• CruciformLong: -10
  
• Cruciform: -9
  
• OptFullBright: -8
  
• OptSpecular750: -7
  
• OptSpecular25: -6
  
• OptSpecular0: -5

I still do not grasp the one to one relationship of ORs table with the Kuju counterparts.

Especially:

• OptSpecular750: -7
  
• OptSpecular25: -6
  
• OptSpecular0: -5

The table only lists Specular but not the two intensities. I assume that Diffuse in the table equates to OptSpecular0: -5.
I can only take a guess at both Overcast and Fog, which I assume have nothing to do with the shaders in the model but more to do with the lighting environment provided for in OR. Please explain your methodology here so that I (and others like myself) can collaborate with you in an intelligent manner on this side. :sweatingbullets:

James Ross, on 29 July 2011 - 10:31 AM, said:

Alpha masking and alpha blending are unrelated to the material types in this topic; we do have problems always rendering alpha blended items in the correct order (which can make some things that should be visible behind them invisible when looking through the alpha blending) but it's not because of a specific material type.

Yes I can see that from version to version of the public release. Some payware models used construction techniques that seem to be at odds with newer rendering techniques and I think that OR has its hands full with backwards compatibility. If a modeler knew what the rendering precedence was for his/her models in OR one could follow the guidelines to create a model that would work consistently in the visual department. In my case, where 3D Crafter (aka 3D Canvas) is used to export the model into the MSTS form I have often wished for much more control as to how the shapefile is output.

A small addendum for the Specular/Shadow response for bright and half-bright is that this would allow for a "glass over look" for polygons that are covered with said materials. This would save the extra polygons now needed to render that effect. eg number boards. Perhaps all of this will be moot when bump maps are included as part of an OR extended shape.

thank you for your interest and response,

Eldorado

[James Ross]

Eldorado.Railroad, on 30 July 2011 - 08:34 AM, said:

The table only lists Specular but not the two intensities. I assume that Diffuse in the table equates to OptSpecular0: -5.
I can only take a guess at both Overcast and Fog, which I assume have nothing to do with the shaders in the model but more to do with the lighting environment provided for in OR. Please explain your methodology here so that I (and others like myself) can collaborate with you in an intelligent manner on this side. :sweatingbullets:

OptSpecular0, OptSpecular25 and OptSpecular750 all go through the "Image" shader; this shader applies specular lighting based on which OptSpecular is used. None of the other types get any specular lighting, as they all go through other shaders.

Each column of the table is a part of OR's rendering, and the table is only to indicate which parts are applied in each shader, not match up to MSTS data (I made the table for something else but it represents what the code does so is relevant for any changes here).

Diffuse, shadows and specular should be clear what they do; overcast is a special "dulling out" effect used in OR for rain and snow environments; day/night is an ambient lighting that fades in/out during sunset/sunrise; headlights are the train headlights, and fog is the distance-based fading-to-gray effect.