[railguy]

I know that this subject has been discussed extensively for a long time, but I wanted to "resurface" it again. What is the technical hurdle, if any, that keeps OR from being able to define light cones for any locomotive or train light--AI, loose consists, etc. included? The two arguments that I've heard before are the (a) MSTS can't do it and (b ) it takes too much computer resources. As to "(a)", well, there are all kinds of things in OR .inc files that MSTS couldn't digest, so I don't see that as a roadblock, anymore. As to "(b )", is that really an issue now? And, if so, how about an option to turn on or turn of "light cast" on trains, etc. on the main option screen for OR? I'd love to hear some input from the developers as to the questions about implementing this. As always, thanks to the OR team for all the great advances that they have made in the program. Attached is a screenshot from Northwest V6 (still on of my favorite routes) with a train meet--also featuring Borislaws great new ES44 cab. Just think how much more real this would look with both trains able to light cast. (Please note, the fuzziness of the image is due to a problem in my photo editing program--the original file is very sharp.)

Attached thumbnail(s)

• 

[James Ross]

railguy, on 26 December 2021 - 09:39 AM, said:

I know that this subject has been discussed extensively for a long time, but I wanted to "resurface" it again. What is the technical hurdle, if any, that keeps OR from being able to define light cones for any locomotive or train light--AI, loose consists, etc. included? The two arguments that I've heard before are the (a) MSTS can't do it and (b ) it takes too much computer resources. As to "(a)", well, there are all kinds of things in OR .inc files that MSTS couldn't digest, so I don't see that as a roadblock, anymore. As to "(b )", is that really an issue now? And, if so, how about an option to turn on or turn of "light cast" on trains, etc. on the main option screen for OR? I'd love to hear some input from the developers as to the questions about implementing this. As always, thanks to the OR team for all the great advances that they have made in the program. Attached is a screenshot from Northwest V6 (still on of my favorite routes) with a train meet--also featuring Borislaws great new ES44 cab. Just think how much more real this would look with both trains able to light cast. (Please note, the fuzziness of the image is due to a problem in my photo editing program--the original file is very sharp.)

The short answer is: because we haven't written the code to do it. :)

The longer answer is:

Open Rails currently uses forward rendering which is simpler to implement and works better with transparency (especially partial transparency), but forces a limit on positional lights. It does not force it to be 1, but it does force you to program how many lights there can be in total. The Open Rails code currently only allows there to be 1 positional light.

The alternative is deferred rendering (also deferred shading, deferred lighting) which is more complex to implement and has problems with transparency, but sets no limit on positional lights.

This article on Forward Rendering vs. Deferred Rendering seems to cover the details quite well.

In summary, we could probably reconfigure the current code to support e.g. 4 cone lights at once, but that number will be locked by the code and performance would be worse than with deferred rendering. I am not certain the code changes would always lower performance (even when there are 0 or 1 lights) or if it would vary.

[railguy]

Thank you for the answer. I would certainly vote for the OR Development Team to pursue this in the future. I'd be curious to know how sims like TS20** have managed to pull this off for years now. The lighting feature is, for me, the only ONE big thing that TS20** does better than the current MG version of OR.

[scottb613]

Hi James,

Thanks for the explanation - I’ve wondered about it as well…

Regards,
Scott

[ExRail]

Can't help thinking of FS2004 and Shockwave 3D Lights
it was badly needed under my Blizzard condition, and would have been great in the dark.
While this properly falls under the train constructor domain, getting this on all the old MSTS/ai trains would be great.

It's my impression that it's just something like the image,
create the shapes with these types of textures, and behaviour
that has night illumination and link there on/off state and transparency
to environment condition, and 'mount it to all front lights and maybe a smaller
adapted version for the red in the rear.
It worked great in FS2004 even greater when reshade was used.

Attached thumbnail(s)

• 

[edwardk]

At one point, I was looking at the code for the cone light. The glow light evidently is shared without issues between the player train and the AI train, but the cone light is different. For some reason the cone light was locked to the player train without consideration that the AI train can also use it. In Material.cs, the initial set up code for the player train is used. Its just a matter of understanding how to incorporate the AI train. The major difference of course is the cone light will be treated the same like the glow light on the AI train. If there is going to be a question of performance issues, then the cone light should have an option to use it.

[ErickC]

ExRail, on 13 January 2022 - 02:43 PM, said:

Can't help thinking of FS2004 and Shockwave 3D Lights
it was badly needed under my Blizzard condition, and would have been great in the dark.
While this properly falls under the train constructor domain, getting this on all the old MSTS/ai trains would be great.

It's my impression that it's just something like the image,
create the shapes with these types of textures, and behaviour
that has night illumination and link there on/off state and transparency
to environment condition, and 'mount it to all front lights and maybe a smaller
adapted version for the red in the rear.
It worked great in FS2004 even greater when reshade was used.

Ooof... I remember those lights. It made it look like you were always flying in fog! Lights only cast beams like that when there are particles in the air.

Having multiple sources of emitted light that casts on objects would be nice, though. As well as independent control of front and rear lights...

[Serana]

James Ross, on 27 December 2021 - 05:35 AM, said:

The alternative is deferred rendering (also deferred shading, deferred lighting) which is more complex to implement and has problems with transparency, but sets no limit on positional lights.

This article on Forward Rendering vs. Deferred Rendering seems to cover the details quite well.

I started reading about deferred rendering. It may not be the best technique to apply in our case. It can't render transparent objects.


A possibility would be to render opaque objects using deferred rendering and transparent objects with forward rendering.
It seems not to be the best way either.

Another way would be to use tiled forward rendering which seems to be as performant as deferred rendering, supports transparent objects, and can be added on an existing forward renderer.
https://www.3dgep.com/forward-plus/
It needs GPU support for compute shaders though. Compute shaders were implemented with Shader Model 4 (so first GPU to support this were ATI Radeon HD2x00 and nVidia GeForce 8x00.
It requires also a Direct3D 11 runtime which is what is currently used by MonoGame, but compute shaders are not yet accessible through MonoGame (it's being developed currently).

[gpz]

gltf-s can have lights attached, which would be good to be supported. Khronos calculates these in a simple for-loop in their reference shader, see: https://github.com/K...s/pbr.frag#L159

KHR_lights_punctual: https://github.com/K...ctual/README.md

[btrs]

Serana, on 22 January 2022 - 04:47 PM, said:

Another way would be to use tiled forward rendering which seems to be as performant as deferred rendering, supports transparent objects, and can be added on an existing forward renderer.
https://www.3dgep.com/forward-plus/
It needs GPU support for compute shaders though. Compute shaders were implemented with Shader Model 4 (so first GPU to support this were ATI Radeon HD2x00 and nVidia GeForce 8x00.
It requires also a Direct3D 11 runtime which is what is currently used by MonoGame, but compute shaders are not yet accessible through MonoGame (it's being developed currently).

As I mentioned in the new model format thread: yet another good reason to move on to Direct3D 10/SM 4.0 and leave that 15+ year old hardware behind. I think for the average user, the replacement cycle of a PC should be around the 10 to 12 year mark (and that's stretching it!). And once the last support of Windows 10 will be discontinued from 2025 onwards, Windows 11 will support only hardware with Intel Core 8th gen/AMD Ryzen 2000 and higher anyway. Why do we need to keep supporting such old hardware/OS configurations when the major developers already have dropped support for them ? (Nvidia no longer provides new Win 7 drivers, apart from the business/enterprise segment etc.. Only LTSC-style security-fixed drivers now.)