[Genma Saotome]

I agree in full -- "static" lights would be a great feature. Consider this: now, anything setup for night textures gets displayed according to the sun, not the clock. Adding some instructions in a .sd file (or eventually into the future version of a world file) could enable the route designer to specify the time of night for night textures to display -- both on and off. Even better, huh? Combine that with the ability to cast light... waaaay cool.

That said, while the potential is there but with any volunteer project it takes someone with an interest in the matter, time, skills, and a willingness to volunteer to do the task. Plenty of good ideas... not always enough hands to get everything done.

Hopefully this one gets picked up and implemented.

[Noisemaker]

Very cool indeed! ;) Out of curiosity, I've started using Vinnie Lanza's great Street Lights and such on my GTA route. But noticed some odd things of 'bleed through' when the lights are on overhead bridges and/or looking back at them with the headout view. Nothing too disconcerting, as it's 'one of those MSTS things'. Does OR tend to fix these lighting anomalies?

[James Ross]

DAve Babb, on 14 May 2012 - 03:16 AM, said:

I know that at the moment work is concentrated towards making OR run MSTS stock / activities at a comparable level, but at some point in the future would it be possible to have better functions for lighting in a route.
Your lighting effects for the cone light are much better than MSTS version, would it be possible to build light 'emitting' objects for placing in a route, such as street lights, yard flood lighting, station platform lights ?
I don't know how resource intensive this kind of lighting is, but the effect created currently with shadows is very impressive, it would be nice if we could create light to help improve the general feel of the environment during hours of darkness.

Creating multiple lights is a serious amount of work, unfortunately, but it's definitely what we want. That will include multiple train headlights and static scenery lights, when we get it.

Noisemaker, on 14 May 2012 - 09:00 AM, said:

Very cool indeed! :thumbup3: Out of curiosity, I've started using Vinnie Lanza's great Street Lights and such on my GTA route. But noticed some odd things of 'bleed through' when the lights are on overhead bridges and/or looking back at them with the headout view. Nothing too disconcerting, as it's 'one of those MSTS things'. Does OR tend to fix these lighting anomalies?

Some of the issues will be just the objects being static polygons, and some will be alpha sorting issues. Currently, OR has similar alpha sorting issues. We'll always look to improve it but there will probably always be anomalies like this.

[Noisemaker]

Thanks as well James. Not a big issue for me really. Just kinda odd looking back at the lights and how strange they are. But we should be looking forward mostly, whether MSTS or OR. :sign_sorry:

[Lindsayts]

Genma Saotome, on 14 May 2012 - 08:09 AM, said:

I agree in full -- "static" lights would be a great feature. Consider this: now, anything setup for night textures gets displayed according to the sun, not the clock. Adding some instructions in a .sd file (or eventually into the future version of a world file) could enable the route designer to specify the time of night for night textures to display -- both on and off. Even better, huh? Combine that with the ability to cast light... waaaay cool.

That said, while the potential is there but with any volunteer project it takes someone with an interest in the matter, time, skills, and a willingness to volunteer to do the task. Plenty of good ideas... not always enough hands to get everything done.

Hopefully this one gets picked up and implemented.

Now I do NOT like posting information unless I am 110% sure and as I have not yet done multiple lighting sources in OpenGL I am not sure but.......... So the OR developers are well come to shoot me down......
First point is in a computor program the author/s must write explicit intructions for ALL things they wish to do, to do everything takes a great deal of develpment time and most likely processing time.

In lighting for a single light source to produce lighting and shadows takes 2 passes of the data (this is why enabling shadows slows the frame so much), the first to generate the lighting the second to generate the shadows, For multiple light sources this all needs to be repeated for ALL light sources. Now this next bit is drawing bit of a "long bow" as I have not yet done multiple light sources, but for smaller light sources such as platform lights, loco headlights etc one will likely have to work out what it is lighting first to save having to calculate its effect on the whole world, so we now have in effect "collision detection" taking place, ie one has to work out what the light is colliding with. This being one of the more difficult and cpu intensive tasks.

Now I am NOT saying this should not be attempted or wished for but one needs to remember the the world is a VERY complex place and after all this is a real time SIMULATOR, in all including the best simulators one must take the mental leap of being in the simulation. It will very likely never be able to on a single desktop system to do everything to all peoples satisfaction.

Lindsay

Post Spript, The main reason for putting this post up is to try and illustrate how complex the whole task including lighting is so people do not start getting to many false hopes.

[James Ross]

Lindsayts, on 12 August 2012 - 01:31 PM, said:

Now I do NOT like posting information unless I am 110% sure and as I have not yet done multiple lighting sources in OpenGL I am not sure but.......... So the OR developers are well come to shoot me down......

Seems like a good explanation to me. Here are some interesting things I'd like to add:

• The headlight in OR does not cast shadows, so only needs 1 pass itself.
  
• But as it is calculated during the rendering of the scenery (i.e. every bit of scenery is drawn with knowledge of the headlight) we have to hand-code in each light.
  
• And we're at the instruction limit for Shader Model 2.
  
• Avoiding everything having to know about every light is usually called 'deferred rendering'.
  
• But that means we need to do two passes over the scene first (at least for DirectX 9).
  
• And then we can render all the light as a single 3rd pass.
  
• The current technique of using additive or medium-blended white-ish polygons for street/station light effects will continue to be the best way for some time to come.