[Genma Saotome]

I have long assumed that anything the route developer does WRT shadows is only about the casting of a shadow by an object and nothing to do with having a shadow appear on an object. Is that correct?

The OR menu option Shadow all objects works as described above, correct?


I usually set options to shadow everything but upon further thought it makes no sense for roads or track to cast shadows on anything and I expect some time is wasted when show everything has been turned on. So... is there a straight forward way, using an ordinary editor to edit parameter values to turn on dynamic shadows on static objects and turn off shadows or roads and track?

[Eldorado.Railroad]

Alas,

TL;DR, possible but in a different way. Yeah, casting shadows everywhere harms frame rates. Yeah, dynamic shadows give the sim some life. Nice to look at.

and now the boring details...

This has been a problem that I have been working on for some years. “Working on” is a loose term. I have a proof of concept to do what you would like, but NOT as you have outlined.

Route builders have a lot of work on their hands and being mindful about turning on dynamic shadows is often not at the top of the list. Maybe each route builder would have their own preference/taste as to what should cast a shadow or not. I think it is a “big ask” to have runactivity.exe decide at runtime, tile by tile load, to read a world tile and assign the static flag for a given object that you have pre-defined to cast a dynamic shadow. Once that has been done, then render said objects in real time with a dynamic shadow as desired.

What I have done on an experimental basis it to de-compile all the world files and run a special script, in a special language to set the static flags such that at runtime those objects will cast a dynamic shadow. As you can well imagine, this involves parsing each and every world file to accomplish this. As well I attempted to “uncast” certain objects, such as vegetation so that even if the author of the route decided to here and there cast dynamic shadows, those objects would have their dynamic shadows undone.

Given the tools/language I was using this was very tedious and error prone. I did a proof of concept with a special script and a text editor. Although it could do what I wanted, it was way too slow to even think of implementing this across hundreds of world tiles. So before the pandemic, I started on a different tack, but some things that are so very easy in ASCII are real buggers in UNICODE. So a few years back I roughed an in memory parsing and setting of static flags based on an input file and I had some success. By then I was getting tired of the project and have not touched it in years. Really I am hoping that some "millenial/genz" will work on this in some language that is FAST, so that it can process hundreds of files in a few minutes. BTW, some of those world files are quite large.

Sorry to be the bearer of “bad tidings”…

Steve

[R H Steele]

An observation ( from a point of extreme naivete regarding coding and computer languages )---I'm assuming that coding OR to render shadows of objects as they actually appear in reality will take a lot of effort, not to mention enormous amounts of processing time/power at runtime? I never have shadows turned on...I don't need them for immersion and they are a little too bizarre looking for my tastes.

[Genma Saotome]

Steve, do you know what the values in StaticFlags() mean?

[Eldorado.Railroad]

Genma Saotome, on 23 April 2024 - 08:48 PM, said:

Steve, do you know what the values in StaticFlags() mean?

Dave,

Pick a world file and pick an object (NOT a track item) you wish to shadow. StaticFlags(10000) will switch the dynamic shadows on at runtime. I am not on my "hobby" machine right now, so I cannot reply to all the vagaries of StaticFlags. You might get lucky looking through the defined constants in the OR C# source code. I cannot recall which file has those definitions for StaticFlags.

Hope this helps,

Steve

[Eldorado.Railroad]

R H Steele, on 23 April 2024 - 06:25 PM, said:

An observation ( from a point of extreme naivete regarding coding and computer languages )---I'm assuming that coding OR to render shadows of objects as they actually appear in reality will take a lot of effort, not to mention enormous amounts of processing time/power at runtime? I never have shadows turned on...I don't need them for immersion and they are a little too bizarre looking for my tastes.

The "standard/stock" implementation leaves a lot to be desired. So in that respect, I agree with you. A few hints, the low hanging fruit is to turn off shadowmapblur and to increase the shadowmapsize to at least 8192. If your system allows, increase that value to 16384 or even 32768. Tweaking shadowmapdistance to a lower value also helps. With a decent machine (not an anemic laptop) made in the last 10 years you should have a solid 60 FPS without hiccups. If dynamic shadows still "sucks" in your opinion then by all means turn it off! Caveat, any errors I have written WRT to actual names in the registry for OR is left as an exercise for the reader to correct!

Steve

[Genma Saotome]

Steve, is it technically possible for some future version of OR to have shadow map specifications set on an object by object basis? Or is the only way the maps work is by a universal definition?

[Eldorado.Railroad]

Genma Saotome, on 24 April 2024 - 10:13 AM, said:

Steve, is it technically possible for some future version of OR to have shadow map specifications set on an object by object basis? Or is the only way the maps work is by a universal definition?

Dave,

I think what should be possible...but still a bit of a headache, is to have shadow map specifications for the outside world and inside of a 3D cab. I do not think that the CSM in OR would allow for such "extravagance". Essentially you would need multiple CSM definitions. This would consume a lot of memory especially if we want nice, high definition shadows. As it stands now, the 3D cab shadow maps would have to be very close (normally there are 4 distances) to render nice tight and "un-jaggy" shadow edges. I have experimented a bit with 3D cabs and decided on using dark-shade because it does not generate or cast dynamic shadows. If the 3D cab model has good ambient occlusion in its texture maps the "nice to have" dynamic shadows would be the "cherry on top". In flight sims I see the compromise of high definition dynamic shadows in the cockpit and less generous dynamic shadows for scenery. Still, playing with the quality of dynamic shadows hurts performance when the values are set too high.


To answer more carefully your question, I think it would bog down runactivity.exe to have to do many comparisons for each AND every world file. If you have a list of 50 objects that "could" be in any world file that you would like to see dynamic shadows cast at runtime, your logic/code would have to read in each object from the world file, then compare it with the up to 50 objects (binary search anyone?) and then decide to cast a shadow for said object. As it is right now OR "looks' for the StaticFlags(1xxxx) and if StaticFlags(1xxxx) exists then that object will cast a dynamic shadow. I think that these types of gymnastics at runtime might not be optimal. What if the route might have 100s of object names that you may want to have dynamic shadows? Are we looking at n x n comparisons here for each world file at runtime?


This is why I was looking at retrofitting world files with StaticFlags(1xxxx). But it was tricky as not every object in a world file has the StaticFlags() entry. I was faced with having to inject the StaticFlags() entry if it was not present, for a specific object(s) that I wanted to cast dynamic shadows. Likewise if I wanted an object NOT to cast a dynamic shadow I had to delete/modify the StaticFlags() entry. As you can see this was an exercise that a simple text editor cannot accomplish. Additionally I had the headache of having to parse each and every object entry and insure that I was not trying to add dynamic shadows to a track object.

Steve

[R H Steele]

Steve, thank you for the answer in post #6...now for some experimentation.