공간 매핑 베스트 프랙티스

공간 매핑으로 생성할 수 있는 데이터 볼륨과 데이터 생성에 따른 속도와 성능로 인해 낮은 레벨의 API를 사용할 때는 고려해야 할 사항이 많습니다.

애플리케이션의 공간 매핑 사용을 신중하게 계획하지 않으면 애플리케이션의 속도와 성능이 심각하게 저하될 수 있습니다. 아래는 공간 매핑으로 인해 발생할 수 있는 몇 가지 문제와 그에 대한 해결 방안의 베스트 프랙티스입니다.

문제: 충돌 데이터 생성이 매우 느립니다.

충돌 데이터 생성은 공간 매핑 데이터를 생성할 때 CPU 연산의 대부분을 사용합니다. 사용하지 않을 충돌 데이터를 요청하면 CPU 리소스를 쓸데없이 묶어두게 되고 배터리 수명이 단축됩니다.

베스트 프랙티스 솔루션

• 필요 시에만 충돌 데이터를 요청합니다. 필요하지 않은 경우 충돌 데이터를 요청하지 않으면 다른 공간 매핑 요청에 대한 지연 속도가 줄어들고 배터리 수명을 늘릴 수 있습니다.
• 가장 중요한 Surface 만 요청합니다. Surface 의 업데이트 시간과 바운딩 박스를 사용하여 데이터 요청의 우선 순위를 결정합니다.

문제: 고밀도 삼각형에서 많은 지오메트리를 생성합니다.

RequestMeshAsync를 통해 Surface 데이터를 요청할 경우, SurfaceData 구조체에서 높은 trianglesPerCubicMeter 값을 지정할 수 있습니다. 이렇게 하면 특히 어수선한 사무실과 같이 많은 오브젝트가 있는 공간에서 매우 많은 양의 지오메트리가 생성됩니다. 지오메트리의 양이 증가하면 데이터 생성 지연 속도와 메모리 사용량이 증가합니다. 또한 메시 밀도가 높을수록 렌더링, 물리 엔진과 같은 런타임 시스템이 느려질 수 있습니다.

베스트 프랙티스 솔루션

• 필요한 공간 매핑 데이터의 최소 해상도를 요청합니다. 생성되는 메시에 대해 더 낮은 해상도를 요청하면 요청을 처리하는 데 소비되는 CPU 시간이 줄어 듭니다. 이렇게 하면 전력 소비를 줄이고 배터리 수명을 늘리며 메시 데이터 전송 지연 속도를 줄일 수 있습니다. 낮은 해상도의 메시는 또한 런타임 성능에 부정적인 영향을 거의 미치지 않으며 메모리 요구 사항에 보다 적은 리소스가 필요합니다. 이는 복잡성이 낮은 지오메트리를 기대하는 물리 런타임에 특히 해당됩니다.

문제: 너무 많은 메시 요청을 대기열에 지정하여 불필요한 작업이 수행됩니다.

SurfaceObservers는 Update가 호출되면 볼륨에서 모든 추가, 업데이트 및 제거된 Surfaces 를 보고합니다.

변경된 Surfaces 의 전체 리스트를 작업 대기열에 추가하면 시스템에서 제거된 후에도 Surfaces 가 작업 대기열에 남아 있을 수 있습니다. 제거된 뒤에도 작업 대기열에 남아 있는 Surfaces 는 여전히 시스템에서 돌아다니며 CPU 시간을 잡아먹지만, mMsh 데이터를 생성하지 않습니다. 이로 인해 대기 중인 요청의 지연 속도가 늘어나게 됩니다.

베스트 프랙티스 솔루션

• 가능한 경우 작업 대기열의 Surfaces 수를 제한합니다. 메시 작업 대기열에 따른 긴 대기 시간을 감안하여, 한 번에 하나의 RequestMeshAsync만 사용합니다. 애플리케이션은 Surface 의 보고된 업데이트 시간과 바운드를 사용하여 RequestMeshAsync 호출의 우선 순위를 정할 수 있습니다.
• Surface 데이터 요청의 우선 순위를 지정하여 애플리케이션이 가장 중요한 데이터를 먼저 얻도록 합니다. 다음 예제를 참조하십시오.
  • 기존 표면에 대한 업데이트보다 새로운 Surfaces 에 더 높은 우선 순위를 부여합니다.
  • 먼 것보다 가까운 Surfaces 에 더 높은 우선 순위를 부여합니다.

문제: 겹치거나 옆에 있는 SurfaceObserver가 동일한 메시를 보고하여 RequestMeshAsync 호출이 중복됩니다.

각 SurfaceObserver는 볼륨이 겹치는 모든 Surfaces 에 대한 변경 사항을 보고합니다. 볼륨이 가까이 있다면 Surface 는 다수의 SurfaceObserver 볼륨과 겹칠 수 있으므로, 애플리케이션 코드는 동일한 Surfaces 를 여러 번 요청할 수 있습니다.

베스트 프랙티스 솔루션

• 모든 SurfaceObservers에 하나의 작업 제출 대기열을 사용합니다. 대부분의 경우, 애플리케이션의 복잡성을 피하기 위해 하나의 SurfaceObserver 만 사용해도 충분합니다. 하지만, 여러 개의 SurfaceObservers 가 필요한 Spatial Mapping 의 고급 사용 사례도 있습니다. 이러한 경우에는, 모든 SurfaceObservers 에 하나의 대기열을 사용하여 독자적으로 메시 요청 우선 순위를 지정합니다.
• 애플리케이션이 복잡성을 요구하지 않는 경우 단일 SurfaceObserver 를 사용합니다.

문제: SurfaceObserver를 업데이트해도 onSurfaceChanged 콜백이 생성되지 않습니다.

이 일반적인 문제는 주로 하나 이상의 설정 문제 때문에 발생하는 경우가 많습니다.

베스트 프랙티스 솔루션

• SurfaceObserver 에 SetVolumeAsAxisAlignedBox와 같은 함수를 통해 유효한 볼륨을 설정합니다.
• Player Settings 의 Publishing Settings 섹션에서 Spatial Perception 을 확인합니다.