2 hour window for shadows for forest objects

[cjakeman]

Forest objects only show shadows from 11 until around 1 o'clock. the rest of the time no shadows at all. And during that time the entire day cycle is run thru in 2 hours.

They start at about 11:24 and end at about 13:27. This is in version 1.3.1.4328.

Reported by CrisGer

[Ryan Young (rayoung)]

Confirmed as far back as version 0.9, and very probably this bug was also present in the original dynamic shadows for forests patch: https://github.com/openrails/openrails/commit/32741bc51b24d685b5a59b49dfb9d27df73c047a

[Ryan Young (rayoung)]

Okay, so the "bug" happens because the shadow does not rotate with the forest object, so it is usually not visible. Per James Ross, this is intentional behavior: http://www.elvastower.com/forums/index.php?/topic/28139-camera-facing-billboard-shadows-are-locked-at-compass-heading-0/

"The reason OR doesn't face the forest billboards towards the camera for shadows is that that results in shadows changing dramatically as the camera moves, which looks very bad indeed. Instead, we face them to the sun, which means the shadow always shows the full-width object (instead of something squashed) no matter what the camera does."

One proposed solution is to cast a second shadow at a perpendicular angle, so that the sun will always cast at least one.

[cjakeman (cjakeman)]

Hi Ryan,

Graphics is not my field, so I'm just writing as an interested observer.

From your comments I think I understand why the "billboard shadows are locked at compass 0" rather than following the camera.

I presume that this results in shadows only appearing full width at noon. At hours distant from noon, the width will be less than the full width so they will become less obvious. Is this what CrisGer is seeing? I guess the effect is worse towards the equator.

What is not clear to me is why the billboard shadows face compass 0" rather than the longitude of the sun?

[Ryan Young (rayoung)]

I believe your interpretation is correct, yes.

The shadows are cast assuming the trees stay fixed at compass heading 0", regardless of the billboard effect. As it turns out, since the reverse side of the tree won't cast anything, this leaves us with a narrow window within which the shadows are actually visible.

I have been poking around the forest rendering code without much success - I am not a graphics person either. :(

[James Ross (twpol)]

The bug was probably not present in the original implementation in https://github.com/openrails/openrails/commit/32741bc51b24d685b5a59b49dfb9d27df73c047a - which calculates the side vector using normalize(cross(eyeVector, upVector)) for both visible and shadow billboards.

But then this optimisation https://github.com/openrails/openrails/commit/c9c32d7342c6cc3a40112ad77f7b6300630d67bd broke both by using matrix.Right instead: https://github.com/openrails/openrails/commit/c9c32d7342c6cc3a40112ad77f7b6300630d67bd#diff-05d10938817f52562d2cf10474b04d11R57 and https://github.com/openrails/openrails/commit/c9c32d7342c6cc3a40112ad77f7b6300630d67bd#diff-05d10938817f52562d2cf10474b04d11R181

However, while the visible problem was quickly spotted and fixed (5 days later) in https://github.com/openrails/openrails/commit/a69a8620bed05d174ed5dabd6f0b17eaf0380f25, it looks like the shadow problem has been around since (7 years later)!

[Ryan Young (rayoung)]

Hi James,

I see. Thanks much for looking into this. And apologies for throwing shade on your code; unable to acquire any versions older than 0.9, I made the bad assumption that this bug had been present since the implementation of dynamic shadows.

[Ryan Young (rayoung)]

The fix is ready to be merged pending the Monogame upgrade: https://github.com/YoRyan/openrails/commit/b01dde6fba536768fd1b938e2fb908a1ec7b92bf

[Peter Gulyas (pzgulyas)]

Ryan,

I believe only the following two lines make sense in your patch:

Vector3 eyeVector = Vector3.Normalize(new Vector3(v.M13, v.M23, v.M33));
sideVector.SetValue(Vector3.Normalize(Vector3.Cross(eyeVector, Vector3.Down)));

The changes to the ShadowMap.fx do not make any difference, because the newly introduced "EyeVector" parameter's value is just passed to the vertex shader output structure's also newly introduced "Normal_Light" member, which eventually is not consumed by the pixel shader, since that had not been changed to, so the value is effectively just lost. Because of this also the C# parts of adding and calculating this value is unnecessary.

In the end, only the above two lines are remaining, that make any difference. Anyway, probably I was the one years ago introducing this bug, that I am really sorry, and glad you guys catched and corrected it! :)

[Ryan Young (rayoung)]

It looks like you were right, Peter. Nice catch. (I'm not a graphics or game programmer, so anything that steps outside of the C# type system is somewhat beyond my comprehension.)

With just those two lines, the new, smaller patch applies cleanly against James' Monogame port. Therefore, it is okay to merge right away. I have filed the PR: https://github.com/openrails/openrails/pull/325

[Peter Gulyas (pzgulyas)]

Glad to help. (Just mentioning my Monogame port: it is about the 8th anniversary I started to work on it, I published the first version of it at the beginning of 2013. :-) )