1 : Chunked LOD 파이프 라인의 어느 지점에서 메쉬가 청크로 분할되는지 이해할 수 없습니다. 초기 메시 생성 중에 발생합니까, 아니면이를 수행하는 별도의 알고리즘이 있습니까?
그것은 중요하지 않습니다. 예를 들어 청킹을 메시 생성 알고리즘에 통합 할 수 있습니다. 플라즈마와 같은 다듬기 알고리즘을 사용하여 더 낮은 레벨이 동적으로 추가되도록 (예 : 플레이어가 가까이 다가 갈 때)이를 동적으로 수행 할 수도 있습니다. 아티스트 입력 또는 고도 측정 데이터에서 고해상도 메시를 생성하고 자산 마무리 시간에 모든 LOD 청크로 집계 할 수 있습니다. 또는 믹스 앤 매치 할 수 있습니다. 실제로 응용 프로그램에 따라 다릅니다.
2 : Chunked LOD 데이터를 저장하는 데 Quadtree 데이터 구조가 사용된다는 것을 이해합니다. 점을 약간 누락했다고 생각하지만 quadtree는 각 세분화 레벨에 대해 정점 및 삼각형 데이터를 저장합니까?
반드시 그런 것은 아닙니다. 트리에는 지오메트리 및 렌더링 방법에 대한 정보 만 저장됩니다. 이것은 모든 트리 노드에 꼭짓점 /면 목록이 있음을 의미 할 수 있습니다. 이 시대에보다 현실적으로 메시 / 인스턴스 핸들을 GPU 메모리에 저장합니다.
3a : 카메라 거리는 일반적으로 어떻게 계산됩니까? 쿼드 트리에 대해 읽을 때 축 정렬 경계 상자가 많이 언급됩니다. 이 경우 각 청크에 카메라 나 플레이어가 가까이 있다는 것을 감지하는 충돌 경계 상자가 있습니까? 아니면 더 좋은 방법이 있습니까? (어쩌면 레이 캐스트?)
매우 저렴하고 쉬운 옵션은 청크의 중심점까지의 거리를 사용한 다음 수정하는 것입니다. 이 거리는 항상 과소 평가된다는 것을 알고 있습니다. 중심점이 거리 Z
에 있으면 청크의 절반이 그 거리 에 가깝다는 것을 의미합니다. 그러나 우리가 모르는 것은 오리엔테이션입니다. 너비가 큰 청크를 보는 경우 청크의 w
가장 가까운 비트는 거리에 있습니다 Z-w
. 그러나 가장 먼저 청크를 보는 경우 가장 가까운 비트는 거리에 있습니다 Z-sqrt(2)*w
. 이 불확실성으로 살 수 있다면 (거의 항상 가능합니다) 끝났습니다. 기본 삼각법을 사용하여 시야각을 보정 할 수도 있습니다.
아티팩트를 최소화하기 위해 카메라에서 청크까지의 최소 거리를 계산하는 것이 좋습니다. 실제로 이것은 포인트-제곱 거리 테스트를 수행 하는 것을 의미 합니다. 중심점까지의 거리를 계산하는 것보다 약간 더 많은 작업이지만, 매 프레임마다 거대를하는 것은 아닙니다.
물리 엔진을 활용하여이를 수행 할 수 있다면 반드시 그렇게해야하지만 실제로는 "충돌"보다 "거리 쿼리"에 대해 더 많이 생각하고 싶을 것입니다.
3b : 청크가 카메라 거리 자체를 계산합니까?
그것은 실제로 엔진의 디자인에 달려 있습니다. 그래도 잎을 비교적 가볍게 유지하는 것이 좋습니다. 플랫폼에 따라 매 수천 개의 지형 청크가 호출마다 오버 헤드가 발생하면 매 프레임마다 자체 업데이트를 수행하여 성능에 심각한 영향을 줄 수 있습니다.
4 : 각 청크가 동일한 "해상도"를 갖습니다. 예를 들어 최상위 레벨에서 메시는 32x32가되고, 세분화 된 각 노드는 32x32가됩니다.
반드시 필요한 것은 아니지만 모든 청크가 같은 양의 공간을 차지하면 편리합니다. 그런 다음 "청크"단위로 (GPU) 메모리 관리를 수행 할 수 있습니다. 하나의 해상도가 다른 꼭지점을 공유하기 때문에 다른 해상도의 배수라면 크기가 다른 두 청크 사이의 이음새를 쉽게 제거하거나 숨길 수 있습니다. (예 : 32x32 및 64x64는 32x32 및 57x57보다 관리하기가 쉽습니다) 청크 지오메트리 크기를 변경해야 할 정당한 이유가 있다면 반드시 해결하십시오.