명백히 말할 위험이 있지만 이미 repo( examples/js/Octree.js )에 있는 threeocttree 버전을 사용해 보셨습니까?

나는 three.js 에서 공간 검색 트리의 하드 와이어 사용에 투표하지 않습니다. 이러한 알고리즘의 오버헤드/복잡성은 많은 응용 프로그램에서 성능 향상의 균형을 초과합니다.

실제 레이캐스트를 수행하기 전에 먼저 경계 상자와 구를 확인합니다.

이는 합리적이며 충분해야 합니다. 사용자가 고급 사용 사례와 관련하여 더 많은 성능이 필요한 경우 언급된 예를 시작점으로 사용할 수 있습니다. 옥트리가 좋은 선택이 될 수 있습니다. 그러나 접근 방식이 매우 정교하기 때문에 대화형 3D 응용 프로그램에서 R-Tree 솔루션을 본 적이 없습니다(알고리즘이 공간 분할 대신 데이터를 수행함).

안녕하세요, 답변해주셔서 감사합니다.
@Mugen87 많은 사용 사례에서 그렇게 빠른 검색이 필요하지 않다는 데 동의합니다. 그러나 3D 개체와 상호 작용하는 메커니즘이 있는 경우(대부분 사용되는 경우) THREE.Raycaster 의 경계 상자/구체를 먼저 확인하는 단계(합리적이라는 데 전적으로 동의합니다 )에서 실제 레이캐스트를 수행할 때 선형 시간 노력에 대한 일정한 시간이 상당히 큽니다. 하나의 전역 검색 트리 대신 일종의 "기하학 검색 트리"를 상상할 수 있습니다. 지오메트리가 변경되지 않는 한(종종 변형이 지오메트리 변경보다 훨씬 가능성이 높음) 검색 트리를 업데이트할 필요가 없습니다.

그래서 공간 검색 트리를 사용한 이러한 종류의 최적화가 three.js 에서 더 중요한 부분이 될 수 있다고 생각했습니다. 그러나 이것이 추가적인 복잡성과 오버헤드를 유발한다는 것도 이해합니다.

@moraxy 예제 버전을 살펴보겠습니다. 그러한 기능이 의미가 있는지 알고 싶었습니다.

다시 한 번 감사드립니다.

더 간단한 검색 트리를 THREE.BufferGeometry 에 통합할 수 있습니다. 예를 들어 computeBoundingBox 에 대한 호출은 해당 정점을 참조하는 일종의 읽기 전용 검색 트리를 구축할 수도 있습니다. THREE.BufferGeometry 는

인스턴스화한 후 지오메트리를 많이 조작할 필요가 없는 정적 객체에 가장 적합합니다.

이 검색 트리는 초기화 후 변경할 필요가 없습니다. 이것은 업데이트/삭제에 대한 약간의 오버헤드를 줄입니다. Octree는 좋은 출발점이 될 것입니다( BabylonJS의 유사한 개념 ).

인스턴스화한 후 지오메트리를 많이 조작할 필요가 없는 정적 객체에 가장 적합합니다.

FWIW, 나는 그것이 진실한 진술이라고 믿지 않습니다.

@WestLangley THREE.BufferGeometry 문서의 인용문

THREE.BufferGeometry 문서

그것은 아마도 제거되어야 할 것입니다 - 어쨌든, 나는 그것이 어떤 종류의 기술적 진술을 의미한다고 생각하지 않습니다. 오히려 그것이 생성된 후 사용자가 지오메트리를 조작하기가 더 어렵다는 것을 의미합니다.

아마도 제거해야 할 것입니다

가장 확실합니다.

방금 PlaneBufferGeometry에서 레이캐스팅을 위한 더 나은 방법을 구현했습니다. 나는 far 매개변수를 사용하고 첫 번째와 마지막 인덱스 위치를 찾습니다. 인덱스 배열이 x/y 순서로 되어 있기 때문에 이것은 평면 버퍼에서 작동합니다. x/y 경계 상자를 벗어나면 모든 충돌이 원거리 범위 밖에 있어야 합니다. 이것을 어딘가에 저지르고 싶은 욕망이 있습니까? 현재 구현은 내 사용 사례에 따라 다르지만 원하는 경우 더 일반적으로 만들려고 합니다. 큰 planeBuffer(2.5초에서 10ms)에서 레이캐스팅 성능을 크게 줄일 수 있었습니다.

@kpetrow three.js octree 예제가 적절하다고 생각합니다. 물론 다른 사람들에게 유용하다고 생각되면 GitHub에서 자유롭게 코드를 공유할 수 있습니다.

과거에 threejs에 포함될 공간 인덱스를 제안한 적이 있습니다. 이 방향으로 작업이 있었고 기존 oct-tree 예제가 그 중 하나입니다. 궁극적으로 이 기능을 일류 시민으로 삼는 것과 관련하여 핵심 커뮤니티의 관심이 부족하다고 생각합니다.

기본 배포판(예제 아님)에 포함할 충분한 관심과 의도가 있는 경우 내 BVH 코드를 프로젝트에 기부할 수 있어 기쁩니다.
내 코드는 두 가지 측면에 중점을 둡니다.

• 역동적인 장면
  
  
  
  • 빠른 삽입
  
  
  • 빠른 삭제
  
  
  • refitting(다시 삽입할 필요 없이 노드가 모양을 변경할 수 있는 기능)
  
  
• 쿼리 속도

2가지 구현이 있습니다.

• 바이너리BVH
  
  
  
  • ByteBuffer를 사용하여 매우 컴팩트함
  
  
  • DataView를 통한 UintX 및 FloatX 유형 혼합
  
  
  • 직렬화에 적합
  
  
  • lzma 라이브러리와 같은 표준 도구를 사용하여 압축할 수 있습니다.
  
  
  • 불변
  
  
  • 빌드 속도가 고도로 최적화되어 있습니다.
  
  
  • BufferGeometry에서만 작동합니다.
  
  
  • SAH 최적화
  
  
  • 광선 쿼리
  
  
• BVH
  
  
  
  • 결과적으로 개체 트리는 이진 구현보다 훨씬 큽니다.
  
  
  • 변하기 쉬운
  
  
  • 빠른 대량 삽입
  
  
  • 빠른 단일 항목 삽입
  
  
  • 재장착
  
  
  • 스택, 재귀 및 스택 없는 순회 구현(다른 성능 특성)
  
  
  • SAH 최적화
  
  
  • 절두체 쿼리
  
  
  • 레이 쿼리
  
  

개인적으로, 나는 공간 인덱스 없이는 살 수 없습니다. 그것은 n^2와 log(n) 성능의 차이입니다. 예를 들어, 현재 프로젝트에서 다음 부분은 공간 인덱스에 의존합니다.

• 경엽 시스템(나무, 꽃, 덤불 등)
• 모든 개체 배치(캐릭터 및 집)
• 선택(마우스 클릭과 같은 상호 작용에 사용)

http://server1.lazy-kitty.com/komrade

지형에는 약 1m 폴리곤이 있으며 수천 그루의 나무를 배치하고 여기에 실시간 레이캐스트를 실행하는 것은 특히 저사양 장치의 경우 절대 해서는 안 됩니다.

레이캐스트를 최적화할 수 있는 모든 것을 보고 싶습니다. 복잡성을 추가하지 않고 최적화할 수 있는 여지가 있습니까? Octree에는 모든 새로운 추가 및 업데이트 등이 포함된 모든 새로운 라이브러리가 필요합니다.

내가 알아차린 한 가지는 지오메트리가 인덱스된 버퍼 배열로 변환되면 더 이상 원래 지오메트리의 속성을 현명하게 사용하지 않는다는 것입니다. 위에서 언급했듯이 평면 버퍼 기하학은 arrayBuffer가 PlaneGeometry에서 왔다는 것을 알면 매우 최적화될 수 있습니다. MESH.raycast( raycaster, intersects ) 메서드를 지오메트리 유형을 기반으로 덮어쓸 수 있습니까?

또 다른 접근 방식은 Raycaster를 별도의 플러그인으로 사용하는 것입니다. 대화식 컨트롤과 로더도 마찬가지입니다. 그런 다음 @Usnul 이 제안하는 것과 유사한 성능의 레이캐스터를 추가하는 것이 좋습니다.

플러그형 Raycaster가 있다는 아이디어가 마음에 들지만 약간의 혼란이 있다고 생각합니다. 내가 유용하다고 생각하는 것은 Raycaster 자체가 아니라 공간 인덱스입니다. 공간 인덱스는 다음과 같은 것을 허용합니다.

• 공간 컬링(절두체 컬링 생각)
• 가시성 쿼리 수행
• 경로 추적 렌더러 빌드
• 빠른 정렬(데이터 지역성 활용)

현재 three.js는 이 중 2개를 명시적으로(정렬 및 컬링) 수행하고 1개는 예제(레이 트레이싱 렌더러)를 통해 수행합니다.

공간 인덱스를 내부적으로 유지하면 정렬 및 컬링이 가속화되어 인덱스를 저장하는 데 필요한 추가 RAM 비용으로 더 큰 장면에 대해 점진적으로 더 많은 이점을 얻을 수 있습니다.

GPU 선택을 사용하지 않는 이유는 무엇입니까? 주변에 몇 가지 예가 있으며 구현하기가 상당히 쉽습니다. 공연은 밤낮이다. 백만 개 이상의 폴리곤 모델이 있는 사용 사례에서 선택은 거의 1초에서 60fps로 실시간으로 실행되는 동시에 모델 위로 드래그했습니다.

https://github.com/brianxu/GPUPicker

@hccampos
GPU 선택이 CPU에서 수행하는 것보다 반드시 더 빠른 것은 아닙니다. GPU의 경우 원하는 정밀도에 비례하는 해상도로 렌더링해야 하므로 픽셀 정확도를 원하면 1:1 화면 해상도로 렌더링해야 합니다. 이것은 별도의 렌더 패스이며 개체를 별도의 고유 색상으로 렌더링한다는 점을 명심하십시오. 추가 렌더 패스는 그래픽 메모리 사용량을 의미합니다(지연된 파이프라인의 경우 일반적).
이진 공간 분할 인덱스를 사용하면 선택에 대한 로그(n) 타이밍 프로필이 제공되므로 1,000,000개의 폴리곤에 대해 광선 쿼리를 해결하기 위해 약 14개의 작업을 보게 됩니다. 데이터 구조에 따라 - 몇 마이크로초가 소요될 수 있으며 프레임 예산에 영향을 미치기 시작하기 전에 수천 개의 쿼리를 허용할 수 있습니다.

1m 폴리 모델이 있고 카메라 방향을 따라 화면 공간에서 직접 장면으로 광선을 투사하려고 한다고 가정해 보겠습니다(사용 사례 선택). 배럴 해상도의 하단인 "풀 HD" 또는 1920 × 1080을 사용한다고 가정해 보겠습니다. RGB만 렌더링(픽셀당 24비트)한다고 가정해 보겠습니다. 렌더링하려면 6220800바이트(약 6Mb) 또는 그래픽 RAM이 필요합니다 저것. CPU 솔루션을 사용하는 경우 리프당 10개의 폴리곤이 있는 AABB BVH를 사용한다고 가정해 보겠습니다. 즉, 약 200,000개의 노드가 필요합니다. 각 노드는 좌표에 대해 약 6 * 8바이트이고 중간 노드에는 하위 포인터에 대해 추가 2 * 4바이트가 있습니다. 리프 노드는 폴리곤 포인터에 대해 10 * 4바이트, 즉 14,400,000바이트(약 14Mb)를 갖습니다. 주요 차이점은 BVH 쿼리가 GPU의 경우에 비해 RAM 대역폭에 대한 요구가 매우 적고 전체 1m 폴리 지오메트리를 렌더링하는 것과 비교하여 쿼리당 몇 가지 작업만 포함된다는 사실을 고려할 때 나타납니다.
2560x1440과 같이 데스크톱에 더 일반적인 해상도를 선택하면 11059200byte 렌더 타겟(11Mb)이 됩니다.

그래픽 램 대역폭의 예산이 많고 셰이더 코어 수가 상당히 많다면 - 물론 간단하고 직관적인 선택 방법입니다.

@Usnul 은 절대적이지만 구현하기에 가장 간단한 솔루션일 것입니다. 공간 인덱스 데이터 구조를 구현하고 유지하는 것은 아마도 threejs 유지 관리자에게 중요하지 않은 부담이 될 것입니다.

즉, 세 개의 일부 또는 별도의 npm 패키지로 훌륭하고 잘 테스트되고 유지 관리되는 공간 인덱스 데이터 구조를 갖고 싶습니다.

사용하는 지오메트리에 대해 이러한 공간 인덱스를 구현하는 것이 궁금해서 BufferGeomtry를 분할하는 아주 간단한 Octree(생성 및 검색 전용)를 구현했습니다. 이 간단한 솔루션으로 저는 매우 유망한 결과를 얻었습니다. 약 500K 정점이 있는 기하학에 적용하여 레이캐스트 시간이 ~120ms에서 ~2.3ms로 단축되었습니다. 현재 트리의 구성은 ~500ms가 걸리지만 웹 워커 내부에서 기하학과 트리 생성은 애플리케이션 시작 시 한 번만 수행되기 때문에 문제가 되지 않습니다.

알고리즘은 THREE.BufferGeometry 에 아주 쉽게 통합될 수 있고 THREE.BufferAttribute 의 dynamic 와 같은 플래그를 사용하여 켜거나 끌 수 있다고 생각합니다. 이렇게 하면 BufferGeometry가 변경되지 않아야 하는 경우에만 사용할 수 있습니다. 불행히도 THREE.Mesh 의 raycast 메서드를 덮어써야 했지만 두 줄만 변경하면 되었습니다(Octree 검색 호출 및 위치 배열 반복).

어쨌든 내 VR 응용 프로그램에서 마우스 클릭 시 한 번뿐 아니라 렌더링 루프 중에 개체 컨트롤러 충돌을 감지해야 합니다. 따라서 현재 솔루션에 의존해야 합니다. 더 개선할 수 있으면 노력하겠습니다.

업데이트 레이캐스트 시간 측정에 실수를 저질렀습니다. 올바른 값은 ~2.3ms입니다(~0.3ms 대신). 그에 따라 위의 값을 변경했습니다.

three.js를 기반으로 구축된 대부분의 복잡한 애플리케이션에서는 빠른 공간 조회를 수행하는 옵트인 방식이 필요하다고 생각합니다. 예를 들어, 3D 편집기. 나는 몇 가지 구현을 가지고 놀았지만 잘 통합되지 않거나 three.js의 특정 버전으로 너무 빡빡하게 래핑됩니다. 따라서 누구든지 three.js의 최신 버전으로의 업그레이드 경로를 중단하지 않고 이를 수행할 수 있는 선택적인 방법이 있다면 좋을 것입니다.

@matthias-w obj 모델에 대해 raycaster를 시도했지만 컨트롤러가 아무 것도 감지하지 못합니다. 광선이 모델을 통과하고 있습니다. 그 문제를 어떻게 고쳤는지 알려주실 수 있나요

선택적 공간 인덱스를 갖는 주제에. 렌더러 자체(예: 컬링용)가 엔진의 필수적인 부분이 되기에도 충분히 유용하다고 생각합니다. 다음은 관련 토론입니다.

13909

이봐! 나도 이것에 약간 관심이 있었지만(그 이후로 레이캐스트 요구 사항에 대한 다른 솔루션을 찾았지만) 내 실험에도 일부 기여할 것이라고 생각했습니다. 다소 거칠지만 몇 달 전에 이것을 정리했습니다.

https://github.com/gkjohnson/threejs-fast-raycast

3개의 지오메트리 객체에 computeBoundsTree 함수를 추가하고 이를 사용하도록 raycast 함수를 재정의합니다(추가된 최적화로 첫 번째 히트만 반환). 정적이고 매우 복잡한 메시에만 정말 유용하며 장면을 공간적으로 분할하는 데는 아무 것도 하지 않습니다. 다음은 80,000개의 삼각형 메시에서 레이캐스트 성능의 차이를 볼 수 있는 데모 입니다. 경계 트리를 계산하는 것은 약간 느리지만 약간의 작업으로 더 부드럽게 할 수 있습니다.

이에 대한 제 의견에 대해서는 약간의 갈등을 느낍니다. 이것은 THREE에 대한 확장으로서 꽤 잘 구축될 수 있는 것과 같은 느낌입니다. 그리고 궁극적으로 복잡하거나 애니메이션된 메시에 대해 삼각형별 검사/충돌/캐스트를 수행하는 것이 최적인 것처럼 보이지 않습니다. 간단한 경우에는 괜찮을 수 있지만 복잡한 경우에 초고속 레이캐스팅(또는 오클루전 컬링, 충돌 등)을 가능하게 하려면 일반적인 평면/큐브/구/캡슐 표현이나 단순화된 메시를 사용하는 것이 더 적합할 것 같습니다. 물론 완벽한 픽셀 캐스트를 찾고 있다면 이것은 잘 작동하지 않지만 올바른 솔루션은 실제로 사용 사례에 따라 다릅니다.

@Usnul @matthias-w 귀하의 octree/BVH 구현은 오픈 소스입니까 아니면 온라인에서 사용할 수 있습니까? 나는 확실히 관심을 가지고 살펴볼 것입니다!

@gkjohnson

octree/BVH 구현 중 하나가 오픈 소스이거나 온라인에서 사용 가능합니까? 나는 확실히 관심을 가지고 살펴볼 것입니다!

코드는 현재 오픈 소스가 아닙니다. 저에게 개인적으로 연락하시면 출처를 알려드릴 수 있습니다.

인스턴스화된 메시에 대해 수행한 예가 있습니다.
http://server1.lazy-kitty.com/tests/instance-foliage-1mil/
위의 예에는 다음이 포함됩니다.

• BVH는 새 인스턴스가 트리에 삽입될 때 동적으로 업데이트됩니다.
• BVH는 즉석에서 깊이 1-2 회전을 사용하여 점진적으로 최적화됩니다.
• BVH는 렌더링할 인스턴스에 대한 절두체 쿼리로 샘플링됩니다.

작업 중인 게임에서 실행 중인 버전이 있습니다.
http://server1.lazy-kitty.com/komrade/

귀하의 구현과 관련하여. 나는 그것을 좋아한다. 나의 것은 2가지 주요 면에서 다르다:

• 나는 성능에 집중한다
• 나는 메모리 풋프린트에 집중한다
• 나는 많은 곳에서 가비지 수집을 피한다

좀 더 구체적인 사항:

• 또한 BVH로 수행하려는 작업에 따라 투명하게 분할 전략을 혼합하여 사용합니다.
• 내 BVH는 AABB 기반입니다.
• 재적합을 통해 노드 경계에 대한 업데이트를 지원합니다.

@Usnul 귀하의 이메일 주소 등을 볼 수 없지만 귀하의 공간 인덱싱 솔루션을 연구하는 데 상당히 관심이 있습니다.

현재 나는 모든 관련 장면 개체를 반복하고 카메라로부터의 거리를 계산합니다. 가장 최적의 접근 방식은 아닙니다.

@titansofttime
이것의
travnick at gmail com
공개적으로 사용할 수 없다는 것을 몰랐습니다. 내 잘못이야.

@Usnul 저도 100만 프로젝트에 관심이 있습니다. 가능하다면 1000만~2000만도 가능하다. 저에게 이메일을 보내주세요: kaori.nakamoto. [email protected]

매우 친절하게 감사합니다!

http://server1.lazy-kitty.com/tests/instance-foliage-10mil/
이것은 1000만 버전입니다.

답장을 늦게 보내서 미안해.
@gkjohnson 코드는 오픈 소스가 아닙니다. 또한 귀하의 솔루션은 제 것보다 훨씬 더 정교하게 들립니다. 따라서 내 솔루션에서 배울 점이 많지 않은 것 같습니다.

@sid3007 문제를 이해하고 있는지 잘 모르겠습니다. 나는 나의 접근 방식을 설명할 수 있다. 아마도 도움이 될 것입니다.

내 사용 사례는 매우 간단합니다. 내 애플리케이션이 시작되면 다양한 모델에 대한 지오메트리가 로드됩니다. 이러한 모델은 사용자가 변형할 수 있습니다. 형상은 변경되지 않습니다. 기하학적 변형이 없습니다. 따라서 애플리케이션이 시작될 때 모든 지오메트리에 대해 한 번 빌드되는 매우 간단한 Octree를 구현했습니다. 옥트리는 동적이지 않습니다. 주어진 지오메트리의 경계 상자와 정점 배열을 기반으로 구축됩니다. 생성하는 동안 8진수에 정점이 포함되어 있는지 또는 8진수의 Box3 경계 상자가 삼각형(인덱싱되지 않은 지오메트리의 연속 3개 정점)과 교차하는지 확인하고 정점 배열 참조를 옥트리 노드와 저장합니다.
메쉬별 옥트리는 메쉬와 함께 저장됩니다. 또한 실제로 octree 교차 테스트 메서드를 호출하기 위해 메쉬 인스턴스의 THREE.Mesh 의 raycast 메서드(한 줄만)를 덮어씁니다. 이것은 메쉬의 기본 교차 논리에서 사용할 수 있는 기하학적 면 정점 인덱스를 반환합니다.
한 가지 최적화를 수행했습니다. octree 생성은 WebWorker(실제로는 작업자 풀) 내에서 앱 시작 시 한 번 수행됩니다. 그 이유는 큰 지오메트리를 위한 트리 생성에 상당한 시간(몇 초)이 걸리기 때문입니다. 이렇게 하면 브라우저 UI가 차단되므로 다른 스레드로 옮겼습니다.
내 접근 방식이 명확해지기를 바랍니다.

@matthias-w 정말 잘한 것 같습니다! 나는 독립적으로 거의 동일한 작업을 수행했지만 성능 향상을 거의 달성했다고 생각하지 않습니다. https://discourse.threejs.org/t/octree-injection-for-faster-raytracing/8291/2 (객체 지향 옥트리 구현 및 Mesh.raycast에 대한 덜 깨끗한 수정)

다른 사람들이 더 많은 실험을 할 수 있도록 Octree 구현을 오픈 소스/기여할 수 있습니까?

@EliasHasle 감사합니다. 사실 첫 번째 측정에서 실수를 저질렀기 때문에 성능 향상은 그다지 좋지 않습니다. 값을 수정했습니다(위의 내 게시물 참조). Octree의 대수 검색 복잡성과 관련하여 타이밍이 더 합리적입니다. 불행히도 지금은 코드를 제공할 수 없지만 올해 말일 수 있습니다. 어쨌든, 내 구현은 매우 간단합니다(그리고 깨끗한 BTW ;). 그래서 특별한 인사이트는 없었을 것 같아요.

@matthias-w 500k 버텍스 메시의 레이캐스트에 대해 2.3ms 대 120ms는 여전히 상당한 개선이라고 생각합니다. 예를 들어 게임에서 발사된 총알의 실시간 해상도를 가능하게 하는 것입니다(계산의 상당히 큰 부분 프레임당 예산).

레이트레이싱도 해보셨나요?

구현이 JS 개체 트리를 기반으로 합니까? 리터럴 개체 또는 프로토타입의 인스턴스? 광산은 완전히 자기 유사하므로 모든 노드는 메서드와 모두가 포함된 옥트리입니다.

@EliasHasle

정적 기하학에 대한 레이캐스팅에 관심이 있다면 저와 다른 사람들은 BVH를 사용하여 삼각형을 인덱싱하고 고성능 레이캐스팅과 정적 복합 기하학에 대한 교차 감지를 허용하는 three-mesh-bvh 에 상당한 노력을 기울였습니다. 트리 구축 프로세스는 더 복잡하므로 시간이 조금 더 걸리지만 수십만 개의 삼각형이 있는 지오메트리에 대해 레이캐스팅할 때 레이캐스팅은 밀리초 미만, 종종 0.1ms 미만까지 걸립니다.

빌드 시간은 몇 가지 다른 방법으로 향상될 수 있지만 내가 원하는 작업에는 충분했습니다. 하지만 개선하는 것은 목록에 있습니다.

메시가 많은 장면에 대해 더 나은 레이캐스팅 및 충돌 감지를 가능하게 하기 위해 동적 장면 기반 옥트리를 만들고 싶지만 좋은 사용 사례가 없었습니다. 언젠가는!

@EliasHasle 내 구현은 JS 클래스 객체의 트리입니다(ES6 클래스, 즉 프로토타입 인스턴스 사용). 기본적으로 노드는 내 구현에서 트리입니다. 그러나 루트 노드를 보유하고 트리를 구축 및 검색(또한 일부 디버깅 및 시각화)하기 위한 메서드를 제공하는 추가 Octree 클래스가 있습니다.

최대 트리 노드 수준 및 리프 노드당 최대 정점 수에 대한 값을 많이 실험하지 않았습니다. 어쩌면 더 나은 조합이 있을지도 모릅니다.
또한 경계 볼륨 계층을 사용하여 교차 테스트를 가속화합니다. 그래서 메쉬 지오메트리의 옥트리를 실제로 확인하기 전에 메쉬의 경계 구와 경계 상자를 테스트합니다.

충돌 감지 접근 방식의 훌륭한 모음집인 책을 추천할 수 있습니다. C. Ericson, Real-Time Collision Detection, CRC Press, 2004

@gkjohnson 멋지네요 ! 성능이 인상적입니다. 어떤 종류의 BVH를 사용하고 있습니까?

@matthias-w 감사합니다!

몇 가지 분할 전략 옵션이 있지만 가장 긴 측면의 중심에서 BVH 노드를 분할하면 트리가 가장 빠르게 구축됩니다. 삼각형은 경계의 중심을 기준으로 측면으로 분할되고 트리 노드는 자식 삼각형을 완전히 포함하도록 확장됩니다(따라서 트리 노드가 약간 겹치게 됨).

@gkjohnson 그러면 BVH 구현은 상자 모양에 따라 축 선택이 가능한 일종의 불균형 Kd-트리입니다. 맞죠? 그렇다면 루트 BB가 큐브에서 너무 멀리 떨어져 있는 경우에 대해 이와 같은 작업을 수행한 다음 조건부 분할 후에 옥트리를 사용하는 방법에 대해 생각하고 있었습니다. 이것은 초기 분할이 2개의 "지도" 차원에서 이루어지고 후속 분할이 3D로 진행되는 @Usnul 의 지도 세계와 같은 경우에 아마도 잘 적용될 것입니다. 루트 BB를 같은 중심을 가진 경계 큐브로 확장한 다음 octree 분할을 끝까지 사용하는 것이 내 것보다 훨씬 더 나은 솔루션이라고 생각합니다.

방금 PlaneBufferGeometry에서 레이캐스팅을 위한 더 나은 방법을 구현했습니다.

@kpetrow PlaneBufferGeometry 에 대한 레이캐스트 최적화 , 꼭짓점 위치가 변경되지 않는다는 가정은 선형 검색이 불충분한 고해상도 지오메트리에 유효하지 않을 가능성이 매우 높습니다. 내가 말할 수 있는 한, 고해상도 PlaneBufferGeometry 의 주요 용도는 토폴로지를 유지하면서 정점을 이동하여 모양을 변경하는 것입니다(예: 지형 구축).

#13909에 찬성하여 마감합니다.