Original Post by: RyanFranz Mon Apr 14 21:16:45 2014
From the CDB webinar Q&A
Q: Can we restore the number of vertex information that has now been deprecated in the 3D model datasets? This was very useful for client device load management.
A: There is no longer any need to do this because the maximum number of vertices per Model-LOD is bounded and known in advance. This way, the client knows what the maximum complexity is. Chapter 6 provides an algorithm for the computation of a modelââ¬â¢s Significant Size (SS) which is based on its vertex count. In turn, the SS determines a modelââ¬â¢s nominal level-of-detail.
Using a worst case value vs. using the actual known value can be a large difference to an RTP (realtime publisher). One goal of an RTP is to maximize the content that is displayed for a client device, and worst case can be a far cry from the expected case in a CDB database.
Also, for a GS point feature, you can't tell what Model-LOD it is referring to. The RTP, when reading the GSFeature shapefiles, only knows the tile-lod of the zip file to find a particular LOD of the model. It would take some searching to find a lower (or higher) LOD of the model, by searching the LOD stack (up or down). This doesn't seem practical to do while flying a CDB database, so the algorithm in section 6.8 for successive LODs doesn't look like it will help us.
Craig
From the CDB webinar Q&A
Using a worst case value vs. using the actual known value can be a large difference to an RTP (realtime publisher). One goal of an RTP is to maximize the content that is displayed for a client device, and worst case can be a far cry from the expected case in a CDB database.
Also, for a GS point feature, you can't tell what Model-LOD it is referring to. The RTP, when reading the GSFeature shapefiles, only knows the tile-lod of the zip file to find a particular LOD of the model. It would take some searching to find a lower (or higher) LOD of the model, by searching the LOD stack (up or down). This doesn't seem practical to do while flying a CDB database, so the algorithm in section 6.8 for successive LODs doesn't look like it will help us.