[eugenR]

This is the most used Signalsystem in German freeware Routes.
German users complain about this problem with this signalsystem in different occasions, but until yet unfortunately without an exact description.
See here (in German)
http://www.tssf.eu/f...p?topic=10937.0
see lines 15,16 (translated):
“It's a pity, that the signal lights of the most recent Signal set of Dennis K. are extremely dark, and in the night they aren't recognizable.”

The Signals use two types of Signallights.
a ) Usual Lights defined in the sigcfg.dat
SignalLight ( 0 "Gruen" Position ( 0.15 0.65 0.045 ) Radius ( 0.165 ) )
b ) Signallights defined as "Semaphore": a coloured brick is moving from the underground to the Light position
This "Semaphore"-Lights shine well day and night in MSTS, but they DON'T SHINE in OR.

With the kind help of an OR developer the following reason has been found:
In the shapes there are two definitions for shader and brightness:
• ShaderNames : names of the used shaders, as: Tex, Texdiff ……
• "LightMatId" : the -5 value in red in vtx_state.(see below)

The shining Bricks are textured with:
Shader Tex, BlendATex, or AddATex
and
vtx_state ( 00000000 9 -5 0 00000002 )
-5 = in gmax corresponds in the standard Lighting Palette to OptSpecular0

MSTS always uses (day and night) for shaders Tex, BlendATex and AddATex
the brightness "Bright", independently of the LightMatId ( = -5)

In OR Shader and Brightness are completely separated:
• ShaderName defines only the used "Shader".
• Brightness is set only by 'LightMatId'

So, if a shape uses ShaderName = Tex and LightMatId = -5:
- In MSTS these areas always shine full bright
- But in OR the LightMatId must be set to -8 ("Bright") for the same result.

The Link to the german Signalsystem Dennis K.:
http://www.eisenbahn-signale.de/

As example see the attached Brick: Tex.s
Textures as the Lights in the Dennis K. Signalsystem.

Adapting OR to the MSTS way of operating would surely increase acceptance of OR in the German world.

Attached File(s)

•  Tex.zip (2.37K)
  Number of downloads: 183

[copperpen]

That may be the reason that no semaphores shine in OR.

[eugenR]

copperpen, on 09 July 2015 - 01:10 PM, said:

That may be the reason that no semaphores shine in OR.

Please decompress the shape with SFM, open it with an editor and see at the begin if you find Tex, BlendATex or AddATex, then it can be the same problem:
shape (
shape_header ( 00000000 00000000 )
volumes ( 2
vol_sphere (
vector ( 0 0.2 0 ) 0.363731
)
vol_sphere (
vector ( 0 0.2 0 ) 0.34641
)
)
shader_names ( 1
named_shader ( Tex )
)

[copperpen]

The first one I looked at has BlendATexDiff. It also has three vtx_states, one is -12 and two are -5

[eugenR]

copperpen, on 10 July 2015 - 12:39 AM, said:

The first one I looked at has BlendATexDiff. It also has three vtx_states, one is -12 and two are -5

-5 is the usual lighting for normal shapes, -12 is = darkshade in the 3D-Tool gmax I think too dark for a Signal light ??
But there are many ways to made Signallights in MSTS.

[James Ross]

eugenR, on 09 July 2015 - 11:59 AM, said:

MSTS always uses (day and night) for shaders Tex, BlendATex and AddATex
the brightness "Bright", independently of the LightMatId ( = -5)

That does seem a bit weird, but plausible; if someone wants to try it go to Shapes.cs around line 1311 where you'll find a dictionary called "ShaderNames", add "SceneryMaterialOptions.ShaderFullBright" to each of the above shader names and see what happens. :)

[Csantucci]

I have created a runactivity.exe and runactivityLAA.exe with the patch proposed by James.
If someone wants to check it, it's here.
 Runactivities.zip (1.24MB)
Number of downloads: 196
It should also be checked that this version does not negatively influence shapes that are not part of signals.

[Csantucci]

James Ross, on 10 July 2015 - 10:57 AM, said:

That does seem a bit weird, but plausible; if someone wants to try it go to Shapes.cs around line 1311 where you'll find a dictionary called "ShaderNames", add "SceneryMaterialOptions.ShaderFullBright" to each of the above shader names and see what happens. :(

This is the patch:
 Shapes_bright.cs.patch.zip (424bytes)
Number of downloads: 196
Unfortunately this is what happens to someone (not only one person):
 Log.txt.zip (4.54K)
Number of downloads: 182

This occurs at line 774 of Materials.cs.
Maybe there is a shape that has ShaderVegetation on, which is ORed with ShaderFullBright causing an unaccepted 0x70 as shader mask?

[James Ross]

Csantucci, on 12 July 2015 - 08:28 AM, said:

This occurs at line 774 of Materials.cs.
Maybe there is a shape that has ShaderVegetation on, which is ORed with ShaderFullBright causing an unaccepted 0x70 as shader mask?

Hmm, could be. Try sticking an extra case in so you have this:

                case SceneryMaterialOptions.ShaderVegetation:
                case SceneryMaterialOptions.ShaderVegetation | SceneryMaterialOptions.ShaderFullBright:

And see if that works?

We may need to alter the behaviour if both are set but at least see if it runs.

[Csantucci]

OK,
this is a couple of runactivities with the above line added.
Re the former version, there was already a feedback about some trees shimmering like christmas trees, so something should be changed in case of vegetation and one of the three ...tex shaders.
 Runactivities.zip (1.3MB)
Number of downloads: 171