sensors Article Towards Efficient Implementation of an Octree for a Large 3D Point Cloud Soohee Han Department of Geoinformatics Engineering, Kyungil University, Gyeongsan 38428, Korea; [email protected] Received: 22 October 2018; Accepted: 11 December 2018; Published: 12 December 2018 Abstract: The present study introduces an efficient algorithm to construct a file-based octree for a large 3D point cloud. However, the algorithm was very slow compared with a memory-based approach, and got even worse when using a 3D point cloud scanned in longish objects like tunnels and corridors. The defects were addressed by implementing a semi-isometric octree group. The approach implements several semi-isometric octrees in a group, which tightly covers the 3D point cloud, though each octree along with its leaf node still maintains an isometric shape. The proposed approach was tested using three 3D point clouds captured in a long tunnel and a short tunnel by a terrestrial laser scanner, and in an urban area by an airborne laser scanner. The experimental results showed that the performance of the semi-isometric approach was not worse than a memory-based approach, and quite a lot better than a file-based one. Thus, it was proven that the proposed semi-isometric approach achieves a good balance between query performance and memory efficiency. In conclusion, if given enough main memory and using a moderately sized 3D point cloud, a memory-based approach is preferable. When the 3D point cloud is larger than the main memory, a file-based approach seems to be the inevitable choice, however, the semi-isometric approach is the better option. Keywords: octree; 3D point cloud; terrestrial laser scanning; memory-based octree; file-based octree 1. Introduction Advances in 3D terrestrial laser scanning technology and its various applications have increased the size of 3D point clouds enormously. Unlike elements stored in conventional spatial database management systems (SDBMS), a 3D point cloud has even more entities—points, up to billions in number, however, each entity is not topologically related to the others. Thus, it is necessary to use relevant methods to handle the data. The methods can be categorized into two: lossy compression or abbreviation, and lossless indexing. The former category eliminates less meaningful points from the 3D point cloud. Several relevant approaches have reported that the reduced data still exhibits consistent results with half or even less point density [1–3]. The latter category retains and uses the original coordinate information of all points, and then uses special data structures to store and retrieve the data efficiently. For example, as a dynamic partitioning algorithm, R-tree is commonly utilized in SDBMS with its derivatives, and might be applicable for this purpose. However, R-tree is based on minimum bounding rectangles (MBR) and points are apt to be enclosed by overlapping nodes, making it a poor solution [4]. K-d tree, which is also a dynamic partitioning algorithm is more efficient and has been officially implemented in the point cloud library (PCL) [5]. However, in the worst case, all of the child nodes should be retrieved to traverse from a node to its child node where the 3D boundary satisfies a positional query [6]. Thus, a large 3D point cloud necessitates proper methods to re-organize or index itself efficiently. Among the known methods, octree is popular for its memory efficiency, query speed and structural simplicity [7]. In octree, only one child node in each depth is traversed because the 3D boundary of each node is implicitly known by positional query. Thus, a leaf node can be advantageously retrieved in this approach. Octree is now being exploited by a number of Sensors 2018, 18, 4398; doi:10.3390/s18124398 www.mdpi.com/journal/sensors Sensors 2018, 18, 4398 2 of 14 applications for segmentation and visualization of 3D point clouds [8–14], and also in PCL. However, octree, as a static partitioning algorithm, has a potential weakness, that is, memory waste because eight child nodes are always declared, even when not all of them bear point(s) within themselves. To address this weakness, a schema was presented to avoid declaration of child nodes that bear no points, and to terminate subdivision if the number of points goes below a threshold after further subdivision [15,16]. A memory efficient encoding method was also employed to minimize the size of a node in octree. The present study uses a native octree, which means that derivations of octree, as introduced in the relevant approaches [15,16] are not considered. Instead, it deals with other issues that influence the performance of octree. These include how to make a compact node in a native octree, how to design functions (methods) applicable to the node, where to store and retrieve the 3D point cloud itself (main memory or HDD), and what the shape of octree should be. From preliminary tests, several influencing factors were found: 1) the size of a node is very flexible but does not have much influence on query speed, and 2) dynamic declaration of nodes in the octree construction process claims more memory than expected, thus, array declaration is preferable after a pseudo octree construction [17]. The present study is based on the array-based approach and this will not be further mentioned in this paper. The paper is structured as follows: implementation of a compact node and relevant methods are outlined in Section 2.1.1, implementation of a file-based octree to reduce main memory usage is described in Section 2.1.2, more efforts to enhance the performance of octree are discussed in Sections 2.1.3 and 2.1.4, and its application is shown in Section 2.2. Results along with the discussion and conclusions follow in Sections3 and4. 2. Material and Methods 2.1. Algorithm Development 2.1.1. Implementation of Octree for a 3D Point Cloud An octree is defined as a tree data structure in which each internal node has exactly eight children, where a three dimensional space is created by recursively subdividing it into eight octants [18]. To index a 3D point cloud using octree the 3D boundary is divided into eight octants, which are further subdivided recursively only when they bear point(s) within themselves until the sequence reaches a given threshold value, namely depth. The final subdivision results in eight leaf nodes that store points within their archives. In the present study, the basic steps used to implement octree from a 3D point cloud were: 1. An axially-aligned minimum bounding hexahedron (hereafter, MBH) is defined to tightly enclose the whole 3D point cloud and assigned to a head node. 2. Eight new MBHs are defined by halving the MBH along the x-, y- and z-axes, and are assigned to eight child nodes. 3. A child node, of which MBH encloses an input point, is chosen and the input point is passed over a child node in further depth. 4. Step 2 and Step 3 are continued until the depth reaches a given threshold value (hereafter, Depth) and the final child node (hereafter, the leaf node) stores the input point. 5. Every point in the 3D point cloud is assigned to the head node and undergoes Step 2 to Step 4. A larger Depth creates more subdivision and allows leaf nodes to have fewer points, and a smaller Depth has the opposite effect. Having fewer points in a leaf node reduces computational overhead in point retrieval, but also increases the traversing route from head to leaf node. Thus, Depth should be experimentally adjusted to minimize the overall point retrieval time. Pseudo codes to implement the steps in C++ language based on the standard template library (STL) are given in Figure1. The Addpoint method selects a child node of which octant encloses an input point, and updates the MBH of the selected child node. The input point is recursively passed over selected child nodes until the depth of the current node (curDepth) equals the final depth (finalDepth). Sensors 2018, 18, x FOR PEER REVIEW 3 of 14 SensorsSensors 20182018,, 1818,, 4398x FOR PEER REVIEW 33 of 1414 (finalDepth). The final selected leaf node pushes back the pointer (pt) of the input point to a vector archive(finalDepth). (pVector). The finalThe GetPointListselected leaf nodemethod pushes recursively back the retrieves pointer child (pt) ofnodes the inputenclosing point the to positiona vector Theofarchive interest final (pVector). selected by a similar leaf The node mechanism,GetPointList pushes back and method the points pointer recursively can (pt)be retrieved of retrieves the input from child point the nodes topVector a vector enclosing of archive the selectedthe (pVector). position leaf Thenode.of interest GetPointList The sizeby a ofsimilar method the node mechanism, recursively class in Figureand retrieves points 1 is child detcanermined nodesbe retrieved enclosing by the from type the the positionof pVectorvariable of interest ofused the inselected by the a similar MBH. leaf mechanism,Thenode. size The of size CNode and of pointsthe is 60node canbytes class be (= retrieved inmbh(6 Figure × from8 1 bytes) is det the ermined+ pVector curDepth(4 by of thethe bytes) selectedtype +of pVector(4 variable leaf node. usedbytes) The in + size the pChild(4 ofMBH. the nodebytes))The size class using of inCNode Figuredouble is1 precision60is determinedbytes (= or mbh(6 36 bybytes the× 8 (=mbh(6 typebytes) of + variable curDepth(4× 4 bytes) used + bytes)depth(4 in the + MBH. pVector(4bytes) The + pVector(4 sizebytes) of + CNode pChild(4 bytes) is + 60pChild(4bytes)) bytes using (= bytes)) mbh(6 double using× 8 precision bytes)single +precision. curDepth(4or 36 bytes In both bytes)(=mbh(6 cases, + pVector(4 × a4 greatbytes) deal bytes) + depth(4 of +memory pChild(4 bytes) is bytes))required+ pVector(4 using during bytes) double tree + precisionconstruction—estimatedpChild(4 orbytes)) 36 bytes using (=mbh(6 single to be precision.× up4 bytes) to 60 In + depth(4both 8 orcases, 36 bytes) a great 8 + pVector(4bytes deal afterof memory bytes) n-subdivisions, + is pChild(4 required bytes))in during the usingworst tree singlecase.construction—estimated precision.