Supported data structures
Cesium supports the following types of Cesium3DTileContent:
Batched3DModel3DTileContent
Instanced3DModel3DTileContent
PointCloud3DTileContent
Composite3DTileContent
Wherein, Composite3DTileContent is composite data, and PointCloud3DTileContent is point cloud data containing only FeatureTable and BatchTable (from the data structure provided by the official, I have not tested it myself).
This section mainly Batched3DModel3DTileContent types, this paper introduces the data structure of 3 dtiles point and core technology.
Apply colours to a drawing
From the diagram, the red line is the state change. TileContent is an abstract concept, concrete is its inheritance class Batched3DModel or Instanced3DModel to complete the specific function, and each specific Content will be different according to its own data structure.
3. State-based 3D Tiles, such as semantics, complete data LOADING through a series of request, and then wrap up the LOADING state, which means data parsing.
After the data is parsed, it enters the READY state, passes the selectTile, and finally calls the update method corresponding to Content to construct the final drawCommand and join the rendering queue. Of course, if there are tiles that need to be freed, they are handled in unloadTiles. Careful people will find Pocessing and Ready states. You end up calling the update method.
GlTF is also based on state management. GlTF parsing and DrawCommand construction, with different states, are done in update methods. As shown above, this is also illustrated by an orange arrow.
A relatively complete process is given above, and the Content is mainly glTF, which has been introduced before. Therefore, BatchTable and FeatureTable in B3DM are mainly focused below.
Batched3DModel3DTileContent
The data structure is laid out as follows
Here, Cesium3DTileBatchTable is the same as the previous BatchTable, which saves the attribute values to the texture for use. Cesium3DTileBatchTable provides a regular flow that allows users to easily create the tile_batchTexture as an expression.
Batchtable structure
The batchtable is a JSON object with 3d tiles. At the same time, batchTable creates a tile_batchTexture based on the length of the JSON (the number of ids) to store the corresponding attributes. At the same time, there are as many Cesium3DTileFeature objects corresponding to as many ids, which can be considered as the accessor of batchTable. It is responsible for reading and writing operations of batchtable with ID as the unique identifier.
Given the data and how to read and write it, you need to provide a specification for how to read and write it, and that is the responsibility of the Cesium3DTileStyle class. Currently, the default is to specify the color based on JSON, such as the height value of the JSON object. Implement a range segmentation effect that specifies the color based on the height value. Of course, if you know how to modify the Shader, you can modify the code to create your own mappings to achieve the desired effect.
parsing
The above is the class structure of the semantic parsing tree, which is also a schematic diagram of the parsing process. Finally, each condition is encapsulated into a statement to realize its own judgment criteria.
Each time through all statements on the tree, find the Node that meets the criteria. In comparison, the left Node of the left Node is first looked, and the attribute used is Height. In this way, the Height value of batchTable can be found by the corresponding id of the feature. If the condition is satisfied, the corresponding color: Purple can be obtained.
As mentioned above, feature is equivalent to an accessor. After obtaining this value, it is directly transmitted to batchValues corresponding to batchtable, where this is the imageData corresponding to the texture. Feature encapsulates the attributes of this read and write operation, which is convenient for users to call.
End, above is Batched3DModel3DTileContent interpretation
Finally, draw lessons from the source code analysis of “chicken silk” big guy