NASA-AMMOS
GlobeControls: make adjusting camera clipping planes optional
Whenever you want to display a globe tileset and additional objects around it, you might want to disable automatic adjustment of camera clipping planes by GlobeControls, so that objects far above the globe's surface can be seen.
Hey! There are already "margin" fields on the GlobeControls to add some extra padding on either side of the globe bounds - do these work for your use case? See nearMargin and farMargin.
do these work for your use case? See nearMargin and farMargin.
Not really, as I would like to totally disable clipping planes adjustment by the controls. However, I noticed that the method does not only updates the clipping planes, but also some other properties, so this PR is a bit too naive. Currently, I have a workaround where I save the clipping planes values before calling update(), then restore them.
Can you explain your use case, then, and why it doesn't work? I'd like to avoid adding a ton more options to the controls 😅
so that objects far above the globe's surface can be seen.
The margin options were added specifically for this use case.
My use case is when the library is integrated into Giro3D. I would like to mix many kind of datasets in the scene: 3D Tiles, Terrain maps, point clouds, 3D models...
Giro3D has an optional mechanism to update the camera clipping planes so that it fits the entities that are visible in the scene. This mechanism is currently overriden by the one in GlobeControls. I would like to avoid it being overriden because IMO it's not the responsibility of a camera control to forcibly set the camera planes. I'd like the controls to simply set the camera position/look at target/fov/zoom, and the rest should be optional.
Besides, some post-processing effects are very sensitive to changes in the depth buffer, so changing the clipping planes every frame can mess with that too. In that case, I want to set a fixed value for both planes (e.g when I know in advance the general volume of a scene) and disable automatic plane computation.
Giro3D has an optional mechanism to update the camera clipping planes so that it fits the entities that are visible in the scene. ... IMO it's not the responsibility of a camera control to forcibly set the camera planes.
Normally I'd agree but are you not seeing issues with rendering the globe when just adjusting the camera planes to encapsulate the scene? It results in some pretty severe depth buffer / zfighting artifacts due to the scale of the models. Other solutions like log depth buffer have pretty serious performance implications and reverse depth buffer is quite difficult to work with at the moment. The orthographic camera can also jump around quite a bit when moving the camera around to make sure the scene isn't clipped and the planes need to be shifted to keep everything in view. The adjustment of the planes have been tuned to keep the scene in a good range to prevent rendering artifacts otherwise the controls would be nearly unusable imo.
If we still want to disable the plane updates lets update the flag to be called autoUpdateClipPlanes and ensure it only disables the clip plane adjustment but we should consider what the behavior for something like the orthographic camera should be. Alternatively you could use something like a "dummy" camera with the controls and copy the camera position or settings you do want manually onto your main render camera.
Normally I'd agree but are you not seeing issues with rendering the globe when just adjusting the camera planes to encapsulate the scene? It results in some pretty severe depth buffer / zfighting artifacts due to the scale of the models.
True, that is why, to mitigate this, we only set the near plane to a fixed value, since in my experience the near plane has a greater effect on visual artifacts.
I am also trying to use the GlobeControls on scene that do not necessarily contain a 3D Tiles tileset, (for example a regular Globe-shaped terrain Map in Giro3D), so I wrap the controls and expose a fake "TilesetRenderer" to match the expected API. It works very well, except for the clipping planes issue.
Alternatively you could use something like a "dummy" camera with the controls and copy the camera position or settings you do want manually onto your main render camera.
This is a good ide ! I'll have a try.
I wrap the controls and expose a fake "TilesetRenderer" to match the expected API.
This is something that I'd considered before, as well - good to hear you found a workaround but this is something that we can definitely remove the strict dependency for in GlobeControls. I made #1071 to track this idea if you have any other thoughts or want to add the functionality.
I'm going to close this for now since it sounds like there's a solution for your use case.