Three.js 전체 가이드

Three.js의 포괄적 아키텍처 가이드: 기본 원리부터 고급 응용까지

66 Mini-Game: Marble Race

---

1부: 3D 세계의 기반

이 파트에서는 Three.js의 핵심 아키텍처 삼중주를 구축합니다. 화면에 무언가를 렌더링하는 데 필요한 기본 구성 요소를 해체하고, 그것들이 무엇인지뿐만 아니라 왜 분리되어 있으며 어떻게 상호 작용하는지에 초점을 맞춰 분석할 것입니다.

07 반응형 캔버스와 전체 화면 모드 설정 가이드

26. 프로젝트 구조화(Code structuring for bigger projects)

47 로딩 스크린과 인트로(Intro and loading progress)

---

1장: 가상 무대: 장면, 카메라, 렌더러

---

1.1 Scene 해부

Scene 객체는 모든 3D 객체, 조명, 카메라를 담는 중앙 데이터 구조이자 가상 환경의 기반으로 제시됩니다. 이는 객체 간의 공간적 관계를 정의하는 트리와 같은 구조인 장면 그래프(scene graph)의 루트 역할을 합니다.  

이 그래프는 단순한 목록이 아니라 계층 구조를 가지며, 이를 통해 복잡한 부모-자식 관계(예: 태양을 공전하는 행성을 공전하는 달)를 설정할 수 있습니다. 이러한 계층적 구조는 변환(위치, 회전, 크기)이 장면 전체에 어떻게 전파되는지를 결정하는 기본 원리입니다. 개발자는 Scene 객체를 생성하고 add() 메서드를 사용하여 객체와 조명을 이 가상 세계에 배치할 수 있습니다.  

---

1.2 뷰어의 렌즈: Camera

카메라의 역할은 장면이 렌더링될 시점을 정의하는 것입니다. 여기서는 두 가지 주요 카메라 유형을 분석합니다.

• PerspectiveCamera 이는 인간의 시각을 모방하도록 설계된 가장 일반적인 카메라입니다. 이 카메라의 생성자인   PerspectiveCamera(fov, aspect, near, far)를 면밀히 분석할 것입니다.
  • fov (Field of View): 카메라 시야의 수직 각도로, 렌즈가 얼마나 "넓은지"를 정의합니다.  
  • aspect: 출력의 너비 대 높이 비율로, 왜곡을 방지하는 데 매우 중요합니다. 이 값은 렌더러의 캔버스 크기와 동기화되어야 합니다.  
  • near 및 far: 이 평면들은 절두체(viewing frustum)를 정의하며, 이는 카메라에 보이는 공간의 부피를 나타내는 잘린 피라미드입니다. 이 부피 밖의 모든 것은 "클리핑"되어 렌더링되지 않으며, 이는 핵심적인 성능 최적화 기법입니다.  
• OrthographicCamera 이는 원근 왜곡 없이 장면을 렌더링하는 카메라로, 객체의 크기가 거리에 관계없이 일정하게 유지됩니다. 2D 스타일 게임, 건축 시각화 또는 기술 다이어그램에 이상적입니다. 이 카메라의 절두체(직육면체)를   PerspectiveCamera의 피라미드와 대조하여 설명할 것입니다. OrthographicCamera 생성자는 3D 월드 단위의 좌표를 예상하며, 픽셀 단위를 사용하지 않는다는 점에 유의해야 합니다.  

06 Three.js 카메라 타입 및 OrbitControls

---

1.3 WebGLRenderer: GPU로의 다리

WebGLRenderer는 Camera를 통해 본 Scene 데이터를 HTML <canvas> 요소에 그려지는 실제 이미지로 변환하는 핵심 요소입니다. 

• 설정 및 구성: 렌더러 인스턴스화, 크기 설정(setSize), 그리고 domElement를 문서 본문에 추가하는 필수 설정 단계를 안내합니다.  
• renderer.render(scene, camera)를 통한 단일 프레임 렌더링 과정은 전체 렌더링 파이프라인을 트리거하는 기본 명령으로 확립될 것입니다.

---

분리의 힘

Scene(데이터), Camera(시점), Renderer(실행)의 분리는 의도적이고 강력한 아키텍처 선택입니다. 이는 단순한 구현 세부 사항이 아닙니다. 이 세 가지 구성 요소가 항상 필요하다는 사실은 각각이 별개의 책임을 가지고 있음을 시사합니다.  

Scene은 세계의 상태를 정의하는 객체와 조명을 보유하고, Camera는 해당 상태에 대한 관점을 정의하는 뷰 매개변수(fov, position 등)를 가집니다. Renderer는 이 둘을 받아 이미지를 생성합니다.

이러한 분리는 이들을 독립적으로 변경할 수 있음을 의미합니다. 단일 Scene은 여러 Camera 관점(예: 메인 플레이어 뷰와 보안 카메라 뷰)에서 렌더링될 수 있습니다. 단일 Scene과 Camera 쌍은 다른 Renderer에 의해 렌더링될 수도 있습니다. 예를 들어, 하나는 주 디스플레이용이고 다른 하나는 저해상도 미니맵용일 수 있습니다. 이러한 관심사 분리는 고전적인 소프트웨어 디자인 패턴으로, 엄청난 유연성을 제공합니다. 이를 통해 개발자는 3D 세계의 복잡성(Scene)을 그것이 어떻게 표현되는지(Camera 및 Renderer)와 독립적으로 관리할 수 있으며, 이는 게임이나 편집기와 같은 복잡한 애플리케이션을 구축하는 데 매우 중요합니다.

Three.js Journey 03

 

---

2장: 보이는 객체의 해부학: Geometry, Material, Mesh

이 장에서는 Three.js에서 보이는 모든 객체의 구성을 해부하고, Mesh = Geometry + Material 공식을 핵심 원리로 확립합니다.

---

2.1 Geometry: 형태와 구조 정의

Geometry는 객체의 정점 데이터, 즉 그 형태를 정의합니다. 여기서는 더 이상 사용되지 않는 Geometry 클래스보다 성능이 뛰어난 현대적인 BufferGeometry를 표준으로 강조할 것입니다. 예시로는 BoxGeometry 및 SphereGeometry와 같은 원시적인 형태가 포함됩니다.  

08 Three.js 기하학 구조 및 다양한 지오메트리(geometries) 정리

12 텍스트(3D Text)

---

2.2 Material: 외관과 빛 상호작용 정의

Material은 색상, 텍스처, 빛과의 상호작용을 포함하여 지오메트리 표면이 어떻게 보이는지를 결정합니다. 다양한 재질 유형에 대한 비판적 분석을 제공하며, 초보자에게 가장 중요한 차이점인 재질이 빛의 영향을 받는지 여부에 초점을 맞출 것입니다.  

• MeshBasicMaterial: 가장 단순한 재질입니다. 빛의 영향을 받지 않으며 설정된 단색으로 렌더링됩니다. 디버깅, 와이어프레임 또는 스타일화된 비조명 장면에 이상적입니다.  
• 빛 의존적 재질: MeshLambertMaterial, MeshPhongMaterial, MeshStandardMaterial. 이 재질들은 보이려면 장면에 하나 이상의 조명이 필요합니다. 이것은 초보자들이 종종 혼란을 겪는 중요한 인과 관계입니다.  
  • MeshPhongMaterial: 반짝이는 하이라이트가 있는 광택 표면에 사용됩니다.  
  • MeshStandardMaterial: roughness와 metalness와 같은 속성을 사용하여 더 사실적인 결과를 제공하는 물리 기반 렌더링(PBR) 재질입니다. 계산 비용이 더 높지만 사실적인 표현을 위한 현대적인 표준입니다.  

11 머티리얼(Material)

2.3 Shader (GLSL)

27 Shaders

28 Shader patterns

29 Animated Water Shader

30 Animated galaxy

31 MeshStandardMaterial 셰이더 확장(Modified materials)

---

2.4 Mesh: 종합

Mesh는 장면에 추가되는 최종 객체입니다. 이는 Geometry 인스턴스와 Material 인스턴스를 결합하여 생성됩니다.  

코드 예시: const mesh = new THREE.Mesh(geometry, material); scene.add(mesh);.  

04 객체 변환(위치, 크기, 회전, lookAt)과 그룹(Group) 사용법

17 Particle(Points)

18 Galaxy Generator

---

표 2.1: 핵심 Three.js 재질 비교

초보자들은 사용 가능한 재질의 수에 압도당하는 경우가 많습니다. 가장 중요한 구별점이자 흔한 버그의 원인은 조명의 필요성입니다. 조명이 없는 장면에   

MeshStandardMaterial을 사용하면 객체가 검게 렌더링되어 개발자를 혼란스럽게 만듭니다. 아래의 비교표는 이러한 주요 차이점과 사용 사례, 성능 영향을 즉시 명확히 합니다. 이 표는 개발자가 예술적 및 성능 목표에 맞는 올바른 재질을 선택하고 "왜 내 객체가 검은색이지?"라는 문제를 사전에 해결하는 데 도움이 되는 강력한 진단 및 의사 결정 도구 역할을 합니다.

재질	조명 필요 여부	주요 속성	일반적인 사용 사례	성능 비용
MeshBasicMaterial	아니요	color, map, wireframe	디버깅, UI 요소, 비조명 스타일 그래픽	가장 낮음
MeshLambertMaterial	예	color, emissive	무광택, 확산 표면 (예: 무광 플라스틱, 돌)	낮음
MeshPhongMaterial	예	color, shininess, specular	반짝이는 하이라이트가 있는 광택 표면 (예: 광택 플라스틱)	중간
MeshStandardMaterial	예	color, roughness, metalness	사실적인 재질을 위한 물리 기반 렌더링(PBR)	높음
MeshToonMaterial	예	color, gradientMap	셀 셰이딩, 만화 같은 미학	중간

09 Three.js 디버그 UI - lil-gui 사용법

---

2부: 장면에 생명 불어넣기

이 파트는 정적인 장면에서 동적이고 움직이는 경험으로 전환합니다. 움직임을 만드는 메커니즘과 조명 및 그림자를 통해 사실감을 달성하는 데 사용되는 기술을 탐구할 것입니다.

---

3장: 움직임의 심장 박동: 애니메이션 루프

---

3.1 프레임별 렌더링의 개념

3D 애니메이션은 각 프레임에서 객체 속성(위치, 회전)에 작은 변화를 주면서 장면을 반복적으로 렌더링하여 만들어지는 환상입니다. 이 렌더링 시퀀스가 바로 애니메이션 루프입니다.

---

3.2 window.requestAnimationFrame: 루프의 엔진

브라우저의 requestAnimationFrame (rAF) 메서드를 애니메이션 루프를 만드는 현대적이고 효율적인 방법으로 기술적으로 분석할 것입니다.  

• setInterval 대비 장점:
  • 동기화: rAF 콜백은 브라우저의 리페인트 주기에 동기화되어 더 부드러운 애니메이션을 만들고 시각적 티어링(tearing)을 방지합니다.  
  • 효율성: 브라우저는 백그라운드 탭에서 애니메이션을 일시 중지하여 성능을 최적화하고 CPU 사이클과 배터리 수명을 절약할 수 있습니다.  
• 구현: 루프는 animate와 같은 함수가 자신에 대해 requestAnimationFrame을 호출하여 영구적이고 논블로킹(non-blocking) 사이클을 생성함으로써 만들어집니다.  

05 Three.js 애니메이션 기초

---

3.3 프레임 속도 독립성: 중요한 모범 사례

cube.rotation.x += 0.01과 같이 고정된 값으로 업데이트를 적용하는 것은 흔한 실수입니다. 이는 애니메이션 속도를 사용자의 모니터 주사율에 의존하게 만듭니다.  

THREE.Clock 또는 requestAnimationFrame이 제공하는 타임스탬프를 사용하여 delta 시간(마지막 프레임 이후 경과 시간)을 계산하는 방법을 소개할 것입니다. 모든 애니메이션은 이 델타와 곱해져야 모든 장치에서 일관된 속도를 보장할 수 있습니다.  

---

브라우저와의 계약으로서의 requestAnimationFrame

requestAnimationFrame을 사용하는 것은 성능 선택 이상의 의미를 가집니다. 이는 개발자로부터 브라우저로 제어권을 근본적으로 전환하는 것입니다. setInterval은 "이 코드를 16ms마다 실행하라"는 명령적인 방식입니다. 개발자가 타이밍을 지시합니다. 반면 requestAnimationFrame은 "다음 리페인트 전에 이 코드를 실행해달라"는 선언적인 방식입니다. 개발자는 작업을 요청하지만, 브라우저가 정확한 타이밍을 결정합니다.

이러한 제어권 이양이 rAF를 더 효율적으로 만드는 이유입니다. 브라우저는 렌더링하기에 최적의 시간을 알고 있으며, 여러 rAF 콜백을 함께 그룹화하고, 탭이 보이지 않을 때 일시 중지할 수 있습니다. 이는 현대 웹 애니메이션이 브라우저의 렌더링 엔진에 명령하는 것이 아니라 협력하는 것에 관한 것임을 시사합니다. 이 "계약"을 이해하는 것은 효율적이고 잘 동작하는 웹 애플리케이션을 작성하는 데 핵심입니다.

---

스크롤 애니메이션

19 스크롤 기반 애니메이션

GSAP 가이드

---

4장: 조명의 예술: 빛과 그림자

---

4.1 Three.js의 조명 이론

목적과 행동에 따라 조명 유형을 구별할 것입니다.

• AmbientLight: 전역적이고 기본적인 조명을 제공하여 다른 조명에 닿지 않는 장면의 부분이 완전히 검게 보이지 않도록 합니다. 방향이 없으며 그림자를 드리울 수 없습니다.  
• DirectionalLight: 태양과 같은 먼 광원을 시뮬레이션하며, 모든 광선이 평행합니다. 사실적인 하이라이트와 그림자를 만드는 데 매우 중요합니다. 이 조명의 방향은 회전이 아니라 위치와   target 속성에 의해 결정됩니다.  

14 조명(Light)

---

4.2 그림자 매핑 파이프라인: 단계별 가이드

그림자 구현은 초보자에게 악명 높을 정도로 어려운 다단계 과정입니다. 이 섹션에서는 명확하고 확실한 체크리스트를 제공합니다.

• 1단계: WebGLRenderer에서 그림자 활성화: renderer.shadowMap.enabled = true;.  
   
• 2단계: 조명이 그림자를 드리우도록 구성: DirectionalLight의 경우 light.castShadow = true;로 설정합니다.  
• 3단계: 조명의 그림자 카메라 구성: light.shadow 속성에는 조명의 관점에서 장면을 렌더링하는 데 사용되는 카메라가 포함되어 있습니다. 최적의 그림자 품질을 위해 그림자를 드리우는 객체를 단단히 포함하도록 절두체(light.shadow.camera.near, far, left, right 등)를 구성해야 합니다.  
• 4단계: 객체가 그림자를 드리우도록 구성: 그림자를 드리워야 하는 각 메시에 대해 mesh.castShadow = true;로 설정합니다.  
• 5단계: 객체가 그림자를 받도록 구성: 지면과 같이 그림자가 드리워져야 하는 각 메시에 대해 mesh.receiveShadow = true;로 설정합니다.  

15 그림자(Shadow)

---

그림자는 두 번째 렌더 패스

그림자는 "공짜"가 아닙니다. 장면을 여러 번 렌더링해야 하기 때문에 계산 비용이 많이 듭니다. light.shadow 속성에 자체 camera가 있다는 사실은 별도의 렌더링 프로세스를 암시합니다. 그림자에 무엇이 있는지 알기 위해 엔진은 먼저 조명의 관점에서 세상을 봐야 합니다. 조명의 관점에서 장면의 깊이를 "그림자 맵"이라는 텍스처에 렌더링합니다.  

그런 다음, 주 카메라의 관점에서 메인 렌더 패스 동안 그려지는 각 픽셀에 대해 엔진은 조명에 대한 상대적 위치를 그림자 맵에 저장된 깊이와 비교합니다. 만약 더 멀리 있다면, 그것은 그림자 안에 있는 것입니다. light.shadow.camera와 light.shadow.mapSize의 존재는 이 두 번째 렌더 패스의 직접적인 증거입니다. 이것이 그림자가 상당한 성능 비용을 갖는 이유를 설명합니다. 즉, 최종 렌더링 외에 그림자를 드리우는 각 조명당 한 번씩 장면(또는 적어도 깊이 정보)을 렌더링하는 것입니다. 이 사실은 성능 최적화에 매우 중요합니다.  

16 Haunted House 프로젝트

---

3부: 상호작용과 고급 기법

이 파트는 사용자 입력, 외부 자산, 그리고 영화 같은 후처리 효과를 통합하여 장면을 상호작용적이고 시각적으로 매력적으로 만드는 데 중점을 둡니다.

---

5장: 차원 연결: 레이캐스팅을 이용한 사용자 상호작용

---

5.1 레이캐스팅 이론

레이캐스팅은 주어진 방향으로 한 지점에서 가상의 광선을 쏘아 무엇과 교차하는지 확인하는 과정입니다. Three.js에서는 2D 마우스 커서가 어떤 3D 객체 위에 있는지 결정하는 "마우스 피킹"의 주요 방법입니다.  

---

5.2 Raycaster 구현

마우스 상호작용에 대한 단계별 가이드:

1. Raycaster 및 Vector2 객체 생성: const raycaster = new THREE.Raycaster(); const mouse = new THREE.Vector2();.  
2. 마우스 이벤트 수신: 창이나 캔버스에 'click' 또는 'mousemove' 이벤트 리스너를 추가합니다.  
3. 마우스 좌표 정규화: 이벤트 핸들러 내부에서 픽셀 기반 마우스 좌표(event.clientX, event.clientY)를 -1에서 +1 범위의 정규화된 장치 좌표(NDC)로 변환합니다. 이는 매우 중요한 단계입니다: mouse.x = (event.clientX / renderer.domElement.clientWidth) * 2 - 1;.  
4. 카메라에서 광선 설정: raycaster.setFromCamera(mouse, camera);를 사용하여 현재 카메라와 마우스 위치를 기반으로 레이캐스터의 원점과 방향을 업데이트합니다.  
5. 교차점 계산: const intersects = raycaster.intersectObjects(scene.children);를 호출하여 교차된 객체의 배열을 거리순으로 정렬하여 가져옵니다.  
6. 결과 처리: intersects.length > 0인지 확인한 다음 intersects(가장 가까운 객체)의 정보를 사용하여 작업을 트리거합니다.  

22 Raycaster와 MouseEvent

---

보이지 않는 변환 파이프라인

단순한 raycaster.setFromCamera() 메서드는 모든 3D 그래픽의 기본이 되는 복잡한 행렬 변환 시리즈를 숨깁니다. 입력은 2D 벡터(NDC)와 Camera이고, 출력은 3D Ray입니다. 엔진은 2D 포인트를 3D 세계로 다시 "역투영"해야 합니다. 이는 렌더링 파이프라인을 역으로 진행하는 것을 포함합니다.

일반적인 렌더링 파이프라인은 다음과 같습니다: 객체의 로컬 공간 -> 월드 공간 (모델 행렬 사용) -> 뷰 공간 (카메라의 뷰 행렬 사용) -> 클립 공간 (카메라의 투영 행렬 사용) -> NDC -> 화면 공간 (픽셀).

레이캐스팅은 이 과정을 반대로 수행합니다. NDC 좌표를 가져와 투영 행렬의 역행렬과 뷰 행렬의 역행렬을 적용합니다. 이는 "화면" 위의 2D 포인트를 3D 월드 공간의 점으로 다시 변환합니다. 그런 다음 광선은 카메라의 위치에서 이 역투영된 지점까지 구성됩니다. 레이캐스팅을 이해하는 것은 단순히 API를 사용하는 것이 아니라, 실시간 3D 그래픽을 뒷받침하는 전체 좌표 공간 변환 파이프라인을 암묵적으로 이해하는 것입니다. 이 지식은 복잡한 시각적 문제를 디버깅하는 데 필수적이며 이전 가능합니다.

48 3D 위치에 HTML 요소 고정하기 (HTML과 WebGL 혼합)

---

물리엔진

20 물리엔진(Physics)

65 React Three Rapier

React Three Rapier

---

6장: 외부 세계 통합: GLTFLoader

---

6.1 glTF: 3D의 JPEG

glTF (.gltf, .glb) 형식을 웹에서 3D 자산을 전송하기 위한 현대적이고 효율적인 표준으로 설명합니다. 이는 작고 빠르게 파싱되도록 설계되었습니다.  

---

6.2 GLTFLoader 사용

• 인스턴스화: 예제 모듈에서 GLTFLoader를 가져와 인스턴스를 생성합니다: const loader = new GLTFLoader();.  
• 모델 로딩: .load() 메서드를 사용하여 모델 URL과 로딩 성공 시 실행될 콜백 함수를 제공합니다. 로드된 gltf 객체는 전체 자산 계층 구조를 포함합니다.  
• 모델 콘텐츠 접근: 가장 중요한 속성은 모델의 계층 구조를 포함하는 Object3D인 gltf.scene입니다. 이것을 메인 장면에 추가합니다: scene.add(gltf.scene);.   gltf 객체는 파일에 있는 경우 animations, cameras 등의 배열도 포함합니다.  
• async/await를 사용한 비동기 로딩: 더 깨끗하고 현대적인 코드를 위해, 중첩된 콜백을 피하는 Promise 기반의 .loadAsync() 메서드를 async/await와 함께 사용하는 방법을 시연할 것입니다.  

21 모델 불러오기(Imported models)

24 Environment Map

---

6.3 Texture

10 텍스처(Texture)

---

로드된 모델은 하위 장면

모델을 로드하면 단일 Mesh가 생성된다는 것은 흔한 오해입니다. 실제로는 완전한 장면 그래프를 제공합니다. API가 gltf.scene을 반환하고 이를 메인 scene에 추가한다는 사실은 장면 내 장면 구조를 암시합니다. 코드 예제에서는 모델 내의 모든 메시에 그림자를 활성화하기 위해  gltf.scene을 순회(traverse)해야 하는 것을 보여줍니다.  

이러한 순회의 필요성은 로드된 객체가 단일체가 아니라 복잡한 계층 구조임을 증명합니다. 개발자는 로드된 glTF를 단일 객체가 아닌 자체 포함된 세계로 취급해야 합니다. 이 정신 모델은 재질 변경, 애니메이션 재생 또는 모델의 특정 부분에 다른 객체 부착(예: 캐릭터의 머리 뼈에 모자 부착)과 같은 모델의 구성 요소를 조작하는 데 매우 중요합니다.

25 Realistic render

---

Blender로 3D 모델링

23 Blender 햄버거 모델링 (Blender 사용법 정리)

---

7장: 영화 같은 비주얼: EffectComposer를 사용한 후처리

---

7.1 후처리 개념

후처리는 장면이 렌더링된 후, 화면에 표시되기 전에 전체 장면에 이미지 기반 효과를 적용하는 것을 포함합니다. 이는 포토샵에서 필터를 적용하는 것과 유사합니다.  

---

7.2 EffectComposer 아키텍처

EffectComposer는 후처리 패스(pass)의 체인을 관리합니다. 주 장면은 화면에 직접 렌더링되는 대신 먼저 오프스크린 버퍼에 렌더링됩니다. 컴포저 체인의 각 패스는 이전 패스의 결과를 입력으로 받아 효과를 적용하고 다른 버퍼에 씁니다. 컴포저는 이러한 "읽기" 및 "쓰기" 버퍼를 내부적으로 교환하는 것을 관리합니다. 체인의 마지막 패스는 그 결과를 화면에 렌더링합니다.  

45 후처리(Post-Processing)

---

7.3 실제 예제: Bloom 효과 구현

RenderPass(초기 장면 렌더링용)와 UnrealBloomPass(블룸 효과 적용용)를 사용하여 EffectComposer를 설정하는 과정을 안내할 것입니다.

블룸은 균일한 빛이 아닙니다. 제어할 수 있습니다. UnrealBloomPass는 luminanceThreshold에 따라 작동합니다. 재질의 방출 색상을 1.0보다 큰 값으로 설정함으로써 개발자와 아티스트는 장면의 어느 부분이 빛날지 정밀하게 제어하여 강력한 예술적 효과를 낼 수 있습니다. 

---

4부: 현대 생태계와 성능 공학

이 마지막 파트에서는 React 생태계와 함께 Three.js 개발의 진화를 탐구하고, 성능 최적화라는 중요한 분야에 대해 심도 있게 다룹니다.

64 Laptop Scene

---

8장: 선언적 패러다임: React Three Fiber (R3F) 소개

---

8.1 명령형에서 선언형으로

• 바닐라 Three.js (명령형): 단계별 명령을 내립니다: 메시 생성, 위치 설정, 장면에 추가.
• R3F (선언형): 원하는 최종 상태를 JSX로 설명합니다: <mesh position={[x, y, z]} />. React와 R3F가 내부적인 명령형 호출을 처리합니다.  

53, 54 React와 React Three Fiber

58 R3F Environment and Staging

---

8.2 R3F 작동 방식

R3F는 커스텀 React 렌더러입니다. React-DOM이 컴포넌트를 DOM에 렌더링하는 것처럼, R3F는 컴포넌트를 Three.js 장면에 렌더링합니다. <mesh>와 같은 JSX 태그는 자동으로 new THREE.Mesh()로 변환됩니다. position={[1, 2, 3]}과 같은 props는 mesh.position.set(1,2,3)으로 변환됩니다. 이를 통해 3D 장면을 React의 컴포넌트 생명주기 및 상태 관리에 직접 통합하여 복잡하고 상호작용적인 장면을 훨씬 쉽게 관리할 수 있습니다.  

55 R3F Application 기초

61 Portal Scene

 

---

8.3 @react-three/drei 생태계

drei는 R3F를 위한 방대한 헬퍼 및 기성 컴포넌트 모음입니다. 카메라 제어( <OrbitControls />), 모델 로딩(useGLTF), 텍스트나 이미지 추가와 같은 일반적인 작업을 위한 추상화를 제공하여 개발 속도를 크게 향상시킵니다.  

56 Drei

60 3D Text

62 Pointer Events (Mouse Events)

---

R3F는 상태 관리의 패러다임 전환

R3F의 진정한 힘은 단순한 문법적 편의가 아니라 UI 상태와 3D 장면 상태의 통합에 있습니다. 바닐라 Three.js에서는 복잡한 장면의 상태(예: 어떤 객체가 선택되었는지, 어떤 색이어야 하는지, 애니메이션 중인지 등)를 관리하려면 별도의 상태 관리 시스템을 구축해야 합니다. 이 시스템은 Three.js 장면 객체와 수동으로 동기화되어야 하며, 이는 복잡하고 오류가 발생하기 쉽습니다.

R3F는 React의 검증된 상태 관리(useState, useReducer 등)를 활용합니다. 3D 장면은 애플리케이션 상태의 반응형 함수가 됩니다. 상태가 변경되면(예: setActive(true)), React는 컴포넌트를 다시 렌더링하고 R3F는 기본 Three.js 객체의 속성(예: 크기)을 효율적으로 업데이트합니다. R3F는 대규모 3D 애플리케이션에서 가장 어려운 문제 중 하나인 상태 관리를 해결합니다. 이는 단순한 편의성을 넘어 견고하고 데이터 기반의 3D 경험을 구축하기 위한 아키텍처적 이점입니다.

---

R3F Animation

정적 렌더링을 통해 원하는 시기에만 frame 갱신하기 (frameloop="demand")

59 Load models(GLTF 모델 로딩과 애니메이션)

---

R3F 디버깅: Leva, r3f-perf

57 R3F Debug

---

R3F 후처리

63 후처리(Post Processing)

 

---

9장: 성능을 위한 공학: 최적화 전략

---

9.1 진단적 사고방식: CPU 바운드 vs. GPU 바운드

최적화하기 전에 병목 현상을 진단해야 합니다. 애플리케이션이 CPU(JavaScript 처리, 객체 관리)에 의해 제한되는지, 아니면 GPU(픽셀 그리기, 셰이더 실행)에 의해 제한되는지라는 주요 진단 질문을 소개할 것입니다.

• 리트머스 테스트: 간단하고 효과적인 테스트는 모든 장면 재질을 MeshBasicMaterial로 교체하는 것입니다. 프레임 속도(FPS)가 크게 증가하면 애플리케이션은 GPU 바운드(복잡한 재질/셰이더에 의해 제한됨)입니다. 그렇지 않다면 CPU 바운드(객체 수, 물리 또는 복잡한 스크립트 로직에 의해 제한됨)입니다.  
   
• 모니터링 도구: 데이터 수집을 위한 필수 도구를 다룰 것입니다: FPS 모니터링을 위한 stats.js와 드로우 콜 검사를 위한 브라우저 개발자 도구(Spector.js).  

---

9.2 최적화 기법 개요

이 섹션은 성능 비용의 원인별로 분류된 상세한 참조 자료 역할을 할 것입니다.

• 드로우 콜 줄이기 (CPU):
  • 지오메트리 인스턴싱: InstancedMesh를 사용하여 수천 개의 동일한 지오메트리를 다른 변환으로 단일 드로우 콜로 렌더링합니다.  
  • 지오메트리 병합: 여러 정적 메시를 단일 BufferGeometry로 결합하여 드로우 콜을 줄입니다.
• 지오메트리 최적화 (CPU/GPU 메모리):
  • 필요한 시각적 품질에 대해 가능한 가장 낮은 폴리곤 모델을 사용합니다. 원거리 객체에 대해 더 간단한 모델로 전환하기 위해 레벨 오브 디테일(LOD)을 사용합니다.  
  • 항상 BufferGeometry를 사용합니다.  
• 렌더링 최적화 (GPU):
  • 조명 및 그림자: 조명은 비용이 많이 들고 그림자는 훨씬 더 비쌉니다. 정적 장면에 대해서는 조명을 베이킹합니다. 그림자 맵 해상도를 가능한 한 낮게 유지하고 카메라 절두체를 가능한 한 타이트하게 유지합니다.  
  • 재질: 투명 객체는 불투명 객체보다 렌더링 속도가 느립니다. 가능한 한 피합니다.  
  • 픽셀 비율: 고해상도 모바일 장치에서는 렌더러의 최대 픽셀 비율을 2 또는 3으로 제한하여 시각적 충실도를 최소한으로 희생하면서 상당한 성능 향상을 얻습니다.  
• 일반적인 모범 사례:
  • 객체 및 메모리 관리: 애니메이션 루프에서 Vector3와 같은 객체를 새로 생성하는 대신 재사용합니다. 더 이상 필요하지 않은 지오메트리, 재질, 텍스처는 메모리 누수를 방지하기 위해 적절히 dispose()합니다.  

46 퍼포먼스 최적화

 

---

성능은 예산

고성능은 무작위 트릭 목록을 적용하는 것이 아니라 "성능 예산"을 관리하는 것입니다. 부드러운 경험을 위해서는 각 프레임을 특정 시간 제한(예: 60 FPS의 경우 16.67ms) 내에 렌더링해야 합니다. 이것이 예산입니다. 장면의 모든 요소—모든 메시, 모든 조명, 모든 텍스처—는 CPU 및 GPU 시간 측면에서 이 예산의 일부를 "비용"으로 사용합니다.  

진단 도구는 이 예산을 감사하는 데 사용됩니다—밀리초가 어디에 사용되는지 확인하는 것입니다. 최적화 기법은 특정 항목의 비용을 줄이거나 예산을 재할당하는 도구입니다. 예를 들어, 저해상도 그림자를 사용하기로 결정하면 더 많은 파티클 효과를 추가하기 위한 예산을 "확보"할 수 있습니다. 궁극적으로 성능 공학은 경제적 활동입니다. 개발자는 회계사처럼 생각하며, 각 프레임의 엄격한 시간 예산에 대해 시각적 품질과 복잡성을 지속적으로 균형을 맞춰야 합니다. 이 "예산" 사고방식은 최적화를 반응적인 작업에서 디자인 및 개발 과정의 핵심 부분으로 변화시킵니다.

---

배포

13 Go Live