Enhancing Query Efficiency for Huge 3D Point Clouds Based on Isometric Spatial Partitioning and Independent Octree Generation

등축형 공간 분할과 독립적 옥트리 생성을 통한 대용량 3차원 포인트 클라우드의 탐색 효율 향상

Abstract

This study aims at enhancing the performance of file-referring octree, suggested by Han(2014), for efficiently querying huge 3D point clouds, acquired by the 3D terrestrial laser scanning. Han's method(2014) has revealed a problem of heavy declining in query speed, when if it was applied on a very long tunnel, which is the lengthy and narrow shaped anisometric structure. Hereupon, the shape of octree has been analyzed of its influence on the query efficiency with the testing method of generating an independent octree in each isometric subdivision of 3D object boundary. This method tested query speed and main memory usage against the conventional single octree method by capturing about 300 million points in a very long tunnel. Finally, the testing method resulted in which twice faster query speed is taking similar size of memory. It is also approved that the conclusive factor influencing the query speed is the destination level, but the query speed can still increase with more proximity to isometric bounding shape of octree. While an excessive unbalance of octree shape along each axis can heavily degrade the query speed, the improvement of octree shape can be more effectively enhancing the query speed than increasement of destination level.

본 연구는 3차원 지상레이저스캐닝을 통해 취득된 대용량 3차원 포인트 클라우드를 효율적으로 탐색하기 위하여 Han(2014)이 제안한 파일 참조 옥트리의 성능을 개선하는 것을 목표로 한다. Han(2014)의 방식을 좁고 긴 형상의 비등축형 구조물인 장대터널에 적용한 결과 포인트 탐색 속도가 크게 저하되는 문제점이 발견되었다. 이에 옥트리의 형상이 포인트 클라우드의 탐색 효율에 미치는 영향을 분석하였으며, 대상물의 3차원 경계를 등축형 하위 영역으로 분할하고 각 영역에 독립적인 옥트리를 생성하는 방식을 제안하였다. 장대터널에서 취득된 약 3억 개의 포인트로부터 단일 옥트리를 생성하는 기존 방식과 다수의 독립적인 옥트리를 생성하는 방식으로 포인트 탐색 속도와 메인 메모리 사용량을 비교하였다. 결과로 다수 옥트리 방식이 유사한 크기의 메인 메모리를 사용면서도 약 2배의 탐색 속도를 나타내었다. 아울러 옥트리의 탐색 속도를 좌우하는 주요 요소는 목표 단계이나 같은 목표 단계에서는 옥트리의 형상이 등축형에 가까울수록 탐색 속도는 여전히 증가함을 확인하였다. 다만 옥트리의 형상이 각 축 방향으로 지나치게 불균형을 이룰 경우 탐색 속도는 크게 저하되며 이 경우 옥트리의 형상 개선이 목표 단계 증가보다 탐색 속도 향상에 효과가 큼을 확인하였다.

1. 서 론

차원 지상레이저스캐닝은 대규모 건설현장에서 토탈스테이션을 이용한 재래식 측량을 대체할 수 있는 첨단 측량 기술로 인식되고 있다. 특히 터널이나 교량, 댐과 같이 국소 표면의 변형이나 부재의 거동이 전체 구조물의 안전에 영향을 미칠수 있는 경우 지상레이저스캐닝을 이용하여 광범위한 영역에 대해 높은 밀도의 측량을 효율적으로 수행할 수 있다. 한편 스캐닝 장비의 발달과 저장 장치의 가격 하락에 힘입어 지상레이저스캐닝을 통해 취득된 포인트 클라우드의 용량이 급격히 증가하고 있는 가운데 이를 효율적으로 활용하기 위해서는 적절한 색인(indexing) 방식의 사용이 필수적이다(Han et al., 2011). 옥트리는 이미 2.5차원 및 3차원 포인트 클라우드의 처리와 관련된 다양한 연구에서 사용되고 있으며(Saxena et al., 1995; Woo et al., 2002; Wang and Tseng, 2004; Schnabel et al., 2007; Cho et al., 2008; Marechal, 2009), 메모리 사용량 및 탐색 속도 면에서 합리적인 방식임이 증명되었다(Han et al., 2011; Han et al., 2012). Han(2013)은 옥트리 생성에 소요되는 메인 메모리의 사용량을 줄이기 위하여 C언어 환경에서 트리를 구성하는 노드 클래스의 멤버 변수와 하위 노드 검색 방식이 미치는 영향을 분석하고 개선 방안을 제시하였다. 그러나 Han(2013)의 방식은 3차원 포인트 클라우드 전체를 메인 메모리에 저장하여 탐색하는 방식으로서 메인 메모리의 용량을 초과하는 포인트 클라우드에 대해서는 적용할 수 없다는 단점이 있다. 이에 Han(2014)은 포인트 클라우드를 메인 메모리에 저장하지 않고 하드디스크에 저장한 상태로 각 포인트에 대한 파일 포인터를 직접적으로 참조하는 방법을 사용함으로써 색인 가능한 포인트 클라우드의 용량을 증가시켰다. 아울러 메인 메모리에 구현된 옥트리를 파일로 저장하고 필요시 복원함으로써 옥트리 구성 시간을 현저하게 줄이는 방법도 제안하였다.

한편 Han(2014)의 방식을 좁고 긴 형상의 구조물인 장대터널에 적용한 결과 포인트 탐색 속도가 크게 저하되는 문제점이 발견되었다. 일반적으로 옥트리는 정육면체의 형상으로 구현하나 대상물을 둘러싸는 최소 크기의 직육면체로 구현하는 것이 리프 노드의 포인트 밀도를 보다 균일하게 유지하여 탐색 효율 제고에 유리하다. 그러나 장대터널과 같이 종방향으로 현저히 긴 대상물을 둘러싸는 형상의 옥트리를 구현하면 개별 리프 노드가 감당하는 포인트의 수가 늘어 탐색 효율이 저하된다. 이에 본 연구에서는 옥트리의 형상이 포인트 클라우드의 탐색 효율에 미치는 영향을 분석하고 터널과 같이 x, y, z 방향으로 현저한 크기 차이를 나타내는 대상물의 포인트 클라우드를 대상으로 탐색 효율을 제고할 수 있는 옥트리 구성 방안을 제시하고자 한다.

 

2. 본 론

기존의 연구에서는 3차원 포인트 클라우드가 차지하는 전체 영역을 둘러싸는 최소의 직육면체에 대하여 단일 옥트리를 생성하였다. 직육면체의 좌하단 및 우상단 3차원 좌표를 각각 (xmin, ymin, zmin), (xmax, ymax, zmax)라 하고 x, y ,z 방향의길이를 각각(= xmax – xmin) , (= ymax – ymin), (= zmax – zmin)라 하면 2번 분할된 상태, 즉 2단계의 목표 단계에서의 옥트리의 형상은 Fig. 1과 같고 n단계 목표 단계에서 리프노드의 크기는 Eq. (1)과 같이 정의한다.

Fig. 1.Octree in destination level 2

아울러 리프노드의 각 축간 크기의 비는 전체 영역을 둘러싸는 직육면체의 각 축간 비율과 같다(Eq. (2)).

만일 장대 터널 또는 교량과 같이 전체 영역을 둘러싸는 직육면체의 수평 방향 길이가 수직 방향 길이에 비하여 매우 커서 불균형을 이루는 경우 리프노드의 수평 및 수직 방향 크기 비율 역시 불균형을 이루게 된다. 이 때 Han(2014)의 연구처럼 일정 반경 안에 존재하는 포인트를 탐색하는 경우 필요 이상으로 많은 인근 포인트에 대한 탐색을 수행해야 한다. 예를 들어 Fig. 2와 같이 포인트 클라우드의 분포 형상이 z축 방향에 비하여 x축 방향으로 긴 경우 단일 옥트리를 생성하면 리프노드 역시 Fig. 3(a)와 같이 x축 방향으로 긴 형상을 갖게 된다. 이 경우 중심으로부터 일정 거리에 있는 포인트를 탐색하기 위해 접근해야 하는 리프노드의 수는 8개이지만 그 안에 속하여 접근해야 하는 포인트의 수는 29개이다. 만일 Fig. 3(b)와 같이 리프노드의 형상이 등축형에 가까우면 12개의 리프노드에 속한 17개의 포인트에만 접근하면 된다. 즉 리프노드의 형상이 등축형에 가까울수록 접근해야 하는 포인트가 수가 감소하므로 탐색 속도가 빨라진다. 특히 Han(2014)의 연구와 같이 옥트리는 접근 속도가 빠른 메인 메모리에 형성되어 있고 리프노드에 속한 포인트는 상대적으로 매우 느린 하드디스크드라이브를 참조할 경우 리프노드의 형상 변화에 의한 효과는 더욱 커질 것으로 기대할 수 있다.

Fig. 2.Generation of a single anisometric octree

Fig. 3.Comparison of query overheads: (a) anisometric leaf nodes, (b) near-isometric leaf nodes

이에 본 연구에서는 Fig. 4와 같이 포인트 클라우드 전체를 둘러싸는 최소 직육면체를 가급적 등축형에 가까운 동일한 크기의 하위 공간으로 분할하고 각각의 하위 공간에 대하여 독립적인 옥트리를 생성하는 방식을 제안한다. 다만 다수의 옥트리를 생성할 경우 메모리의 사용량이 증가한다는 단점이 존재한다. 예를 들어 Fig. 4처럼 4개의 옥트리를 독립적으로 생성하면 Fig. 2의 단일 옥트리에 비해 최대 4배의 메모리를 소요할 수 있다. 따라서 하위 공간의 형상이 등축형에 가까운 정도에 따라 귀결되는 탐색 속도와 메인 메모리 사용량 등을 분석하고자 한다. 이를 위해 분할 전 직육면체의 x, y, z 방향 길이 중 최단 길이와 분할 후 공간의 x, y, z 방향 길이 중 어느 것과의 비율도 임계치 tl (1이상의 실수)을 초과할 수 없도록 공간을 분할한다. 분할 전 공간의 x, y, z 방향 길이 를 크기 순서대로 로 정의하면, 과 방향으로 분할될 공간의 수 n1과 n2는 Eq. (3)과 같이 정의한다.

Fig. 4.Generation of multiple isometric octrees

Eq. (3)에서 ceil(r)은 실수 r보다 작지 않은 최소의 정수로 정의한다. 분할된 공간의 , 과 방향 길이 과 는 식(4)와 같이 정의한다.

예를 들어 tl = 1 인 경우 과 의 크기는 보다 크지 않으며 분할된 공간은 거의 등축형을 이루게 된다. tl = 2인 경우 과 의 크기는 의 두 배보다 크지 않으며 분할된 공공간은 두 축이 나머지 한 축에 비해 거의 2배인 직육면체의 형상을 이루게 된다.

 

3. 적용 및 평가

본 연구에서는 3차원 포인트 클라우드로부터 옥트리를 생성하고 저장하며 재현하기 위하여 소요된 시간과 메인 메모리의 크기를 측정하였으며, 옥트리의 탐색 성능을 파악하기 위하여 일정 반경 안에 존재하는 인근 3차원 포인트에 대한 탐색 시간을 측정하였다. 비교 대상은 Han(2014)의 파일 참조방식과 동일한 단일 옥트리를 생성하는 방식(이 후 단일 옥트리 방식)과 본 연구에서 제안한 다수의 독립적인 옥트리를 생성하는 방식(이 후 다수 옥트리 방식)이다. 실험에 사용한 포인트 클라우드는 길이가 약 1.5km인 철도 터널에 대한 3차원 지상레이저스캐닝으로 취득된 자료이며 보안상 정확한 위치와 출처는 생략한다. 포인트 클라우드의 제원은 Table 1과 같으며 실험에 사용된 시스템의 사양은 Table 2와 같다. 포인트 클라우드의 x 방향 크기는 569.16m, y 방향크기는 1442.58m임에 비하여 z 방향 크기는 19.05m로서 수평 반향과 연직 방향이 큰 차이를 보이고 있다. Han(2014)의 연구에서는 포인트 클라우드를 저장하고 파일 포인터를 참조하기 위하여 하드디스크드라이브를 사용하였으나 본 실험에서는 보다 안정적인 성능 평가를 위하여 SSD(Solid State Drive)를 사용하였다.

Table 1.Specifications of point cloud

Table 2.Specifications of system

단일 옥트리 방식의 경우 공간 분할 횟수인 목표 단계(Han, 2013)를 9부터 13까지 설정하였다. 목표 단계 14부터는 시스템이 기본적으로 사용하는 백그라운드 서비스와 함께 8GB 이상의 메인 메모리를 소요하여 시스템이 페이지 메모리를 사용함으로써 정확한 성능 측정이 불가함에 따라 실험에서 제외하였다. 다수 옥트리 방식의 목표 단계는 8부터 10까지 설정하였으며 분할된 공간의 축간 길이 비율 임계치인 tl 은 1부터 3의 정수로 설정하였다. 아울러 목표 단계 10에서 tl = 1인 경우 백그라운드 서비스와 함께 8GB 이상의 메인 메모리를 소요하여 실험에서 제외하였다.

각 목표 단계에서 리프 노드의 크기와 옥트리의 생성, 저장, 재현에 소요된 시간 및 메모리의 크기는 Table 3과 같다. 단일 옥트리 방식의 경우 리프노드의 최장 축(y축)과 최단 축(z축)의 크기 비율이 약 60배의 불균형을 이룬다. 반면 다수 옥트리방식의 경우는 최장 축(y축)과 최단 축(z축)의 크기 비율이 tl = 1일때 1배, tl = 2일 때 2배, tl = 3일 때 3배 3배 미만으로 불균형이 크게 해소된 것을 확인할 수 있다. 옥트리의 생성, 저장, 재현에 소요된 시간은 옥트리 구현에 소요된 메인 메모리의 크기와 밀접한 관련이 있는 것으로 파악되었으며 전반적으로 큰 차이를 보이지 않았다.

Table 3.Time and main memory taken by octree generation

옥트리의 탐색 성능을 평가하기 전체 포인트 수의 약 0.01%인 30054개의 포인트를 중심으로 반경 5cm 이내의 포인트를 탐색하였다. 모든 경우에 대하여 탐색된 포인트의 수는 17554511개로 동일하여 옥트리의 탐색 정확성에는 결함이 없는 것을 확인할 수 있다. 탐색 시간과 사용된 메인 메모리의 크기는 Table 4와 같으며 탐색 속도에 따라 오름차순으로 정렬하였다.

Table 4.Comparisons of main memory usage and query time

Table 4의 case 1에서 다수 옥트리 방식의 목표 단계를 10, tl = 2로 설정할 때 가장 빠른 속도를 기록하였고 단일 옥트리 방식에서 목표 단계를 12, 13으로 설정하였을 때를 제외하고는 다수 옥트리 방식의 탐색 속도가 우세했다. 다수 옥트리 방식과 단일 옥트리 방식에서 각각 가장 빠른 속도를 비교하면 case 1과 case 3에서 1/366.99sec : 1/582.60sec ≒ 1.59 : 1로서 다수 옥트리 방식이 약 1.6배 빠른 것을 확인할 수 있다. 반면 당시의 메인 메모리 사용량은 5111MB : 6416MB ≒ 0.80 : 1로서 다수 옥트리 방식이 20% 가량 적게 사용함을 확인할 수 있다. 아울러 유사한 크기의 메인 메모리를 사용할 경우 다수 옥트리 방식이 단일 옥트리 방식에 비해 탐색 속도가 빠름을 확인할 수 있다. 예를 들어 case 12와 case 10에서 다중 옥트리 방식이 단일 옥트리 방식에 비하여 메인 메모리를 3% 가량 많이 소요하지만 탐색 속도는 2.8배 빠름을 확인할 수 있으며, case 9와 case 11에서 메모리는 4% 가량 적게 소요하면서 탐색 속도는 1.6배 빠름을 확인할 수 있다.

한편 다수 옥트리 방식의 경우 tl 이 1에 가까울수록, 즉, 옥트리의 형상이 등축형에 가까울수록 탐색 속도가 명백히 빨라짐을 확인할 수 있다. 다만 이에 의한 효과는 목표 단계의 증가로 인한 속도 향상 효과를 능가할 수는 없음을 확인할 수 있다. 예를 들어 목표 단계 9에서 tl 값에 관계 없이 목표 단계 8보다 탐색 속도가 빠르며 목표 단계 10 역시 목표 단계 9보다 빠르다.

Fig. 5는 소요된 메모리의 크기와 탐색 시간의 추세를 그래프로 나타낸 것으로 소요되는 메인 메모리의 크기가 증가할수록 탐색 속도는 빨라진다는 일반적인 원리를 확인할 수 있다. 아울러 다중 옥트리 방식이 단일 옥트리 방식과 비교하여 비슷한 크기의 메인 메모리를 소요할 경우 탐색 속도는 2배 가량 빠름을 확인할 수 있다. 따라서 본 연구에서 제안한 다중 옥트리 방식이 보다 단일 옥트리 방식에 비하여 성능이 우수하다고 결론지을 수 있다.

Fig. 4.Generation of multiple isometric octrees

 

4. 결 론

본 연구에서는 3차원 지상레이저스캐너로부터 취득한 대용량의 포인트 클라우드로부터 효율적인 탐색을 수행하기 위하여 Han(2014)이 제안한 파일 참조 옥트리의 성능을 향상시키고자 하였다. 특히 장대터널과 같이 연직 방향에 비해 종방향의 크기가 매우 큰 대상물에 대하여 취득한 포인트 클라우드로부터 옥트리를 생성할 경우 리프 노드의 형상이 특정 방향으로 지나치게 커져 탐색 성능이 저하되는 문제점이 발생할 수 있다. 이를 해결하기 위해 본 연구에서는 포인트 클라우드를 감싸는 3차원 공간을 가급적 등축형에 가까운 하위 공간으로 분할하고 각 공간에 대하여 독립적인 옥트리를 생성하는 방법을 제안하였다. 본 연구를 통하여 다음과 같은 결론을 내릴 수 있다.

- 일반적으로 옥트리의 탐색 속도를 증가시키려면 메인 메모리의 추가적인 소요를 감수해야 한다.- 옥트리의 탐색 속도를 좌우하는 주요 요소는 목표 단계이며 같은 목표 단계에서는 옥트리의 형상이 등축형에 가까울수록 탐색 속도는 증가한다.- 옥트리의 형상이 각 축 방향으로 지나치게 불균형을 이룰 경우 탐색 속도는 크게 저하되며 이 경우 옥트리의 형상 개선이 목표 단계 증가보다 탐색 속도 향상에 효과가 크다.

Han(2014)의 연구와 본 연구에서는 메인 메모리에 옥트리를 생성하고 파일 포인터를 리프노드에 저장하는 방식을 사용함으로써 옥트리 생성에 여전히 많은 메모리가 소요되며 잦은 파일 참조로 인해 탐색 속도 향상에는 한계가 있다. 향후 연구에서는 파일 포인터 저장과 잦은 파일 참조를 해소할 수 있는 방법을 강구하고자 한다.