describe

Cesium launched the 3D Tiles data specification around March 2016, which provides LOD capability based on glTF, targeting massive 3D model data in the Web environment. Tile flow technology similar in concept to Terrain and imagery is used.

3DTiles also allows us to tweak Styling using the 3D Tiles Styling language.

loading

tiles = scence.primitives.add(new Cesium.Cesium3DTileset({
    url: ' '
}))
Copy the code

As shown above, Cesium provides the Cesium3DTileset class to manage Tile scheduling. In Cesium, 3DTiles are the location of a Primitive.

When we create a Cesium3DTileset, each Tile corresponds to a Cesium3DTile. As shown above, the root node is root, content is the file name corresponding to the root node, parent-b3dm, four child nodes, the file name corresponding to the child node is ll.b3dm……

Scheduling process

3dTiles is essentially a JSON object.

After the JSON object is acquired, the rootTile root node is first created, and then in the while loop, the tree is traversed breadth-first, with each node having a parentTile bound parent (except for the root node) and a children array that holds all the corresponding children of that node.

At initialization, Cesium3DTileset stores all the nodes and associations in the 3DTiles tree. This is equivalent to reading a book, we will first look at the table of contents of the book, to understand a general.

However, if there is a large amount of data, loading all nodes for the first time is a performance bottleneck. This is the current design weakness of 3D Tiles

The following is part of the source code

Scheduling management logic

The functions of the four functions are roughly as follows:

processTiles

Processing Tile corresponding DrawCommand state, determine some translucent rendering order

selectTiles

Request specific B3DM data, different types according to the corresponding class to complete the data download, according to the LOD policy to determine which tiles into the render queue.

updateTiles

In the current frame state, the tree is traversed, and the corresponding Model:: Update of the Tile is called to complete the data parsing and finally construct the DrawCommand

unloadTiles

Determine if the current number of Tiles exceeds the upper limit and unload any additional Tiles

In the selectTiles function, the data content (b3dm suffix) of the Tile is downloaded first, identified by the contentUnloaded sign, and then returned if the root node’s data has not been unloaded

UpdateTiles looks simpler, specifying the specific Content.. Update. This process is the previous Pimpron and Model update.

conclusion

One thing I learned was the RequestScheduler class, which basically dictates a maximum number of concurrent requests, collects download requests in each frame but doesn’t send them, sorts the requests in the queue the next frame (camera distance), and then sends them. The implementation is very clever, easy to manage. After all, it is necessary to have such a Manager to control massive data.

The big problem is deletion (because there are no big data tests, just guessing from the code logic).

First, update and SELECT are both asynchronous or workers thread mechanisms, so there will be memory leakage in the case of large data volume.

Second, Replace queues mindlessly delete, not according to the current range and LOD, which is a big flaw in the design. It only considers visible and invisible, but does not optimize the deletion strategy.

Draw on the source code of ‘Chicken silk’ big guy analysis original address