Hi!
There is a way to control the geometric density of the 3D terrain (I’m using Cesium World Terrain)? I found how control the imagery detail and the rendering resolution but I’d like to play with the geometric detail;
I think, for our kind of application, we can sacrifice a little bit of polygonal complexity to gain more performance and reduce data transfers.
Thank you!
I think your best bet is changing the Globe’s screen space error:
https://cesiumjs.org/Cesium/Build/Documentation/Globe.html?classFilter=Globe#maximumScreenSpaceError
I believe that affects both imagery and terrain. I don’t think there’s a way at runtime to change the vertex count of the tiles. The easy way would just be to request lower resolution tiles which are more lightweight but less accurate. I think changing the geometric tile would require retiling a special version of the entire Cesium World Terrain.
Hi Omar!
I already played with maximumScreenSpaceError but, as you say, it affects also imagery.
I’ve just had a (fast) look on Cesium code and I found a static parameter (Cesium.TerrainProvider.heightmapTerrainQuality) that it seems what I’m looking for BUT give me a strange problem: when I set it to 0.1 (default is 0.25) I see about 1/3 less requests / data transfer from Cesium World Terrain but much more requests from imagery server (more: the total data transfer of imagery is about the same - same MB, but with much more requests). It seems that it finishes to load the terrain / imagery about in the same time (with less terrain data) BUT then it load a lot of imagery tiles without any apparent reason.
If you set it with lower values (ie 0.02) it continues to load imagery tiles indefinitely.
Conclusion: heightmapTerrainQuality best value is the default one, but it’s a clue that it’s possible to do what I want without retiling the CWT.
Can you investigate further? I think that the possibility to tune the geometric detail without reduce the quality of imagery could be a really useful feature with mobile devices (or dated hardware),
a lower polygon density is far less visible (for non technical users) than pixellated / blurred imagery 
Thank you!
This isn’t directly configurable, but you can modify the Cesium source code to achieve what you want. Specifically this line:
https://github.com/AnalyticalGraphicsInc/cesium/blob/6cfb8b80870ee802c4b8d110eb3e7460760a27d9/Source/Scene/ImageryLayer.js#L546
You would change the globe’s normal maximumScreenSpaceError property to a larger value (e.g. double it), and then change the line linked above to a smaller value (e.g. cut it in half, to 0.5). Despite the outdated comment, Cesium today is able to handle more images attached to a terrain tile than there are available texture units, so it should work pretty well.
Exposing this as a public property on ImageryLayer would be straightforward. We’d love to see a pull request for it if you’re up for it.
Kevin
Thank you for your reply!
I immediately give a try to your hint but I found the same results I had changing the value of heightmapTerrainQuality: for very small values it’s OK but if you want to do more (I think that for my application I can use very high values of maximumScreenSpaceError, like 50) you’ll experience the problem I wrote about: exponential loading of imagery tiles, and the the consequent high bandwidth / CPU usage / loading time.
I can suppose that is an extreme scenario never considered / tested from developers, and so it’s absoluty reasonable that something can’t work properly.
I made a Sandcastle demo.
commenting the first line to use the default heightmapTerrainQuality (0.25) I have 111 3D terrain requests / 1.1MB and 115 imagery requests / 3.1MB (I obtain this values using Chrome inspector and filtering request for type XHR and string “terrain” for terrain tiles or “virtualearth” for imagery tiles)
setting heightmapTerrainQuality to 0.1 (as in my example) I have 88 3D terrain requests / 806KB (good!) and 545 imagery requests / 10.4MB (WTF!? 
)
Conclusion
the good news is that the parameters you talking about is already exposed
the bad news is that you can’t touch it
A little update.
I found that playing with higher values of heightmapTerrainQuality (1 or 2) you have a lot of terrain tiles to load but the numbers of imagery tiles Cesium needs fall considerably (with 1 you have 36 requests / 0.8MB).
I took two screenshots (heightmapTerrainQuality 0.25 and 1) and they were identical, so I can exclude that Cesium loaded imagery tiles at different resolutions between the two tests.
There is more. I took a look at imagery tiles content and I found that a big part of this 36 requests are useless for the area that is rendered.
I’ll open a new thread because I think that is relevant.