Hi,
I have read the technical blog concerning Skipping Levels of Detail.
“Doing so allows the engine to render low resolution tiles when they are far from the camera and high resolution tiles when they are near the camera.”
I have one question: Does this approach mean I have to prepare my data in a special way ?
I have a dataset with a
Terrain: generated 30m Resolution (400 x 300 km)
BaseLayer: Zoom 1 bis 5 OSM-Map (generated with gdal2tiles)
Image: Orthophotos (generiert mit gdal2tiles)
Project needs 1GM RAM in chrome. I have the impression, that the data isn’t loaded according to level of detail - do I have to consider something at the preparation of the data ?
Rüdiger
Hi,
I have seen the old discussons on that topic
opened 07:39PM - 15 Apr 16 UTC
type - enhancement
category - 3d tiles
category - terrain and imagery
Hi, guys!
Some time ago we decided to replace NASA World Wind working as Java A… pplet in browser by Cesium in order to display multiple imagery layers (I mentioned it in #2047). Our application allows a user to specify filter parameters (such as time range, geographic region, satellites, sensors and type of products of interest) and display found raster data (set of segments grouped by orbits) on the globe. I overlay each orbit of processed data as a separate imagery layer. To demonstrate it here is a screenshot of the application:
Initially plain WMS was used to send imagery tiles but in order to increase performance we are switched to WMTS. Unfortunately, it helped a little. I started to look at source code and found that some work to choose tiles for rendering is done [here](https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Scene/QuadtreePrimitive.js#L387). It's very difficult to understand what's going on there at a glance but I stated that many tiles starting from zero level of detail up to current level of detail are analyzed and prepared for requesting/rendering constantly in short time interval. Probably, something is wrong with detection of which tiles on lower-detail levels should be used 'cause, for example, when I enable imagery layer on 7th level of detail I see a lot of tile requests (at least 250-300), and most of them are empty (they are outside of current viewport):
If I enable all imagery layers per page (no more than 20) and zoom in I end up with browser hanging...I guess, that all these things happen in main JavaScript thread, and there are too many tiles! This fact seriously limits Cesium application in our case that's why I open the issue.
I look at [terrain and imagery roadmap](https://github.com/AnalyticalGraphicsInc/cesium/issues/526), but didn't find anything related to this there.
What can we do? Any ideas? Do you plan, guys, some improvements on this? Is it possible to use some another algorithm to filter tiles (is it called culling?), probably, to skip some levels of detail (even all excepting the current one) or improve existing algorithms by limiting to only really visible tiles (which are in viewport and are not covered by tiles of other imagery layers).
I'm also ready to try to do something but don't know where to start. Is there any tutorial describing in details how imagery layers are loaded?
CesiumGS:master ← CesiumGS:fill-tiles
opened 12:27PM - 23 Sep 18 UTC
This is _not_ ready to merge yet, but I'm opening it now to track remaining prob… lems and ideas, some of which will go on the roadmap rather than being implemented prior to merging this branch.
Required:
* [x] I've modifed the upsample worker to start immediately rather than the first time it's needed, because in this branch it's needed much later and it's a long wait to start it up once we do realize it's needed. Not sure if this is ok. Also I've done that in such a way that it throws an exception.
* [x] Fill mesh / vertex array should be freed once the tile is loaded.
* [x] Fill tile generation allocates more memory than necessary. The worst offender is that it creates two copies of the vertices for... reasons.
* [x] Test failures.
* [x] There's debug code around (sometimes commented out).
* [x] What should the default setting of `QuadtreePrimitive.preloadAncestors` be?
* [x] ~~Test with the new BVH data from the modified server and make sure that it's still working as expected and providing a benefit.~~ Tested it and found it provided no benefit, removed it.
* [x] Test with terrain exaggeration, with/without water mask, and with all the combinations of possible vertex data, i.e. with/without normals, Web Mercator texture coordinate.
* [x] Code duplication between real loading process and fill generation (e.g. around imagery layers)
* [x] Entire globe flickers when adding a new imagery layer.
Broken Sandcastle examples:
* [x] 3D Tiles feature picking crashes trying to use destroyed vertex array after moving around a bit. Caused by draw command referencing fill tile vertex array but real vertex array has already been loaded and fill freed.
* [x] Clamp to terrain initially loads a black scene.
Nice to have:
* [x] The fill tile generation is buggy in some cases, which can lead to cracks between adjacent fill tiles and (rarely) even flickering as a fill tile switches its geometry back and forth between frames. Mostly it looks ok though.
* [x] For very coarse tiles (e.g. levels 0-4), fill tiles could use some more vertices in order to match the globe curvature. There's a fairly obvious artifact from this when spinning the globe quickly from a global view.
* [x] We're a little too aggressive in waiting for tiles to be ready before rendering them, which can lead to slow imagery layers blocking all refinement.
Future:
* [ ] We could reduce the need for fill tiles by upsampling culled tiles (but not loading their terrain or imagery) so they're ready to render when the camera moves and they're no longer culled. We'd only want to do this when the parent is loaded, though, which it really only will be (eventually) if `QuadtreePrimitive.preloadAncestors` is true.
* [ ] Currently fill tiles match adjacent vertices at their edges and have just one vertex in the midle. We could improve their quality by also copying vertices that fall inside the tile from the nearest ancestor, but then we'd need a much more complicated tessellation, like an incremental Delaunay. Using the existing triangles when all three ancestor vertices are fall inside the tile will help. Probably not worth the CPU time, but it would be interesting to investigate.
Could it be that the imageryprovider doesn’t use this techniques ?
Rüdiger