Problem with Color and EmissiveColor commands

Hi!

In the new 1.7.1.6 version I have a problem with Color and EmissiveColor commands:
I use a white base for displays in vehicles and I color afterwards with these commands.
Like this:

Code:

[MeshBuilder]
Vertex 0.625,3.105,4.233
Vertex 0.625,2.9,4.233
Vertex -0.625,2.9,4.233
Vertex -0.625,3.105,4.233
Face 3,2,1,0
[Texture]
Load ../_kijelzo/01_1.png
Coordinates 0,0,0
Coordinates 1,0,1
Coordinates 2,1,1
Coordinates 3,1,0
Color 100,250,20
EmissiveColor 100,250,20


An example for display pics:


And the problem is:
The colors in the two versions (1.7.1.5 /first column/ vs 1.7.1.6 /second column/) do not match:


Color commands:
Turquoise:
Color 35,250,102

EmissiveColor 35,250,102
Orange:
Color 255,70,0
EmissiveColor 255,110,0
Green:
Color 100,250,20
EmissiveColor 100,250,20

Thanks in advance!

if you want the texture  to stay at full strength regardless of lighting (day/night) you might find it better to forget color and simply load a daytime and a night time texture (which can be one and the same.
Try this, without specifying either normal or emissive color:
[texture]
Load ../_kijelzo/01_1.png, ../_kijelzo/01_1.png

graymac wrote:if you want the texture  to stay at full strength regardless of lighting (day/night) you might find it better to forget color and simply load a daytime and a night time texture (which can be one and the same.
Try this, without specifying either normal or emissive color:
[texture]
Load ../_kijelzo/01_1.png, ../_kijelzo/01_1.png

First, please don't do that
This is taking advantage of an unintentional lighting 'bug', which has actually caused quite a PITA to reproduce in GL3.0.


The correct / supported method of getting that effect is to simply declare the face as emitting pure white, e.g.

Code:

EmissiveColor 255,255,255

I can see the issue with the color change (only on GL3.0 renderer), am trying to get to the bottom of it.

I *really* hate GL lighting
Going yet deeper into this rabbit hole, it seems we weren't taking account of the GL.LightModel parameter in the shader (which predicatably isn't the default, otherwise this wouldn't have happened).

Try the build from today:
https://vps.bvecornwall.co.uk/OpenBVE/Builds/OpenBVE-2020-06-06.zip

I don't think this has broken anything else, but stand to be corrected.....

It's better, but not the same. Maybe it's somewhere in the middle between the two:
/middle column/


An interesting thing:
In Object Viewer, with new renderer it displayed correctly.

This build has a little more fiddling, but primarily aimed at objects with both a daytime / nighttime texture:
https://vps.bvecornwall.co.uk/OpenBVE/Builds/OpenBVE-2020-06-07.zip

Potentially stupid question:
What does the *old* renderer look like?

This should now very nearly match the current output of the new renderer.

I was take some new pic:

In my opinion the correct is the Object Viewer.

An idea:
Can the lighting settings of the route also change it? An illuminated surface should not change from it (if I remember correctly that was the case in the old versions).

Yet another try, we might have something here:
https://vps.bvecornwall.co.uk/OpenBVE/Builds/OpenBVE-2020-06-08.zip

I've fiddled (again....) with some more things, and I *think* the new renderer is now an exact replica of the old.
This also alters the unlit polygon hack to avoid producing off-color polygons under some circumstances.


NOTE:

Object Viewer and Route Viewer deliberately do not apply the two-textures hack.
To produce approximately the same effect, please use an emissive color of 255,255,255

It seems ok.

But I don't know, if I see an illuminated surface from two different angles, why has it different colors too?

Possible effect of directional lighting parameters?

I've been thinking about this before, too. But a luminous surface should not change from that.