[Eldorado.Railroad]

?

[James Ross]

Eldorado.Railroad, on 20 September 2010 - 10:02 AM, said:

1) In the demo videos on YouTube there seems to be "true" dynamic shadows for trees! In my tests yesterday I was unable to determine if the tree shadows are only triggered if the proper StaticFlags parameters are set in any given world file. If this is so, should the StaticFlags be set for "tree shadows" or "dynamic shadows"? Feel free to express your answer as actually statements/numbers that need to be changed directly in a world file, I avoid using the MSTS RE for this task!

Currently, OR will do dynamic shadows only for things with a shadow enabled in the MSTS RE, excluding track, dyntrack and forests (which never produce shadows). It doesn't care which shadow type is selected, though - any of the four RE options will produce the same dynamic shadow in OR.

Eldorado.Railroad, on 20 September 2010 - 10:02 AM, said:

2) In the demo videos on YouTube it appears that the template that is used to generate the dynamic shadow for trees is the 1-bit alpha channel for the texture of the given shape file. Is this correct?

The dynamic shadows are produced using the actual textures on the shape, however, the technique used for the shadows (Variance Shadow Map) does not support "partial shadows" - an area is either in shadow or it is not. For 1-bit alpha textures, this corresponds exactly to the shadow; for higher bit alpha textures, alpha < 0.25 is transparent and >= 0.25 is solid.

We may revisit (and possibly change) both the technique used for shadows and the higher bit alpha handling in the future.

Eldorado.Railroad, on 20 September 2010 - 10:02 AM, said:

3) Most, if not all foliage shape files use the cruciform parameter for display in the simulator. If my supposition is correct in question 2) are both (or more) shape file surfaces used to create the dynamic shadows? If not please explain how this works.

OR produces shadows using all surfaces of cruciform scenery.

Eldorado.Railroad, on 20 September 2010 - 10:02 AM, said:

4) Would OR support alpha channels for foliage that are greater than 1-bit? The reason for this question is that some slight transparency might render some interesting effects as far as dynamic shadows are concerned?

OR does not support this the way you want, though see my answer to 2.

Eldorado.Railroad, on 20 September 2010 - 10:02 AM, said:

5) Because of limitation of the current camera modes (notably, that the focus for the 2 and 3 keys are always the first or last engine/car in a consist) I can't confirm if shapes in a consist cast shadows on each other? Do they indeed cast shadows on each other? Certainly scenery objects do cast shadows on one another.

Objects are self-shadowing and everything is shadowed equally but, as a side-effect of the technique used (see 2), shadows tend to get pretty faint closer to the casting object, so it may be tricky to reliably see this on cars in a consist.

Eldorado.Railroad, on 20 September 2010 - 10:02 AM, said:

6) In MSTS, any shape that is either animated, has a hierarchy, or is placed in a world file as a Gantry item will not display dynamic shadows even if the StaticFlags parameters are properly set. Does OR copy this limitation? Could I request that in future that all shapes be able to cast dynamic shadows if the proper StaticFlags parameters are set?

I believe it is already the case that all objects produce shadows if set (excluding track, dyntrack and forests), but if you have an example of a non-static object with the shadow StaticFlags set that is not casting a shadow let me know and I'll see what I can do.

Eldorado.Railroad, on 20 September 2010 - 10:02 AM, said:

7) In MSTS, Freight Animations (FA) DO NOT cast dynamic shadows which leads to incomplete shadows for engines that use them and there are many that insist on using them for things other than handrails. Why does OR duplicate this "feature"? All shapes should be treated equally. :good:

Do you have evidence that OR duplicates this "feature"? It should be casting shadows from any and all objects equally, including any animated bits.

Eldorado.Railroad, on 20 September 2010 - 10:02 AM, said:

8) Not having the metric for computational intensity as far as dynamic shadows are concerned in OR, I think there should be a method of limiting when/where they are cast. I doubt that they would be visible/important much beyond 1000-2000 meters from the camera. I think that this feature should be completely adjustable to the user's needs/requirements.

I think 2000m is actually the max view distance in OR currently; from the cab, shadows are only produced up to ~1000m. If you use a higher camera, this increases, up to the max view distance. This is a balancing act between two things: showing shadows on everything (reasonably) visible, and having as much detail on near-by shadows as possible (or they go very blocky).

While I would consider a max view distance option useful, I'm not so sure about one specifically for shadows (beyond the current on/off).

Eldorado.Railroad, on 20 September 2010 - 10:02 AM, said:

9) I don't know what others do to calibrate their screens as far as gamma, contrast, and brightness. It would be really great to have a deterministic method of doing so in OR. The only thing that I can think of is to create a giant cube that has calibration B/W and color (colour) images on its sides. Can somebody show the way here? I think this is the root of some of the complaints I have read about elsewhere that "dynamic shadows are too bright". This stems from (at least for the ATI method) from having two calibration methods, one for the desktop and one for full screen Directx. The full screen method is at best a pure guess as to what it will actually look like. I discovered some time ago that what shadows looked like in MSTS were directly attributed to the gamma, contrast, and brightness which unfortunately varies between monitors.

I just calibrate through the Windows tool and leave everything else alone, but a calibration utility or gamma adjustment option is certainly something to consider for OR.

[Genma Saotome]

Question: Assume it's 6pm and we have one object is casting a long shadow upon another, lower object and this second object is not set to cast shadows. On the second object is a face whose normal is tipped slightly away from the sun, essentially lying under the "range" of the cast shadow but still mostly facing skyward. Would that normal be: 1) illuminated by the sun as-if it were facing the sun? 2) Illuminated by the sun but darker than the rest of the object would be w/o the cast shadow? or 3) Something else?

[James Ross]

Genma Saotome, on 20 September 2010 - 12:40 PM, said:

Question: Assume it's 6pm and we have one object is casting a long shadow upon another, lower object and this second object is not set to cast shadows. On the second object is a face whose normal is tipped slightly away from the sun, essentially lying under the "range" of the cast shadow but still mostly facing skyward. Would that normal be: 1) illuminated by the sun as-if it were facing the sun? 2) Illuminated by the sun but darker than the rest of the object would be w/o the cast shadow? or 3) Something else?

Makes my mind hurt trying to think about this, but I believe it's 3) not illuminated by the sun but also not darkened by the shadow. (We only apply shadow darkening to things facing the sun.)

[Genma Saotome]

James Ross, on 20 September 2010 - 01:35 PM, said:

Makes my mind hurt trying to think about this, but I believe it's 3) not illuminated by the sun but also not darkened by the shadow. (We only apply shadow darkening to things facing the sun.)

Here:



The track on the left... the shadows in both the berm and the track ballast don't look quite right... doesn't make sense to me that the ambient light on the right side of that berm is the same for in the building shadow as it is outside of the building shadow (further away from the viewer). I might be wrong on that but it strikes me as odd that it appears this way. Makes me think the berm shape(s) need to be casting dynamic shadows too... which sort of begs the question of why not cast shadows from everything instead of assigning a flag in every .w entry?

[James Ross]

Genma Saotome, on 21 September 2010 - 09:12 AM, said:

Makes me think the berm shape(s) need to be casting dynamic shadows too... which sort of begs the question of why not cast shadows from everything instead of assigning a flag in every .w entry?

The problem isn't what is casting shadows, but what is getting shadowed. We need to really sort out the whole lighting in the shaders at some point, it's rather messy and one result is that applying shadows to things facing away from the sun didn't look very good (buildings in particular). It's on my list. :wheelchair:

[captain_bazza]

James, there is no process that I know of during modeling that affects shadows, ie, whether the model (rollingstock) has them or not. Shadow for scenery model is defined in the model's data entry in the route's .REF file. The defaults are fairly basic shadow shapes. I use the default 'shaders' allowed in MSTS.

At the moment, we are stuck with basic (or none) shaders for advanced special effects.

Railworks uses a special shadow shape model, which is incorporated into the rollingstock, and scenery, model. I don't particularly like that system, it's time consuming and tricky. Also, the results can be bizzare in some cases.

Cheers Bazza