[Genma Saotome]

What does OR do for sun and shadow with the inside of a model as viewed thru a window (e.g., looking into a passenger car?)? What does it do under an overhang? With an opening in a roof?

[James Ross]

Genma Saotome, on 23 July 2011 - 11:21 AM, said:

What does OR do for sun and shadow with the inside of a model as viewed thru a window (e.g., looking into a passenger car?)? What does it do under an overhang? With an opening in a roof?

There are three kinds of surface for rendering regarding shadows:

• Non-shadowed: Not affected by the sun position or any shadowing.
  
• Facing the sun: Shadowed according to the shadow map. The closest such surface to the sun is "lit" and all others are "unlit".
  
• Facing away from the sun: Shadowed always.

Two of the above are unaffected by the shadow map code because they're constantly shadowed or not. The remaining kind of surface is affected. Within the bounds of the shadow map resolution, all such surfaces are shadowed if there is an object (with shadowing enabled) blocking the sun.

So, if you enable the hidden "ShadowAllShapes" option, which makes everything cast shadows, they should be completely correct (again, within the limits of the shadow map resolution). If you don't enable that option, only objects set to cast shadows in the MSTS RE will cast shadows basically - but when they do cast shadows, they should again be completely correct.

The shadow map resolution generally means (IME) that anything less than about two feet/50cm will not shadow very precicely but larger objects will do okay. Any transparency within an object should be fully respected too.

[James Ross]

Eldorado.Railroad, on 27 July 2011 - 12:16 PM, said:

As I understand it, the four shadow maps used are all of equal size. Through the use and testing of v677 I have often mused at having lower resolution maps for the most distant shadows, eg:4096,4096,2048,1024. This would free up resources and increase performance while allowing the same visual appeal as long as there was some control offered to the user to set what the map ranges should/could be. Since the furthest maps are of lower resolution, blur should also be selectively applied only to the lowest resolution maps to hide the holes?

They are indeed all equal size in terms of texture resolution. This seems quite standard for cascading shadow maps, as the ones covering things further away are spread over a larger area so 1 texel (texture pixel) is still approximately the same size on-screen. It's not that exact, of course, but that's the intention.

I'd be hesitant at allowing control over the shadow map ranges - that seems like it is getting too fine a level of fiddling. That said, I thought the source we were going to release would be compilable by people but someone scuppered that without me knowing so I may have to add options like this.

Eldorado.Railroad, on 27 July 2011 - 12:16 PM, said:

I really hope that the next public release does not discard the user control over shadows if he/she wishes to exploit them. If anything more user control would be most welcome.

We're certainly not going to discard options generally (and the shadow ones in particular haven't changed), but we'll always need to consider what makes sense to fiddle with here. E.g. if we switched the shadows to a different method (so they were no longer cascading shadow maps), some of the existing options would make no sense. I don't think you'd object to that kind of removal, provided we included tweaking options for the new method. :thumbup3:

My aim is to let people adjust things that don't have obvious good values for everyone, but still try for good default values.

[CrisGer]

I like the detail being addressed in all of this discussion, I LOVE good shadows and hope for the best we can do, i think with modern computers, most people will have much better systems than were common say back when MSTS first came out. I have upgraded both CPU and GPU over the years and am looking forward to testing the current release very much...thanks again for the thoughtful discussion and great work on OR>

[Genma Saotome]

James, with the present shadowing mask resolution, what's the largest an object can be and still fit within the dimensions of the smallest shadow mask?

[James Ross]

The typical diameter of the sphere encompasing the area mapped by the first shadow map level is ~205 meters and is located ~63 meters in front of the camera. The shadow map resolution only affects the detail within that area, not the physical size of it.

[James Ross]

Eldorado.Railroad, on 30 July 2011 - 08:56 AM, said:

One day I will sit down and read the code to determine the algorithm used to create the ranges, which appear to be non-linear for a given shadow distance set in the registry.

Have a look at InitializeShadowMapLocations in RunActivity\Processes\RenderProcess.cs, that contains the set-up for the shadow map ranges. It uses an average between linear and logarithmic placement to get a reasonable balance (this choice comes from a paper on shadow mapping).

[Genma Saotome]

James Ross, on 30 July 2011 - 07:23 AM, said:

The typical diameter of the sphere encompasing the area mapped by the first shadow map level is ~205 meters and is located ~63 meters in front of the camera. The shadow map resolution only affects the detail within that area, not the physical size of it.

James, I'm working on this model and I'd like to know if there is anything I can do with the model that addresses the unusually dark show that appears mid image on the dock and dock roof. To my eye it doesn't appear to be cast from anything at all -- the shadow cast from the silos on the left is correct for the position of the sun and if you look further to the right the overhang roof casts a shadow upon the dock that looks correct. The really dark shadow looks completely wrong.




The model is a tad longer than 300m. I expect I'll break it up into a couple of smaller models so I can manage LOD's with a bit smaller values -- Would that make a difference? Or making polys that are not >200m long? Or is it a problem in the OR software?

[James Ross]

Genma Saotome, on 22 August 2011 - 12:27 PM, said:

The model is a tad longer than 300m. I expect I'll break it up into a couple of smaller models so I can manage LOD's with a bit smaller values -- Would that make a difference? Or making polys that are not >200m long? Or is it a problem in the OR software?

Splitting it may help... the sharp, horizon-like edge of the spurious shadow is likely to be a shadow map cascade boundary (where two different levels of detail in the shadow map join), which is probably the result of the object not being included in both the shadow maps it straddles.

This could be a bug in OR (it's depressingly hard to get the exact culling boundary to work) or it could be a weirdness in the model. On the model side, OR does more or less depend on the view sphere and such data to be correct; if the values are much smaller than the actual object, for example, it will disappear before it is fully off-screen and other such weirdness.

[Genma Saotome]

Another question: In this image the sunlight spills down along the vertical face of the building... and creeps past the overhanging roof:



The shadow of the roof looks right upon it's lower, horizontal surface as well as upon the shipping dock concrete. What can you suggest about the sunlight under the roof? Extend the dock roof into the building? Make it its own model? Make the wall under the dock roof part of the roof instead of part an extension of the wall?