-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shadows use scene near/far #3691
Conversation
Perhaps put a |
I'm sure it is outside the scope of this PR, but there are a lot of artifacts for terrain. For a good place to test, use the gecoder to zoom to "Seneca rocks" Also note that the skirts still cause artifacts: We could turn off skirts for the depth pass. It would also be an interesting optimization in general to render skirts after the surface geometry to take advantage of early z. Likewise, we could also not draw skirts if we know all the neighbor tiles are the same LOD so it is watertight. Food for thought, we don't need to do all of this for shadows. |
Maybe just use the BV of the tiles that are expected to be loaded, not the low LOD parent tiles. Perhaps try to hack this in first to see how well it works then we can figure out an elegant approach since 3D Tiles would also need changes. |
Just those comments. |
Updated. The new approach for finding the shadow near/far is working better. |
I've only been testing on Windows, I'll try this out on OSX tomorrow. |
I'm getting a framebuffer incomplete error in Chrome. When I fallback to the color texture, it works fine. Firefox is working, so maybe this is just a Chrome issue. |
Added a fix to #3711. |
Cherry-picked into #3711 |
For #2594
terrainCast
- toggle terrain casting shadows (off by default now)fitNearFar
- use the near and far computed increatePotentiallyVisibleSet
to limit the shadow map bounds. This helps a lot with views that face the ground, and helps a little with horizon views because it uses a tighter near plane. There is still the problem where moving the camera causes large terrain tiles to load, which throws off the near and far computed from the draw commands. I've tried a few different approaches to recognize when this happens, but none are ideal yet.DrawCommand.receiveShadows
. I removed the code that was using this, so nothing is using this right now, but it might be useful to keep. SinceDrawCommand.castShadows
exists, it doesn't stand out.