Dynamic Lighting & Backgrounds, based upon the time of day

Another one of those missing features from openBVE has always been a proper lighting model, which can alter the lighting dynamically based upon the time of day, and handle tunnels appropriately.

The most recent nightly goes some way to rectifying that issue, and I'd appreciate feedback upon this
(23rd October 2016 or newer)

Developer Implementation:


Routefile:

1. Delete the existing Route.AmbientLight() , Route.DirectionalLight() and Route.Direction() values.
   
2. Add the new parameter Route.DynamicLight() this must point to the lighting definition file (Explained below)
   
3. Alter your existing .Brightness values to assume a base light value of 255.
   

Lighting Definition File:
This is a new XML based format. First, let's have a very basic example:

Code:

<?xml version="1.0" encoding="utf-8"?>
<openBVE xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Brightness>
        <Time>00.00</Time>
        <AmbientLight>0,0,0</AmbientLight>
        <DirectionalLight>0,0,0</DirectionalLight>
        <LightDirection>0.223606797749979, 0.86602540378444, -0.447213595499958</LightDirection>
        <CabLighting>80</CabLighting>
  </Brightness>
  <Brightness>
        <Time>12.00</Time>
        <AmbientLight>160,160,160</AmbientLight>
        <DirectionalLight>160,160,160</DirectionalLight>
        <LightDirection>0.223606797749979, 0.86602540378444, -0.447213595499958</LightDirection>
        <CabLighting>255</CabLighting>
  </Brightness>
</openBVE>

As you can hopefully see, the XML file consists of a series of sections.
Each of these defines the world lighting conditions at a specified point in time:

• Time : The 24-hour based time for which this lighting definition refers.
  
• AmbientLight : The ambient lighting you wish to use at this point.
  
• DirectionalLight : The directional lighting you wish to use at this point.
  
• LightDirection : The direction of the directional light at this point.
  
• CabLighting : The MAXIMUM cab brightness value at this point.
  

In-Game:
A simple cosine based interpolation curve is used to interpolate the current lighting values.
The cab brightness is the MINIMUM of the interpolated cab brightness value, and that set by the routefile.

Video




The video above shows the 158 running through a cab brightness cycle on my test route, and hopefully should demonstrate what I'm on about

Chris, this is going to be another fantastic new feature of the sim, besides the TrackFollowerFunction, working bogies, the package management system, etc. It looks very exciting and I'll definitely play with it when I have time.

I like the idea Chris, so given that the Dynamic Lighting is put into place, would it bring along the introduction of headlight reflections at some point? Just out of interest

Just tested the feature and I am very impressed! It really makes tunnel creation easier. So far I have not found any issues, but there is something that gave me some trouble.

The .LightDirection command in CSV routes uses spherical coordinates (theta and phi) to set the position of the light source. However, the new LightDirection command in the XML file uses Cartesian coordinates (x, y and z) instead. The conversion between the two systems is not difficult (the formula even appears in the official OpenBVE developer documentation), but using different units for the same function may be confusing. Imagine using miles per hour, kilometers per hour or meters per second depending on the command, it would be the same.

I would stick to spherical coordinates (which have been used until now in CSV routes). If someone prefers Cartesian coordinates, they just have the formula to make things easier.

Oops, that was a minor oversight; openGL works in cartesian co-ordinates, and they're IMHO much easier to deal with
Choice is always better though!

Couple of small improvements for today's build:
The following formats may be used for LightDirection:

1. CartesianLightDirection : Specifies the light direction using cartesian co-ordinates.
   
2. LightDirection : Specifies the light direction using cartesian co-ordinates.
   
3. SphericalLightDirection : Specifies the light direction using spherical co-ordinates. (As per current routes)
   

Light colors will now take a hexadecimal color as an alternative to a RGB color.

Now added to the main developer documentation.

A direct link to the page describing Dynamic Lighting is here:
http://openbve-project.net/documentation/HTML/route_dynamiclight.html

I've tried to keep it in the same format as Michelle used, and hopefully it's reasonably understandable, but please let me know if otherwise.

Northern Line wrote:I like the idea Chris, so given that the Dynamic Lighting is put into place, would it bring along the introduction of headlight reflections at some point? Just out of interest

That would require an update of the object format, or the implementation of a new format, plus work in the engine; Not at present, but I haven't forgotten it either.

Technicalities:
CSV and B3D objects don't define a specular map. Whilst it's possible to define a specular map with X format objects, the current parser doesn't read it.
The emissive color is also somewhat of a hack, as it's internally generating the emissive map that the texture shader needs from the texture.

I get this error in the loading screen using the AnimatedObjectDemonstrationRoute.csv


Unexpected XML declaration. The XML declaration must be the first node in the document, and no white space characters are allowed to appear before it. Line 1, position 5.

Where should the dynamic lighting file go?

It's OK. I think it was just a cut and paste error.

Do I understand correctly that you can, but needn't restrain to two steps? Meaning you could also define intermediary steps to create colourful sunrises and sunsets or full moon light night?
Wouldn't it make sense to optionally allow to set corresponding sky textures? Or even return the currently closest step as a value to the route itself, so you can use time- and location-dependant sky textures (sensitive if you want to include the skyline of a distant city via the sky texture)?

This is an excellent addition which I have tested. I tested it by adding it to a few min period but after this period it repeats this sequence repeatly. I particularly like being able specify different LightDirection values especially when the sun is low. I used 3 time points when testing this.

One thing that would be good to see is making the lighting sequence random to simulate different day lengths and sunrise/set times maybe by referencing several different files and picking a random one.

Marc Riera wrote:Just tested the feature and I am very impressed! It really makes tunnel creation easier. So far I have not found any issues, but there is something that gave me some trouble.

How does it make tunnel creation easier? In what way have you used it so far? I am curious about the potential of this feature.

Quork wrote:Do I understand correctly that you can, but needn't restrain to two steps? Meaning you could also define intermediary steps to create colourful sunrises and sunsets or full moon light night?
Wouldn't it make sense to optionally allow to set corresponding sky textures? Or even return the currently closest step as a value to the route itself, so you can use time- and location-dependant sky textures (sensitive if you want to include the skyline of a distant city via the sky texture)?

It should support essentially unlimited lighting steps if you so desire.
I've tested with 6, but there's nothing limiting you adding more.

Corresponding sky textures is on the longer term list, as this is a little more complex-
Most of the framework is in place already, but in order for this to work properly, in the worst case scenario, you'd need a blend between 4 textures.

ecreek wrote:

Marc Riera wrote:Just tested the feature and I am very impressed! It really makes tunnel creation easier. So far I have not found any issues, but there is something that gave me some trouble.

How does it make tunnel creation easier? In what way have you used it so far? I am curious about the potential of this feature.

Take a daytime route.
Here you'll probably want to use a brightness value of ~200 outside of your tunnels.
Inside the tunnels, you'll want a brightness value of ~80.

Now take the nightime route:
Outside you might want a brightness value of ~120.
In the tunnel you still want a brightness value of ~80.

In order to do this with original BVE routefiles, you need to create a separate routefile for each timeperiod, and remember to alter all .Brightness values appropriately. If you're also using shading under bridges, this might be several hundred brightness commands to alter for each set of lighting conditions.


On the other hand, with the new lighting XML, all lighting levels are dealt with automatically.

Take our tunnel example:
The single routefile needed is built with an outside brightness of 255. 
In daytime, the maximum cab brightness is 200, and so it is capped at that. When night comes around, the outside brightness drops, and the cab lighting is adjusted appropriately
Our tunnel is on the other hand always built with an interior brightness of 80. This is below both the daytime and nightime maximum values, and hence the cab will always darken to the correct level.

It also means that we don't require hacks to alter the exterior lighting level-
It's possible to use a combination of fog and a lower brightness value to partially simulate the overall exterior light changing, but this then in turn causes issues with tunnels.

I did some more testing of this using 5 time points. Some of these times are before the starting time of the route and some of the times are after the starting time of the route. It seems that the sequence starts at the first time in the lighting file which doesn't seem to correspond with the current in game time assuming I have done this right.

Changing the start time in the route file to a later time without changing the lighting file results in no change in the brightness. In the lighting file I have the brightness increasing over time and I would have expected to see the scene brighter at this later time.

When you get to the last time does the brightness stay at this amount? As I wondering when I did the test of a few minutes period it would repeat the sequence repeatedly continuously even for times after the last time period.

MattD6R wrote:I did some more testing of this using 5 time points. Some of these times are before the starting time of the route and some of the times are after the starting time of the route. It seems that the sequence starts at the first time in the lighting file which doesn't seem to correspond with the current in game time assuming I have done this right.

Changing the start time in the route file to a later time without changing the lighting file results in no change in the brightness. In the lighting file I have the brightness increasing over time and I would have expected to see the scene brighter at this later time.

When you get to the last time does the brightness stay at this amount? As I wondering when I did the test of a few minutes period it would repeat the sequence repeatedly continuously even for times after the last time period.

Hmm, something doesn't seem right.
At the minute, I'm not sure if it's your understanding, or a bug

Can I see your XML please, and have the time you're using as the route start?


This is a simplified description what should happen, assuming an XML containing entries for 00:00 , 09:00 , 12:00 and 18:00
Our route starts at 10:00.

1. The XML is sorted by time once parsed.
   
2. The XML entry containing the 'current' time-slot is selected. (09:00 is selected)
   
3. The brightness value is then interpolated with that of the next time-slot. (The values for 09:00 and 12:00 are interpolated, based upon the fact that we're 1/3 of the way between those two times)
   

Once the last time-entry is reached, it will then interpolate with the first, and the cycle will then repeat. (The values for 18:00 and 00:00 are interpolated)
Obviously, using the example times above, it'd take several hours to get back to the 0:00 brightness.

I modified your sample changing the times and the ambient light values. I havn't worried about any of the other variables at the moment. Below is the code of the 5 time points test I did:

Code:

<?xml version="1.0" encoding="utf-8"?>
<openBVE xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Brightness>
        <Time>00.00</Time>
        <AmbientLight>0,0,0</AmbientLight>
        <DirectionalLight>0,0,0</DirectionalLight>
        <LightDirection>0.223606797749979, 0.86602540378444, -0.447213595499958</LightDirection>
        <CabLighting>80</CabLighting>
  </Brightness>
  <Brightness>
        <Time>05.00</Time>
        <AmbientLight>20,20,20</AmbientLight>
        <DirectionalLight>160,160,160</DirectionalLight>
        <LightDirection>0.223606797749979, 0.86602540378444, -0.447213595499958</LightDirection>
        <CabLighting>255</CabLighting>
  </Brightness>
  <Brightness>
        <Time>06.00</Time>
        <AmbientLight>60,60,60</AmbientLight>
        <DirectionalLight>160,160,160</DirectionalLight>
        <LightDirection>0.223606797749979, 0.86602540378444, -0.447213595499958</LightDirection>
        <CabLighting>255</CabLighting>
  </Brightness>
  <Brightness>
        <Time>07.00</Time>
        <AmbientLight>90,90,90</AmbientLight>
        <DirectionalLight>160,160,160</DirectionalLight>
        <LightDirection>0.223606797749979, 0.86602540378444, -0.447213595499958</LightDirection>
        <CabLighting>255</CabLighting>
  </Brightness>
  <Brightness>
        <Time>09.00</Time>
        <AmbientLight>140,140,140</AmbientLight>
        <DirectionalLight>160,160,160</DirectionalLight>
        <LightDirection>0.223606797749979, 0.86602540378444, -0.447213595499958</LightDirection>
        <CabLighting>255</CabLighting>
  </Brightness>
  <Brightness>
        <Time>10.00</Time>
        <AmbientLight>160,160,160</AmbientLight>
        <DirectionalLight>160,160,160</DirectionalLight>
        <LightDirection>0.223606797749979, 0.86602540378444, -0.447213595499958</LightDirection>
        <CabLighting>255</CabLighting>
  </Brightness>
</openBVE>


The starting time is 07.54 in my WIP route. I changed the time to 09.54 but the brightness was still very dark.

The XML of the few min test I don't have anymore but just to see the change in brightness I made the AmbientLight something like this:
7.54 0
7.55  80
7.56 160

This wouldn't of course be used in general use.

Then after 7.56 the brightness reduced to nothing and then back to the full brightness over several minutes then back to full brightness and then reduced to nothing over several minutes and kept on repeating this over and over.

My fault

Instances where the brightness value wrapped around between the last and first members of a longer array were somewhat broken, and so I had to change the approach slightly. (Hadn't thought of that )

I think the latest build should fix things.

Thanks Chris. Both of the previous tests I did now work correctly with brightness increasing over time. The 5 time point test worked at different times correctly only to around the last time point. After that time it reduced brightness but seems to be behaving correctly as it being interpolated with the first time.

Chris, the dynamic lighting doesn't apply to the background. Wouldn't it be good if it did? Or what is the rationale behind not applying it to the background?

Do you mean the sky? The sky texture should be adequate to the time. Especially at dawn and dusk the sky is way brighter than the rest. Dimming it would be no good at all IMHO.

phontanka wrote:Chris, the dynamic lighting doesn't apply to the background. Wouldn't it be good if it did? Or what is the rationale behind not applying it to the background?

To be exact, I think you'll find that the directional light doesn't apply to the background (sky), but the ambient light affects it's overall perceived brightness to a certain degree
A skybox (Which is effectively what our background frustrum is a variant of) shouldn't reflect the diffuse lighting in the scene, so I agree with Quork that if you're looking to play with this sort of effect the background texture should be changed as appropriate.

Time based backgrounds are coming, but there's a little more work involved than just lighting.

I've just hit another major milestone today:


I know this doesn't actually look like anything much ( ), but the important thing is that the background here is actually an object, rather than a texture wrapped around!
Dynamic background switching also now works nicely.


Need to clean the code up and check for errors & stupid mistakes before this is ready for public consumption, but this should also help with getting BVE5 routes running.

Cheers

Current nightly now has dynamic backgrounds

First, a sample XML:

Code:

<?xml version="1.0" encoding="utf-8"?>

<openBVE xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Background>
        <Time>00.00</Time>
        <Mode>FadeIn</Mode>
        <Repetitions>6</Repetitions>
        <Texture>Cloudy.png</Texture>
  </Background>
  <Background>
        <Time>10.00</Time>
        <Mode>FadeIn</Mode>
        <Repetitions>6</Repetitions>
        <Texture>Sunny.png</Texture>
        <TransitionTime>10</TransitionTime>
  </Background>
</openBVE>

These are a little different to the lighting configuration, and the available parameters are explained below:

• Time: Sets the time at which the transition to this background will begin.
  
• Mode: May be set to FadeIn , FadeOut or None. This controls the transition effect between backgrounds.
  
• TransitionTime: The time in seconds which the transition takes. (Standard backgrounds use a 0.8s fade-in)
  
• Texture: The texture to use.
  
• Repetitions: The number of times the texture is repeated around the viewing frustrum.
  

Background objects are also supported, albeit non-dynamic.
Sample code for this is as follows:

Code:

<?xml version="1.0" encoding="utf-8"?>

<openBVE xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Background>
        <Object>Background.b3d</Object>
  </Background>
</openBVE>

• Object: The object to use. (B3D, CSV or X only. No .animated support)
  

This also fixes one erronious error message when using Dynamic Lighting.

Are you planning to enable location- and time-dependant background as well? The easiest thing for that would be, IMHO, to pass a variable from the route to the backgrounds file.
Or is it possible, which would be the best solution, to call multiple background files in the route, just like background textures in the classic format?

That's exactly what this does, probably wasn't clear enough about the exactitudes of the XML usage

Suppose the following code:

Code:

With Texture.Background(0)
    .Load(TestRoute\Background.xml)
With Texture.Background(1)
    .Load(TestRoute\Background2.png)
    .Aspect(1)


When Background 0 is selected in the route, the dynamic background (Sample above) will be used.
When Background 1 is selected, the texture will be used.

Implementation within the route file is no different to previously, and should behave in exactly the same way.

Perfect! That's really great work =)