3DB-ROC Data Structure Organization for Three-Dimensional Building Models

With the rapid development of technologies such as smart city, digital twin, and metaverse, the data volume of three-dimensional building models is experiencing explosive growth. To address the issue of efficient organization and management, existing approaches primarily rely on single-structure spatial indices (e.g., R-tree, Octree) or hybrid indices. However, single-structure methods often suffer from limitations like node overlap (R-tree) or unbalanced structures (Octree) with uneven data distribution. While hybrid indices are effective for point clouds, their application to 3D building models remains limited, and existing implementations may introduce inefficiencies during construction or for fine-grained data organization within complex buildings. Hereby, this paper proposes a 3DB-ROC data structure organization method for three-dimensional building models. This method combines the advantages of R-tree and octree. Firstly, using a single building as the basic unit, the R-tree organizes the 3D building model data in a coarse-grained manner. Then, in a fine-grained manner, the octree is employed to organize the individual building model data within a single building. This hierarchical strategy minimizes tree depth, balances structure, and boosts data handling and query performance. Experimental evaluation on metaverse platform data demonstrates that: Firstly, 3DB-ROC outperforms R-tree, octree, KD-tree, BVH, and 3DOR in construction speed and insertion efficiency; Secondly, it achieves faster region retrieval than octree, particularly for small-area queries; Moreover, the method maintains balanced spatial utilization and acceptable global retrieval latency. These results confirm that 3DB-ROC effectively addresses the requirements of efficient organization and management of 3D building models, especially in applications requiring frequent data construction and insertion.

Abstract licence: CC BY-NC-ND

43 more references, whose wording the paper’s licence keeps private.

A person counts once a day per paper. We keep no cookie and no address: a reader is a hash that changes every day. Any month under five reads shows no number.