-
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
Odd Columbus View Lighting... #592
Comments
I was trying to show global coverage and realized that this happens in 2D as well. (black parts of the map even when zoomed out to home view) @pjcozzi and @kring any ideas on this? Will this probably just "go away" when some planned features/roadmap item gets implemented? It doesn't appear to happen when terrain/water are used. |
I just tried it out, and I see it with terrain/water too. It's sensitive to the angle of the camera. If you're truly looking straight down, it doesn't happen. But if the camera is angled a bit, it does. |
I think see what's going on here. The polygons are lit entirely by diffuse lighting. Diffuse lighting is computed in Cesium in an "interesting" way - at least part of which is my fault. For starters, it's computed with two light sources attached to the camera: one pointing straight ahead and the other pointing straight down. I'd argue that diffuse light should be based on the sun position instead, but there are some problems with that, that would mean we'd have to do more than just light polygons with diffuse light. In particular, polygons on the night side of the globe would be un-lit. I guess whether that's a bug or a feature depends on your intended use-case... In any case, things get more interesting in CV and 2D, and this part is my fault. Here's how it's supposed to work: Imagine we render the globe in 3D, with a 3D camera position, lighting, the whole bit. And only then we project it to 2D or 2.5D. Cesium doesn't actually work that way, but that's the impression I was trying to create, and I think it's working correctly. I also think it's the right thing to do, especially for lighting. For example, you wouldn't want to show sun lighting or specular highlights in 2D based on the projected position of the sun, right? It would look wrong, and more importantly it wouldn't reflect the real world. This scheme breaks down with the camera-mounted diffuse light sources, though. It's easy to create a situation where the camera and polygon, in the 3D world before projection to 2D, are nearly on opposite sides of the world from each other. In that scenario, the polygon will appear black. Yet the polygon may still be well within the viewport once it has been projected to 2D. Two solutions I can think of:
The second may sound preferable, but it means some parts of our lighting will use projected positions, and others (such as specular highlights and water) will use unprojected positions, which could get messy. I'm not sure how messy off hand. |
I'm sure this is some sort of general known issue with Columbus View lighting, but I couldn't find an existing issue describing it.
The text was updated successfully, but these errors were encountered: