Antigravity Agent
40 lines
5.1 KiB
Markdown
40 lines
5.1 KiB
Markdown
---
|
|
id: [[P-Reinforce|P-Reinforce]]-AUTO-95FEB9
|
|
category: Dev
|
|
confidence_score: 0.90
|
|
tags: [auto-reinforced]
|
|
last_reinforced: 2026-04-20
|
|
github_commit: "[P-Reinforce] Continuous Worker - React Three Fiber에서 Rapier 물리 엔진 최적화하기"
|
|
---
|
|
|
|
# [[React Three Fiber에서 Rapier 물리 엔진 최적화하기|React Three Fiber에서 Rapier 물리 엔진 최적화하기]]
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
> React Three Fiber(R3F) 환경에서 `@react-three/rapier`를 사용할 때, 대규모 `InstancedRigidBodies` 적용, 비트마스크 기반의 충돌 필터링, Rust 메모리 에러 방지를 위한 상태 캐싱, 그리고 렌더링 루프 분리를 통해 연산 오버헤드를 극적으로 줄이는 고성능 물리 엔진 최적화 기법입니다.
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
**1. InstancedRigidBodies를 활용한 대규모 물리 객체 처리** 수백, 수천 개의 물리 객체(총알, 파편 등)를 개별 `<RigidBody>`로 렌더링하면 물리 연산과 드로우 콜 오버헤드로 인해 프레임이 급락합니다. 이를 방지하려면 Three.js의 `[[InstancedMesh|InstancedMesh]]`를 `<InstancedRigidBodies>`로 감싸서 사용해야 합니다. 이 방식을 사용하면 수천 개의 인스턴스에 대한 위치, 회전, 물리적 상태를 배열(`InstancedRigidBodyProps[]`) 형태로 단 번에 초기화하고 단일 드로우 콜로 렌더링할 수 있어 성능이 비약적으로 향상됩니다.
|
|
|
|
**2. interactionGroups를 통한 충돌 및 솔버 연산 최소화** 모든 객체가 서로 충돌 여부를 계산하게 두면 엔진에 큰 부하를 줍니다. Rapier에서는 `collisionGroups` 및 `solverGroups` 속성에 비트마스크(Bitmask)를 설정하여 상호작용할 대상을 제한할 수 있습니다. 라이브러리에서 제공하는 `interactionGroups` 헬퍼 함수를 사용해 객체가 속한 그룹과 상호작용할 그룹을 명시(예: `interactionGroups(0,)`)함으로써 불필요한 충돌 연산을 원천적으로 차단해야 합니다.
|
|
|
|
**3. [[Physics|Physics]] Hooks 캐싱을 통한 Rust 메모리 에일리어싱 에러 방지** 복잡한 일방향 플랫폼(One-way platform) 등 고급 충돌 필터링을 위해 `useFilterContactPair` 훅을 사용할 때, 물리 스텝 진행 도중 `translation()`이나 `linvel()` 같은 RigidBody 속성에 직접 접근하면 WASM(Rust) 계층에서 에일리어싱 에러가 발생합니다. 이를 방지하려면 반드시 `useBeforePhysicsStep` 훅을 사용해 물리 스텝 시작 전에 필요한 객체들의 상태(위치, 속도 등)를 자바스크립트 `Map` 등 캐시(Cache) 메모리에 미리 저장해 두고, 필터링 훅에서는 이 캐시된 데이터만 읽도록 설계해야 합니다.
|
|
|
|
**4. On-demand Rendering 및 물리 스텝 수동 제어** 기본적으로 `@react-three/rapier`는 프레임이 렌더링될 때마다 물리 시뮬레이션을 업데이트합니다. 하지만 화면의 시각적 업데이트가 필요 없을 때도 물리 연산이 필요하거나, 반대로 물리 연산을 일시정지하고 싶다면 `<Physics updateLoop="independent">`를 설정하여 렌더링 루프와 물리 루프를 분리할 수 있습니다. 또한 `useRapier().step()` 메서드를 통해 물리 시뮬레이션을 수동으로 진행(Manual stepping)시킬 수도 있습니다.
|
|
|
|
**5. 센서(Sensor) 활용 및 충돌 이벤트 내 React 상태 업데이트 지양** 물리적 반발력이나 밀어내기 연산이 필요 없고 오직 '영역에 들어왔는지(Overlapping)' 여부만 판별해야 한다면 해당 콜라이더에 `sensor` 속성을 부여해야 불필요한 솔버(Solver) 연산을 줄일 수 있습니다. 또한, `onCollisionEnter`와 같은 빈번한 충돌 이벤트 내부에서 React의 `set[[State|State]]`를 호출하면 심각한 리렌더링 지연이 발생하므로, 전역 상태 변경이 아닌 이상 명령형(Imperative) 파티클 시스템에 직접 신호를 보내 처리하는 것이 바람직합니다.
|
|
|
|
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
|
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
|
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
- **Related Topics:** [[InstancedMesh (드로우 콜 최적화)|InstancedMesh (드로우 콜 최적화]], Web Worker (웹 워커), Garbage Collection (GC) 최적화, [[Object Pooling (오브젝트 풀링)|Object Pooling (오브젝트 풀링]]
|
|
- **Projects/Contexts:** 고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처
|
|
- **Contradictions/Notes:** Rapier의 스냅샷(Snapshot) 기능(`world.takeSnapshot()`)을 이용해 물리 세계의 상태를 저장하고 복원할 수 있지만, 복원 시점의 객체 생성 순서나 식별자가 스냅샷 캡처 시점과 정확히 일치하지 않으면 RigidBody들이 엉키는(Scramble) 버그가 발생하므로 상태 직렬화에 각별한 주의가 필요합니다.
|
|
|
|
---
|
|
|
|
_Last updated: 2026-04-15_
|
|
|
|
---
|