Polyline `clampToGround` performance penalty when idle, unnecessary

Sandcastle example

Browser: Chrome latest

Operating System: Win10

I’m manually creating polygon entities from some external data sources, and am using polylines to draw separate outlines for them because of https://github.com/CesiumGS/cesium/issues/8577 et al. This means I wind up with hundreds to thousands of polylines with ~10-30 points. Performance was getting bad, then I noticed that for some reason when I switched from 3D to 2D, the apparent lag was completely fixed.

The linked example creates a grid of 2500 squares. If you pick “un-clamped” from the menu, performance should dip briefly while the initial geometry is computed, then stay at or around 60fps on decent hardware. It might dip down a bit when panning and zooming, but generally is good in both 2D and 3D modes. Pick “clamped”, though, and stay in 3D mode, and you’re lucky to reach double digits, even when totally idle. Switching to 2D fixes the problem – maybe the clampToGround property is ignored?

I’m not sure exactly what I’m asking to fix here. Of course, with terrain turned off (as in my example), clampToGround isn’t actually necessary, but I don’t want to have to re-declare my entities, or go around updating properties, every time the user toggles terrain on or off. Maybe the “clamping logic” could be disabled when the default (WGS84) terrain provider is in use? The continued penalty strongly suggests that clamping must be performed again on each frame, maybe clamping results could be cached somehow? Alternately, clamping could be event-driven, where collections that own entities with clamped graphics recompute heights only when the containing terrain tile’s height data is updated?

[likangning93]

Would it make sense to build this into the core library? That is, should the volume-intersection approach be avoided – effectively, should clampToGround be ignored – when the Viewer uses WGS84 terrain provider, since we know ahead of time exactly where the intersection would be?

My gut feeling is that might be too specific for the core library, or the behavior might be complicated by other features like Z-indexing of clamped shapes, or clamping to 3D Tiles. It might be better as an application-specific optimization when the application in question doesn’t need those complicating features.

[thw0rted]

Thanks to both of you, that does help clarify the situation. I didn’t realize that the clamping was happening as a GL operation, though I guess it makes sense in hindsight, once I noticed the load placed on the GPU. Your Sandcastle clearly illustrates the process with debugShadowVolume. The “invisible” extruded volumes would definitely get complex with my use case. It must be a totally different (and much more expensive) process from the non-clamped equivalent. Given that understanding, it seems like a strong argument in favor of my previous plan to disable the clamp setting when terrain is disabled.

Would it make sense to build this into the core library? That is, should the volume-intersection approach be avoided – effectively, should clampToGround be ignored – when the Viewer uses WGS84 terrain provider, since we know ahead of time exactly where the intersection would be?

(FYI, I’m aware of requestRenderMode and do use it in production, which prevents high GPU load when the application is totally idle. I still need to address the subject problem to get a decent framerate when the user is displaying time-dynamic / animated content, or when they’re simply moving around the map.)