LazySonic Blog

[Graphics] 복셀 마칭큐브와 Mesh Terrain - 4

LazySonic — Fri, 29 May 2026 01:37:43 +0900

Ch4. 케이스 스터디 — UE 5.8 MeshTerrainMode / MeshPartition에서 마칭큐브가 호출되는 자리

지금까지 본 추상적 절차 — 8비트 인덱스 → 두 장의 테이블 → 보간 → 모호성 처리 — 가 실제 게임 엔진의 한 줄 코드로 응결되는 자리를 보면 알고리즘 이해가 마무리된다. UE 5.8에 새로 들어온 두 플러그인, MeshTerrainMode와 MeshPartition이 그 자리다. 이 챕터는 그 둘이 무엇이고, "두 절벽 붙이기" 인터랙션이 어떻게 복셀화 + 마칭큐브 + 협대역 SDF로 풀리는지를 따라간다. 검증 소스는 원본 블로그 글(https://develop-4-art.tistory.com/169)과 UE 5.8 릴리스 노트, Epic 공식 문서다(로컬 UE 소스가 5.6이므로 클래스 수준의 직접 확인은 외부 문서에 의존한다).

두 플러그인의 역할 분담

UE 5.8의 메시 기반 지형 시스템은 두 개의 분리된 플러그인이 짝을 이루는 구조다.

• `MeshTerrainMode` — 에디터 모드 플러그인. 지형 생성·편집·스컬프팅 같은 작업의 UI/도구 레이어를 담당한다. 6개의 서브모드(Create / Edit / Sculpt 등 — 디테일은 [지난 글](https://develop-4-art.tistory.com/169) 참조)가 이 안에 들어있고, 각 서브모드가 내부적으로 MeshPartition의 메시 데이터를 갱신한다.

• `MeshPartition` — 런타임 + 에디터 양쪽에서 살아 있는 데이터 레이어. 월드를 청크로 자르고, 각 청크의 메시(=FDynamicMesh3 삼각형 집합)와 (필요할 때) 협대역 SDF를 들고 있다. 런타임에는 그냥 정적 메시처럼 동작하고, 에디터에서만 편집 가능한 상태가 된다.

기존의 Landscape 시스템이 하이트맵 텍스처를 GPU에서 매 프레임 셰이더로 변위시키는 구조였다면, 새 메시 테레인은 데이터가 처음부터 진짜 삼각형이다. 하이트맵은 일회성 임포트 포맷으로만 쓰이고, 임포트가 끝나면 결과는 FDynamicMesh3 메시로 변환돼 MeshPartition에 박힌다. 그 이후 모든 편집 — 끌어올리기, 깎기, 절벽 두 개 합치기 — 은 모두 메시 위에서 직접 일어난다.

"두 절벽 붙이기" — MC가 호출되는 정확한 자리

이 글의 본 주제와 직결되는 자리가 바로 여기다. 사용자가 에디터에서 절벽 두 개를 가까이 가져가서 "합쳐라"라고 명령하는 순간, 다음 단계가 차례로 일어난다.

[IMAGE 15 — UE5.8 메시 테레인 "두 절벽 합치기" 파이프라인 (SVG): 박스 다이어그램 — Input(두 FDynamicMesh3) → ① Voxelization (좁은 영역만) → ② Narrow-band SDF → ③ **Marching Cubes** → ④ 결과 FDynamicMesh3 → MeshPartition 갱신. 화살표 + 단계 라벨.]

1. 선택 영역 추출. 두 절벽 메시 중 합쳐질 부근(예: 한 청크 또는 사용자가 지정한 박스)만 잘라낸다.

2. 복셀화(voxelization). 그 좁은 영역만 N³ 격자(보통 해상도가 청크 단위 한정으로 작게 잡힘)로 샘플링한다. 두 메시의 표면에서 부호 있는 거리를 평가해서 각 격자 점에 SDF 값을 채운다.

3. 협대역 SDF(narrow-band SDF) 구축. 표면 근처의 좁은 띠 안쪽만 정확한 SDF 값을 들고 있고, 그 바깥은 "충분히 멀다"로 잘라낸다. 메모리·계산 양쪽에서 보수적이고, 우리 목적엔 표면 근처 값만 있으면 충분하다.

4. 마칭큐브. 그 SDF 격자를 입력으로 iso = 0 등치면을 추출한다. Ch3에서 본 그 절차 — 큐브 인덱스 → 엣지 테이블 → 보간 → 삼각형 테이블 → 정점 등록 — 이 격자 한 칸씩 행진하며 도장 찍힌다. 출력은 새 FDynamicMesh3 삼각형들이다.

5. `MeshPartition` 갱신. 결과 메시가 두 원본 메시의 자리를 교체하고, BVH/충돌 메시가 재구축된다.

핵심은 MC 호출이 통째로 에디터 안에서 일어난다는 점이다. 한 번 베이크된 결과는 그 이후 런타임에서는 그냥 정적 메시로 보인다. 사용자가 다시 편집 모드에 들어가서 같은 영역을 또 만지지 않는 한 마칭큐브가 다시 돌 일은 없다.

왜 에디터 전용인가

런타임 동적 편집이 안 되는 이유는 마칭큐브 자체의 비용보다도 후속 비용에 있다.

• 새 메시를 만든 다음 충돌 메시(BVH/PhysX/Chaos 등)를 재구축해야 한다. 청크 단위라도 ms 단위로 떨어진다.

• LOD 메시(원본 외에 단순화된 메시 여러 단계)를 재계산해야 한다.

• GPU 리소스(정점 버퍼, 인덱스 버퍼)를 업로드해야 한다 — 메인 스레드를 잡으면 프레임 드랍.

• 정적 라이팅이 미리 베이크돼 있던 경우 그 라이팅이 무효화된다.

이 누적 비용 때문에 UE 5.8은 첫 출시 단계에서 MC 베이크를 에디터 전용으로 못 박았다. 알고리즘 자체는 청크 단위 GPU 컴퓨트로 런타임에서도 충분히 돌릴 수 있다 — 사실 Voxel Tools, Voxel Farm 같은 서드파티는 이미 그렇게 한다. UE 5.8의 결정은 "런타임이 안 된다"가 아니라 "런타임 동적 편집의 후속 비용을 첫 출시에서 책임지지 않는다"에 가깝다.

협대역 SDF가 등장한 이유 — Ch3의 모호성 케이스와 연결

Ch3에서 모호성 케이스(6/10/12/13)를 다룰 때 "위상이 약간 거짓말을 해도 시각적으로 큰 문제가 안 되는 자리에서는 그냥 15케이스 표를 쓰고 모호성을 무시한다"고 했는데, 사실 모호성을 거의 발생시키지 않는 입력을 미리 만드는 길도 있다. 그 길이 바로 협대역 SDF로 입력을 정규화하는 것이다.

협대역 SDF는 표면 근처에서 부드럽고 단조롭게 변하는 부호 있는 거리 함수다. 이런 입력에서는 한 큐브 안에서 안/밖 비트가 대각선으로 갈리는 패턴 — 즉 6/10/12/13 같은 모호성 케이스 — 자체가 거의 발생하지 않는다. SDF의 단조성이 큐브 안의 위상을 미리 정리해주는 셈이다.

[IMAGE 16 — 두 절벽 메시가 마칭큐브로 매끄럽게 융합되는 컷 (nanobanana 일러스트): 두 거친 절벽 사이의 좁은 협곡이 부드러운 곡면으로 이어지는 비유 컷. 정확 데이터 아님.]

즉 UE 5.8의 파이프라인은 마칭큐브를 모호성이 거의 없는 입력에서만 호출하도록 설계되어 있다. 입력을 협대역 SDF로 정규화하는 한 단계를 앞에 두는 것으로, MC 자체는 단순한 15케이스 표만으로도 충분히 안전하게 동작한다. 알고리즘과 입력의 책임을 깔끔하게 분리한 디자인이다.

좁은 영역만 베이크하는 이유

엔진 입장에서는 두 절벽 청크 전체를 다시 베이크할 수도 있지만, 그러면 사용자가 만진 적도 없는 자리까지 메시가 재구성되고 정점 ID가 바뀌어버린다. 머티리얼 페인팅, 식생 인스턴스 같은 attachment가 끊긴다. 그래서 메시 테레인은 편집이 영향을 미치는 좁은 박스만 잘라서 베이크하고, 결과 메시를 원본 메시의 해당 영역에만 patch-in 한다. 협대역 SDF가 "협대역"인 이유도 같다 — 표면 근처 좁은 띠만 정확히 들고 있으면 충분하기 때문에 메모리도, 베이크 시간도 박스 부피에 비례한다.

이 좁은 박스 베이크는 사실 GPU 컴퓨트로 옮기기 매우 좋은 워크로드다. 박스가 작으니 한 컴퓨트 디스패치로 충분히 들어가고, 격자 한 칸당 한 스레드 → atomic이 거의 필요 없는 두 패스 구조 → 결과는 작은 정점 버퍼 한 묶음. UE 5.8 첫 출시에서는 CPU 베이크로 깔린 듯하지만, 후속 릴리스에서 GPU 베이크로 내려갈 가능성이 가장 높은 자리다 — 알고리즘 자체가 그렇게 설계되어 있고, MC 가족 30년 노하우가 이미 GPU 구현을 충분히 다듬어 두었다.

실전 — 한 번 직접 만져보면 보이는 것

알고리즘 글이 가장 빨리 흡수되는 자리는 결국 자기 손으로 한 번 만져본 다음이다. UE 5.8을 설치할 수 있다면 다음 짧은 시나리오로 마칭큐브가 호출되는 순간을 직접 확인할 수 있다.

1. 새 레벨에 Mesh Terrain 추가. 에디터 모드 패널에서 MeshTerrainMode를 켠 다음 Create 서브모드로 작은 패치 두 개를 만든다. 절벽처럼 가파른 경사가 좋다.

2. 두 패치를 가까이. 두 절벽이 서로 마주 보도록 위치를 조정한다. 이 시점까지는 마칭큐브가 호출되지 않는다 — 그냥 두 개의 독립 FDynamicMesh3다.

3. Edit 또는 Sculpt 서브모드로 합치기. 두 절벽 사이에 브러시로 채우거나 "merge" 작업을 트리거한다. 이 순간 에디터가 "Baking…" 표시를 잠깐 띄울 텐데, 그 짧은 시간 안에 복셀화 + 협대역 SDF + 마칭큐브 + 메시 재구성이 차례로 일어난다.

4. 결과 메시 확인. 와이어프레임 모드로 보면 합쳐진 영역의 삼각형 토폴로지가 원본 절벽 두 개와 완전히 다른 — 마칭큐브 특유의 격자-aligned 삼각형 — 으로 바뀐 게 보인다. 격자 해상도(에디터 설정에서 조절 가능)를 올리면 더 부드러운 곡면이 나오고, 내리면 격자 흔적이 더 도드라진다.

5. 언두/리두. 합치기 결과는 한 번의 베이크 결과이므로 undo로 되돌릴 수 있다. 마칭큐브 호출은 비결정적이지 않으니(같은 입력 → 같은 출력) 같은 자리를 여러 번 만져도 결과가 떨리지 않는다.

이 한 시나리오를 한 번 돌려보고 와이어프레임을 한 번 확인하고 나면, Ch2-3의 모든 추상 절차가 "내가 방금 본 그 격자 위의 그 삼각형들"로 머릿속에 박힌다.

정리 — 이 글이 끝나는 자리

이 글은 마칭큐브의 핵심 — 8비트 인덱스, 두 장의 테이블, 보간, 모호성, 비교, 성능 — 을 한 번에 풀고, 그게 UE 5.8 메시 테레인의 한 자리에 어떻게 박혀 있는지까지 따라왔다. 처음 읽었을 때 한 줄로 지나친 "복셀화 + 마칭큐브 + 협대역 SDF" 표현이, 이제는 왜 그 세 단계의 순서로 묶여 있고, 왜 에디터 전용인지가 보일 것이다.

남은 자리는 두 군데다.

• 런타임 동적 편집. 후속 비용을 엔진이 흡수하기 시작하면 마칭큐브가 런타임으로 내려올 수 있다. UE 5.x의 향후 릴리스를 기다리거나, Voxel Tools / Voxel Farm 류의 서드파티로 우회하면 된다.

• 날카로운 모서리. MC는 항상 부드러운 메시를 뽑으니, 날카로운 모서리가 필요한 자리는 Dual Contouring 또는 그 변종(Manifold DC, Cubical MC)이 더 적합하다. 마찬가지로 서드파티 영역이거나, 직접 구현해야 하는 자리다.

마칭큐브는 1987년 논문 한 편으로 시작해서 30년 넘게 표준 자리를 지킨, 흔치 않은 사례의 알고리즘이다. 단순한 룩업 두 번이 정말로 메시를 토해낸다는 사실 — 그 단순함이 모든 후속 변종이 결국 돌아오는 기준점을 만들었다. 다음에 어디서든 등치면 추출이라는 단어를 만나면, 그 자리는 거의 항상 마칭큐브거나 그 가족이다. 그리고 이제 그 자리를 다시 만났을 때, 한 큐브 안에서 무엇이 일어나는지가 한 번에 떠오를 것이다.

[Graphics] 복셀 마칭큐브와 Mesh Terrain - 3

LazySonic — Fri, 29 May 2026 01:35:50 +0900

[Graphics] 복셀 마칭큐브와 Mesh Terrain - 1

[Graphics] 복셀 마칭큐브와 Mesh Terrain - 2

[Graphics] 복셀 마칭큐브와 Mesh Terrain - 4

Ch3. 딥다이브 — 인덱싱 → 테이블 → 보간 → 모호성 → 비교 → 성능

이 챕터는 한 큐브 안에서 마칭큐브가 실제로 무슨 일을 하는지를 끝까지 푼다. 8개 안/밖 비트가 어떻게 8비트 정수 하나로 압축되고, 그 정수가 어떻게 엣지 테이블·삼각형 테이블이라는 두 장의 미리 계산된 룩업표를 한 번씩 조회해서 삼각형을 토해내는지, 보간이 어떻게 정확한 위치를 잡는지, 그리고 1987년부터 따라다닌 모호성(ambiguity) 케이스가 왜 위상 결정을 흔드는지까지가 한 묶음이다. 마지막에는 Dual Contouring / Surface Nets 같은 사촌 알고리즘들과의 짧은 비교, 그리고 성능·메모리 실전 고려사항으로 마무리한다.

8비트 인덱스 — 한 칸을 한 정수로 압축

Ch2에서 정한 인덱싱 컨벤션을 그대로 들고 온다. V_i가 안이면 i번 비트가 1이라는 규칙으로, 한 큐브의 안/밖 패턴은 0…255 사이의 정수 하나로 압축된다.

cubeIndex = 0

for i in 0..7:

if scalar[V_i] < iso:

cubeIndex |= (1 << i)

여기서 부등호 방향은 컨벤션이다. 이 글에서는 "안 = 값이 등치값보다 작다" 를 일관되게 쓴다(Bourke 코드와 동일, OpenVDB와 동일). 부호 있는 거리 장(SDF)을 쓰면 "안 = 음수"가 되니 같은 의미가 된다. 부호를 통째로 뒤집은 컨벤션을 쓰는 구현체도 있는데(특히 의료 영상의 일부 코드), 그 경우 결과 메시의 노멀이 뒤집힌 채로 나온다. 정점이 같은 자리에 찍히므로 메시 자체는 옳고, 보통 노멀만 부호 뒤집어 처리하면 끝이다.

256개 케이스가 나오지만, 회전(큐브의 회전 대칭군은 24개)과 반사 대칭으로 묶으면 15개 고유 케이스로 줄어든다. 1987년 Lorensen & Cline의 SIGGRAPH 원논문이 처음 분류한 것도 정확히 이 15개다.

[IMAGE 08 — 15 unique cases (Python): 4×4 grid (15 + blank), 각 cell은 isometric 큐브 + 안쪽 정점 검정 동그라미 + 등치 삼각형 빨강. Case 0(전부 밖) ~ Case 14 라벨. Paul Bourke의 polygonising 테이블을 독립 렌더링 (Lorensen Fig 4 트레이스 아님).]

이 15 케이스를 회전·반사로 펼치면 다시 256개 케이스가 모두 나오는데, 실제 구현은 그 256개를 미리 펼쳐서 두 장의 표에 박아 놓는다. 런타임에 회전 행렬을 곱할 필요가 없으니 룩업 한 번이 진짜로 룩업 한 번이다. 그 두 장의 표가 다음 절에서 만날 엣지 테이블과 삼각형 테이블이다.

두 장의 룩업 표 — 엣지 테이블 & 삼각형 테이블

엣지 테이블 — "어느 엣지가 교차되었나"

엣지 테이블은 길이 256의 배열이고, 각 원소는 12비트 마스크다. cubeIndex로 한 번 인덱싱하면 그 큐브에서 등치면이 가로지르는 12개 엣지 중 어느 것이 활성인지가 한 비트씩 켜져 있다.

// 발췌: paulbourke.net/geometry/polygonise

int edgeTable[256] = {

0x0, 0x109, 0x203, 0x30a, 0x406, 0x50f, 0x605, 0x70c,

0x80c, 0x905, 0xa0f, 0xb06, 0xc0a, 0xd03, 0xe09, 0xf00,

// ... (총 256개)

};

int edgeMask = edgeTable[cubeIndex];

if (edgeMask == 0) return; // 전부 안이거나 전부 밖, 삼각형 없음

edgeMask & (1 << e) [0001 0000 1001]가 켜져 있으면 E_e 엣지에 등치면이 교차한다는 뜻이다. 그 자리에 보간 교점을 찍어둔다(자세한 보간 공식은 다음 절).

edgeMask & (1 << e) [0001 0000 1001] 의 시각적의미 :
V0(물 속)에서 출발해서 물 밖의 꼭짓점으로 향하는 엣지는 딱 3개뿐입니다. V1으로 가는 E0, V3로 가는 E3, V4로 올라가는 E8입니다.

삼각형 테이블 — "어느 엣지들을 잇는가"

삼각형 테이블도 길이 256이지만, 각 원소는 길이 16의 정수 배열이다. 3개씩 묶이는 엣지 인덱스 트리플의 나열이고, 끝은 −1로 종료된다. 한 큐브에서 최대 5개의 삼각형이 나올 수 있으므로 15개의 엣지 인덱스 + 종료 −1로 16칸이다.

( 엣지 테이블을 통해 교차하는 엣지들을 찾아 그 위에 점(교점)을 찍었다면, 삼각형 테이블은 "그 점들을 어떤 순서로 이어서 삼각형(폴리곤)을 만들 것인가?"를 알려줍니다. )

// 예: cubeIndex == 0xe (V1,V2,V3가 안)

// triTable[0xe] = { 9, 8, 3, 9, 3, 2, 9, 2, 11, -1, ... }

// → 삼각형 3개: (E9, E8, E3), (E9, E3, E2), (E9, E2, E11)

for (int i = 0; triTable[cubeIndex][i] != -1; i += 3) {

addTriangle(vertOnEdge[triTable[cubeIndex][i + 0]],

vertOnEdge[triTable[cubeIndex][i + 1]],

vertOnEdge[triTable[cubeIndex][i + 2]]);

}

여기서 vertOnEdge[e]는 엣지 테이블 단계에서 미리 계산해 둔, E_e 위의 보간 교점이다. 이 두 단계를 합치면 한 큐브에서 0~5개의 삼각형이 나온다.

[시각적 예시: 이어서 삼각형 만들기]

상황: 위의 예시와 동일하게 cubeIndex가 1인 상황입니다. 교차점이 생긴 엣지는 E0, E3, E8입니다.
테이블 조회: triTable[1]을 조회하면 결과 배열은 [0, 8, 3, -1]로 나옵니다. (-1은 배열의 끝을 의미합니다.)
시각적 의미: * 첫 번째 교점: E0 엣지 위의 점
- 두 번째 교점: E8 엣지 위의 점
- 세 번째 교점: E3 엣지 위의 점
- 이 세 점을 선으로 쫙 이어붙이면 V0 꼭짓점 하나만 싹둑 잘라내는 형태의 작은 삼각형 1개가 허공에 그려집니다. 이것이 렌더링될 메시의 한 조각입니다.

[IMAGE 09 — 테이블 룩업 흐름 (SVG): cubeIndex(8-bit) → edgeTable → 활성 엣지 마스크(12-bit) → vertOnEdge 보간 → triTable → 삼각형 트리플. 화살표 + 작은 큐브 픽토그램.]

룩업 한 번이 끝나면 그 큐브의 메시 기여분은 결정이다. 격자 전체에 같은 절차를 마칭하면 전역 메시가 완성된다. 데이터 의존성이 한 큐브 안으로 닫혀 있다는 점이 GPU 병렬화의 자유도를 그대로 보장한다.

엣지 보간 — 정확한 교점 찍기

엣지 테이블이 "어느 엣지가 활성"인지만 알려준다면, 그 엣지 위 어디에 정점을 찍을지는 보간이 결정한다. 등치값보다 작은 끝과 큰 끝 사이를 선형 보간한다.

v0 iso v1

●----------|-------------●

p0 p p1

t = (iso - v0) / (v1 - v0) // ∈ [0, 1]

p = p0 + t * (p1 - p0)

여기서 v0, v1은 엣지 양끝의 스칼라 값, p0, p1은 양끝의 좌표, iso는 등치값, t는 보간 파라미터다. iso == v0이면 t == 0이라 정점은 정확히 p0에 떨어지고, iso == v1이면 t == 1이라 p1에 떨어진다. 수치적으로 v0 == v1인 자리는 0으로 나누기가 되니, t = 0.5로 폴백하거나 작은 엡실론 가드를 두는 게 보통이다(그 자리는 등치값이 끝과 정확히 같다는 의미라 어느 위치를 골라도 거의 동일하다).

[IMAGE 10 — 엣지 보간 (SVG): 한 엣지 수평선, 왼쪽 끝 v0=-0.4, 오른쪽 끝 v1=+0.8, iso=0 표시. 보간 t = 0.4/1.2 = 0.333 → p = p0 + 0.333*(p1-p0) 위치에 빨강 점. 수식 박스 인접 배치.]

선형 보간을 쓰는 것은 한 큐브 내부에서 스칼라 장이 선형으로 변한다고 가정하기 때문이다. 실제 장은 일반적으로 비선형이지만, 한 칸이 충분히 작으면 그 안에서의 선형 근사가 만들어내는 오차는 무시할 만한 수준이고, 등치면 자체의 위상은 정확히 보존된다. 더 정확한 위치가 필요하면 격자 해상도를 올리는 것이 보간 차수를 올리는 것보다 거의 항상 더 효과적이다 — 이 점은 마칭큐브 가족의 거의 모든 후속 논문이 공유하는 결론이다.

모호성 케이스 — 면 모호성, 내부 모호성, dual surface

Lorensen & Cline의 원논문은 15 케이스로 깔끔하게 끝나지만, 그 분류 안에는 위상적으로 잘못된 메시를 만들 수 있는 케이스가 숨어 있다. Dürst가 1988년에 처음 지적했고, 그 이후 30년 동안 수많은 변종 논문이 이 자리를 두드렸다. 핵심 케이스는 네 자리 — 6, 10, 12, 13 — 이다.

Case 6 — 면(face) 모호성

한 큐브의 어떤 한 면(face)에서, 그 면의 4 꼭짓점이 대각선으로 안-밖이 갈리는 패턴이 나타나면 면 모호성이 발생한다. 그 면을 가로지르는 등치선을 두 가지 합법적인 방식으로 그릴 수 있고, 이웃 큐브의 같은 면에서 어느 쪽을 골랐는지와 어긋나면 두 큐브 사이의 메시에 구멍이 뚫린다.

[IMAGE 11a — 면 모호성 (Case 6) (SVG): 같은 8버텍스 패턴(예: V1+V2 안)에서 두 가지 합법 삼각화 A·B를 좌·우 나란히. 면 가운데 점선으로 "두 합법 곡선" 강조.]

Case 6은 마칭 스퀘어의 Case D(saddle)가 3D로 올라온 직접 후예다. 해결법은 그 면의 중앙에 보간된 스칼라 값을 따로 평가해서 위상을 결정하는 asymptotic decider[등가면 테스트](Nielson & Hamann, 1991)다. 같은 결정 함수를 양쪽 큐브가 똑같이 적용하므로 자동으로 일관된 선택이 나온다.

Case 13 — 내부(internal) 모호성과 dual surface

Case 13은 더 까다롭다. 큐브의 8 꼭짓점이 대각선 쌍으로 안-밖이 갈리는 패턴인데, 이 경우 큐브 내부에서 등치면을 두 가지 위상으로 그릴 수 있다. 한쪽은 두 갈래 표면이 큐브를 관통하며 갈라지는 모양이고, 다른 쪽은 두 표면이 큐브 내부에서 좁은 터널로 이어지는 모양이다. 같은 안/밖 비트가 연결된 메시 vs 분리된 메시라는 완전히 다른 위상을 만든다.

[IMAGE 11b — 내부 모호성 (Case 13) (SVG): 동일 8버텍스 패턴(대각 쌍)에서 좌측은 두 표면 분리, 우측은 좁은 터널로 연결. "dual surface" 라벨.]

이 dual surface 문제를 가장 정직하게 다루는 길은 큐브 내부 중심의 보간된 스칼라 값까지 동원해서 위상을 결정하는 것이고, Asymptotic Decider의 확장 버전 또는 Nielson의 "MC33"이라 불리는 33케이스 확장 분류가 표준 해법이다(원래 15 케이스 안에 모호성 케이스들을 추가 분기로 풀어 33개로 다시 묶는다). Case 10, 12는 6 / 13의 사촌으로, 같은 가족 안에서 처리된다.

Asymptotic Decider 공식 (스니펫)

면 모호성 케이스 한 자리에서 실제로 어떻게 결정하는지만 한 번 보고 가자. 한 면의 4 꼭짓점 값을 a, b, c, d(좌하·우하·우상·좌상 순)라 하면, 그 면을 가로지르는 두 등치선의 점근(asymptote) 교점에서 평가한 스칼라 값은

f_center = (a * c - b * d) / (a + c - b - d)

이고, f_center의 부호가 iso보다 크냐 작냐로 두 가지 합법 연결 중 하나를 고른다. 이웃 큐브의 같은 면도 같은 4 꼭짓점을 공유하므로 같은 값을 얻고, 결과적으로 두 큐브가 자동으로 같은 연결을 선택한다 — 추가 통신 없이 일관성이 보장되는 점이 이 방법의 우아한 점이다.

Case 13 같은 내부 모호성도 같은 아이디어를 큐브 중심으로 확장한 결정 함수로 풀린다. 디테일은 Nielson & Hamann (1991) 원논문과 MC33 분류표(Chernyaev 1995, Lewiner et al. 2003)가 표준 참고문헌이다.

수치 안정성과 퇴화 케이스

v0 == v1(앞서 언급한 0 나누기), v_i == iso(꼭짓점이 정확히 등치값 위에 있음), 그리고 한 큐브에서 여러 정점이 같은 좌표로 떨어져 퇴화 삼각형(degenerate triangle, 넓이 0)이 생기는 경우 — 이 세 가지는 어떤 마칭큐브 구현체든 한 번씩은 부딪힌다. 표준 처리는 다음과 같다.

• v0 == v1 → t = 0.5로 폴백(또는 작은 엡실론 가드).

• v_i == iso → 안/밖 컨벤션에 따라 한쪽으로 일관되게 분류(보통 "안"으로). 모든 큐브가 같은 규칙을 쓰면 인접 큐브 사이의 불일치가 없다.

• 퇴화 삼각형 → 메시 등록 단계에서 넓이 검사로 필터링. 또는 BVH/충돌 메시 구축 시 자동으로 무시되도록 후처리.

이 세 가지는 정확한 결정이 핵심이 아니라 모든 큐브가 같은 규칙을 따른다는 일관성이 핵심이다. 한 큐브에서 안으로 분류한 정점이 옆 큐브에서 밖으로 분류되면 그 자리에 메시 구멍이 뚫린다.

실용적으로는 게임용 절차적 지형처럼 위상이 약간 거짓말을 해도 시각적으로 큰 문제가 안 되는 자리에서는 그냥 15케이스 표를 쓰고 모호성을 무시한다. 의료 영상 / CAD처럼 정확한 위상이 중요하면 MC33 또는 그 후속 분류를 쓴다. UE 5.8 메시 테레인은 게임 쪽이라 단순한 분류면 충분한데, "두 절벽을 합치는" 자리는 사용자가 미리 SDF로 부드럽게 깔아두므로 모호성 자체가 잘 발생하지 않는다.

이웃 알고리즘 — Dual Contouring, Surface Nets

마칭큐브가 30년 넘게 표준 자리를 지킨 만큼, "마칭큐브의 약점을 노린" 사촌 알고리즘들도 여럿이다. 두 가지만 짧게 비교한다.

항목	Marching Cubes	Surface Nets (Gibson 1998)	Dual Contouring (Ju et al. 2002)
정점 위치	엣지 위 보간 교점	큐브 중심 (격자 노드의 듀얼)	큐브 내부, 헤시안 최적화
입력	스칼라 값	스칼라 값	스칼라 값 + 엣지 노멀
모호성 케이스	6/10/12/13 (해결법 별도)	거의 없음 (정점이 큐브당 1개)	거의 없음
날카로운 모서리	표현 불가 (항상 부드러움)	표현 약함	표현 가능 (날카로운 특징 보존)
구현 복잡도	낮음 (테이블 룩업)	중간	높음 (QEF 최적화)
메시 토폴로지	매니폴드 보장 어려움	항상 매니폴드	매니폴드 보장 어려움 (Manifold DC 변종 필요)

[IMAGE 12 — MC vs Surface Nets vs Dual Contouring (Python): 같은 sharp-corner SDF 입력에 대해 세 알고리즘의 출력 메시 와이어프레임 3개 나란히. MC는 모서리 둥글, Surface Nets는 약간 더 부드러움, DC는 모서리 보존.]

UE 5.8 메시 테레인이 MC를 쓰는 이유는 명확하다. "두 절벽을 합치기"는 모서리 보존이 핵심이 아니라 위상 변화가 부드럽게 일어나는 게 중요하다. 사용자가 만지작거리는 동안 메시가 매끄럽게 변형되는 게 보장돼야 하는 에디터 인터랙션이므로, MC의 항상-부드러운 출력이 오히려 장점이다. 날카로운 모서리는 따로 모델링하면 되고, 절벽의 자연스러운 곡면은 MC가 그대로 뽑아준다. 구현 복잡도가 낮아서 에디터 전용 베이크 코드로 깔기에도 부담이 적다.

성능 — 메모리, 병렬화, 청크 베이크

마칭큐브의 성능 특성은 한 문장으로 요약된다: 창피할 만큼 병렬화가 잘 되지만, 메모리 대역폭이 보틀넥이다.

• 연산 비용: 한 큐브당 룩업 2번(엣지 테이블 + 삼각형 테이블) + 보간 최대 12번 + 삼각형 등록 최대 5개. 분기는 거의 없고, 데이터 의존성이 한 큐브 안에 닫혀 있다.

• 메모리 비용: N³ 격자라면 스칼라 장 N³개를 들고 있어야 한다. 8버텍스 샘플링은 인접 큐브 7개와 6면을 공유하므로, 캐시 친화적인 z-order 또는 청크 단위 슬라이스 접근이 거의 필수다. 출력 메시도 케이스에 따라 한 큐브당 0~15개의 정점(중복 제거 전)이 나오므로 메모리 예약은 보수적으로 잡는다.

• GPU 매핑: 한 큐브 = 한 스레드 그룹의 한 스레드. 텍스처 또는 SSBO에 스칼라 장을 깔고, append-buffer로 정점을 모은다. 정점 중복 제거(엣지 인덱스 → 정점 인덱스 해시)는 두 번째 패스로 처리하는 게 보통이다.

• 청크 베이크: UE 5.8 MeshPartition처럼 큰 월드를 청크로 자른 다음 청크 단위로 베이크하면 메모리 부하가 분산되고, 청크 경계에서만 정점 공유를 별도 처리하면 된다. 청크 내부는 완전 독립 처리.

[IMAGE 13 — 성능 컷 (nanobanana 일러스트): 거대한 복셀 그리드 위에 청크 단위로 마칭이 동시에 진행되는 추상 컷. 정량 데이터 아님, 분위기.]

실전 수치는 케이스에 따라 천차만별이지만, 64³ 격자의 메시화는 데스크톱 CPU 1코어에서 수 밀리초 단위, GPU에서는 마이크로초 단위로 떨어진다. 일반적인 게임 엔진에서 에디터 베이크 단계의 비용은 거의 무시할 만하다. 런타임 동적 편집이 부담스러운 이유는 메시 자체보다도 충돌 메시 재구성 + GPU 리소스 업로드 + LOD 재계산같은 후속 비용이 누적되기 때문이다.

정점 중복 제거 — 엣지 인덱스 해시

한 큐브 한 큐브가 독립적으로 처리되면, 두 인접 큐브가 공유하는 같은 엣지 위에 같은 보간 교점이 두 번 등록된다. 좌표가 동일하다는 게 보장돼 있으니 좌표 비교로 중복을 제거할 수도 있지만, 부동소수점 비교는 위험하다. 표준적인 트릭은 엣지 한 개를 전역적으로 식별하는 정수 키를 만들어서 그 키 → 정점 인덱스 해시를 들고 다니는 것이다.

// 엣지의 두 끝 격자 인덱스 (a, b) — 항상 a < b로 정렬

edgeKey = pack3(min(a, b)) * SHIFT + pack3(max(a, b))

if edgeKey in cache: reuse cache[edgeKey]

else: cache[edgeKey] = registerVertex(p)

GPU 구현은 보통 두 패스로 푼다 — 첫 패스에서 각 엣지 위에 정점을 후보로 등록(activeEdge 마스크 + prefix sum), 두 번째 패스에서 그 정점 인덱스를 참조해 삼각형 인덱스 버퍼를 만든다. 한 패스 안에서 모든 걸 끝내려면 atomic 연산이 필요한데, atomic이 비싸므로 두 패스 분리가 보통 더 빠르다.

청크 경계 처리 — UE5.8 MeshPartition의 자리

청크 단위 베이크가 가장 까다로워지는 자리는 청크 경계다. 두 청크가 공유하는 엣지 위 정점이 양쪽에서 같은 좌표여야 하고, 그 정점에 연결되는 삼각형들이 두 청크에서 모순 없이 만나야 한다. 표준 해법은 청크 그리드를 한 칸 겹쳐서(overlap = 1) 베이크하고, 두 번째 패스에서 경계 정점을 stitching하는 것이다. UE 5.8 MeshPartition이 청크를 자르는 방식도 결국 이 패턴 위에 서 있다 — 한 청크 안은 완전 독립이고, 청크 사이의 일관성은 별도 패스가 책임진다.

이 분리 덕분에 청크 베이크는 독립적이고 병렬화 가능한 N개의 작은 베이크 + 결정론적인 stitching 한 번으로 분해된다. 큰 월드도 청크 단위로 점진 베이크가 가능하고, 사용자가 한 영역을 편집한 결과가 다른 영역으로 새지 않는다.

이 챕터 요약

단계	무엇	자료구조
1. 분류	8버텍스 안/밖 → 8비트 정수	cubeIndex ∈ [0, 256)
2. 엣지 마스크	어느 엣지가 활성인가	edgeTable[256] → 12-bit mask
3. 보간	활성 엣지 위 교점 위치	t = (iso-v0)/(v1-v0)
4. 삼각형 트리플	활성 엣지 인덱스로 삼각형 구성	triTable[256][16]
5. 모호성 해결	면/내부 dual surface 결정	asymptotic decider, MC33
6. 누적	격자 전체에서 메시 합성	per-cube 독립

마칭큐브가 30년 넘게 표준 자리를 지킨 이유가 이 표 안에 모두 들어 있다. 6단계 중 5단계가 룩업과 산술이고, 한 단계(모호성 해결)만 분기를 요구하는데 그마저도 입력을 SDF로 정규화하면 사실상 우회된다. 알고리즘 자체의 단순함이 후속 30년의 모든 변종이 "그래도 결국 돌아오는" 기준점을 만들었다.

이제 마칭큐브가 한 큐브 안에서 무슨 일을 하는지를 끝까지 따라왔다. 8비트 인덱스 한 번 만들고, 두 장의 표를 한 번씩 조회하고, 최대 12개 엣지에서 선형 보간을 한 번씩 돌리면 한 큐브의 메시 기여분이 결정된다. 격자 전체에 이 절차가 독립적으로 일어나니 GPU로 옮기든 청크로 베이크하든 자유다. 다음 챕터에서는 이 알고리즘이 UE 5.8 메시 테레인의 "두 절벽 붙이기" 흐름에서 정확히 어느 자리에 박혀 있는지를 본다 — 추상 절차가 엔진 코드로 응결되는 한 자리를 확인하는 것이다.

[Graphics] 복셀 마칭큐브와 Mesh Terrain - 2

LazySonic — Fri, 29 May 2026 01:33:44 +0900

[Graphics] 복셀 마칭큐브와 Mesh Terrain - 1

[Graphics] 복셀 마칭큐브와 Mesh Terrain - 3

[Graphics] 복셀 마칭큐브와 Mesh Terrain - 4

Ch2. 입문 — 2D 마칭 스퀘어로 직관 잡고 3D로 점프

마칭큐브는 3D 알고리즘인데, 처음 만나면 큐브 8버텍스가 동시에 안/밖이 갈리는 그림이 머릿속에 잘 그려지지 않는다. 한 차원 내려가서 2D부터 보면 같은 아이디어가 손바닥만한 격자에 펼쳐지고, 거기서 3D로 점프하는 게 훨씬 자연스럽다. 이 챕터는 2D의 마칭 스퀘어(marching squares)로 직관을 잡은 다음, 그 직관을 그대로 한 차원 끌어올려 3D 마칭큐브로 넘어가는 게 목표다.

2D 마칭 스퀘어 — 4 꼭짓점, 16 케이스, 4 고유 케이스

스칼라 장 f(x, y)가 평면에 정의돼 있다고 하자. 우리가 원하는 건 그 장의 등치선(isoline), 즉 f = iso가 되는 곡선이다. 격자(grid) 한 칸을 떼어내면 그 칸은 4개의 꼭짓점을 가진 사각형이다. 각 꼭짓점에서 스칼라 값을 한 번씩 샘플링해 두면, 그 값이 iso보다 작으냐 크냐로 안(below) / 밖(above) 두 상태 중 하나가 된다.

꼭짓점 4개 × 상태 2개니까 한 칸이 가질 수 있는 안/밖 패턴은 정확히 2⁴ = 16가지다. 0000(전부 밖)부터 1111(전부 안)까지. 각 패턴마다 등치선이 그 사각형을 어떻게 가로지르는지가 정해진다. 가장 흔한 패턴 한두 개만 그림으로 보면 "아하" 하는 순간이 온다.

[IMAGE 04 — Marching Squares 16 cases (Python/matplotlib): 4×4 grid, 각 셀에 4꼭짓점 채움 패턴 + 그 안을 가로지르는 등치선. 회전/반사로 묶이는 4 고유 케이스는 색상 그룹으로 표시. 좌표 정확.]

회전(90°·180°·270°)과 반사 대칭으로 묶으면 16개 케이스는 결국 4개의 고유 케이스로 줄어든다.

• Case A — 전부 안 / 전부 밖. 등치선 없음. (0000, 1111)

• Case B — 한 꼭짓점만 다른 상태. 그 꼭짓점을 둘러싼 두 엣지를 가로지르는 짧은 직선 한 조각. (8개 패턴이 회전·반사로 묶임)

• Case C — 인접한 두 꼭짓점이 같은 상태. 사각형을 가로지르는 직선 한 조각. (4개 패턴)

• Case D — 대각선 두 꼭짓점만 같은 상태 (saddle). 두 조각이 나오는데, 두 가지 연결 방식이 모두 합법이다. 이게 2D판 모호성(ambiguity) 케이스다. (2개 패턴)

Case D의 두 가지 합법 연결 중 어느 쪽을 고를지는 보조 정보 — 예를 들어 사각형 중앙의 보간된 스칼라 값 — 로 결정한다. 이게 3D에서 Case 6 / 13 같은 모호성 케이스로 그대로 확대된다. 2D에서 잠깐 머리를 갸웃하게 만드는 정도지만, 3D에서는 "터널(tunnel)이 뚫리느냐 막히느냐"가 갈리는 위상 결정으로 격상된다. Ch3에서 다시 만난다.

"Marching"이라는 이름의 유래

이 알고리즘 가족이 굳이 마칭(marching, 행진)이라는 군대 용어를 달고 다니는 이유는, 격자의 한 칸 한 칸을 마치 검열관이 행진하듯 순회하면서 같은 룩업 규칙을 반복 적용하기 때문이다. 한 칸의 결정이 옆 칸에 영향을 주지 않고, 모든 칸이 똑같은 짧은 절차를 거친다. 컴파일러로 치면 한 줄짜리 함수를 격자 전체에 map() 하는 셈이고, GPU로 옮기면 한 칸당 한 스레드를 띄우면 끝이다. 알고리즘 이름이 곧 그 구조를 광고하는 드문 사례다.

대안 이름인 cuberille(라틴어로 "큐브 격자"), isosurfacing, contouring 같은 표현들도 같은 가족을 가리키지만, 마칭 계열만이 "한 칸씩 도장 찍듯 진행한다"는 구현 패턴까지 이름에 박아 넣었다.

점프 — 4 꼭짓점이 8 꼭짓점이 되는 순간

여기까지 잡았으면 3D 마칭큐브는 같은 알고리즘을 한 차원 끌어올린 것이다. 정확히 세 가지가 바뀐다.

1. 격자 한 칸의 꼭짓점이 4개 → 8개로 늘어난다. 사각형이 큐브가 되니까.

2. 케이스 수가 2⁴ = 16 → 2⁸ = 256으로 폭증한다. 모든 안/밖 조합.

3. 출력이 선분(line segment)이 아니라 삼각형(triangle)이다. 등치선이 등치면이 됐으니까.

[IMAGE 05 — 2D Marching Squares → 3D Marching Cubes (SVG): 좌측에 4꼭짓점 한 케이스, 우측에 8꼭짓점 큐브의 대응되는 케이스. 화살표로 차원 점프. 4→8, 16→256, 선분→삼각형 라벨링.]

256은 큰 숫자처럼 들리지만, 회전(24개)과 반사 대칭을 모두 적용해 묶으면 결국 15개의 고유 케이스로 줄어든다. 이 15 케이스를 한 장에 그려둔 그림이 마칭큐브 글의 트레이드마크 같은 다이어그램이고, Ch3에서 자세히 본다.

여기서 한 가지 안심해도 되는 사실. 256개 케이스 표를 직접 손으로 채울 일은 거의 없다. 1987년 Lorensen & Cline의 원논문이 15 케이스를 그려서 발표한 이후, Paul Bourke의 polygonising 코드(paulbourke.net/geometry/polygonise)가 public-domain으로 256개 표를 모두 펼쳐 풀어 깔아 두었고, 그 표가 사실상 모든 마칭큐브 구현의 출발점이 됐다. OpenVDB, FastNoise, Voxel Tools, Unreal Engine 내부 GeometryProcessing 모듈까지 — 모두 같은 인덱싱 컨벤션과 같은 (또는 동등한) 룩업 테이블을 공유한다. 즉 새 프로젝트에서 마칭큐브를 들고 와야 할 때 진짜로 직접 짤 부분은 스칼라 장을 어떻게 채울지(노이즈 vs SDF vs CT 데이터) 정도이고, 케이스 분류와 룩업은 거의 모두 잘 다듬어진 레퍼런스에서 옮겨오면 된다.

큐브 인덱싱 컨벤션 — 끝까지 들고 갈 약속

3D에서 8개 꼭짓점에 번호를 매기는 방식은 구현체마다 살짝 다르지만, 이 글에서는 Paul Bourke의 polygonising 코드와 대부분의 오픈소스 구현(특히 OpenVDB, FastNoise)이 채택한 표준을 따른다. 이 표는 이 글 끝까지 그대로 쓰니까 한 번에 못 박고 가자.

인덱스	좌표 (x, y, z)	위치 설명
V0	(0, 0, 0)	바닥 — 앞-왼쪽
V1	(1, 0, 0)	바닥 — 앞-오른쪽
V2	(1, 1, 0)	바닥 — 뒤-오른쪽
V3	(0, 1, 0)	바닥 — 뒤-왼쪽
V4	(0, 0, 1)	위 — 앞-왼쪽
V5	(1, 0, 1)	위 — 앞-오른쪽
V6	(1, 1, 1)	위 — 뒤-오른쪽
V7	(0, 1, 1)	위 — 뒤-왼쪽

엣지는 그 사이를 잇는다. 12개의 엣지에도 번호가 있다.

인덱스	잇는 꼭짓점	위치
E0	V0 — V1	바닥 앞
E1	V1 — V2	바닥 오른쪽
E2	V2 — V3	바닥 뒤
E3	V3 — V0	바닥 왼쪽
E4	V4 — V5	위 앞
E5	V5 — V6	위 오른쪽
E6	V6 — V7	위 뒤
E7	V7 — V4	위 왼쪽
E8	V0 — V4	세로 — 앞-왼쪽
E9	V1 — V5	세로 — 앞-오른쪽
E10	V2 — V6	세로 — 뒤-오른쪽
E11	V3 — V7	세로 — 뒤-왼쪽

[IMAGE 06 — 큐브 8버텍스 / 12엣지 인덱싱 (SVG): isometric 큐브, V0-V7 라벨 + E0-E11 엣지 라벨. 바닥(z=0) 옅은 색, 위(z=1) 진한 색으로 구분. 좌표축 표시.]

이 번호 매김이 정해지면 한 칸의 안/밖 패턴은 8비트 정수 하나로 압축된다. V_i가 안이면 i번 비트가 1이라는 단순한 규칙이다. 즉 안/밖 패턴 → 0…255 사이 정수 = 큐브 인덱스. 그 인덱스가 곧 256 케이스 중 어느 케이스인지를 가리키는 키가 된다. Ch3의 테이블 룩업이 바로 이 인덱스 한 방으로 결정된다.

복셀 — 마칭이 실제로 행진하는 단위

"복셀"이라는 단어를 여러 의미로 쓰는데, 마칭큐브 맥락에서는 3D 격자의 한 칸, 정확히는 그 칸의 8개 꼭짓점에서 스칼라 값을 샘플링했다는 사실을 가리킨다. 그래서 NxNxN 그리드에는 (N-1)³개의 복셀 칸이 있고, 각 칸마다 위에서 본 8버텍스 인덱싱 → 256 케이스 룩업 → 삼각형 추출이 독립적으로 일어난다.

[IMAGE 07 — Voxel grid 분위기 (nanobanana 일러스트): 반투명한 3D 그리드 위에 등치면이 살짝 떠오르는 컷. 칸마다 마칭이 진행되는 느낌. 정확 좌표보다는 시각적 분위기.]

여기서 "독립적"이라는 단어가 중요하다. 한 큐브의 결과가 옆 큐브에 직접 의존하지 않으므로 알고리즘은 창피할 만큼 병렬화가 잘 된다(embarrassingly parallel). GPU 컴퓨트 셰이더로 옮기기 쉬운 이유, UE 5.8 MeshPartition이 청크 단위로 베이크할 수 있는 이유가 모두 여기에서 온다.

물론 인접 큐브가 같은 엣지를 공유하므로, 그 엣지 위에 찍히는 보간 교점도 두 큐브에서 같은 좌표여야 한다. 보간 공식이 양쪽에서 동일한 두 끝값으로 계산되니 자연히 그렇게 되지만, 정점 중복(같은 엣지 교점을 두 번 등록)을 피하려면 엣지 인덱스 → 정점 인덱스 해시를 들고 다니는 게 보통이다. 구현 디테일은 Ch3의 성능 절(節)에서 다시 만난다.

스칼라 장이 어디서 오는가

8버텍스 샘플링이라는 표현을 가볍게 썼지만, 그 값이 어디서 오는가는 사용 케이스마다 다르다. 의료 영상에서는 CT 보클(voxel)의 헝(Hounsfield) 단위가 그대로 들어오고, 게임의 절차적 지형에서는 3D Perlin / Simplex 노이즈가 위치를 받아 실수 하나를 뱉는다. UE 5.8 메시 테레인에서는 하이트맵을 한 번 임포트한 다음 그 결과를 협대역 SDF로 들고 있다가, 두 메시를 합칠 때 그 SDF 값을 8버텍스에서 평가하는 식이다. 즉 마칭큐브 입력은 함수든 보클 그리드든 SDF 텍스처든 상관없이, "한 점에 실수 하나를 돌려주는 무언가"면 충분하다. 이 추상화가 알고리즘이 30년 넘게 살아남은 이유 중 하나다.

노멀은 어떻게 구하나

삼각형이 나와도 셰이딩에 쓸 노멀이 없으면 메시가 완성되지 않는다. 마칭큐브에서 노멀은 보통 스칼라 장의 그래디언트(∇f)를 정규화해서 쓴다. 정점 좌표가 정해진 다음 그 좌표에서 ∂f/∂x, ∂f/∂y, ∂f/∂z를 중앙 차분(central difference)으로 추정하고, 부호는 등치값 방향에 맞춰 뒤집는다. 별도의 후처리(per-face normal → vertex normal averaging) 없이 샘플링 단계에서 바로 부드러운 노멀이 떨어지는 게 마칭큐브 가족의 깔끔한 점이다.

이 챕터 요약

차원	한 칸의 꼭짓점	케이스 수	회전·반사 후 고유 케이스	출력
2D (Marching Squares)	4	2⁴ = 16	4	선분
3D (Marching Cubes)	8	2⁸ = 256	15	삼각형

다음 챕터에서는 그 15 케이스가 어떻게 한 장에 펼쳐지는지, 엣지 테이블과 삼각형 테이블이 어떻게 한 번의 룩업으로 메시를 토해내는지, 그리고 1987년부터 따라다닌 모호성 케이스의 정체를 차례로 푼다. 차원이 늘어났을 뿐 "한 칸을 8비트로 압축해 룩업 한 번에 끝낸다"는 핵심 골격은 2D 마칭 스퀘어 때와 정확히 같다는 점만 머릿속에 들고 넘어가면 된다. 핵심은 비트 패턴 하나가 곧 인덱스고, 인덱스 하나가 곧 케이스고, 케이스 하나가 곧 미리 계산된 삼각형 묶음을 가리킨다는 사실 — 룩업 한 번이 메시 한 조각이다.

[Graphics] 복셀 마칭큐브와 Mesh Terrain - 1

LazySonic — Fri, 29 May 2026 01:32:06 +0900

[Graphics] 복셀 마칭큐브와 Mesh Terrain - 2

[Graphics] 복셀 마칭큐브와 Mesh Terrain - 3

[Graphics] 복셀 마칭큐브와 Mesh Terrain - 4

마칭큐브는 3차원 스칼라 장(scalar field)에서 등치면(isosurface)을 삼각형 메시로 뽑아내는 알고리즘이다. 1987년 Lorensen과 Cline이 SIGGRAPH에서 발표한 이후 의료 영상의 CT 표면 재구성부터 게임의 절차적 지형, 유체 시뮬레이션의 마칭 결과 렌더까지, "복셀 그리드를 진짜 메시로 바꿔야 하는 모든 자리"의 표준이 되었다. UE 5.8에 새로 들어온 MeshTerrainMode / MeshPartition 플러그인도 절벽 두 개를 붙이는 그 순간에 내부적으로 복셀화 → 마칭큐브 → 협대역 SDF 파이프라인을 돌린다. 이 글은 그 핵심을 한 번 끝까지 풀어본다.

왜 이 글이 따로 필요한가

지난 글에서 UE 5.8의 메시 기반 지형 시스템 두 종(MeshTerrainMode, MeshPartition)을 훑었다. 그때 "두 절벽을 합치는 순간엔 복셀화 + 마칭큐브 + 협대역 SDF가 에디터에서 돌아간다"는 한 줄로 넘어갔는데, 그 한 줄의 무게가 사실 글 전체보다 무겁다. 마칭큐브를 모르면 그 파이프라인이 왜 그렇게 생겼는지, 왜 런타임이 아니라 에디터 전용인지, 왜 협대역 SDF로 잘라내는지가 전부 블랙박스로 남는다.

그래서 이번엔 순서를 뒤집는다. 마칭큐브가 주연이고, UE 5.8 메시 테레인은 그 알고리즘이 실제 엔진 코드에 어떻게 박혀 들어가는지를 보여주는 사례 한 편이 된다.

이 글이 답하는 것 / 답하지 않는 것

답하는 것

• 등치면이 뭐고, 왜 "큐브 단위로 행진"하면 그게 뽑히는지

• 큐브 8버텍스를 안/밖으로 분류해서 만든 8비트 인덱스가 어떻게 256개 경우, 그리고 회전·반사 대칭으로 15개 고유 케이스로 줄어드는지

• 엣지 테이블과 삼각형 테이블이 무엇을 들고 있고, 한 번의 룩업으로 어떻게 삼각형들이 튀어나오는지

• 선형 보간으로 엣지 위 교점을 어디에 찍는지 (t = (iso - v0) / (v1 - v0))

• 1987년부터 따라다닌 모호성 케이스 (6, 10, 12, 13) — 면 모호성과 내부 모호성, 그리고 dual surface 문제가 왜 생기는지

• Dual Contouring / Surface Nets 같은 사촌 알고리즘들과의 짧은 비교

• 성능 / 메모리 측면의 실전 고려사항

• 위 모든 게 UE 5.8 MeshTerrainMode의 "두 절벽 붙이기" 흐름에 어떻게 매핑되는지

[IMAGE 02 — Ch1 metaphor: "two cliffs welded into one continuous surface by an unseen algorithmic chisel"]

답하지 않는 것

• 등치면 이론의 미분기하학적 정초 (풀리 핸들 같은 토폴로지 깊이)

• GPU 컴퓨트 셰이더 구현 코드 (의사코드까지만)

• Manifold Dual Contouring, Cubical Marching Squares 같은 고급 변종의 전체 구현

• UE 플러그인의 6개 서브모드(Create / Edit / Sculpt 등) 디테일 — 그건 지난 글로 충분히 깔아 두었다

• 런타임 동적 편집 기능에 대한 추측 (현재 에디터 전용이라는 사실만 인용한다)

4단계 로드맵

챕터	무엇
Ch1	지금 읽고 있는 개요
Ch2	입문 — 2D 마칭 스퀘어로 직관 잡고 3D로 점프
Ch3	딥다이브 — 인덱싱 → 테이블 → 보간 → 모호성 → 비교 → 성능
Ch4	사례 — UE 5.8 `MeshTerrainMode`에서 마칭큐브가 실제로 호출되는 지점

순서대로 읽으면 매끄럽지만, 각 챕터는 자기 토픽 문장 한 줄로 시작해서 독립적으로 떠먹어도 큰 무리가 없게 잘랐다.

전제 독자

게임 프로그래머 또는 테크니컬 아티스트(TA)를 가정한다. 다음은 글 안에서 따로 풀지 않고 그냥 쓴다.

• 스칼라 장(scalar field): 공간상의 점마다 실수 한 개가 정의된 함수 f(x, y, z) → ℝ

• 등치면(isosurface): 그 값이 특정 임계값과 같아지는 지점들의 집합 { p : f(p) = iso }

• SDF(Signed Distance Field): 가장 가까운 표면까지의 부호 있는 거리. 안쪽이 음수, 바깥이 양수

• 복셀(voxel): 3D 그리드 셀. 여기서는 한 셀의 8개 꼭짓점에서 스칼라 값을 샘플링했다는 의미

• 메시 토폴로지 기본: 버텍스 / 엣지 / 삼각형 / 노멀, 매니폴드 / 비매니폴드

이 정도는 UE의 FDynamicMesh3 API나 Houdini의 VDB / VolumeSDF 노드를 만져본 사람이라면 이미 머릿속에 들어있는 어휘다.

이 글의 그림들 — 책임 분리

본격적으로 들어가기 전에 한 가지만 분명히 해 두자. 마칭큐브 같은 알고리즘 글은 그림의 정확성이 글의 정확성을 절반쯤 결정한다. 큐브 8버텍스 어디가 V0인지 한 칸 어긋나면 인덱싱 규칙 전체가 무너지고, 256 케이스 중 6번이 13번처럼 그려지면 모호성 절(節)이 통째로 거짓말이 된다. 그래서 이 글의 그림은 두 갈래로 명확히 갈라 그렸다.

• 정확 도식 (SVG / Python). 큐브 인덱싱, 15 케이스 그리드, 엣지 테이블 룩업 흐름, 보간 벡터, ambiguity 분기 — 좌표가 의미를 갖는 모든 도식은 손으로 짠 SVG 또는 matplotlib 스크립트로 만들었다. 코드가 공개되어 있으니(output/scripts/) 재현 가능하고, 라벨 한 칸 옮기는 수정도 안전하다.

• 일러스트 (AI 이미지 — nanobanana). 표지, 비유 컷, 분위기 컷처럼 "느낌"만 전달하면 되는 자리는 nanobanana(Gemini 기반 이미지 생성)로 뽑았다. 정확성은 글이 책임지고, 그림은 호흡 정도만 맞춘다.

이 분리를 미리 깔아두는 이유는, 본문에서 "이건 도식이라 좌표를 믿어도 된다 / 이건 일러스트라 시각적 분위기만 읽어라" 같은 메타 설명을 매번 붙이지 않기 위해서다. 캡션의 톤만 보고도 어느 쪽인지 짐작하면 된다.

표기 약속

• 큐브 8버텍스는 V0–V7로 라벨링한다. 인덱싱 규칙(어느 모서리가 V0인지)은 Ch2의 "큐브 인덱싱 컨벤션" 표에서 한 번에 못 박아 두고, 이후 챕터 전체에서 동일하게 쓴다.

• 12 엣지는 E0–E11이다.

• 등치값은 iso. 한 엣지 위 두 끝값은 v0, v1 (소문자 v는 스칼라 값, 대문자 V는 정점 위치).

• 보간 파라미터는 t ∈ [0, 1]. 교점 위치는 p = p0 + t * (p1 - p0), t = (iso - v0) / (v1 - v0).

자, 시동 걸었다. 다음 챕터에서 2D 격자 위에 등치선을 그어 보면서 3D로의 점프를 준비한다. 그 점프가 끝나고 나면 마칭큐브의 핵심 골격이 이미 손바닥에 들어와 있을 것이다.

[UE5/Mesh Terrain] Mesh Terrain 오버뷰

LazySonic — Thu, 28 May 2026 09:39:32 +0900

0. 핵심 요약

UE 5.8-Preview는 두 개의 신규 Experimental 플러그인을 통해 "Mesh Terrain" 시스템을 도입했다:

에디터 모드를 제공하는 `MeshTerrainMode`와 런타임 데이터/스트리밍을 담당하는 `MeshPartition`. 두 플러그인 모두 5.7.4에는 존재하지 않는다.

핵심 결론:

Mesh Terrain은 Landscape처럼 영구적인 2D 하이트맵을 저장하지 않는다.

하이트맵은 일회성 임포트 포맷일 뿐이며, 임포트 직후 `FDynamicMesh3` 삼각형 메시로 변환된다. 이 덕분에 오버행/동굴/분기 토폴로지가 가능하다.

두 절벽 메시를 하나로 합치는 작업은 가능하다 — 단, 에디터 타임 한정으로 복셀화(Voxelization) 기반 CSG 도구 `FVoxelBooleanMeshesOp` / `FVoxelMergeMeshesOp`를 통해 수행된다.

내부적으로 마칭 큐브(MarchingCubes)와 협대역(Narrowband) SDF가 사용된다.

패키지된 런타임에서는 복셀/SDF 저장소가 없으며, 베이크된 `FMeshData` 삼각형 메시만 유통된다.

1. 플러그인 구성

1.1 두 개의 신규 플러그인

플러그인	역할	모듈 수	런타임/에디터
MeshTerrainMode	Mesh Partition 편집을 위한 인터랙티브 툴 모음	1 (Editor)	에디터 전용
MeshPartition	런타임 데이터 + 스트리밍 + 에디터 워크플로	5 (Runtime 2 + Editor 3)	혼합

MeshTerrainMode 매니페스트 요약

결론적으로 아직 Experimental이며, 기본적으로 활성화되지 않습니다.

FriendlyName: "Mesh Terrain Mode"
Category: "Mesh Partition"
Description: "Mesh Partition을 생성/편집하기 위한 인터랙티브 툴 모음"
DocsURL: https://dev.epicgames.com/community/learning/knowledge-base/nK7J/unreal-engine-introduction-to-mesh-terrain#meshterrainmode
Plugins 의존성: MeshModelingToolset, MeshModelingToolsetExp, MeshLODToolset, ToolPresets, StylusInput, ModelingToolsEditorMode, MeshPartition
EnabledByDefault: false / IsExperimentalVersion: true

MeshPartition 모듈

MeshPartition (Runtime, Default)
MeshPartitionCompute (Runtime, PostConfigInit)
MeshPartitionEditor (Editor)
MeshPartitionModelingToolset (Editor)
MeshPartitionEditorUI (Editor)

2. 데이터 표현 — Landscape vs Mesh Terrain

2.1 Landscape 기준선

Landscape는 영구 2D 하이트맵 기반 시스템이다.

핵심 구조: `FHeightmapData`가 `UTexture2D` 래핑 (LandscapeComponent.h:321)
저장 포맷: uint16 raw 배열 + LOD별 mip — `TMap<int32, TArray<uint16>> HeightMipData` (LandscapeComponent.h:227)
그리드: `(SubsectionSizeQuads + 1) * ComponentNumSubsections` 정점 (예: 4×63+1 = 253 정점/컴포넌트)
LOD: 컴포넌트별 결정론적 mip + GPU에서 정점 모핑
토폴로지: **2D 정규 그리드만**. X-Y 평면 + Z 높이. 오버행/동굴 불가능
스트리밍: `ALandscapeStreamingProxy`가 셀별 액터 분할
편집: 브러시 페인팅으로 높이만 수정
결정론: 높음 (고정 그리드, 재현 가능)

2.2 Mesh Terrain (MeshPartition) 표현

Mesh Terrain은 완전 3D 삼각형 메시 기반이다.

핵심 구조: `FMeshData` — 명시적 정점/삼각형 배열 (MeshPartitionMeshData.h:17)
`FDynamicMesh3` 및 `FMeshDescription`과 양방향 변환
`FTriMeshCollisionData`로 변환되어 복합 충돌 생성
토폴로지: 완전 3D. 오버행/동굴/분기 가능
스트리밍: `ACompiledSection` 액터가 World Partition 그리드(`GridCellCoord`)에 등록
`bSplitSectionsToMatchWorldPartitionRuntimeGrid` 플래그로 자동 그리드 정렬
결정론: 낮음 (메시 편집 순서 의존)

TArray<FVector3d> Vertices;       // 3D 위치

TArray<FIndex3i> Triangles;       // 삼각형 인덱스

TArray<FVector3f> Normals;        // 법선

TArray<FUVChannel> ChannelUVs;    // UV 채널

TArray<FWeightLayer> WeightLayers; // 가중치 레이어

2.3 하이트맵의 역할 — 일회성 임포트

Mesh Terrain에서 하이트맵은 "시작점" 임포트 포맷일 뿐, 런타임 데이터 모델이 아니다.

`FHeightmapImporter`가 PNG/RAW 하이트맵을 `TArray64<uint16>`로 로드 (MeshPartitionHeightmapImporter.h:22)
바이리니어 보간으로 UV → 정점 XY + Z(높이) 매핑 (MeshPartitionHeightmapImporter.cpp:418)
쿼드 분할 → 삼각형 그리드 생성 (MeshPartitionHeightmapImporter.cpp:432)
섹션별 메시를 병렬 스레드로 빌드 후 `AMeshPartition` 액터에 머지 (MeshPartitionHeightmapImporter.cpp:235)
임포트 직후 하이트맵 텍스처 폐기. 이후 모든 편집은 정점 단위로 진행
에디터 메인 진입점: `BeginHeightmapImport` 액션 (MeshTerrainMode.cpp:1023)

2.4 차이 매트릭스

항목	Landscape	Mesh Terrain
높이 저장	영구 `UTexture2D` + `uint16` mip 배열	임포트 시점만; 이후 삼각형 메시
메시 형태	암묵적 2D 그리드	명시적 `FDynamicMesh3`
오버행/동굴	불가능 (2D 함수 제약)	가능 (완전 3D)
분기 토폴로지	불가능	가능
LOD	컴포넌트별 결정론 mip	Nanite fallback 의존
스트리밍	셀별 액터 (효율적 2D)	섹션별 (그리드 인식 약함)
편집	브러시 페인팅 (높이만)	모디파이어 스택 (비파괴 + 지오메트리 변형)
결정론성	높음	낮음

3. MeshTerrainMode 에디터 구조

3.1 메인 클래스

// MeshTerrainMode.h:38
class UMeshTerrainMode : public UBaseLegacyWidgetEdMode, 
public ILegacyEdModeSelectInterface

`UBaseLegacyWidgetEdMode` 기반 에디터 모드. ModelingToolset 인터랙티브 툴 인프라(`UInteractiveToolBuilder`, `UInteractiveTool`)를 사용한다.

3.2 서브모드 6종

서브모드	목적	주요 툴	연산 모델
Create	절차적 메시 생성	CreateMegaMeshRectangle, HeightmapImport, DrawSpline, Pattern	메시 신규 생성 또는 하이트맵 임포트
Edit	메시 토폴로지/변환	Convert/Expand/Split/Stitch/Merge MegaMesh, ResectionMesh, EditPivot, BakeTransform, AttributeEditor	구조적 편집 (변위 없음)
Sculpt	정점 + 하이트맵 스컬핑	[Sculpt] Offset/Move/Smooth/Pinch/Flatten + [Height] HeightSculpt/HeightSmooth/HeightFlatten/ZeroHeight/SlopeErode	정점 푸시-풀(3D) + Z잠금 브러시(혼합)
Shapes	CSG 부울 모디파이어	Add Box/Sphere/Cylinder/Capsule/Cone/Torus/Rectangle/Disc	모디파이어로 적용되는 CSG
Paint	어트리뷰트 페인팅	MeshAttributePaint, MeshVertexPaint, AttributeEditor	정점 색상/어트리뷰트 (비기하)
Modifiers	절차적 변형 스택	MeshProject, TexturePatch, Spline, ProjectMeshLayers, Lattice, Noise, Patch / Boolean / Remesh / SplineRemesh	변위 + 리메시 + CSG

3.3 Sculpt 서브모드의 듀얼 팔레트

Sculpt는 두 가지 모드를 함께 제공한다.

[Sculpt 팔레트] 정점을 노멀 방향으로 푸시/풀 — **완전 3D** 변형, 오버행 생성 가능
[Height 팔레트] Z축에만 작용하는 변위 — Landscape 스타일의 하이트필드 편집, 하이트맵 임포트 후에 사용

이 분리는 "기본 하이트맵 기반 지형"과 "3D 스컬프트 영역"을 동시에 한 자산 안에서 다루기 위함이다.

3.4 모디파이어 스택

모디파이어	범주	효과	토폴로지 변경
URemeshModifier	리토폴로지	Uniform/Adaptive 링, Red-Green 테셀레이션	O
UBooleanModifier	CSG	Union / Subtract / Trim	O (구멍/오버행)
UMeshProjectModifier	변위	참조 메시에 Z 투영 (Raise/Lower/Set)	X
USplineModifier	변위	스플라인 경로 따라 변형	X
UPatchModifier	로컬 패치	국지 메시 부분 교체	O (국소)
UTexturePatchModifier	변위	텍스처 기반 변위	X
UNoiseModifier	변위	절차적 정점 오프셋	X
ULatticeModifier	변위	FFD(자유 형식 변형) 격자	X

실행 모델: `FTransformerPipeline`이 모디파이어 체인을 비동기 태스크로 실행. 결과는 `FMeshData`에 베이크.

4. 두 절벽 합치기 — 복셀/SDF 알고리즘

4.1 결론

두 개의 분리된 절벽 메시를 토폴로지 일관성 있게 (오버행 포함) 하나로 합치는 작업은 **에디터에서 가능**하다. 내부적으로 복셀화 + 마칭큐브 + 협대역 SDF가 사용된다. **런타임에서는 불가능** — 결과는 베이크된 삼각형 메시로만 유통된다.

4.2 사용 가능 도구

툴	클래스/Op	위치	역할
Voxel Boolean	FVoxelBooleanMeshesOp	VoxelBooleanMeshesOp.h:21	복셀 그리드 union/diff/intersect
Voxel Merge	FVoxelMergeMeshesOp	VoxelMergeMeshesOp.h:21	복셀 기반 메시 통합
Iso-Surface Offset	IsoSurfaceD	MergeMeshesTool.cpp:74	암시적 표면 오프셋 제어
Narrowband SDF	TSweepingMeshSDF<>	MeshSimpleShapeApproximation.cpp:551	NarrowBand_SpatialFloodFill 모드
Marching Cubes	MarchingCubesGridScale 설정	MeshSimpleShapeApproximation.cpp:398	SDF → 메시 추출
ProxyLOD CSG	IVoxelBasedCSG::CreateCSGTool()	VoxelMergeMeshesOp.cpp:48	ProxyLOD 통합

4.3 MeshTerrainMode에서 등록된 액션

// MeshTerrainMode.cpp:918
ToolManager->RegisterToolType("BeginVoxelMergeTool", ...);

// MeshTerrainMode.cpp:921
ToolManager->RegisterToolType("BeginVoxelBooleanTool", ...);

MeshTerrainModeManagerActions.cpp:184-185 에서 "Voxel Boolean" 및 "Voxel Merge" 명령어가 UI에 노출된다.

4.4 알고리즘 동작 흐름 (두 절벽 → 단일 메시)

입력: `FDynamicMesh3` × 2 (절벽 A, 절벽 B)
복셀화: 각 메시를 협대역 SDF로 변환 (`TSweepingMeshSDF<>` + NarrowBand_SpatialFloodFill)
CSG 연산: 복셀 도메인에서 union / subtract / intersect / merge
마칭 큐브: 결과 SDF의 iso-surface (`IsoSurfaceD` 오프셋) 추출 → 새 `FDynamicMesh3`
옵션: 리메시 모디파이어로 정점 분포 정리
결과 베이크: `FMeshData`로 압축되어 `ACompiledSection` 액터에 저장

4.5 런타임 제약

`ModelingOperatorsEditorOnly` 모듈은 **에디터 전용** — 패키지에 포함되지 않음
`FMeshBoolean` (GeometryCore 런타임 모듈)은 존재하지만 `MeshPartitionEditor/Modifiers/MeshPartitionBooleanModifier.cpp:6`에서만 사용 — 에디터 모디파이어로 한정
`MeshPartition.Build.cs` (런타임)에는 Boolean 모디파이어 모듈 없음
런타임 데이터는 베이크된 `FMeshData` 삼각형 메시뿐. SDF/복셀 그리드는 저장되지 않음
결론: "두 절벽 합치기"는 **에디터 워크플로 한정**. 게임 플레이 중 동적 합성은 불가

5. 채널 / 충돌 / 렌더링

5.1 채널 시스템 (메타데이터)

`FChannelMap` / `FChannelName` — 명명된 어트리뷰트 (가중치 레이어 등)
커스텀 프리미티브 데이터(Custom Primitive Data)로 머티리얼 룩업 — 5비트 슬롯 패킹, 최대 24채널
채널 텍스처는 UV 공간에 래스터화 (월드 공간 복셀 아님)
Virtual Texture fallback 컴포넌트
타일 기반 머티리얼 캐시

5.2 충돌

`UMeshPartitionCollisionComponent`가 `FTriMeshCollisionData` 보유
`IInterface_CollisionDataProvider` 구현 — 복합 충돌(Complex Collision)을 삼각형 메시에서 직접 추출
`bCanEverAffectNavigation` 플래그로 NavMesh 영향 제어
채널별 물리 머티리얼 매핑 (가중치 폴백)

5.3 컴포넌트 계층

클래스	역할	파일
AMeshPartition	루트 액터, 정의 + 컴포넌트 보유	MeshPartition.h:24
UMeshPartitionDefinition	공유 설정 에셋	MeshPartitionDefinition.h:149
UMeshPartitionComponent	PrimitiveComponent 기반	(Runtime)
UMeshPartitionStaticMeshComponent	StaticMeshComponent 래퍼	(Runtime)
UMeshPartitionCollisionComponent	충돌 전용	MeshPartitionCollisionComponent.h:35
ACompiledSection	런타임 결과 액터 (World Partition)	MeshPartitionCompiledSection.h:163

6. 제약사항 및 결론

6.1 사용 시 제약

Experimental 단계 — API 변경 가능성 큼
기본 비활성화 (`EnabledByDefault: false`)
StylusInput 의존 — 스타일러스 디바이스 지원 권장
World Partition 활성 환경 필요 — `bSplitSectionsToMatchWorldPartitionRuntimeGrid`
자체 LOD 없음 — Nanite 의존
런타임 동적 토폴로지 변경 불가 — 모든 CSG/복셀은 에디터에서 베이크

6.2 Mesh Terrain이 적합한 시나리오

오버행/동굴/아치 등 비-함수형 지형이 필요한 환경 (절벽, 협곡, 동굴 입구)
아티스트가 스컬프팅 워크플로로 직접 모델링하는 핸드크래프트 지형
CSG로 절차적 절벽 결합/구멍 뚫기가 필요한 레벨
Nanite 활용 가능한 PC/콘솔 타깃

6.3 Landscape를 유지해야 하는 시나리오

거대한 2D 함수형 지형 (km 단위 평원, 언덕)
결정론적 LOD 모핑이 중요한 게임 (모바일/멀티플레이)
Layer 기반 텍스처 블렌딩 워크플로
스플랫맵 + 풀/디칼 시스템에 강하게 의존하는 프로젝트

6.4 두 시스템 병행 권장

UE 5.8 단계에서는 "기본 지형 = Landscape, 특수 오버행 영역 = Mesh Terrain" 하이브리드 접근이 현실적이다. Mesh Terrain은 절벽/동굴/아치 등 함수형으로 표현할 수 없는 국지 지형에 한정 사용하고, 평원/언덕은 Landscape의 효율적 2D 스트리밍과 결정론적 LOD를 활용한다.

부록 A. 핵심 파일 경로

Plugins/Experimental/MeshTerrainMode/MeshTerrainMode.uplugin

Plugins/Experimental/MeshTerrainMode/Source/MeshTerrainMode/Private/MeshTerrainMode.h

Plugins/Experimental/MeshTerrainMode/Source/MeshTerrainMode/Private/Submodes/*

Plugins/Experimental/MeshPartition/MeshPartition.uplugin

Plugins/Experimental/MeshPartition/Source/MeshPartition/Public/MeshPartitionMeshData.h

Plugins/Experimental/MeshPartition/Source/MeshPartitionEditor/Public/MeshPartitionHeightmapImporter.h

Plugins/Runtime/MeshModelingToolset/Source/ModelingOperatorsEditorOnly/Public/CompositionOps/VoxelBooleanMeshesOp.h

Plugins/Runtime/MeshModelingToolset/Source/ModelingOperatorsEditorOnly/Public/CompositionOps/VoxelMergeMeshesOp.h

Plugins/Runtime/GeometryProcessing/Source/DynamicMesh/Private/ShapeApproximation/MeshSimpleShapeApproximation.cpp

Source/Runtime/Landscape/Classes/LandscapeComponent.h

부록 B. 공식 문서

Epic Dev Community: "Introduction to Mesh Terrain"
URL: https://dev.epicgames.com/community/learning/knowledge-base/nK7J/unreal-engine-introduction-to-mesh-terrain#meshterrainmode

부록 C. 향후 조사 권장

Nanite 적용 시 LOD 비용 측정 — Landscape mip 시스템과 비교 벤치마크
Voxel Boolean의 입력 메시 해상도별 베이크 시간/메모리 프로파일
World Partition 셀 경계에서의 메시 이음새(seam) 처리 방식 검증
멀티 유저 에디터에서의 모디파이어 스택 동시 편집 충돌 정책

[Graphics] 복셀 렌더링 - 3 <Spatial Hash Map>

LazySonic — Thu, 19 Mar 2026 13:23:21 +0900

Spatial Hash Map (공간 해시 맵)

[Graphics] 복셀 렌더링 - 2 <언리얼 SVT>

기존 포스팅 내용 요약[Graphics] 복셀 렌더링 - 1 본격적인 이야기에 앞서, 지난 포스트에서 다루었던 '복셀(Voxel) 데이터를 메모리에 욱여넣는 방법'을 짧게 되짚어 보겠습니다. 거대한 3D 공간에서

develop-4-art.tistory.com

기존 포스트였던 언리얼 SVT에 이어 이제 트리구조에서 벗어난 해시맵에 대한 이야기를 다뤄보겠습니다.

1.트리(Tree)의 한계와 Spatial Hash Map의 등장

SVO, NanoVDB, SVT는 모두 '위에서 아래로 길을 찾아가는' 구조입니다. 지도를 보고 목적지를 찾아가는 것과 같죠.
하지만 데이터가 매 프레임 파괴되고 생성되는 동적인 환경(Dynamic Environment)에서는 지도가 수시로 바뀝니다. 지도를 고쳐 그리는 시간(Re-build)이 렌더링 시간보다 더 걸리는 배보다 배꼽이 더 큰 상황이 벌어집니다.
그래서 그래픽스 프로그래머들은 길 찾기를 포기하고, "좌표를 부르면 즉시 데이터가 튀어나오는 방법"을 선택했습니다. 그것이 바로 공간 해시 맵입니다.

O(1)의 마법: 해시 함수(Hash Function)

작동 원리: 3D 공간의 특정 좌표 $(x, y, z)$를 복잡한 수학 공식(해시 함수)에 집어넣습니다. 이 함수는 해당 좌표를 1차원 메모리 배열의 특정 인덱스(예: 705번 방)로 즉시 변환해 줍니다.
압도적 장점: 트리의 깊이(Depth)를 타고 내려갈 필요가 없습니다. 무조건 단 한 번의 연산으로 끝납니다. 즉, 수학적으로 가장 완벽한 $O(1)$의 읽기/쓰기 속도를 자랑합니다.
무한한 공간: 전체 월드의 크기를 미리 정해둘 필요가 없습니다. 우주 끝에 있는 좌표라도 해시 함수에 넣기만 하면 배열의 어느 한 칸으로 매핑되기 때문입니다.

가장 널리 쓰이는 해시 함수 형태(Teschner et al., 2003, 테슈너의 충돌관련 논문집)는 다음과 같습니다.

$$h(C_x, C_y, C_z) = ((C_x \cdot p_1) \oplus (C_y \cdot p_2) \oplus (C_z \cdot p_3)) \pmod{N}$$

$p_1, p_2, p_3$: 매우 큰 소수 (서로 다른 임의의 소수)
$\oplus$: 비트 XOR 연산자
$N$: 1차원 배열(해시 테이블)의 전체 크기

추천하는 소수 값 ($p_1, p_2, p_3$)

보통 충돌(Collision)을 최소화하기 위해 실험적으로 검증된 다음과 같은 큰 소수들을 사용합니다.

$p_1 = 73856093$
$p_2 = 19349663$
$p_3 = 83492791$

왜 이런 공식을 사용할까요?

소수 곱셈: 좌표값에 불규칙성을 부여하여, 공간상에 규칙적으로 배치된 물체들이 해시 테이블의 같은 인덱스로 몰리는 현상(Clustering)을 방지합니다.
XOR 연산 ($\oplus$): 덧셈 대신 XOR을 사용하면 각 좌표의 비트 정보가 섞이면서 해시값이 더 고르게 분포됩니다. 비트 연산이므로 연산 속도도 매우 빠릅니다.
모듈러 연산 ($\pmod{N}$): 계산된 거대한 해시값을 우리가 실제로 메모리에 할당한 1차원 배열의 크기($N$) 안으로 구겨 넣는 역할을 합니다.

2. 해시 맵의 치명적인 단점 (Trade-off)

세상에 공짜는 없습니다. $O(1)$의 쾌감을 얻은 대신 아주 치명적인 두 가지를 포기해야 했습니다.

해시 충돌 (Hash Collision)

공간은 무한하지만 우리가 가진 1차원 배열(메모리)의 크기는 유한합니다. 완전히 다른 두 3D 좌표를 해시 함수에 넣었는데, 하필 똑같이 '705번 방'이라는 결과가 나올 수 있습니다. 이를 해결하기 위해 연결 리스트(Linked List)로 방을 늘리거나 다른 빈방을 찾아 헤매는 추가 연산이 필요해져 성능이 널뛰기할 수 있습니다.

공간 지역성의 붕괴 (Loss of Spatial Locality)

GPU는 메모리를 한 번 읽을 때, 요청한 데이터 주변의 데이터를 뭉텅이로 캐시(Cache)에 올려서 속도를 냅니다. SVO나 NanoVDB는 이웃 복셀들이 메모리 상에서도 이웃해 있었습니다.
하지만 해시 맵을 통과하면? 현실의 3D 공간에서는 바로 옆에 딱 붙어있는 이웃 복셀이라도, 메모리 배열 상에서는 1번 방과 100만 번 방처럼 극과 극으로 흩어지게 됩니다. 캐시 미스(Cache Miss)가 미친 듯이 발생하며 렌더링 성능이 바닥을 칩니다.

3. 활용 사례 1: 마인크래프트의 "청크(Chunk) 기반 하이브리드 해시 맵"

https://www.youtube.com/watch?v=7OHrE2krQU8&list=PLVsTSlfj0qsWEJ-5eMtXsYp03Y9yF1dEn&index=2

그렇다면 마인크래프트는 이 무시무시한 캐시 미스를 뚫고 어떻게 그 수많은 블록을 실시간으로 렌더링할까요? 정답은 "낱개의 복셀을 해싱하지 않고, 덩어리(Chunk)를 해싱한다"는 천재적인 타협안에 있습니다.
마인크래프트는 무한한 월드를 보통 $16 \times 384 \times 16$ 크기의 거대한 기둥인 청크(Chunk) 단위로 썰어버립니다.

거시적(Macro) 관리 - 해시 맵: 플레이어가 이동할 때 (청크의 X 좌표, 청크의 Z 좌표)를 해시 키(Key)로 삼아, 수만 개의 청크 중 내가 원하는 청크를 $O(1)$의 속도로 즉시 찾고 버립니다. (월드 스트리밍에 최적화)
미시적(Micro) 관리 - 1차원 연속 배열: 청크를 열어보면 그 안에는 해시 맵이 아니라, $16 \times 16 \times 16$ 단위로 쪼개진 순수한 연속 배열(Dense Array)이 들어있습니다.

결과적으로 청크 덩어리를 찾을 때는 해시 맵으로 빛의 속도로 찾고, 렌더링을 위해 블록을 긁어올 때는 1차원 배열 덕분에 주변 블록들이 한 번에 CPU 캐시에 쏙 들어옵니다. (공간 지역성 완벽 방어)

이제 청크를 이용한 메모리 구조 내 공간 지역성을 방어하는 방법은 익혔는데 그렇다면 렌더링 차원에서는 어떨까요?

그리디 메싱(Greedy Meshing)이란 무엇인가?

그리디 메싱 알고리즘 설명

마인크래프트 같은 네모네모 복셀 게임에서 가장 멍청한 렌더링 방식은 "모든 블록의 6개 면을 다 그리는 것"입니다.

겉에서 보이지 않는 땅속 블록의 면까지 그리면 GPU가 터집니다. (이걸 막는 게 Face Culling)
Face Culling을 해서 겉에 보이는 면만 그린다고 쳐도, 평평한 벽돌 담장이 $10 \times 10$ 크기라면 $100$개의 작은 네모(200개의 트라이앵글)를 그려야 합니다.

그리디 메싱은 여기서 한 발 더 나아간 폴리곤 압축 알고리즘입니다.

핵심 원리: "어차피 똑같은 재질(예: 돌 블록)의 면이 평평하게 이어져 있다면, 자잘한 네모 100개로 나누지 말고 거대한 네모 1개로 합쳐서(Merge) 그리자!"
결과: $10 \times 10$ 담장을 그릴 때 200개였던 트라이앵글이, 단 2개의 트라이앵글로 압축됩니다. 렌더링 부하가 기하급수적으로 줄어듭니다.

청크(Chunk)와 그리디 메싱의 완벽한 시너지

그렇다면 이 그리디 메싱 알고리즘은 왜 반드시 '청크'라는 단위 위에서 돌아가야만 할까요?

① 무한한 세계를 묶어주는 "작업의 한계선"

그리디 메싱은 주변 블록들을 탐색하며 "너 나랑 같은 블록이야? 그럼 합치자!"를 반복하는 알고리즘입니다. 만약 청크라는 구역(Boundary)이 없다면, 평평한 바다가 끝없이 펼쳐져 있을 때 알고리즘은 멈추지 못하고 무한히 탐색을 계속하다가 메모리 한계로 뻗어버릴 것입니다.

청크의 역할: 그리디 메싱에게 "딱 이 $16 \times 384 \times 16$ 공간 안에서만 합치기 작업을 수행해!"라는 물리적인 제한 구역(Scope)을 제공합니다.

② 비동기 멀티스레딩 (Asynchronous Multithreading)

마인크래프트에서 플레이어가 맵을 돌아다니면 새로운 지형이 계속 생성됩니다. 이때 메쉬를 굽는(Bake) 과정은 CPU 연산을 꽤 많이 먹습니다.

청크의 역할: 맵이 청크 단위로 썰려 있기 때문에, "A 청크는 1번 스레드에서 그리디 메싱해!", "B 청크는 2번 스레드에서 메싱해!" 하고 병렬 처리(Multi-threading)를 던져주기가 완벽하게 좋습니다. 메인 스레드(프레임)를 멈추지 않고 백그라운드에서 메쉬를 조립할 수 있는 비결입니다.

③ 부분 업데이트의 효율성

크리퍼가 터져서 블록 하나가 부서졌다고 상상해 봅시다.

SVO처럼 전체 월드가 묶여있다면 월드 전체의 그리디 메싱을 다시 계산해야 할 수도 있습니다.
하지만 청크가 있다면? "해당 블록이 속한 단 1개의 청크 메쉬만 파기하고, 그 청크만 그리디 메싱을 다시 돌려서 GPU에 새로 올려주면" 끝입니다.

주의사항 : 두 개념이 만났을 때 발생하는 유일한 타협점 (Trade-off)

청크 기반 그리디 메싱에는 아주 미세한 단점이 하나 있습니다. 바로 '청크 경계선(Chunk Boundary)'입니다.

A 청크와 B 청크가 맞닿아 있는 평평한 초원이 있다고 칩시다.
시각적으로는 완벽하게 이어져 보이지만, 알고리즘은 A 청크와 B 청크를 따로 계산합니다.
따라서 A 청크 끝에서 메쉬 합치기가 한 번 끊어지고, B 청크 시작에서 새로운 메쉬가 생깁니다. 즉, 청크와 청크가 만나는 경계선에서는 폴리곤이 완벽하게 하나로 합쳐지지 않고 쪼개지는 현상이 발생합니다.
하지만 이 정도의 폴리곤 낭비는 청크 시스템이 주는 막대한 성능적 이점에 비하면 아주 사소한 비용(Trade-off)으로 치부됩니다.

청크슬라이싱

그리디 메싱 알고리즘의 이해

1. 그리디 메싱의 시각적 알고리즘

먼저 그리디 메싱이 청크(Chunk)의 단면을 어떻게 묶어내는지 시각적으로 이해해 봅시다.

탐색 시작: 좌표 0부터 시작하여 블록의 타입(예: 잔디)을 확인합니다.
수직 확장 (Y축): 바로 위 블록이 같은 '잔디' 타입이라면 쿼드(Quad)의 높이를 키웁니다. 공기(Air) 블록이나 다른 타입의 블록을 만날 때까지 수직으로 계속 확장합니다.
수평 확장 (X축): 수직 확장이 끝난 묶음을 통째로 옆 열(Row)과 비교합니다. 옆 열의 블록들도 방금 묶은 블록들과 타입이 완벽히 일치한다면 가로로 확장합니다.
데이터 초기화: 이미 쿼드로 묶인 블록들은 다음 탐색에서 중복 처리되지 않도록 메모리에서 지워줍니다.

이 직관적인 로직의 가장 큰 문제는 "루프(Loop)를 너무 많이 돈다"는 것입니다. 매번 배열의 인덱스를 찾아가 데이터를 비교하는 과정은 CPU를 병목에 빠지게 합니다.

2. 패러다임의 전환: 32비트 정수(Integer)와 1차원 배열

속도를 높이기 위해 3차원 배열에 모든 블록 ID를 쑤셔 넣는 방식을 버려야 합니다.

블록 타입별 평면 분리: 잔디 평면, 흙 평면 등 블록 타입별로 데이터를 완전히 분리합니다.
바이너리(Binary) 변환: 이제 특정 위치에 잔디가 있으면 True(1), 없으면 False(0)로 표현할 수 있습니다.
비트 패킹(Bit Packing): Boolean 값 32개는 단 하나의 32비트 정수(32-bit Integer)에 들어갑니다!

이렇게 하면 2차원 평면 데이터가 순수한 1차원 배열로 평탄화되며, 각 요소(정수 하나)가 32개의 복셀(한 줄)의 정보를 온전히 품게 됩니다.

3. 비트 연산(Bitwise Manipulations)의 마법

데이터가 32비트 정수로 변환되었으므로, 복잡한 반복문 대신 단일 CPU 명령어(Instruction)로 그리디 메싱을 처리할 수 있습니다.

높이 구하기: CPU가 지원하는 Trailing Zero Bits(끝에서부터 연속된 0의 개수)를 세는 하드웨어 연산을 통해 첫 번째 블록의 Y 위치를 단숨에 찾아냅니다.
수평 비교: 마스크(Mask)를 생성하여 옆 열의 32비트 정수와 AND 연산 등으로 비교하면, 수직으로 쌓인 블록들이 모두 일치하는지를 루프 없이 단 한 번의 연산으로 판별할 수 있습니다.

이 비트 연산 기반의 탐색은 눈 깜짝할 사이에 끝나버릴 정도로 압도적으로 빠릅니다.

4. 가장 무거운 짐 덜어내기: 페이스 컬링(Face Culling) 최적화

그리디 메싱의 근본적인 지연 원인은 겉으로 드러난 면(Face)을 찾기 위해 이웃한 복셀을 끝없이 샘플링하는 과정이었습니다 (초기 버전에서는 청크 하나당 110만 번 샘플링 발생).

이를 해결하기 위해, 같은 축(Axis) 선상에 있는 블록들의 충돌 여부를 비트 시프트(Bit Shift)로 계산합니다.

32개의 복셀 데이터를 담은 정수(Column)를 복사합니다.
이 복사본을 왼쪽이나 오른쪽으로 1비트 시프트(Shift) 합니다 (이웃 블록과의 위치를 맞추는 과정).
시프트 된 비트들을 반전(Flip) 시킵니다 (빈 공간을 1로, 채워진 공간을 0으로).
마지막으로 원본 정수와 조작된 정수를 AND 연산 합니다.

이 간단한 비트 조작만 거치면, "오직 공기와 맞닿아 있는 겉면(Exposed Faces)"의 위치만이 1(True)로 남게 됩니다. 무거운 루프 검사 없이 단 4줄의 연산으로 컬링이 끝나는 것입니다.

1 = 블록 있음 (Solid)
0 = 블록 없음 (Air)

Step 1. 원본 데이터 (Original)

Plaintext

(위) [0] [1] [1] [0] [1] [0] (아래)

우리가 찾아야 할 정답은 어디일까요? 블록(1)의 바로 위(오른쪽)에 공기(0)가 있는 곳입니다. 즉, 맨 오른쪽의 [1]과 왼쪽 덩어리의 끝인 [1]이 겉면이 됩니다.

Step 2. 시프트 연산 (Shift)

데이터를 통째로 오른쪽(아래)으로 한 칸 밀어버립니다. (블록들의 위치를 한 칸 이동시켜서 바로 옆 칸과 비교하기 위한 준비 단계입니다.)

Plaintext

원본:   [0] [1] [1] [0] [1] [0]
시프트: [0] [0] [1] [1] [0] [1]  <-- 모든 값이 오른쪽으로 한 칸 밀림

Step 3. 비트 반전 (Flip)

방금 밀어버린 시프트 데이터의 0과 1을 완전히 뒤집어 버립니다. (~ 연산)

Plaintext

시프트: [0] [0] [1] [1] [0] [1]
반전:   [1] [1] [0] [0] [1] [0]

이 반전된 데이터의 의미는 무엇일까요? 바로 "원래 블록이 있던 자리의 바로 윗칸(오른쪽 칸)이 공기(Air)인가?"를 나타내는 지도(Mask)가 된 것입니다.

Step 4. AND 연산 (최종 결합)

이제 [Step 1의 원본]과 [Step 3의 반전 데이터]를 AND 연산(둘 다 1일 때만 1)으로 겹쳐봅니다.

Plaintext

원본:     [0]  [1]  [1]  [0]  [1]  [0]  (나는 블록인가?)
반전:   & [1]  [1]  [0]  [0]  [1]  [0]  (내 윗칸은 공기인가?)
--------------------------------------
결과:     [0]  [1]  [0]  [0]  [1]  [0]  (나는 윗칸이 공기인 블록이다!)

청크 슬라이싱의 이해

See the Pen Chunk Slicing by SungmMin Jeon (@SungmMin-Jeon) on CodePen.

청크 슬라이싱의 4단계 원리

$32 \times 32 \times 32$ 크기의 큐브 모양 청크가 있다고 상상해 봅시다.

탄탄의 알고리즘은 이 거대한 3D 덩어리를 한 번에 메싱하려고 덤벼들지 않습니다. 철저하게 "분할 정복(Divide and Conquer)'을 시도합니다.

Step 1. 6개의 방향 분리 (Separating Directions)

모든 복셀 큐브는 6개의 면(위, 아래, 왼쪽, 오른쪽, 앞, 뒤)을 가집니다.

알고리즘은 이 6개의 방향을 완전히 독립적인 작업으로 분리합니다. 예를 들어, "지금부터는 '위를 바라보는 면(Up Faces)'만 만들 거야!"라고 타겟을 하나만 정하는 것입니다.

Step 2. 축을 따라 얇게 썰기 (Slicing the Axis)

'위를 바라보는 면'을 찾으려면 Y축(위아래 축)을 탐색해야 합니다.

알고리즘은 $32 \times 32 \times 32$ 청크를 Y축을 따라 32장의 아주 얇은 도마 위 슬라이스(2D 평면)로 썰어버립니다.

마치 식빵을 32장으로 얇게 써는 것과 똑같습니다. 이제 한 장의 슬라이스는 $32 \times 32$ 크기의 완벽한 2D 평면이 되었습니다.

Step 3. 2D 평면에서의 비트 마법 (Apply 2D Greedy Meshing)

이제 준비가 끝났습니다! 방금 썰어낸 얇은 2D 슬라이스 한 장을 도마 위에 올립니다.

이 평면 위에서 앞서 우리가 배운 '비트 연산(Trailing Zeros)을 이용한 O(1) 쿼드 압축' 마법을 시전합니다. 3D를 신경 쓸 필요 없이 오직 이 2D 평면 안에서만 사각형을 넓게 묶어냅니다.

Step 4. 반복 및 결합 (Iterate and Combine)

도마 위의 슬라이스 메싱이 끝나면, 다음 슬라이스를 올려서 똑같이 작업합니다.

Y축 32장 슬라이스 완료 (위를 바라보는 면 끝!)
방향을 바꿔 X축(오른쪽 면) 32장 슬라이스 반복
Z축(앞쪽 면) 32장 슬라이스 반복...
이렇게 6개 방향 $\times$ 32장 = 총 192장의 2D 슬라이스를 각각 처리한 뒤, 만들어진 폴리곤(Mesh) 조각들을 하나로 합치면 완벽한 3D 청크 메쉬가 탄생합니다.

왜 이렇게까지 썰어내는 걸까? (슬라이싱의 위력)

"그냥 3D 상태에서 뭉치면 안 되나? 왜 굳이 192장으로 썰어내는 고생을 하지?"라는 의문이 드실 수 있습니다. 여기에는 하드웨어 아키텍처를 고려한 엄청난 이점이 숨어 있습니다.

복잡도 붕괴 (3D $\rightarrow$ 2D)
3D 공간에서 부피를 가진 큐브들을 병합하는 알고리즘은 극도로 복잡하고 버그가 생기기 쉽습니다. 하지만 슬라이싱을 통해 문제를 2D 평면의 직사각형 묶기로 격하시키면, 알고리즘이 무서울 정도로 단순해지고 비트 연산이라는 궁극의 무기를 쓸 수 있게 됩니다.
캐시 친화성 (Cache Friendly)
메모리는 기본적으로 1차원 선형 구조입니다. 3D 공간을 이리저리 점프하며 탐색하면 메모리 캐시 미스(Cache Miss)가 터집니다. 하지만 하나의 축을 고정하고 2D 슬라이스 단위로 평면을 훑으면, 메모리를 아주 예쁘게 순차적으로 읽어 들일 수 있어 CPU가 최대의 속도를 낼 수 있습니다.
독립적인 병렬 처리
각각의 슬라이스는 다른 슬라이스의 결과에 영향을 받지 않습니다. 즉, 1번 슬라이스와 2번 슬라이스를 서로 다른 스레드(Thread)에 던져서 동시에 메싱하게 만드는 멀티스레딩 최적화가 매우 용이해집니다.

https://techartnomad.tistory.com/594
[Greedy Meshing(그리디 메싱) 이론, 처리 구조, 활용 이유 및 Voxel Chunk(복셀 청크)
2001년 쯤인가.. 삼성종합기술원에서 연구원으로 있을 때 복셀렌더링용 플러그인 개발에 참여 해 보고는 너무나 오랫만이라 트렌드 따라가기 위해 메모 해 놓는 중이다.– Unity Engine 6 기반 최신 V

복셀 렌더링 자료 조사
- 복셀라이징
https://indievisuallab.github.io/
[IndieVisualLab
Indie Visual Lab Indie Visual LabはリアルタイムCGプログラミングについての技術資料を作成・公開したり、その技術に基づくコンテンツ開発を行っているサークルです。
indievisuallab.github.io](https://indievisuallab.github.io/)
https://github.com/IndieVisualLab/UnityGraphicsProgrammingSeries/
https://github.com/IndieVisualLab/UnityGraphicsProgramming2/tree/master/Assets/RealTimeGPUBasedVoxelizer
[UnityGraphicsProgramming2/Assets/RealTimeGPUBasedVoxelizer at master · IndieVisualLab/UnityGraphicsProgramming2
書籍「UnityGraphicsProgramming vol.2」のサンプルコードリポジトリ. Contribute to IndieVisualLab/UnityGraphicsProgramming2 development by creating an account on GitHub.
github.com](https://github.com/IndieVisualLab/UnityGraphicsProgramming2/tree/master/Assets/RealTimeGPUBasedVoxelizer)
- 마칭큐브
https://pichachu.tistory.com/33
https://xoft.tistory.com/47

[Graphics] 복셀 렌더링 - 2 <언리얼 SVT>

LazySonic — Thu, 5 Mar 2026 01:34:50 +0900

기존 포스팅 내용 요약

[Graphics] 복셀 렌더링 - 1 <복셀과 자료구조>

본격적인 이야기에 앞서, 지난 포스트에서 다루었던 '복셀(Voxel) 데이터를 메모리에 욱여넣는 방법'을 짧게 되짚어 보겠습니다. 거대한 3D 공간에서 텅 빈 공간(Empty Space)을 쳐내기 위해 우리는 다음과 같은 트리 기반의 자료구조들을 살펴봤습니다.

SVO (Sparse Voxel Octree): 공간을 8등분하며 파고드는 직관적인 구조. 동적 업데이트와 LOD에 유리하지만, 노드를 찾기 위해 메모리 주소를 계속 추적해야 하는 '포인터 체이싱(Pointer Chasing)' 때문에 GPU가 제 속도를 내지 못하는 치명적인 단점이 있었습니다.
SVDAG (Sparse Voxel Directed Acyclic Graph): SVO에서 더 나아가, 똑같이 생긴 덩어리(중복 데이터)들마저 하나로 병합해 버리는 극한의 메모리 압축 기술입니다.
NanoVDB: GPU가 가장 싫어하는 '포인터'를 아예 없애버린 혁명적인 구조. 트리의 논리적 형태는 유지하되, 물리적으로는 거대한 1차원 배열(Flat Array)에 데이터를 빽빽하게 세워두고 '비트 연산'과 '점프(Offset)'만으로 데이터를 빛의 속도로 읽어냅니다. (구름, 연기 등 정적인 데이터 읽기에 적합)

그렇다면 NanoVDB가 게임 엔진의 최종 정답일까?

지난 포스트의 마지막에서 우리는 한 가지 의문을 던졌습니다. "블록이 실시간으로 박살 나는 마인크래프트는 SVO를 쓸까? 언리얼 엔진은 NanoVDB를 그대로 쓸까?"

정답은 "아니오"입니다.

NanoVDB는 완벽에 가까운 구조지만, '게임 엔진(실시간 렌더링)'이라는 가혹한 환경에서는 역부족이었습니다.

이에 이번 포스트에서는 다음 두 가지 새로운 패러다임을 이야기하고자 합니다.

언리얼 엔진의 SVT (Sparse Volume Texture): NanoVDB는 데이터를 읽어올 때 부드러운 혼합(보간)을 위해 셰이더 연산(ALU)을 너무 많이 씁니다. 언리얼 엔진은 GPU에 공짜로 탑재된 '텍스처 하드웨어 필터링'을 써먹기 위해, 1차원 배열을 억지로 3D 텍스처 형태로 비틀어버렸습니다.
마인크래프트의 Spatial Hash Map (공간 해시 맵): 곡괭이질 한 번에 지형이 무너지는 환경에서는 트리를 타고 내려갈 시간조차 아깝습니다. 트리를 아예 부숴버리고, 좌표를 부르면 즉시 데이터가 튀어나오는 $O(1)$의 마법, 공간 해싱을 선택했습니다.

언리얼 엔진의 SVT (Sparse Volume Texture)

언리얼 SVT 공식문서

지난 포스트에서 우리는 NanoVDB가 포인터를 없애고 1차원 배열(Linear Buffer)을 통해 극강의 탐색 속도를 이끌어낸 과정을 보았습니다. 그렇다면 언리얼 엔진 5의 나이아가라(Niagara) 유체 시뮬레이션이나 Heterogeneous Volumes는 NanoVDB를 그대로 사용할까요? 정답은 아래와 같습니다.

"데이터를 들고 올 때는 VDB를 쓰지만, GPU로 렌더링할 때는 SVT(Sparse Volume Texture) 사용"

완벽해 보이는 NanoVDB를 굳이 다른 형태로 변환하는 이유, 그것은 바로 GPU 하드웨어의 구조적 특징 때문입니다.

1. NanoVDB의 뼈아픈 약점: 소프트웨어 보간과 ALU 병목

구름이나 연기 같은 볼류메트릭 데이터를 렌더링할 때, 마인크래프트처럼 각지게 보이지 않으려면 복셀과 복셀 사이의 중간 밀도값을 아주 부드럽게 섞어주어야 합니다. 이를 삼선형 보간(Trilinear Interpolation)이라고 합니다.

* 쌍선형 보간은 2차원 평면 상에서 한 점의 위치를 보간을 통해 구하기 위해 사용하는 방법으로

흔히 우리가 사용하는 1차원 보간인 Lerp를 X축으로 두번, Y축으로 한 번 (반대로 Y축 2번 X축 1번이어도 됩니다.) 수행하여 구할 수 있습니다.

위키백과 쌍선형 보간 참조

* 삼선형 보간은 이런 보간 방식을 3차원상에서 수행하는 것을 의미합니다.

위키백과 삼선형보간 참조

NanoVDB의 딜레마: NanoVDB는 근본적으로 1차원 버퍼입니다. 따라서 셰이더에서 임의의 위치에 있는 부드러운 값을 얻으려면, 주변 8개의 복셀 데이터를 버퍼에서 직접 찾아 읽어온 뒤, 셰이더 코드 안에서 복잡한 수학 공식으로 직접 섞어주어야 합니다.
화면의 수백만 픽셀마다 레이(Ray)를 쏘며 매 스텝 이 무거운 연산을 반복한다면? GPU의 연산 유닛(ALU)이 비명을 지르며 프레임이 곤두박질치게 됩니다.

2. SVT의 핵심: 가상 메모리(Virtual Memory)의 3D화

Page Table과 Physical 3D Tiles

그래픽스 프로그래머들은 생각했습니다.

"GPU 안에는 텍스처를 기가 막히게 섞어주는 전용 하드웨어인 TMU(Texture Mapping Unit)가 놀고 있잖아? 데이터를 무식하게 버퍼에 넣지 말고, 3D 텍스처에 구겨 넣으면 TMU가 공짜로 보간을 해주지 않을까?"_

이 발상에서 탄생한 것이 SVT입니다. 언리얼 엔진은 5.3 버전부터 SVT 개념을 도입했으며(https://www.youtube.com/watch?v=QtJzitZweWM), SVT는 컴퓨터 운영체제의 '가상 메모리 페이징' 기법을 3D 그래픽스에 그대로 이식한 구조로, 두 개의 거대한 3D 텍스처로 이루어집니다.

Page Table Texture (가상 주소록):
전체 월드 공간을 덮고 있는 저해상도 3D 텍스처입니다.
- 실제 밀도 데이터가 아니라, "진짜 데이터가 있는 물리적 주소(인덱스)"만 적혀 있습니다.
- 텅 빈 공기(Empty Space)라면 이곳에 0이 적혀 있습니다.
Physical Texture Atlas (물리 데이터 창고):
빈 공간은 싹 쳐내고, 실제 데이터가 존재하는 $8 \times 8 \times 8$ 크기의 '페이지(Page)'들만 테트리스처럼 빽빽하게 모아둔 거대한 고해상도 3D 텍스처입니다. (기존 VDB의 Leaf Data에 해당)

이 이원화된 구조 덕분에 빈 공간의 메모리 낭비는 완벽하게 제거(NanoVDB의 장점)하면서도, 최종 데이터는 3D 텍스처 형태에 보관(TMU 활용 가능) 할 수 있게 되었습니다.

특징	OS 가상 메모리 페이징	언리얼 SVT
가상공간	Virtual Memory (연속된 거대한 주소 공간)	렌더링할 구름의 전체 3D Bounding Box
매핑 테이블	Page Table (가상 $\rightarrow$ 물리 주소록)	Page Table Texture (저해상도 3D 주소록 텍스처)
물리 공간	Physical RAM (파편화된 실제 메모리 조각, Frames)	Physical Texture Atlas (데이터가 꽉 찬 타일들의 모음)
블록 단위	보통 4KB 단위의 Page/Frame	보통 $8 \times 8 \times 8$ 단위의 Voxel Brick (타일)
빈 공간 처리	페이지 테이블에 '할당 안 됨(Null)' 표시	Page Table Texture에 0 기록 (Empty Space Skipping)
데이터 스트리밍	디스크(SSD)에서 RAM으로 Swap In	디스크/CPU에서 VRAM 물리 텍스처로 Tile Streaming

3. 실무에서 SVT 제작 및 임포트하는 방법

언리얼 VDB 파이프라인 기초

4. 실무 구현의 최대 난제: 경계면 아티팩트와 패딩(Padding)

이론은 완벽하지만, SVT를 실제 엔진에 구현할 때 그래픽스 엔지니어들의 뒤통수를 치는 엄청난 문제가 하나 발생합니다. 바로 경계면 필터링(Boundary Filtering) 문제입니다.

Physical Texture 안에는 서로 다른 공간에서 온 $8 \times 8 \times 8$ 페이지들이 순서 없이 다닥다닥 붙어있습니다. 만약 하드웨어 텍스처 유닛(TMU)이 '페이지의 끝자락(경계면)'에 있는 복셀을 삼선형 보간하려고 하면 어떤 일이 벌어질까요?

전혀 상관없는 옆 페이지의 데이터까지 스며들어와 같이 섞여버립니다(Bleeding). 결과적으로 렌더링 된 구름 표면에 끔찍한 격자무늬(Artifact)가 생겨버리죠. (텍스쳐 아틀라스에서도 쉽게 겪는 이슈입니다.)

언리얼 엔진의 해결책: 1-Voxel Padding

이 문제를 해결하기 위해 언리얼 엔진의 SVT는 물리 텍스처에 데이터를 올릴 때 $8 \times 8 \times 8$ 원본 크기 그대로 저장하지 않습니다.

사방으로 1복셀씩 이웃 페이지의 데이터를 복사해 와서 덧붙인(Padding) $10 \times 10 \times 10$ 크기로 뻥튀기하여 저장합니다.

이렇게 여분의 보호막(Padding)을 둘러치면, TMU가 경계면에서 보간 연산을 하더라도 항상 올바른 이웃 복셀 데이터와 섞이게 되어 아티팩트가 완벽하게 사라진다고 설명합니다. (이로 인해 메모리를 약간 더 쓰게 되는 Trade-off를 감수하는 것입니다.)

하지만, 이는 전통적인 아틀라스 관리방법에서도 사용했던 솔루션이고 우리는 이에 상응하는 대가가 무엇인지 알고 있습니다.

1. 밉맵 블리딩 (Mipmap Bleeding): 하드웨어 밉맵의 사용 불가

2D 아틀라스에서 가장 아티팩트가 심하게 터지는 순간은, 카메라가 멀어져서 밉맵(Mipmap)이 작동할 때입니다. 해상도가 절반씩 줄어들다 보면 결국 패딩 공간마저 뭉개지면서 옆 텍스처의 색상이 스며들어옵니다(Bleeding).

SVT의 한계:
이 때문에 SVT의 Physical Texture는 GPU 하드웨어가 자동으로 만들어주는 밉맵 생성 기능(GenerateMips)을 절대 사용할 수 없습니다. 만약 3D 아틀라스를 그대로 축소해 버리면, 전혀 상관없는 5번 구역 연기와 100번 구역 구름이 섞여버리는 대참사가 일어납니다.
SVT의 해결책 (비용 증가):
언리얼 엔진은 이 블리딩을 막기 위해 각 밉맵 레벨(LOD)마다 별도의 SVT(Page Table + Physical Texture 세트)를 아예 새로 만듭니다. 즉, Mip 0용 아틀라스, Mip 1용 아틀라스, Mip 2용 아틀라스를 CPU나 Compute Shader에서 각각 따로 계산해서 메모리에 올려야 합니다. 유지보수와 메모리 관리 비용이 기하급수적으로 증가합니다.

2. 메모리 뻥튀기 (The Curse of Volume): 3D 패딩의 끔찍한 나비효과

2D 텍스처에서 1픽셀 패딩을 두르는 것은 전체 용량에 큰 타격을 주지 않습니다. 하지만 3D 공간인 복셀에서는 '부피(Volume)'의 저주가 시작됩니다.

$8 \times 8 \times 8$ 크기의 원본 데이터 블록은 512개의 복셀을 가집니다.
여기에 사방으로 1복셀씩만 패딩을 둘러도 $10 \times 10 \times 10$이 되어 1000개의 복셀이 됩니다.
결과: 고작 1복셀 두께의 경계면 아티팩트를 막겠다고, 메모리를 무려 95%나 더 쓰게 되는 미친 낭비가 발생합니다.

SVT의 해결책: 이 메모리 폭발을 줄이기 위해, 실제 상용 엔진에서는 블록(Page)의 기본 크기를 훨씬 크게 잡습니다. 예를 들어 $32 \times 32 \times 32$ (32,768 복셀)로 잡고 패딩을 둘러 $34 \times 34 \times 34$ (39,304 복셀)로 만들면, 오버헤드 비율을 약 20% 수준으로 억누를 수 있습니다. (대신 블록이 너무 커지면 빈 공간을 쳐내는 효율이 떨어지는 또 다른 딜레마에 빠집니다.)

3. 부동소수점 정밀도 한계 (Floating-Point Precision Seams)

패딩을 완벽하게 둘렀다고 해도 시각적 아티팩트가 생길 수 있습니다. 셰이더에서 레이마칭을 할 때, 3D 월드 좌표를 물리 텍스처(Physical Texture) 내부의 아주 미세한 UVW 좌표로 변환하는 수학적 계산을 거칩니다.

문제점: GPU의 float 부동소수점 연산은 소수점 아래로 내려갈수록 미세한 오차가 발생합니다. 이 오차 때문에 텍스처 샘플러가 우리가 의도한 '안전한 1복셀 패딩 구역'을 아주 미세하게(0.0001 픽셀만큼) 벗어나서 샘플링하게 되면, 구름이나 연기 표면에 아주 얇고 날카로운 경계선 틈새(Seam)가 깜빡거리며 보이게 됩니다.
해결책: 셰이더 프로그래머들은 이 아티팩트를 없애기 위해 UVW 좌표가 절대 패딩 바깥으로 넘어가지 않도록, 수식 끝에 미세한 오프셋을 더하고 빼거나 clamp() 함수를 걸어주는 등 피눈물 나는 예외 처리 코드를 추가해야 합니다.

5. 셰이더(HLSL) 레벨의 SVT 샘플링 (수도 코드)

실제 언리얼 엔진 내부의 셰이더 코드가 레이마칭을 수행할 때, SVT를 어떻게 읽어오는지 그 논리적 흐름을 단순화한 수도 코드(Pseudo Code)입니다.

// SVT 텍스처 자원들
Texture3D<uint> PageTableTex;         // 주소록 (가상 공간)
Texture3D<float> PhysicalTex;         // 실제 데이터 (물리 공간 아틀라스)
SamplerState TrilinearSampler;        // 하드웨어 보간 샘플러

float SampleSVT(float3 WorldPos)
{
    // 1. 월드 좌표를 Page Table의 3D 가상 UVW 좌표 [0~1]로 변환
    float3 VirtualUVW = WorldToVirtualUVW(WorldPos);

    // 2. 주소록(Page Table) 읽기: 현재 좌표가 속한 페이지의 물리적 주소를 가져옴
    // (Point 샘플링: 섞이지 않은 정확한 정수 인덱스만 획득)
    uint PhysicalPageIndex = PageTableTex.Load(PointSampler, int(floor(VirtualUVW)), 0);

    // 3. 빈 공간(Empty Space) 스킵 로직
    // 주소가 0이면 텅 빈 공기! 무거운 연산 즉시 종료. (NanoVDB의 Bitmask 역할)
    if (PhysicalPageIndex == 0)
    {
        return 0.0f; 
    }

    // 4. 가상 좌표 안에서 나의 디테일한 위치(Local UVW) 및 패딩(Padding) 보정 계산
    float3 PhysicalUVW = ConvertToPhysicalUVW(PhysicalPageIndex, VirtualUVW);

    // 5. 하드웨어 삼선형 보간의 마법!
    // GPU의 TMU가 알아서 8개 복셀을 부드럽게 섞어 반환함. (ALU 연산 거의 제로)
    return PhysicalTex.SampleLevel(TrilinearSampler, PhysicalUVW, 0);
}

텍스처를 두 번 읽는 것(Indirection)은 GPU 입장에서 부담일 수 있습니다.
하지만 코드의 3번 단계를 보세요. PhysicalPageIndex == 0일 경우 두 번째 텍스처 읽기(PhysicalTex 샘플링)를 아예 생략해 버립니다. 구름이 없는 90%의 허공을 렌더링할 때 엄청난 연산 스킵이 발생하므로 전체적인 성능은 압도적으로 유리해집니다.

아래는 이제 실제 언리얼 엔진 내 구현 사용부입니다.
(SparseVolumeTextureCommon.ush)

// PageTable에서부터 Voxel의 UVW 좌표값을 가져오는 과정입니다.
float3 SparseVolumeTextureGetVoxelCoord(Texture3D<uint> PageTable, FSparseVolumeTextureUniforms Uniforms, float3 PageTableCoord, int MipLevel)
{
    // Load from page table texture
    // 아래 보면 PageTable (가상 테이블)로부터 주소값을 가져올 때는 MipLevel을 사용하는 것을 알 수 있습니다.
    const uint PackedPhysicalTileCoord = PageTable.Load(int4(floor(PageTableCoord), MipLevel)).x;
    const int3 PhysicalTileCoord = int3(PackedPhysicalTileCoord & 0xFFu, (PackedPhysicalTileCoord >> 8u) & 0xFFu, (PackedPhysicalTileCoord >> 16u) & 0xFFu);
    const uint TileMipLevel = PackedPhysicalTileCoord >> 24u;

    // Scale TileCoord by 1 / exp2(ActualMipLevel - DesiredMipLevel) to get correct UVs when sampling from a higher mip as fallback
    const float TileRcpMipLevelFactor = rcp(float(1u << (TileMipLevel - uint(MipLevel))));
    const float3 FracTileCoord = frac(PageTableCoord * TileRcpMipLevelFactor);

    const float3 VoxelCoord = float3(PhysicalTileCoord) * float(SPARSE_VOLUME_TILE_RES_PADDED) + (FracTileCoord * float(SPARSE_VOLUME_TILE_RES) + float(SPARSE_VOLUME_TILE_BORDER));
    return VoxelCoord;
}

float3 SparseVolumeTextureSamplePageTable(Texture3D<uint> PageTable, FSparseVolumeTextureUniforms Uniforms, float3 UVW, uint AddressU, uint AddressV, uint AddressW, int MipLevel = 0)
{
    // Apply address mode to UVW and clamp mip level to resident levels
    UVW = SparseVolumeTextureApplyAddressMode(UVW, AddressU, AddressV, AddressW);
    MipLevel = clamp(MipLevel, 0, Uniforms.HighestMipLevel);

    const float RcpMipLevelFactor = rcp(float(1u << (uint)MipLevel));
    const float3 VolumePageCoord = UVW * Uniforms.VolumePageResolution;
    const float3 MipPageTableOffset = floor(Uniforms.PageTableOffset * RcpMipLevelFactor);
    const float3 PageTableCoord = VolumePageCoord * RcpMipLevelFactor - MipPageTableOffset;

    const float3 VoxelCoord = SparseVolumeTextureGetVoxelCoord(PageTable, Uniforms, PageTableCoord, MipLevel);
    const float3 VoxelUVW = VoxelCoord * Uniforms.TileDataTexelSize;
    return VoxelUVW;
}

// 위에서 얻은 UVW를 아래 PhysicalTileData 샘플링 함수에 사용함으로써 실제 저장된 값을 가져올 수 있습니다.
float4 SparseVolumeTextureSamplePhysicalTileData(Texture3D PhysicalTileDataA, Texture3D PhysicalTileDataB, SamplerState TileDataSampler, float3 VoxelUVW, int PhysicalTileDataIndex)
{
    // SampleLevel을 할 때 보면 Mip Bleeding을 해소하기 위해 MipLevel을 0.0f로 고정하고 있는 것을 알 수 있습니다.
    switch (PhysicalTileDataIndex)
    {
    case 0: return PhysicalTileDataA.SampleLevel(TileDataSampler, VoxelUVW, 0.0f);
    case 1: return PhysicalTileDataB.SampleLevel(TileDataSampler, VoxelUVW, 0.0f);
    default: return 0.0f;
    }
}

경계면 패딩(Padding)
이전에 "패딩 때문에 메모리 낭비가 있을 것이다."라고 했습니다. 이에 엔진에서는 아래와 같이 로직을 명시하고 있습니다.

// UE 코드 내부 (SparseVolumeTextureCommon.ush Line 8) 
#define SPARSE_VOLUME_TILE_RES 16 // 순수 데이터 타일 크기 (예: 16)
#define SPARSE_VOLUME_TILE_RES_PADDED (SPARSE_VOLUME_TILE_RES + 2 * SPARSE_VOLUME_TILE_BORDER) // 패딩이 포함된 타일 크기
#define SPARSE_VOLUME_TILE_BORDER 1 // 경계면 패딩 두께 (예: 1)

수학적 계산: 물리적 타일 시작 위치(Padded 기준) + (타일 내 비율 * 순수 해상도) + 테두리 두께(Border)
이 수식이 바로, 하드웨어 삼선형 보간(Trilinear Interpolation) 시 블리딩(Bleeding) 아티팩트를 막기 위해 1복셀씩 안쪽으로 밀어 넣어서 샘플링하는 정확한 오프셋 계산입니다. 우리가 논의했던 이론이 코드 한 줄로 완벽히 구현되어 있습니다.

Page Table의 비트 패킹 (데이터 압축)
수도 코드에서는 단순히 uint PhysicalPageIndex 하나만 가져온다고 쳤지만, 언리얼은 32비트 정수 하나(PackedPhysicalTileCoord)에 4가지 정보를 욱여넣었습니다.

// 32비트를 8비트씩 쪼개서 X, Y, Z, MipLevel을 추출함 int3 PhysicalTileCoord = int3(PackedPhysicalTileCoord & 0xFFu, (PackedPhysicalTileCoord >> 8u) & 0xFFu, (PackedPhysicalTileCoord >> 16u) & 0xFFu); uint TileMipLevel = PackedPhysicalTileCoord >> 24u;

물리적 텍스처(Physical Texture)가 1차원 배열이 아니라 3D 텍스처이기 때문에, 1D 인덱스가 아닌 3D 타일 좌표 $(X, Y, Z)$가 필요합니다. 이를 8비트씩 잘라서 쓰고, 남은 상위 8비트는 해당 타일의 밉맵(MipLevel) 정보를 담는 데 사용하여 메모리 대역폭을 극한으로 아꼈습니다.

분기문(if) 없는 Empty Space 처리 (Branchless Optimization)
수도 코드에서는 빈 공간을 만나면 렌더링을 멈추기 위해 if (Index == 0) return 0; 이라는 분기문을 넣었습니다. 하지만 언리얼 코드에는 if문이 보이지 않습니다. 왜 그럴까요?

언리얼의 꼼수 (Tile 0 예약)

GPU는 if문을 만날 때 성능이 저하될 수 있습니다(Warp Divergence). 언리얼은 이를 막기 위해, Physical Texture의 가장 첫 번째 타일(0, 0, 0 위치)을 '모든 값이 0(투명)으로 꽉 찬 블랙 타일'로 만들어 둡니다.

Page Table에서 빈 공간을 만나 PackedPhysicalTileCoord가 0이 나오면, if문으로 끊지 않고 그냥 0번 타일(투명한 블랙 타일)의 좌표를 계산해서 샘플링하게 둡니다. 결과적으로 투명한 값이 반환되므로 시각적 결과는 같으면서 GPU 파이프라인이 멈추지 않게(Branchless) 최적화한 것입니다.

하드웨어 삼선형 보간 (Trilinear Filter)
이 부분이 우리가 NanoVDB 대신 SVT를 쓰는 궁극적인 이유였죠.복잡한 수학 공식 하나 없이, SampleLevel 함수와 TileDataSampler (여기에 Trilinear 필터 세팅이 들어있음)를 호출하여 GPU 텍스처 유닛(TMU)에 보간을 완전히 떠넘겼습니다.

PhysicalTileDataA.SampleLevel(TileDataSampler, VoxelUVW, 0.0f);

밉맵 폴백 (Mipmap Fallback) 로직
언리얼 코드의 아주 특별한 부분입니다.

const float TileRcpMipLevelFactor = rcp(float(1u << (TileMipLevel - uint(MipLevel))));

이 폴백 함수를 디테일하게 살펴보면 아래와 같습니다.

// TileMipLevel(가진 것) = 2, MipLevel(원하는 것) = 0 이라고 가정해 봅시다.

// 1단계: 해상도 차이 계산 (비트 시프트)
(TileMipLevel - uint(MipLevel)) // 2 - 0 = 2 (2단계 차이남)

// 2단계: 크기 비율 계산 (2의 거듭제곱)
1u << 2 // 이것은 2^2 와 같습니다. 즉, 값이 '4'가 됩니다.
// (Mip 2 타일은 1D 축을 기준으로 Mip 0 타일보다 4배 더 넓은 공간을 포괄합니다)

// 3단계: 역수(Reciprocal) 취하기
rcp(4.0f) // 1.0f / 4.0f = 0.25f

언리얼 월드는 방대해서, 특정 구역의 고해상도(Mip 0) 데이터가 메모리에 아직 덜 로딩(Streaming)되었을 수 있습니다. 이때 코드가 터지지 않고, "원하는 밉맵이 없으면, 현재 메모리에 올라와 있는 더 낮은 해상도(TileMipLevel)의 데이터를 스케일링해서 일단 보여줘!"라는 강력한 예외 처리 로직이 들어있습니다.

원래 이 포스트를 통해 Spatial Hash Map에 대한 이야기까지 나눈 뒤 렌더링 쪽으로 넘어가고자 했으나, 생각보다 발표 시간이 촉박하여 다음 포스팅에서 이어 설명한 뒤 렌더링으로 이어갑니다.

[Graphics] 복셀 렌더링 - 1 <복셀과 자료구조>

LazySonic — Fri, 20 Feb 2026 21:03:15 +0900

연관 포스트

[Graphics] 복셀 렌더링 - 2 <언리얼 SVT와 Spatial Hash Map>

다각형(Polygon)의 껍데기를 넘어 속이 꽉 찬 세계로

1. 우리가 지금까지 보았던 '징후'들

그동안 그래픽스 스터디하면서 알게 모르게 계속 마주쳤던 녀석이 있습니다.

Ray Marching & SDF: 그냥 3D 모델을 띄우는 게 아니라, 수학적인 거리 함수로 공간을 탐색하며 그림자를 만들었죠.

https://iquilezles.org/articles/distfunctions/

https://www.shadertoy.com/view/XslGRr

Sphere Tracing: 부드러운 그림자(Soft Shadow)를 만들기 위해 공간을 '구(Sphere)' 단위로 듬성듬성, 하지만 효율적으로 건너뛰었습니다.

UE5 Lumen: 루멘이 빛을 계산할 때 "Mesh Distance Field"를 쓴다는 거 보셨던 기억이 있으실 겁니다. 메시를 있는 그대로 쓰는 게 아니라, '공간에 대한 정보'로 변환해서 처리했다는 뜻입니다.
- 언리얼 레이트레이싱과 루멘

언리얼 레이트레이싱과 루멘

이번 세션은 설명을 한번 쭉 읽고, 이어서 나오는 시그라프 문서를 그대로 읽으면 된다. 1회차와 2회차 게임을 하듯이 구성했다. 오픈월드 RT전통적인 레이트레이싱은 닫힌 방 안에서 디테일한

gamedevlab.tistory.com

사실 이 모든 건 "3D 공간을 어떻게 효율적으로 표현하고 계산할 것인가?" 라는 거대한 질문에 대한 답들이었습니다. 그리고 오늘 우리는 그 질문의 가장 직관적이고 강력한 대답 복셀(Voxel)에 대해 본격적으로 파헤쳐 보려 합니다.

2. 복셀(Voxel), 도대체 왜 다시 뜨는가?

픽셀 (Pixel): Picture (사진/그림) + Element (요소)
- 2D 평면 이미지를 구성하는 가장 작은 점입니다. 우리는 모니터라는 평면 도화지 위에 수많은 픽셀을 찍어서 그림을 봅니다.
복셀 (Voxel): Volume (부피/공간) + Element (요소) (또는 Volumetric Pixel)
- 3D 공간을 구성하는 가장 작은 단위입니다. 평면에 찍히는 '점'이 아니라, 공간을 차지하는 '정육면체(큐브)' 형태를 띱니다.
- 속이 꽉 차 있습니다. 부수면 부서진 단면이 바로 보이고, 쌓으면 지형이 됩니다.

과거에는 "복셀? 그거 마인크래프트 같은 네모네모 그래픽 아니야?"라고 했지만, 이제는 다릅니다. 하드웨어가 발전하고 Unreal Engine 5.7에서 Voxel Foliage 같은 기능이 정식으로 들어올 만큼, 복셀은 '리얼리스틱 그래픽'의 핵심 기술로 자리 잡고 있습니다.

3. 복셀과 메모리 폭발

복셀에는 치명적인 단점이 있습니다. 데이터가 너무 큽니다.

1024 X 1024 해상도의 2D 이미지는 1MB 정도지만, 1024 X 1024 X 1024 복셀은 수 GB가 넘어갑니다.

그래서 오늘 스터디 핵심은 "어떻게 이 큰 데이터를 압축하고, 빠르게 꺼내 쓸 것인가?"입니다.

아래는 오늘 이 이야기의 핵심이 되는 내용을 요약해놓은 것 입니다.

자료구조의 진화 (The Container):
3D 배열에서 시작해, 필요한 곳만 저장하는 SVO (Sparse Voxel Octree)
- 중복을 제거해 극도로 압축하는 SVDAG
- 영화(VFX)와 게임 양쪽에서 표준이 된 NanoVDB
- 그리고 O(1) 접근 속도를 노리는 Spatial Hash Map
렌더링과 알고리즘 (The Technique):
- 데이터가 비어있는지 아닌지 빠르게 확인하는 Ray Marching 전략.
- 각진 복셀을 부드러운 곡선으로 깎아내는 Marching Cubes와 Dual Contouring.
- LOD가 서로 다를 때 지형이 찢어지는 걸 막는 Transvoxel 개념.
실전 응용 (The Reality):
- 이 모든 이론이 집대성된 최신 기술, Unreal Engine 5.7의 Voxel Foliage가 도대체 어떤 원리로 돌아가는지.

자료구조의 진화

이제 복셀 렌더링의 핵심인 '방대한 3D 데이터를 메모리에 어떻게 효율적으로 담을 것인가'를 해결하기 위한 자료구조의 진화 과정을 살펴보겠습니다. 무식한 3D 배열(Dense Grid)에서 시작해, 현대 게임 엔진과 VFX에서 사용하는 최적화된 구조까지의 흐름입니다.

복셀 데이터의 가장 큰 특징은 희소성(Sparsity)입니다. 거대한 3D 월드에서 실제로 물체가 존재하는 공간(표면이나 내부)보다 텅 빈 공간(Empty Space)이 차지하는 비율이 압도적으로 높습니다. 따라서 '빈 공간은 저장하지 않고, 존재하는 데이터만 빠르게 찾는 희소성 탐색과 극대화'가 모든 자료구조의 핵심 목표입니다.

1. SVO (Sparse Voxel Octree)

가장 고전적이면서도 직관적인 희소 데이터 구조입니다. 3D 공간을 8개의 정육면체(Octants)로 분할하고, 데이터가 존재하는 공간만 계속해서 파고들어 가는 옥트리 구조입니다.

(Voxel Compression)

동작 원리: 루트(Root) 노드가 전체 공간을 포괄합니다. 공간을 8등분 했을 때 빈 공간인 자식 노드는 생성하지 않고 메모리 할당을 멈춥니다. 데이터가 있는 자식 노드만 다시 8등분하며 원하는 해상도에 도달할 때까지 분할 합니다.
특징 및 장점:
- 계층적 LOD (Level of Detail): 트리의 얕은 깊이(Depth) 노드를 읽으면 자연스럽게 낮은 해상도의 복셀 덩어리가 되므로, 거리에 따른 LOD 구현이 매우 쉽습니다.
- Empty Space Skipping: 레이마칭(Ray Marching) 시 큰 빈 공간 노드를 만나면 내부를 검사할 필요 없이 통째로 건너뛸 수 있어 탐색 효율이 높습니다.
깊이에 따른 수학적 탐사속도
- 수학적 시간 복잡도 : $O(logN) 또는 O(D)$
  특정 위치의 복셀을 찾거나 레이(Ray)를 쏠 때, 전체 공간 $N$을 뒤질 필요 없이 루트 노드에서부터 해당 위치가 포함된 자식 노드만 따라 내려가면 됩니다.
  즉, 최대 깊이 $D$만큼만 검사하면 돼, 수학적으로는 매우 훌륭하고 빠릅니다.
- GPU에서 실제 속도 : "포인터 체이싱(Pointer Chasing)의 지옥"
  GPU는 수천 개의 코어가 메모리에 있는 데이터를 한 번에 뭉텅이로 가져올 때(Coalesced Memory Access) 최고의 성능을 냅니다.
  그런데 SVO를 탐색하려면 다음 과정을 거쳐야 합니다.
  1. 부모 노드 메모리 읽기
  2. 어느 자식 노드로 갈지 계산 후, 자식 노드의 메모리 포인터 확인
  3. 자식 노드 메모리 읽기 (캐시 미스 발생 확률 높음)
  4. 다시 그 자식의 주소 확인...
  이렇게 앞의 결과를 알아야만 다음 데이터를 읽을 수 있는 종속적인 메모리 접근이 깊이 $D$만큼 반복됩니다.
  깊이가 10이라면, 최악의 경우 GPU가 연산은 안 하고 메모리를 가져오는 데만 10번을 쉬어야 합니다.
  수학적으로는 빠르지만, 물리적인 VRAM 접근 지연 때문에 프레임 드랍의 주범이 됩니다.
  (이후 설명할 NanoVDB가 트리를 얕고 넓게 만든 이유가 바로 이것입니다.)
한계점: 트리가 깊어질수록 자식 노드를 찾기 위한 포인터 체이싱(Pointer Chasing)이 심해져 GPU의 메모리 캐시 미스(Cache Miss)를 유발합니다.
- 실제 데이터보다 노드 간의 관계를 정의하는 포인터 메모리 오버헤드가 큽니다.
깊이 제한: 이론상으로는 무한히 파고들 수 있지만, 실시간 렌더링에서는 메모리와 GPU 구조의 한계 때문에 보통 최대 깊이를 10~12 레벨 정도로 제한합니다.
- SVO는 한 번 깊어질 때마다 해상도가 2배씩 늘어납니다.
- 해상도와 깊이의 관계:깊이 $D$일 때, 3D 그리드의 해상도는 $2^D \times 2^D \times 2^D$ 가 됩니다.
- 깊이 8 = 256 x 256 x 256
- 깊이 10 = 1024 x 1024 x 1024 (약 10억 개의 복셀 공간)
- 깊이 12 = 4096 x 4096 x 4096

만약 수 킬로미터 단위의 거대한 오픈 월드에서 1cm 크기의 정밀한 복셀을 표현하려고 SVO의 깊이를 계속 늘린다면 어떻게 될까요? 빈 공간을 아무리 잘라낸다 하더라도, 노드 자체를 가리키는 포인터 데이터만으로도 VRAM이 터져버립니다.

해결 전략 (Voxel Clipmap):그래서 넓은 월드에서는 단일 SVO 깊이를 무식하게 늘리지 않습니다. 카메라를 중심으로 가까운 곳은 깊이가 깊은(고해상도) SVO를, 먼 곳은 얕은(저해상도) SVO를 여럿 겹쳐서 사용하는 카스케이드(Cascade) 방식을 사용합니다.
섀도우 맵에서 쓰는 CSM(Cascaded Shadow Maps)과 같은 원리입니다.

Voxel Clipmap Nvidia VXGI 정보

SVO의 주요 응용 사례 (게임 및 그래픽스)
이러한 한계에도 불구하고 SVO가 가진 '공간의 계층적 분할'이라는 강력한 장점 때문에 여러 혁신적인 기술에 응용되었습니다.
- Voxel Cone Tracing (실시간 글로벌 일루미네이션):
  루멘(Lumen)이 등장하기 전, 에픽게임즈와 NVIDIA가 시도했던 차세대 GI 기술(VXGI)의 핵심입니다. 씬(Scene) 전체의 빛과 색상 정보를 SVO에 굽습니다. 그리고 화면의 픽셀에서 빛을 추적할 때 얇은 선(Ray)이 아니라 점점 퍼지는 원뿔(Cone) 형태를 쏩니다. 원뿔이 커지면서 SVO의 더 얕은 깊이(큰 노드, 즉 거칠게 블러링된 빛 정보)를 자연스럽게 읽어와 부드러운 반사광과 간접광을 만들어냅니다.
  해당 기술은 복잡하기에 더 간단한 예시를 위해 위 기술의 근간이 됐던 SSAO와 VXAO 기법을 비교해보겠습니다.
- 기존 SSAO의 방식이 위와 같이 Screen Pass에서 각 픽셀 위치에서 반구 형태의 Depth Test를 수행했다면,
  VXAO는 복셀 안에 지형이나 물체가 얼마나 빽빽하게 들어있는지, 즉 '불투명도(Opacity)' 지도만 만들어 둡니다.

이렇게 미리 구워놓는 덕분에 화면 밖의 데이터도 3D 복셀로 메모리에 올라가 있기 때문에, 카메라 뒤에 있는 거대한 바위가 드리우는 간접 그림자까지도 화면에 정확하게 계산해 낼 수 있는 겁니다. 그리고 화면을 그릴 때 표면에서 원뿔(Cone) 모양의 레이더를 쏩니다. 원뿔이 넓게 퍼져나가면서 '아, 저 멀리에 불투명도 0.8짜리 거대한 복셀 덩어리(상위 밉맵)가 있네? 그럼 이쪽 방향으론 빛이 덜 들어오겠다'라고 판단하는 거죠.

SVO의 게임 산업에서의 사용사례

대규모 파괴 가능 지형 (Destructible Terrain):
수많은 개체가 맵을 파고드는 생존 게임이나 샌드박스 게임에서 지형을 관리할 때 쓰입니다. 플레이어가 땅을 파내면 해당 구역의 SVO 노드만 쪼개서 업데이트하면 되므로, 폴리곤 메시에 불리언(Boolean) 연산을 하는 것보다 훨씬 빠르고 안정적으로 지형 변화를 처리할 수 있습니다.
충돌 감지 (Collision Detection) 및 공간 쿼리:
물리 엔진에서 수많은 오브젝트가 동시에 얽혀있을 때, SVO 구조를 활용하면 아주 빠르게 충돌 가능성이 있는 그룹을 솎아낼 수 있습니다. "이 거대한 노드 안에는 빈 공간뿐이다"라는 것을 한 번의 확인으로 통과할 수 있기 때문입니다.
자동화된 3D LOD (Level of Detail):
SVO의 레벨 12가 원본 메시라면, 레벨 10, 레벨 8로 올라갈수록 자연스럽게 형태가 단순화된 디테일이 나옵니다. 원경에 있는 오브젝트나 지형을 그릴 때 트리의 상위 노드만 렌더링하는 방식으로 자동 LOD 시스템을 구축할 수 있습니다.

2. SVDAG (Sparse Voxel Directed Acyclic Graph)

SVO가 빈 공간(Empty Space)을 쳐냈다면, SVDAG는 중복되는 공간(Duplicate Space)마저 하나로 합쳐버리는 구조입니다.

[논문 리뷰] Hybrid Voxel Formats for Efficient Ray Tracing

이름의 유례를 이미지와 함께 이해해보면 다음과 같습니다.

Sparse Voxel (희소 복셀):
기본 베이스는 SVO와 같습니다. 3D 공간에서 데이터가 없는 빈 곳은 저장하지 않습니다. '희소한' 데이터만 다룹니다.
Directed Graph (방향성 그래프):
그림 왼쪽의 SVO(Tree)를 보세요. 부모에서 자식으로 화살표가 한 방향으로만 흐릅니다. 그리고 한 자식은 오직 한 부모만 가집니다. 이게 '트리'입니다.
그림 오른쪽의 SVDAG(Graph)를 보세요. 'Shared Nodes' 부분을 보시면, 하나의 자식 노드를 여러 부모가 동시에 가리키고 있습니다. 부모-자식 관계가 1:N이 아니라 N:M으로 얽히기 시작했습니다. 더 이상 단순한 트리가 아니라, 화살표 방향이 있는 '그래프' 구조가 된 것입니다.
Acyclic (비순환):그래프 구조이지만, 화살표를 따라가다 보면 절대 자기 자신으로 되돌아오지 않습니다. 만약 자식이 부모를 가리키거나, 형제끼리 서로 가리켜서 뺑뺑 돌 수 있다면(Cycle), 컴퓨터가 데이터를 찾다가 무한 루프에 빠져버립니다.
SVDAG는 SVO에서 파생되었기 때문에, 항상 '위에서 아래로', '큰 공간에서 작은 공간으로'만 화살표가 흐릅니다. 그래서 '비순환(Acyclic)' 구조가 보장됩니다.
이게 가장 중요합니다. "Cyclic(순환하는)"의 반대말입니다.

SVDAG 빌드 알고리즘

Step 1: 최하단 리프 노드 병합 (Leaf Nodes & Hashing)

대상: 트리의 가장 깊은 곳에 위치한 실제 데이터 블록 (예: $2 \times 2 \times 2$ 복셀 노드)
작동 원리:
1. 각 노드가 가진 내부 데이터(색상, 밀도 등)를 기반으로 해시값(Hash Value)을 생성합니다.
2. 생성된 해시값을 해시 사전(Hash Dictionary)에 조회합니다.
3. 중복 발생: 사전에 동일한 패턴이 이미 존재한다면, 새로운 메모리를 할당하지 않고 기존에 등록된 고유 노드(Unique Leaf Node)의 주소(포인터)만 반환받아 공유합니다.
4. 이 과정을 통해 수많은 리프 노드가 단 몇 개의 고유한 데이터 블록으로 압축됩니다.

Step 2: 내부 노드 병합 (Internal Nodes & Pointer Hashing)

대상: 리프 노드를 제외한 상위 부모 노드들
작동 원리:
1. 한 단계 위로 올라가면, 부모 노드의 정체성은 데이터가 아니라 '자신이 거느린 8개 자식 노드의 포인터 조합'으로 결정됩니다.
2. 이 8개의 자식 포인터 배열을 통째로 해싱(Pointer Hashing)하여 다시 사전에 조회합니다.
3. 중복 발생: "내 자식들 구성과 완전히 똑같은 구성을 가진 다른 부모 노드"가 사전에 있다면, 현재 노드는 삭제되고 기존의 고유 내부 노드(Unique Internal Node)를 가리키게 됩니다.

Step 3: 최종 DAG 구조 완성 (Final Root & DAG Structure)

대상: 루트(Root) 노드
작동 원리:
1. Step 2의 과정을 트리의 최상단인 루트 노드에 도달할 때까지 재귀적(Recursive)으로 반복합니다.
2. 결과적으로 메모리 상의 모든 중복 데이터와 중복 경로가 제거된, 극도로 압축된 방향성 비순환 그래프(DAG) 형태가 완성됩니다.

4. Nano VDB (Nano Volumetric Dynamic B+ Tree)

NanoVDB의 태생을 이해하려면 먼저 영화(VFX) 업계의 표준인 OpenVDB를 알아야 합니다. 구름, 폭발, 연기 같은 복잡한 볼륨 데이터를 저장하기 위해 만들어진 OpenVDB는 매우 훌륭한 트리 구조를 가졌지만, GPU 기반의 실시간 렌더링에 올리기에는 치명적인 단점이 있었습니다. 바로 잦은 '포인터 체이싱(Pointer Chasing)'과 메모리 파편화입니다.

NVIDIA는 이를 실시간 렌더링에 맞게 개조하여 NanoVDB를 탄생시켰습니다.

NanoVDB와 SVO 구조 비교 도식화

이 구조가 GPU에서 압도적인 성능을 내는 핵심 이유는 크게 두 가지입니다.

1. 얕고 넓은 트리 (Shallow and Wide Tree)

SVO가 2 x 2 x 2씩 잘게 쪼개며 깊이 파고드는(Deep) 방식이었다면, NanoVDB는 가지를 아주 넓게 뻗는(Wide) 방식을 취합니다.

고정된 4단계 깊이: NanoVDB는 보통 Root -> Internal Node 1 -> Internal Node 2 -> Leaf Node라는 딱 4단계의 깊이만 가집니다.
거대한 브랜칭 팩터(Branching Factor): 한 번 내려갈 때 8개로 쪼개는 게 아니라, 아주 큰 덩어리로 쪼갭니다. 예를 들어 리프 노드 하나가 $8 \times 8 \times 8 = 512$개의 복셀을 한 번에 품고 있습니다.
효과: 트리를 타고 내려가는 횟수 자체가 3~4번으로 고정되므로 탐색 시간이 매우 짧고 일정합니다.

3D 좌표값을 인덱싱하는 방법

(X,Y,Z) 총 96비트짜리 데이터가 있다고 가정하자. 여기서 각 축마다 20비트씩 잘라내서 도합 60비트를 Root Node Hash Table의 Key로 삼아, Internal Node2의 1D Array를 구한다.
각 축마다 남아있는 비트는 12비트다. 여기서 우리는 Internal 2에서 한 축당 비트 5개 ($2^5$ 개)씩 사용하여 한 축에 32개짜리 복셀 공간을 표현할 수 있다.
(이를 통해 해당 공간 값이 (12, 16, 24) 와 같은 식으로 인덱싱 될 수 있는 것 이다.)
이제 시프트하고 남은 각 축당 비트는 7개다. 이를 4비트와 3비트로 쪼개어 두개의 추가 레이어를 만든 것 이다.
두 레이어에서도 같은 연산을 반복하고 마지막에 남게되는 Leaf Index를 이용하여 데이터를 읽기/쓰기 하는 구조인 것이다.

2. 선형 메모리 직렬화 (Linear Memory Serialization)

이것이 NanoVDB 최적화의 꽃입니다. GPU는 메모리 이곳저곳을 점프하며 읽는 것을 극도로 싫어하고, 한 번에 연속된 메모리를 뭉텅이로 긁어오는 것(Coalesced Memory Access)을 가장 좋아합니다.

포인터 대신 오프셋(Offset): NanoVDB는 트리 구조임에도 불구하고, 실제 메모리 상에서는 거대한 1D 배열(Linear Buffer) 딱 하나로 존재합니다.
배치 방식: 메모리의 맨 앞에는 Root 노드가, 그 뒤에는 모든 Internal 노드들이 빽빽하게, 그리고 마지막에는 모든 Leaf 노드(실제 복셀 데이터들)가 한 덩어리로 줄을 서 있습니다.
효과: 자식 노드를 찾을 때 주소(Pointer)를 묻는 게 아니라, "내 위치에서 몇 바이트(Byte) 뒤로 가라(Offset)"는 단순 덧셈 연산으로 데이터를 찾습니다. 캐시 미스(Cache Miss)가 획기적으로 줄어듭니다.

3. 비트마스크(Bitmask)를 이용한 초고속 빈 공간 건너뛰기

NanoVDB의 노드 안에는 해당 공간에 데이터가 꽉 차 있는지, 텅 비어있는지(Empty Space)를 나타내는 64비트 정수형 비트마스크(Bitmask)가 들어있습니다.

레이마칭을 하다가 빈 공간을 만나면, 무거운 부동소수점 연산을 할 필요 없이 단순히 비트 연산(Bitwise Operation) 몇 번만으로 "이 노드는 비었으니 통과!" 하고 거대한 공간을 한 번에 스킵해 버립니다.

4. SVO 대비 NanoVDB의 메모리 효율성

① '포인터 메타데이터' 오버헤드 제거

SVO의 경우: 자식 노드가 8개라면, 부모 노드는 8개의 메모리 주소(64-bit 포인터)를 들고 있어야 합니다. 트리가 깊어질수록 실제 복셀 데이터(밀도값)보다 '길 안내를 위한 포인터 메타데이터'의 용량이 배보다 배꼽이 더 커지는 현상이 발생합니다.
NanoVDB의 경우: 1차원 배열(Flat Array)에 데이터를 빽빽하게 줄 세우고, 비트 연산으로 오프셋을 계산합니다. 각 노드가 무거운 포인터 배열을 들고 있을 필요가 없으므로, 메타데이터가 차지하는 용량이 기하급수적으로 줄어듭니다.

② 64비트 마스크(Bitmask)를 통한 극한의 압축

NanoVDB의 리프 노드(Leaf Node)나 내부 노드 앞단에는 항상 64비트 정수형 마스크가 존재합니다.

만약 $4 \times 4 \times 4 = 64$개의 서브 복셀 공간이 있다면, 이를 64개의 float(256바이트)로 0인지 1인지 저장하는 것이 아닙니다.
단 하나의 64비트 정수(8바이트)를 사용하여, 각 비트의 0과 1로 빈 공간 여부를 기록합니다. 데이터가 있는 곳만 실제 배열에 값을 할당하므로, 메모리 낭비가 0에 수렴하게 됩니다.

③ 캐시 친화적(Cache-Friendly) 연속 메모리

메모리가 파편화되어 있지 않고 한 덩어리의 배열로 연속되어 있기 때문에, GPU가 VRAM에서 데이터를 가져올 때(Memory Fetch) 한 번의 요청으로 대량의 연관 데이터를 캐시에 올릴 수 있습니다. 이는 실질적인 대역폭 효율을 극대화합니다.

5. OpenVDB와 NanoVDB의 차이

OpenVDB는 후디니나 블랜더와 같은 곳에서 볼류메트릭한 정적 데이터를 만들 때 사용됩니다. (생성된 확장자는 .vdb입니다.)

내부적으로는 배열 기반의 B+ 트리구조인 NanoVDB와는 다르게 포인터 기반으로 작성된 B+트리구조입니다. 다만, NanoVDB와 유사하게 4개의 레이어 계층 (Root, Internal Nodes2, Internal Nodes1, Leaf Data)을 가지고 있어 위에서 서술한 비트 쉬프트를 통한 포인터 인덱스 참조와 같은 로직은 동일 합니다.

이런 구조적 차이 때문에 기존에 문제였던 Pointer Chasing과 메모리 파편화가 그대로 발생한다는 문제점이 있지만, 포인터 기반인 덕에 복셀 데이터의 수정과 삽입이 Nano VDB 보다 훨씬 유리합니다.

때문에 DCC툴인 후디니와 같은 곳에서 OpenVDB를 통해 데이터를 구축하고 리얼타임 렌더링이 필요한 게임 엔진에서는 NanoVDB 기반으로 변환하여 처리합니다.

좋습니다. 이제 트리를 기반으로 하는 두 메모리 관리 기법의 핵심 원리를 이해했으니 기법별로 사용하는 시점과 차이를 정리해보겠습니다.

NanoVDB와 SVO 사용시점

요약 비교 및 정리

구분	SVO (Sparse Voxel Octree)	NanoVDB
메모리 구조	노드 간 포인터 기반의 트리 (파편화됨)	1D 선형 배열 기반의 얕은 트리 (연속됨)
최대 장점	빠른 실시간 데이터 수정(파괴/생성), 계층적 LOD	GPU 캐시 친화적, 압도적인 레이마칭 탐색 속도
최대 단점	포인터 체이싱으로 인한 지연, 메타데이터 메모리 낭비	동적 업데이트(구조 변경) 비용이 매우 큼
주요 사용처	파괴 가능한 동적 지형, Voxel Cone Tracing (GI)	실시간 구름/연기 볼륨 렌더링, 고해상도 SDF 처리

NanoVDB를 사용해야 하는 경우

NanoVDB는 "한 번 구워진 데이터를 GPU에서 빛의 속도로 읽어야 할 때"

볼류메트릭 이펙트 (구름, 연기, 폭발):
- 밀도가 제각각인 이질적 볼륨(Heterogeneous Volumes)을 레이마칭(Raymarching)으로 렌더링할 때 압도적인 성능을 냅니다.
- 언리얼 엔진의 SVT 백엔드나, 영화 VFX 렌더링에서 표준으로 쓰이는 이유입니다.
고해상도 SDF (Signed Distance Field) 저장:
- 매우 복잡한 충돌체나 고품질 루멘표면 캐시를 위해 무거운 3D 거리장 데이터를 저장하고 빠르게 쿼리해야 할 때 유리합니다.
정적인(Static) 데이터 중심:
- 1차원 배열로 꽉 짜여 있기 때문에, 복셀 하나를 부수거나 구조를 바꾸려면 배열 전체의 크기를 다시 잡고 메모리를 재할당(Re-build)해야 합니다. 즉, 실시간 지형 파괴 같은 동적인 변화에는 매우 쥐약입니다.

SVO (Sparse Voxel Octree)를 사용해야 하는 경우

SVO는 "실시간으로 부수고 만들거나, 거대한 계층적 LOD가 필요할 때"

실시간 파괴 가능 지형 (마인크래프트 류, 샌드박스 게임):
- 플레이어가 곡괭이로 땅을 파서 복셀 데이터가 실시간으로 바뀔 때, SVO는 해당 노드의 '포인터'만 똑 끊어버리거나 자식 포인터를 새로 할당하면 그만입니다. 전체 메모리를 다시 짤 필요가 없으므로 동적 업데이트 속도가 매우 빠릅니다.
자동화된 거대 스케일 LOD 렌더링:
- 트리의 얕은 노드(큰 박스) 자체가 자연스러운 저해상도 LOD 역할을 합니다. 먼 거리의 지형을 그릴 때는 굳이 리프 노드까지 내려가지 않고 상위 노드에서 렌더링을 멈출 수 있어, 원경 처리에 강력합니다.
Voxel Cone Tracing (실시간 GI):
- 빛이 퍼져나가는 원뿔(Cone)의 크기에 맞춰 트리의 상위/하위 노드를 샘플링하여 부드러운 간접광을 만들 때, SVO의 완벽한 계층구조가 필수적입니다.

그렇다면 마인크래프트는 어떤 구조인가?

이제 배운 내용을 토대로라면 마인크래프트는 실시간으로 복셀 데이터가 수정되어야 하니 SVO를 기반으로 제작되어야 할 것 같습니다.

하지만, 실제로는 Sparse Hash Map과 해당 자료구조의 단점을 보완한 'Chunk 기반의 하이브리드 해시 맵' 을 기반으로 작성됐습니다.

때문에, Sparse Hash Map과 언리얼에서 사용하고 있는 SVT에 대한 내용도 추가적으로 설명해야 하는데 해당 포스트가 생각보다 길어져 다음 챕터에서 마저 이야기를 진행하도록 하겠습니다.

[UE5/Plugin] TurboSequence 심층 분석

LazySonic — Fri, 16 Jan 2026 17:15:05 +0900

Github

LukasFratzl/TurboSequence: Skeletal Based GPU Crowds for UE5

개요

TurboSequence는 Niagara Mesh Particles를 사용하되, Skeletal Mesh가 아닌 Static Mesh를 렌더링합니다. 핵심 트릭은 애니메이션 데이터를 텍스처에 베이크하고, GPU Compute Shader + Vertex Shader에서 실시간 스키닝을 수행하는 것입니다.

왜 Niagara SkeletalMesh Instance가 아닌가?

Niagara의 SkeletalMesh 렌더러는 내부적으로 각 인스턴스마다 개별 draw call을 발생시킵니다. TurboSequence는 이를 우회하여:

Static Mesh를 Niagara Mesh Particles로 렌더링 (단일 instanced draw call)
애니메이션을 GPU에서 계산하여 CPU 오버헤드 제거

파이프라인 전체 구조

1단계: 오프라인 변환 (Content Pipeline)

// TurboSequence_ControlPanelLibrary_Lf.cpp - ConvertSkeletalMeshToTurboSequence_BlueprintThreadSafe

1.1 Static Mesh 생성

// 원본 Skeletal Mesh의 각 LOD를 Static Mesh로 변환
for (int32 i = 0; i < SkeletalMesh->GetLODNum(); ++i)
{
    UStaticMesh* StaticMesh = NewObject<UStaticMesh>();
    // Skeletal Mesh의 정점 데이터를 Static Mesh로 복사
    // 본 웨이트는 제거되고 Bind Pose 정점만 저장
}

1.2 애니메이션 라이브러리 텍스처 생성

// TurboSequence_Helper_Lf.cpp - CreateAnimationLibraryTexture2D

핵심은 모든 애니메이션 프레임의 본 Transform을 텍스처에 베이크:

텍스처 구조:
- Width: NumBones * 3 (각 본당 3픽셀 = Rotation Quat + Translation + Scale)
- Height: TotalAnimationFrames (모든 애니메이션의 모든 프레임)
- Format: RGBA16F (고정밀도)

예시:
- 본 50개, 애니메이션 10개 (각 100프레임) = 150x1000 텍스처
- Pixel[0-2, FrameY] = Bone0의 Rotation(RGBA), Translation(RGB), Scale(RGB)
- Pixel[3-5, FrameY] = Bone1의 데이터...

텍스처 픽셀 인코딩:

// 각 본의 Transform을 3개 픽셀에 저장
FLinearColor RotationPixel = FLinearColor(Quat.X, Quat.Y, Quat.Z, Quat.W);
FLinearColor TranslationPixel = FLinearColor(Pos.X, Pos.Y, Pos.Z, 0);
FLinearColor ScalePixel = FLinearColor(Scale.X, Scale.Y, Scale.Z, 0);

1.3 본 웨이트 텍스처 생성

// 각 정점의 본 인덱스와 웨이트를 텍스처에 저장
// Width: NumVertices
// Height: 1
// RGBA: (BoneIndex0, Weight0, BoneIndex1, Weight1)

2단계: 런타임 CPU (Game Thread)

// TurboSequence_Manager_Lf.cpp

2.1 인스턴스 스폰

FTurboSequence_MinimalMeshData_Lf AddSkinnedMeshInstance_GameThread(...)
{
    // 1. MeshAsset에서 Static Mesh + 텍스처 참조 가져오기
    // 2. Niagara System에 인스턴스 추가 준비
    // 3. GPU에 전달할 메타데이터 구성
    FTurboSequence_MinimalMeshData_Lf Data;
    Data.AnimationStartFrame = 0;
    Data.AnimationEndFrame = 100;
    Data.CustomData = FVector4f(...); // Niagara User Parameter로 전달
    return Data;
}

2.2 애니메이션 업데이트 (Concurrent)

void UpdateMeshAnimation_Concurrent(...)
{
    // CPU에서는 메타데이터만 업데이트 (어떤 애니메이션, 어떤 프레임)
    Instance.AnimationStartFrame = NewAnimStartFrame;
    Instance.AnimationTime += DeltaTime;
    // 실제 본 계산은 GPU에서 수행
}

2.3 Solve (Game Thread)

void SolveMeshes_GameThread(float DeltaTime, ...)
{
    // 1. CPU에서 업데이트된 모든 인스턴스 데이터를 모음
    // 2. Niagara System에 인스턴스 데이터 전달
    // 3. GPU Compute Shader 디스패치 스케줄링
    
    for (UpdateGroup : UpdateGroups)
    {
        NiagaraComponent->SetCustomData(InstanceData); // GPU로 전송
        DispatchComputeShaders(UpdateGroup);
    }
}

3단계: 런타임 GPU - Compute Shader

// Shaders/Private/BoneSettings_CS_Lf.usf

3.1 본 데이터 준비 Compute Shader

[numthreads(64, 1, 1)]
void BoneSettings_CS_Lf(uint3 ThreadId : SV_DispatchThreadID)
{
    uint InstanceID = ThreadId.x;
    
    // 1. 인스턴스 메타데이터 로드 (Niagara User Parameters)
    float AnimTime = InstanceAnimTimes[InstanceID];
    int StartFrame = InstanceStartFrames[InstanceID];
    int EndFrame = InstanceEndFrames[InstanceID];
    
    // 2. 현재 프레임 계산
    float FrameFloat = StartFrame + (AnimTime * FPS);
    int Frame0 = floor(FrameFloat);
    int Frame1 = ceil(FrameFloat);
    float BlendAlpha = frac(FrameFloat);
    
    // 3. 애니메이션 라이브러리 텍스처에서 본 Transform 샘플링
    for (int BoneIdx = 0; BoneIdx < NumBones; BoneIdx++)
    {
        // 텍스처 UV 계산
        float U0 = (BoneIdx * 3.0f) / TextureWidth;
        float V0 = Frame0 / TextureHeight;
        float V1 = Frame1 / TextureHeight;
        
        // 본 Transform 로드 (3픽셀 = Rotation, Translation, Scale)
        float4 Rot0 = AnimLibraryTexture.SampleLevel(Sampler, float2(U0, V0), 0);
        float4 Trans0 = AnimLibraryTexture.SampleLevel(Sampler, float2(U0 + 1.0/Width, V0), 0);
        float4 Scale0 = AnimLibraryTexture.SampleLevel(Sampler, float2(U0 + 2.0/Width, V0), 0);
        
        float4 Rot1 = AnimLibraryTexture.SampleLevel(Sampler, float2(U0, V1), 0);
        float4 Trans1 = AnimLibraryTexture.SampleLevel(Sampler, float2(U0 + 1.0/Width, V1), 0);
        float4 Scale1 = AnimLibraryTexture.SampleLevel(Sampler, float2(U0 + 2.0/Width, V1), 0);
        
        // 4. 프레임 보간
        float4 FinalRot = QuatSlerp(Rot0, Rot1, BlendAlpha);
        float3 FinalTrans = lerp(Trans0.xyz, Trans1.xyz, BlendAlpha);
        float3 FinalScale = lerp(Scale0.xyz, Scale1.xyz, BlendAlpha);
        
        // 5. 결과를 Per-Instance 본 버퍼에 저장 (다음 단계에서 사용)
        OutBoneTransforms[InstanceID * NumBones + BoneIdx] = 
            ComposeTransform(FinalRot, FinalTrans, FinalScale);
    }
}

3.2 메시 단위 Compute Shader

// Shaders/Private/MeshUnit_CS_Lf.usf
[numthreads(64, 1, 1)]
void MeshUnit_CS_Lf(uint3 ThreadId : SV_DispatchThreadID)
{
    uint InstanceID = ThreadId.x;
    
    // 추가 메시별 로직 (LOD 선택, 가시성 등)
    // 실제 정점 스키닝은 Vertex Shader에서 수행
}

4단계: 런타임 GPU - Vertex Shader (Material)

// Shaders/Private/GPU_VertexSkinning_VS_Lf.ush
// Material Function: MF_TurboSequence_PositionOffset_Lf에서 호출

정점 스키닝 수행

float3 TurboSequence_VertexSkinning(
    float3 LocalPosition,
    uint VertexID,
    uint InstanceID)
{
    // 1. 본 웨이트 텍스처에서 해당 정점의 영향받는 본 정보 로드
    float4 BoneWeightData = BoneWeightTexture.Load(int3(VertexID, 0, 0));
    int BoneIndex0 = int(BoneWeightData.x);
    float Weight0 = BoneWeightData.y;
    int BoneIndex1 = int(BoneWeightData.z);
    float Weight1 = BoneWeightData.w;
    
    // 2. Compute Shader에서 계산한 본 Transform 로드
    float4x4 BoneMatrix0 = BoneTransforms[InstanceID * NumBones + BoneIndex0];
    float4x4 BoneMatrix1 = BoneTransforms[InstanceID * NumBones + BoneIndex1];
    
    // 3. 정점에 본 Transform 적용 (스키닝)
    float3 SkinnedPos0 = mul(float4(LocalPosition, 1.0), BoneMatrix0).xyz;
    float3 SkinnedPos1 = mul(float4(LocalPosition, 1.0), BoneMatrix1).xyz;
    
    // 4. 웨이트 블렌딩
    float3 FinalPosition = SkinnedPos0 * Weight0 + SkinnedPos1 * Weight1;
    
    // 5. World Position Offset으로 출력
    return FinalPosition - LocalPosition; // Offset 반환
}

Material Graph 연결

Material:
  World Position Offset Pin <- MF_TurboSequence_PositionOffset_Lf 출력
  ├─ VertexID (Vertex Interpolator)
  ├─ InstanceID (Niagara Mesh Particles 자동 제공)
  └─ Bone Transform Buffer (Compute Shader 출력)

5단계: Niagara Instanced Rendering

// Niagara System이 최종 렌더링 수행
NiagaraRenderer->DrawInstances(
    StaticMesh,                    // 변환된 Static Mesh
    Material,                      // 커스텀 스키닝 Material
    InstanceCount,                 // 10k-50k 인스턴스
    PerInstanceData                // Compute Shader 결과
);

핵심: Niagara는 하나의 DrawIndexedInstanced 호출로 모든 인스턴스를 렌더링. GPU는 각 인스턴스마다 Vertex Shader를 실행하며, 그 안에서 본 스키닝이 발생.

GPU 메모리 레이아웃

GPU Memory:
├─ Animation Library Texture (VRAM)
│  └─ 150x1000x8bytes = ~1.2MB (본 50개, 프레임 1000개 기준)
├─ Bone Weight Texture (VRAM)
│  └─ NumVertices x 16bytes (정점당 4개 float)
├─ Bone Transform Buffer (Compute Shader 출력)
│  └─ NumInstances x NumBones x 64bytes (4x4 행렬)
│     예: 10k instances x 50 bones = ~30MB
└─ Static Mesh Vertex/Index Buffers (VRAM)
   └─ 표준 Static Mesh 데이터

성능 최적화 원리

왜 빠른가?

Draw Call 극소화
- 기존: 10k 인스턴스 = 10k draw calls
- TurboSequence: 10k 인스턴스 = 1 draw call (아키타입당)
CPU 부하 이동
- 기존: CPU에서 본 행렬 계산 → GPU로 전송
- TurboSequence: CPU는 메타데이터만 업데이트, GPU가 모든 계산 수행
메모리 대역폭 최적화
- 애니메이션 데이터를 텍스처 압축으로 전송
- 본당 3픽셀(48바이트) vs 기존 본 행렬(64바이트)

트레이드오프

장점:

수만 개 인스턴스를 단일 draw call로 렌더링
CPU 오버헤드 거의 없음
애니메이션 블렌딩도 GPU에서 가능

단점:

Static Mesh 변환 필요 (오프라인 작업)
텍스처 메모리 사용 (애니메이션마다 텍스처 생성)
복잡한 애니메이션 블렌딩 제한 (CPU 로직 필요 시 병목)
본 개수 제한 (30-75개 권장, 텍스처 크기 이슈)

코드 흐름 요약

1. [Editor] Skeletal Mesh → Static Mesh + Animation Textures
2. [CPU GameThread] Spawn Instances → Update Animation Meta
3. [CPU GameThread] SolveMeshes → Dispatch Compute Shaders
4. [GPU Compute] BoneSettings_CS → Calculate Bone Transforms per Instance
5. [GPU Compute] MeshUnit_CS → LOD/Visibility processing
6. [GPU Vertex] Material Vertex Shader → Skinning per Vertex
7. [GPU Raster] Niagara Instanced Draw Call → Final Render

실제 구현 확인 파일

Compute Shader: Shaders/Private/BoneSettings_CS_Lf.usf, MeshUnit_CS_Lf.usf
Vertex Shader: Shaders/Private/GPU_VertexSkinning_VS_Lf.ush
Material Functions: MF_TurboSequence_PositionOffset_Lf.uasset
Texture 생성: Source/TurboSequence_Lf/Private/TurboSequence_Helper_Lf.cpp::CreateAnimationLibraryTexture2D
Compute Dispatch: Source/TurboSequence_Lf/Private/TurboSequence_Manager_Lf.cpp::SolveMeshes_GameThread

이 구조로 Niagara의 Static Mesh Instancing + GPU Compute Skinning을 결합하여 대규모 크라우드 렌더링을 달성합니다.

[UE5/Interchange] FBX 임포트 LOD 장애 Guide

LazySonic — Mon, 8 Dec 2025 09:26:33 +0900

(Interchange FBX → LOD Description 오류 / Legacy Import → UV NaN 경고)

1. 개요

Unreal Engine 5.6.1에서 FBX를 임포트할 때 기본적으로 Interchange Pipeline이 사용된다.
하지만 일부 FBX 파일(특히 2020.x 포맷 기반의 LOD 포함 에셋)에서 다음과 같은 문제가 발생할 수 있다.

- LOD Description 손상
- LOD 그룹 혹은 LODMetadata가 비정상적으로 읽힘
- Interchange FBX Import 실패 또는 메시 빌드 중단
- Legacy FBX Import 사용 시 임포트는 되지만 UV 데이터에 NaN이 포함되는 경고 발생

본 문서는 위 문제를 해결하거나 예방하기 위한 DCC 단계의 처리 방법
그리고 Unreal 임포트 파이프라인 설정 관련 절차를 안내한다.

2. 문제 상황 요약

2.1 Interchange FBX Import 사용 시

UE5.6.1에서 FBX 2020.3 파일을 Import하면 다음 오류가 발생할 수 있다.

LOD Description is corrupted or missing.
Failed to import mesh using Interchange pipeline.

원인 후보:

- Interchange가 FBX 2020.x 포맷의 LODMetadata parsing을 완전히 지원하지 않음
- FBX 내 일부 LOD Node의 구조가 구버전 FBX SDK에서 생성된 형태와 충돌
- LOD 그룹의 이름 규칙이 Interchange 기준과 맞지 않는 경우
- FBX 변환 과정에서 잘못된 Custom Attribute/Metadata가 추가된 경우

2.2 Legacy FBX Import 사용 시

`Interchange.FeatureFlags.Import.FBX=false` 옵션을 통해 구(legacy) FBX Importer를 강제로 사용하면
임포트 자체는 통과하지만, Cooking 중 아래 경고가 출력된다.

Mesh ~ has NaNs in its vertex instance UVs!
Offending uvs are set to zero.

원인:

* FBX 파일 내부의 일부 버텍스 UV 값이 NaN(Not a Number) 으로 포함되어 있음
* Interchange는 이 값을 읽지 못해 실패하지만 Legacy는 읽고 0으로 치환하여 임포트 성공

즉, 근본적인 문제는 FBX 파일 내부 데이터가 깨져 있음에 가깝다.

3. 해결 전략 개요

단계	조치
1	DCC 툴에서 메시의 UV, LOD, History 를 점검하여 데이터 손상 여부 확인
2	FBX Export 시 버전 및 옵션을 정상화 (문제 있는 Metadata 제거 포함)
3	UE에서 Interchange 사용 여부 결정
4	Legacy로 임포트한 경우 NaN 경고가 뜨면 DCC 단계에서 메시를 정리 후 재수출

4. DCC(Blender / 3ds Max / Maya)에서 확인해야 하는 사항

4.1 UV 데이터 검증

Blender

Edit Mode → UV Editor 열기
`Select → Select All by Trait → Non-Uniform` 또는 `Select → Select Linked`
아래 항목을 점검:
- UV가 존재하지 않는 Faces
- 면적이 0이거나 뒤틀린 UV
- UV 좌표가 매우 큰 값(Float Overflow 근처)
- Add-on 또는 스크립트로 잘못된 UV 자동 생성의 흔적
`UV → Pack Islands` 또는 새 Unwrap으로 재정리할 수 있음

3ds Max

UVW Unwrap Modifier 적용
UV View 창에서 다음 확인:
오른쪽 아래에서 “Invalid Faces” 자동 선택
UV가 존재하지 않는 Face (Empty Channel)
Custom Attribute에 의해 UV가 자동 변형된 흔적

Maya

UV Editor → UV > Cleanup
옵션:
"Check for Invalid Components"
"Non-Manifold Geometry"
"Overlapping UVs" (선택)
필요하면 History 삭제 후 새 UV 생성

4.2 메시/LOD 구조 점검

FBX 2020.x 기반에서 LOD 그룹이 꼬이는 주요 원인은 다음이다.

- LOD 이름 규칙이 Unreal 표준과 불일치

-   예: `mesh_LOD0`, `mesh_LOD1`, `meshLOD2` 같은 혼재된 네이밍
-   LOD Mesh 또는 Group Node 안에 빈 Transform 노드가 들어가 있는 경우
-   LOD 사이즈가 0 Triangles인 경우
-   LOD 일부가 Hidden/Disabled 상태로 Export된 경우
-   Export 이전에 삭제된 히스토리가 노드 메타데이터로 남아 있는 경우

4.3 History / Custom Data 삭제

Maya:

Edit → Delete by Type → History

3ds Max:

- `Utilities → Reset XForm → Collapse`
- `Editable Poly → Clean up`

Blender:

- `Object → Apply → All Transforms`
- `Mesh → Clean Up → Delete Loose / Degenerate Dissolve`

이러한 정리 과정에서 NaN UV 또는 잘못된 LOD Metadata가 사라지는 경우가 많다.

5. FBX Export 설정 가이드

FBX 버전 선택

- UE5.6.x와의 호환성이 가장 높은 버전: FBX 2018 / 2019
- 2020.x는 Interchange 지원 범위가 미완성인 부분이 있어 문제가 발생할 수 있음

권장 Export 설정

설정	값
FBX Version	2018 / 2019 권장
Smoothing Groups	ON
Tangents & Binormals	OFF (UE에서 자동 생성 권장)
Preserve Instances	OFF
Embed Media	OFF
Bake Animation	OFF (필요 시 최소화)
Triangulate	ON (특수 메시일 경우)
Add Leaf Bones	OFF (특히 Blender)
Units	cm 또는 m → UE 스케일 일관성 유지

6. Unreal Engine Import 절차

6.1 Interchange 기본 사용 (권장)

문제 없는 FBX라면 아래 옵션을 그대로 사용한다.

- `Interchange.FeatureFlags.Import.FBX=true` (기본값)

장점:

- 향후 UE 메이저 버전에서 지원 지속
- LOD 및 메타데이터 처리 개선

6.2 Interchange 실패 시 Legacy Import 사용

아래 콘솔 변수로 Legacy FBX Import 강제 가능:

Interchange.FeatureFlags.Import.FBX=false

이 경우 임포트는 성공할 수 있지만, 메시 빌드 중 UV NaN 경고가 발생할 수 있다.

경고 예시:

Mesh ~ has NaNs in it's vertex instance uvs! Offending uvs are set to zero.

6.3 NaN UV 발생 시 조치

- NaN 값은 Unreal이 자동으로 (0,0) 으로 치환하지만 정확한 UV가 필요한 경우(머티리얼, 라이트맵) 반드시 DCC에서 수정해야 한다.
- 아래 단계 수행:

LOD0 기준으로 메시/UV를 처음부터 다시 정리
LOD1 이상도 동일하게 UV 정합성 유지
FBX 2018/2019 포맷으로 재수출
Interchange Import로 재시도
여전히 실패하면 Legacy Import 후 메시/LOD 재빌드

7. 문제 원인 정리

단계	문제	원인
Interchange Import	LOD Description 오류	FBX 2020.x LODMetadata 불일치 / 노드구조 손상
Legacy Import	UV NaN 발생	FBX 내부 UV Float 값이 NaN으로 포함되어 있음
DCC	UV 및 메시 구조 손상	잘못된 Modifier/History/Export 스크립트 사용

8. 결론

-   UE5.6.x의 Interchange는 FBX 2020.x 포맷에서 일부 LOD 구조를 완벽히 해석하지 못해 문제가 발생할 수 있다.
-   Legacy Import로 우회할 수 있지만, UV NaN 문제처럼 FBX 자체 데이터 손상이 드러날 수 있다.
-   가장 확실한 해결책은 DCC 단계에서 메시 및 LOD 구조를 정리하고 Stable FBX Format(2018/2019) 으로 재수출하는 것이다.
-   가능하다면 Interchange Import를 사용하는 것이 장기적으로 안전하다.

9. 추가 참고 자료

-   Unreal Documentation – Interchange Framework
-   FBX SDK 2019 vs 2020 Metadata 차이
-   Blender FBX Export Known Issues (Add Leaf Bones / Broken UV Data)
-   Autodesk FBX 2020 Change Notes

[UE5/Networking] IRIS 네트워크 모델 분석

LazySonic — Fri, 5 Sep 2025 16:56:40 +0900

기존 네트워크 기법과의 차이
- 개념
  - Push 모델 기반
  - Replication Graph 의 경우 필터링으로 대체 됨
  - 브릿지와 리플리케이션 시스템으로 구성. 목표는 기존 Polling 기법 기반으로 수 많은 virtual call을 탐색 및 호출하는 구조를 개선하기 위함.
- RPC
  - 이제 무조건 RPC는 RPC 수행 대상자의 Replicated State Data가 적용된 이후에 수행된다.

활성화 방법

PushDown 모델 활성화 필요
- 만약 아이리스에 대해서만 활성화 하고 싶다면, 'Net.IsPushModelEnabled' 활성화하면 됨

// Enable iris if it is not already on by default
if (!bUseIris)
{
    // If we enable Iris for a single target we also need to set the TargetBuildEnvironment to unique, as other projects in the solution might want it compiled out
    BuildEnvironment = TargetBuildEnvironment.Unique;
    bUseIris = true;
}

구조

ReplicationState
- 가장 기초적인 네트워크 Primitive 데이터이며, 사실상 리플리케이트 될 데이터를 담는다.
- 해당 데이터를 설명하기 위해 ReplicationStateDescriptor를 하나씩 들고 있다.
ReplicationStateDescriptor
- 메모리 레이아웃, 조건, 필터링, 우선순위 설정, 직렬화 방법에 대한 데이터를 들고 있다.
- 해당 State Descriptor를 커스터마이징하여 사용하는 예시는 TestNetworkPlugin에서 볼 수 있다.
ReplicationFrament
- 게임플레이 코드와 리플리케이션 시스템 사이에서 스테이트를 주고 받는 작업을 담당한다. (말로는 이해 불가, 내부 코드 분석은 아래와 같다.)
  - ReplicationFragment.h
    - FReplicationStateOwnerCollector
    - FReplicationStateApplyContext
      - Descriptor pointer
    - 주석
      - 하나 이상의 ReplicationState를 오너와 바인딩한다. 이는 NetObject를 구성할 때 핵심이 된다.
      - 게임쪽에서 이 데이터를 추출하거나 지정할 수 있다.

ReplicationProtocol

FReplicationProtocol은 정적인 구조 정의이고,
FReplicationInstanceProtocol은 실제 객체 인스턴스와 연결된 동적인 상태를 관리합니다.

구조 관계 요약

FReplicationProtocol	어떤 데이터가 복제될지 정의 (정적)	FReplicationStateDescriptor 배열 포함
FReplicationInstanceProtocol	실제 객체 인스턴스의 복제 상태 관리 (동적)	FReplicationFragment* 배열 포함
FReplicationFragment	실제 복제 상태 추적 및 직렬화	FReplicatedState 포함
FReplicationBridge	객체 등록/해제 및 Protocol ↔ Instance 연결	FReplicationInstanceProtocol 생성 및 관리

NetHandle

아이리스 시스템 초기화 전체흐름
- FReplicationSystemUtil::BeginReplicationForActorsInWorldForNetDriver
- AActor::BeginReplication
  - Call::FReplicationSystemUtil::BeginReplication
  - Called From
    - FReplicationSystemUtil::BeginReplicationForActorsInWorldForNetDriver
    - FReplicationSystemUtil::FlushNetDormancy
- FReplicationSystemUtil::BeginReplication
  - ForEachReplicationSystem{Call::EngineReplicationBridge::StartReplicatingActor}
- FReplicationSystemUtil::AddDependentActor
  - ForEachReplicationSystem{Call::EngineReplicationBridge::StartReplicatingActor)
- EngineReplicationBridge::StartReplicatingActor
- ObjectReplicationBridge::StartReplicatingRootObject
- ObjectReplicationBridge::StartReplicatingNetObject
  - ```
  개별 인스턴스 프로토콜 생성 : FReplicationInstanceProtocolPtr InstanceProtocol = FReplicationProtocolManager::CreateInstanceProtocol
```
- 인스턴스 프로토콜 구분자 계산 : FReplicationProtocolIdentifier ProtocolIdentifier = FReplicationProtocolManager::CalculateProtocolIdentifier
- 프로토콜 구분자와 아키텍쳐 타입을 이용해 프로토콜 가져옴 못 찾으면 아래에서 아에 생성함 : FReplicationProtocol* ReplicationProtocol = ProtocolManager→GetReplicationProtocol(ProtocolIdentifier, ArchetypeOrCDOUsedAsKey)
- 넷 핸들러 구축 및 인스턴스 연결
  - FNetHandle NetHandle = FNetHandleManager::GetOrCreateNetHandle(Instance←리플리케이트할 대상을 기반으로 넷핸들러 생성)
  - FNetRefHandle RefHandle = UReplicationBridge::InternalCreateNetObject(AllocatedRefHandle, NetHandle, ReplicationProtocol)
    - AllocatedRefHandle과 프로토콜을 이용해 넷 오브젝트 생성 맟 핸들 반환 : UReplicationBridge::InternalCreateNetObject
  - 더티 트래킹을 위해 인스턴스와 인스턴스 프로토콜을 바인딩 : UReplicationBridge::InternalAttachInstanceToNetRefHandle
  - Push Model 인 경우 인스턴스에 PushId 지정 : UObjectReplicationBridge::SetNetPushIdOnInstance
더티 트래킹의 전체 흐름
- BeginReplication() → StartReplicatingActor() → FReplicationBridge가 FReplicationInstanceProtocol을 생성.
- 이때 FReplicationFragment들이 바인딩되고, 각 Fragment는 자신의 FReplicatedState를 관리.
2. 데이터 변경 감지 (Dirty Detection)
- 이 함수는 각 프레임마다 호출되어 상태의 변경 여부를 감지합니다.
- 내부적으로는 FReplicatedState의 메모리를 비교하거나, 커스텀 로직을 통해 변경 여부를 판단합니다.
변경 감지 방식
- 메모리 비교: 이전 상태와 현재 상태를 비교하여 변경된 바이트를 추적.
- 커스텀 로직: PollReplicationStateChanges()를 오버라이드하여 특정 조건에서만 더티로 간주.
3. 더티 마킹 (Dirty Marking)
- 변경된 상태는 이 버퍼에 기록됩니다.
- 각 FReplicatedState는 더티 비트 마스크를 통해 어떤 필드가 변경되었는지 추적합니다.
FReplicationInstanceProtocol::MarkStateDirty()
- Fragment가 변경된 상태를 감지하면 이 함수를 호출하여 해당 상태를 더티로 마킹.
- 이후 전송 대상에 포함됨.
4. 직렬화 및 전송
- 더티로 마킹된 상태만 직렬화하여 네트워크 패킷에 포함.
- FNetSerializer를 통해 필드 단위 직렬화가 수행됨.
FReplicationProtocol::ReplicationStateDescriptors
- 어떤 필드를 어떻게 직렬화할지 정의된 메타데이터를 기반으로 처리.
5. 클라이언트에서 수신 및 적용
- 수신된 패킷을 역직렬화하여 FReplicatedState에 적용.
- FReplicationFragment::ApplyReplicatedState()를 통해 실제 객체에 반영.
핵심 구조체 변화 요약
고급 팁
- IRIS는 푸쉬 모델이기 때문에, 더티 상태를 감지하지 못하면 복제가 발생하지 않습니다.
- PollReplicationStateChanges()를 커스터마이징하면, 조건부 복제나 최적화된 전송이 가능합니다.
- FReplicationFragment는 상태를 직접 관리하므로, 커스텀 Fragment를 구현하면 더티 트래킹 로직을 세밀하게 제어할 수 있습니다.

FReplicatedState	변경된 필드의 값이 업데이트됨
FReplicationStateChangeBuffer	변경된 필드의 인덱스/비트가 기록됨
FReplicationInstanceProtocol	해당 Fragment의 상태를 더티로 마킹
FNetSendHandler	더티 상태만 직렬화하여 전송

FNetReceiveHandler::DeserializeAndApply()
FNetSendHandler::SerializeAndSend()
FReplicationStateChangeBuffer
FReplicationFragment::PollReplicationStateChanges()
1. 객체가 등록되고 초기화됨

[Rendering] First Person Rendering

LazySonic — Wed, 3 Sep 2025 14:59:34 +0900

참고 발표

First-Person Rendering in Unreal Engine 5.6 | Unreal Fest Orlando 2025

언리얼 엔진에서 1인칭 솔루션을 제공하는 이유

도전과제

1. 씬 클리핑

2. Field of View

3. Fake Legs

4. Lighting, Shadow

5. Reflections

도전과제 요약정리

기존 해결방법

에셋 기반으로 해결 하던 방식

Headless Mesh	Floating Arms

렌더링 기법을 통해 해결 하던 방식

1. Compositing

1인칭과 3인칭 각각 따로 그린 뒤 씬을 합치는 방법을 고안해봤으나,

해당 방법에서는 빛과 그림자를 결합하는 과정에서 해결 불가능한 문제가 생기며, 비용 또한 높다는 단점이 있다.

2. Seperate Render Pass

1인칭 메시를 먼저 그린 뒤 뎁스 스텐실과 같은 장치를 통해 3인칭 뷰 정보가 이를 덮어 씌우지 못 하도록 그리는 방법이다.

이 방법은 꽤 괜찮지만, 1인칭 메시가 Depth 정보를 모두 덮어 씌우기 때문에 Depth 기반의 Post Process를 사용하지 못 하는 문제가 발생한다.

또한, 이 문제는 반투명 객체나 파티클과의 결합에서도 문제를 야기하기 때문에 일반적인 게임에선 사용하기 어렵다.

3. Custom Projection Matrix

1인칭 FOV 데이터를 분리하여 1인칭에 맞는 메트릭스를 별도로 구성, 이를 기반으로 1인칭 메시들을 그려 빛과 그림자가 드리우게 하고 3인칭 이후에 글려 클리핑을 방지하도록 하는 방법이다.

다만, Fake Legs과 Legs의 지면 클리핑 문제는 해결해야 하는 문제이며 별도의 매트릭스를 관리해야한다는 점에서 다소 복잡성이 높다.

그렇지만, 언리얼엔진은 이 방법이 그렇게 어려운건 아니라 생각해 이 아이디어를 바탕으로 1인칭 FOV 데이터를 분리, 별도의 메트릭스를 구성하여 렌더링하도록 하는 방법을 채택했다.

언리얼에서 제공하는 솔루션

Cliping

Full Scale Geometry	Scaled Geometry
전체 사이즈 지오메트리로 라이팅을 연산하는 경우 굉장히 정확하게 그려짐으로, 대부분의 상황에 제대로 보인다. 다만, 클리핑 되는 상황이 발생하는 경우 실제로 클리핑 되어야 하는 안쪽의 경우 어둡기 때문에 사진과 같이 그림자 지게 보인다.	다소 부정확한 라이팅이 일반적으로 사용되어 이따금씩 플리커링 처럼 그림자가 생기는 이슈가 있을 수 있다. 다만, 클리핑되는 지역에서도 정상적인 느낌으로 그림자를 줄 수 있다는 장점이 있다.

위 두 상황을 적절히 타개하기 위해 언리얼 엔진에서는 Scaling and Morphing을 적용하기로 했다.

수식 설명에 필요한 기본 수학 지식

(추가 작성 예정)

행렬변환

역행렬

프로젝션 행렬

솔루션에 사용되는 수식 설명

FOV Correction

M * V * P_fp = M * 'T' * V * P = M * V * P_fp * P^-1 * V^-1 * V * P

우리는 여기서 변환행렬 'T'를 구하고자 한다.

유도 과정

M*V*P_fp = M*T*V*P => M 역행렬을 양쪽에 곱함 => V*P_fp = T*V*P

양쪽에 V역행렬을 곱함=>P_fp = T*P => P 역행렬을 곱함 => T = P_fp * P^-1

=> M*V*P_fp = M * (P_fp*P^-1) * V * P

※ 그럼 여기서 왜 V^-1*V를 중간에 넣어주는가?

그 이유는 T 연산 자체가 카메라 공간(V)에서 이뤄져야 하는 연산이기 때문이다. 따라서 M * V 로 카메라 공간으로 이동 후 T 연산 한 결과물은 카메라 공간상의 결과물이 됩니다. 이를 다시 월드로 돌리기 위해 V^-1을 뒤에 곱해줍니다.
이 결과물이 M*V*P_fp*P^-1*V^-1*V*P가 됩니다. 여기서 V^-1*V가 항등행렬이라 당황스러울 수 있지만 흐름을 따라가면 말한대로 공간상의 정의를 설명하기 위한 중요 요소가 됩니다.

고로 T = V*P_fp*P*V^-1이 됩니다.

With Scaling

S = ScaleMatrix(s,s,s)

T = V*P_fp*P^-1*S*V^-1

Simplify

P_fp*P^-1=(f,f,1)

위와 같이 정리가 가능한 이유는

프로젝션 행렬의 경우 위와 같은 행렬을 갖고 (Theta는 FOV) 이는 FOv에 따라 x,y 축으로 확대 축소가 이뤄진다는 뜻 이다.

여기서 P와 P_fp의 차이는 FOV의 값 차이 뿐이다. 이에 따라 P_fp에 P 역행렬을 곱하면 기저

f = tan(FOV/2) / tan(FOV_fp/2)

Final Transform

T = V*ScaleMatrix(f*s, f*s, f*s)*V^-1

위 과정에 의한 Final Transform을 구성하는 로직은 SceneView.h, FViewMatrices::Init 내 FirstPersonTransform 연산부에서 확인 가능합니다.

이렇게 구성된 FirstPersonTransform은

FViewInfo::TUniquePtr<FViewUniformShaderParameters> CachedViewUniformShaderParameters

위 URV 구조체에 아래와 같이 등록되며

#define VIEW_UNIFORM_BUFFER_MEMBER_TABLE

VIEW_UNIFORM_BUFFER_MEMBER_PER_VIEW(FMatrix44f, FirstPersonTransform)
VIEW_UNIFORM_BUFFER_MEMBER_PER_VIEW(FMatrix44f, PrevFirstPersonTransform)

URV로 등록된 FisrtPersonTransform을 각종 쉐이더의 VertexPass 에서 'MaterialTemplate.ush' 에 있는 'ApplyMaterialFirstPersonTransform' 함수를 통해 WorldPositionWithWPO로 변환한다.

관련 로직은 'BasePassVertexShader.usf' 에서 확인 가능하다.

Fake Legs

위에서 이야기했던 내용에 따르면 1인칭 메시가 그려지는 공간을 왜곡함으로써 클리핑과 조명 렌더링에 대한 영역을 해결해 나갔다는 것을 알 수 있다.

그렇다면 팔이 아니라 1인칭 다른 바디 파츠에 대해선 어떻게 처리해야 할까?

위와 같다면, 다리와 몸통 같은 경우도 공간이 왜곡되어 바닥과 일치하지 않는 장애가 생기진 않을까?

영상속 답변은 '생긴다'. 이에, 솔루션으로 제공한 기능이 'World Space Interpolation' 마테리얼 노드다.

해당 노드는 'MaterialTemplate.ush' 내에서 다음과 같이 3인칭 공간과 1인칭 공간 사이를 보간하여 WPO를 구성하는데 사용된다.

void ApplyMaterialFirstPersonTransform(FMaterialVertexParameters Parameters, inout float3 WorldPositionWithWPO)
{
#if SUPPORT_FIRST_PERSON_RENDERING
	BRANCH
	if (IsFirstPerson(Parameters))
	{
		const float LerpAlpha = GetMaterialFirstPersonInterpolationAlpha(Parameters);
		const float3 FirstPersonPosition = TransformToFirstPerson(WorldPositionWithWPO, LerpAlpha);
		WorldPositionWithWPO = FirstPersonPosition;
	}
#endif
}

이 노드를 이용해 실질적인 Fake Legs를 구현한 샘플은 FPS Sample에서 다음과 같이 확인할 수 있다.

의미는 스피어 마스크에 시각적 장애가 없는 임의의 상수 Scale을 넣어 절대 월드 위치와 1인칭 공간상의 절대 위치 차를 보간 알파값으로 등록함으로써 시각 아티펙트를 수정한다.

Casting Scene Shadows

오로지 그림자만 캐스팅하고 프리미티브는 숨긴다.

1인칭 그림자는 별도 쉐도우 맵을 그리고 씬과 융화된다.

관련한 로직은 'SceneRendering.h'와 'ShadowSetup.cpp', 'ShadowSceneRenderer.cpp' 를 참고하면 도움이 된다.

- ShadowSetup에서 FSortedShadowMap 내 VirtualShadowMapShadows를 1인칭 여부 확인 후 생성한다.

- ShadowSceneRenderer에서 1인칭 그림자인지 확인 후

HWRT Reflections

실무 세팅 및 적용

[업무에 쫓겨 이후 작성 예정]

[UE5/Plugin] 언리얼 Mass Entity Framework와 Unity DOTS 비교, 그리고 활용법

LazySonic — Tue, 2 Sep 2025 22:06:59 +0900

1. Unity ECS와 DOTS 개요

ECS(Entity Component System)

Unity가 도입한 ECS는 “데이터 지향적 설계”를 통해 기존 객체 지향(OOP)의 한계를 극복하려는 접근입니다.

Entity: 단순히 ID 값. 그 자체로는 아무 기능도 없음.
Component: Entity에 부착되는 순수 데이터. 예: Position, Velocity, Health.
System: 특정 컴포넌트 조합을 가진 엔티티를 찾아 로직을 실행. 예: MovementSystem은 Position과 Velocity를 가진 엔티티에 대해 위치를 갱신.

Hot / Cold 데이터 분리

CPU 성능은 캐시 히트율에 크게 좌우됩니다. ECS는 자주 갱신되는 Hot 데이터와 가끔 접근되는 Cold 데이터를 분리해 캐시 효율을 높입니다.

Hot: Position, Rotation, Velocity → 매 프레임 사용.
Cold: WeaponType, AIConfig → 조건부로만 접근.

이렇게 하면 불필요한 데이터 로딩 없이 필요한 데이터만 연속적으로 메모리에 올릴 수 있어, SIMD 및 멀티스레딩 효율이 극대화됩니다.

DOTS (Data-Oriented Tech Stack)

Unity의 DOTS는 ECS에 Jobs System과 Burst Compiler를 결합한 기술 스택입니다.

Jobs: 멀티스레딩 지원.
Burst: CPU 아키텍처에 맞춰 SIMD 최적화된 네이티브 코드 생성.
ECS: 데이터 지향적 구조로 확장성 확보.

정리하자면, DOTS는 대규모 데이터를 CPU에서 효율적으로 돌리기 위한 Unity만의 병렬화·최적화 풀 스택입니다.

2. Unreal Mass Entity Framework: 개념과 명칭

언리얼 엔진도 ECS와 같은 데이터 지향적 모델을 필요로 했습니다. 하지만 이미 Actor/Component 체계가 뿌리 깊게 자리잡고 있었기 때문에 혼란을 피하기 위해 Mass Entity Framework라는 독자적인 이름을 사용합니다.

핵심 개념

Fragment: Unity ECS의 Component와 유사. 순수 데이터 단위.
Tag: 특정 속성을 나타내는 경량 마커. 조건 분기에 사용.
Processor: Fragment 조합에 로직을 실행하는 단위.
Trait: Fragment, Tag, Processor를 패키징한 개념.
- 예: CharacterTrait을 붙이면 이동, 렌더링, 입력 등 관련 Fragment와 Processor가 자동 추가됨.

이러한 구조 덕분에, Mass는 프로그래머뿐 아니라 디자이너도 Trait 기반으로 쉽게 엔티티를 구성할 수 있습니다.

3. Movement 구현 예시

실제 Movement를 처리하는 과정을 예로 들어보겠습니다.

Fragment 정의

struct FTransformFragment : public FMassFragment
{
    FTransform Transform;
};

struct FVelocityFragment : public FMassFragment
{
    FVector Velocity;
};

Processor 구현

UCLASS()
class UMassMovementProcessor : public UMassProcessor
{
    GENERATED_BODY()

public:
    UMassMovementProcessor()
    {
        ExecutionOrder.ExecuteInGroup = UE::Mass::ProcessorGroupNames::Movement;
    }

protected:
    virtual void Execute(FMassEntityManager& EntityManager, FMassExecutionContext& Context) override
    {
        auto TransformList = Context.GetMutableFragmentView<FTransformFragment>();
        auto VelocityList  = Context.GetFragmentView<FVelocityFragment>();

        for (int32 i = 0; i < Context.GetNumEntities(); i++)
        {
            TransformList[i].Transform.AddToTranslation(
                VelocityList[i].Velocity * Context.GetDeltaTimeSeconds()
            );
        }
    }
};

SIMD 적용 예시

#include <immintrin.h> // AVX Intrinsics

UCLASS()
class UMassSIMDGravityProcessor : public UMassProcessor
{
    GENERATED_BODY()

public:
    UMassSIMDGravityProcessor()
    {
        ExecutionOrder.ExecuteInGroup = UE::Mass::ProcessorGroupNames::Movement;
    }

protected:
    virtual void Execute(FMassEntityManager& EntityManager, FMassExecutionContext& Context) override
    {
        auto Velocities = Context.GetMutableFragmentView<FVelocityFragment>();
        const int32 NumEntities = Context.GetNumEntities();

        const float DeltaTime = Context.GetDeltaTimeSeconds();
        __m128 Gravity = _mm_set_ps(0.f, 0.f, -980.f * DeltaTime, 0.f); // [X, Y, Z, Padding]

        for (int32 i = 0; i < NumEntities; i += 4) // 4개 단위로 SIMD 처리
        {
            // Velocities[i] ~ Velocities[i+3]를 로드
            __m128 vx = _mm_loadu_ps(&Velocities[i + 0].Velocity.X);
            __m128 vy = _mm_loadu_ps(&Velocities[i + 1].Velocity.X);
            __m128 vz = _mm_loadu_ps(&Velocities[i + 2].Velocity.X);
            __m128 vw = _mm_loadu_ps(&Velocities[i + 3].Velocity.X);

            // Z 축에만 중력 적용 (X, Y는 그대로)
            vx = _mm_add_ps(vx, Gravity);
            vy = _mm_add_ps(vy, Gravity);
            vz = _mm_add_ps(vz, Gravity);
            vw = _mm_add_ps(vw, Gravity);

            // 다시 저장
            _mm_storeu_ps(&Velocities[i + 0].Velocity.X, vx);
            _mm_storeu_ps(&Velocities[i + 1].Velocity.X, vy);
            _mm_storeu_ps(&Velocities[i + 2].Velocity.X, vz);
            _mm_storeu_ps(&Velocities[i + 3].Velocity.X, vw);
        }
    }
};

ISPC 적용 예시 (더 간단한 SIMD 활용법)

// Gravity.ispc
export void ApplyGravity(uniform float3* velocities, uniform int N, uniform float dt)
{
    foreach (i = 0 ... N)
    {
        velocities[i].z += -980.0f * dt; // SIMD 병렬화 자동 적용
    }
}

C++ Processor에서는 ISPC 함수를 호출하기만 하면 됩니다:

extern void ApplyGravity_ispc(FVector* Velocities, int N, float dt);

virtual void Execute(FMassEntityManager& EntityManager, FMassExecutionContext& Context) override
{
    auto Velocities = Context.GetMutableFragmentView<FVelocityFragment>();
    ApplyGravity_ispc(&Velocities[0].Velocity, Context.GetNumEntities(), Context.GetDeltaTimeSeconds());
}

실무 팁

GetMutableFragmentView를 사용하면 성능 오버헤드 없이 대규모 연속 데이터 접근 가능.
Processor는 Chunk 단위 병렬 실행되므로, SIMD 최적화 효과가 큼.
필요시 ParallelForEachEntityChunk를 이용해 코어 활용 극대화 가능.

4. Fragment 접근 및 수정 방식

SharedPtr

장점: 데이터 소유권 관리에 유리.
단점: 참조 카운트 연산 비용 때문에 루프 내부에서는 비효율.
사용 예시: 외부 모듈과 데이터 공유, 긴 생명주기를 가진 대형 오브젝트 관리.

ArrayView / ConstArrayView

장점: 오버헤드가 거의 없는 뷰 타입.
단점: 소유권 없음.
사용 예시: Processor 내부에서 대규모 시뮬레이션 처리 시 권장.

결론: 성능 중심 로직 = ArrayView, 메모리 관리 필요 = SharedPtr

5. Mass Entity Framework 플러그인

Mass는 다양한 플러그인과 결합해 기능을 확장할 수 있습니다.

MassGameplay: 캐릭터, NPC, 일반적인 게임 플레이 지원.
MassCrowd: 수천 명 이상의 군중 시뮬레이션.
MassTraffic: 차량, 교통 네트워크, 신호등 제어.
MassLOD: 엔티티 단위 LOD 최적화.
MassReplication: 네트워크 복제 최적화.
MassSmartObjects: NPC와 상호작용 가능한 오브젝트 시스템.
MassDebug/Visualizer: 시각화 및 디버깅 도구.

이 플러그인들을 조합하면 단순한 시뮬레이션을 넘어 도시 전체 생태계까지 구성할 수 있습니다.

6. Mass가 적합한 게임 장르

Mass는 특히 대규모 단순 객체 처리에서 강력합니다.

RTS/전략 게임: 수백~수천 개 유닛 동시 제어.
군중/생태계 시뮬레이션: 도시 인구, 동물 무리, 생태계.
트래픽/레이싱 게임: 도로 네트워크, NPC 차량.
샌드박스/서바이벌: 월드 내 자원, 몬스터, 동물 개체.

실무에서는 Actor + Mass 하이브리드 구조를 쓰는 경우가 많습니다.

Mass: 단순하고 대량의 NPC/오브젝트.
Actor: 복잡한 개체(보스 몬스터, 플레이어 캐릭터).

7. Mass 내부 구조 이해하기

Mass의 성능 핵심은 Archetype-Chunk 메모리 구조입니다.

Archetype: 특정 Fragment 조합을 가진 Entity 그룹.
Chunk: 동일 Archetype 엔티티들을 묶어 저장하는 단위.
Chunk는 Struct-of-Arrays(SoA) 형식으로 데이터를 저장해 캐시 효율이 뛰어남.
Processor는 Query를 통해 대상 Chunk를 찾아내고, 이를 한 번에 처리.

즉, CPU는 연속 메모리에 정렬된 데이터만 읽으므로 캐시 미스가 최소화되고, SIMD 활용률이 높아집니다.

마무리

Unity DOTS와 Unreal Mass는 모두 데이터 지향적 패러다임을 기반으로 하지만, 구현 철학이 다릅니다.

Unity: ECS를 “게임 개발의 기본 모델”로 삼고 독립적 기술 스택 구축.
Unreal: 기존 Actor/Component 시스템과 공존 가능한 별도 프레임워크로 Mass 개발.

Mass의 강점은 다음과 같습니다.

Trait 기반으로 손쉬운 구성.
대규모 시뮬레이션에 적합한 고성능 Chunk 구조.
플러그인 생태계를 통한 확장성.

앞으로 대규모 NPC, 군중, 트래픽, 생태계 시뮬레이션을 구현하고 싶다면, Mass Entity Framework는 반드시 고려해볼 가치가 있는 강력한 도구입니다.

참고

https://github.com/Megafunk/MassSample/blob/main/README.md

MassSample/README.md at main · Megafunk/MassSample

My understanding of Unreal Engine 5's experimental ECS plugin with a small sample project. - Megafunk/MassSample

github.com

https://contents.premium.naver.com/unrealstudy/unreal/contents/250524153826875lb

DX12 기반 복셀엔진 개발 마일스톤

LazySonic — Sun, 10 Aug 2025 18:55:33 +0900

DirectX 12 기반 복셀 렌더링 엔진 – 전체 마일스톤 계획

M0 – 최소 실행 엔진 (Minimal Engine Bring-Up)

목표: 실행 가능한 최소 엔진 뼈대 구축

Win32 창 생성 및 이벤트 루프
Core / Engine 모듈 초기화
DX12 Agility SDK + DXC 설정
D3D12 RHI 초기화 (Device, Queue, SwapChain, RTV, Fence)
화면 단색 Clear & Present
Debug/Release 빌드 환경 안정화

M1 – 타일 단일 시뮬레이션 & 디버그

목표: 1개 타일에서 토사(Cellular Automata) 및 유체(Heightfield) 기본 시뮬레이션 구현

RHI UAV/SRV 리소스 핸들링
Compute Shader로 토사 CA 1스텝 처리 (ping-pong 버퍼)
얕은수 기반 유체 시뮬레이션 초기 버전
Slice 뷰 디버그 렌더링
시뮬 파라미터(중력, 스텝 수 등) 조절 UI

M2 – 렌더링 통합 & 메싱

목표: 시뮬레이션 데이터를 3D 메시로 변환해 렌더링

RenderGraph 최소 버전 도입 (패스 의존성/리소스 관리)
Marching Cubes로 토사/지면 메싱
단색 머티리얼 기본 셰이딩
프러스텀 컬링 적용
와이어프레임 / 노멀 디버그 뷰

M3 – 멀티 타일 & 경계 교환

목표: 여러 타일이 연결된 월드 시뮬레이션

타일 경계(ghost cell) 버퍼 설계 및 교환
멀티 타일 동시 시뮬 안정화
타일 LOD 및 스트리밍 초석
시뮬레이션 성능 최적화 (타일 활성/비활성 관리)
프로파일러 도입 (CPU/GPU 타이밍)

M4 – 토사 ↔ 유체 상호작용 & 고도화

목표: 토사와 유체의 상호작용 및 시각적 개선

침식/퇴적 로직
유체 입자 표현(PBD/MPM) 또는 고급 solver 적용
물 표면 메싱 및 반사/굴절 렌더링
Async Compute 병렬화
고급 조명(간단한 GI 또는 SSAO) 적용

M5 – 에디터/툴 확장

목표: 개발 생산성 향상을 위한 디버그/에디터 기능

ImGui 기반 월드/타일 편집
시뮬레이션 파라미터 실시간 조정
RenderGraph 시각화
셰이더 핫리로드
캡처/리플레이 기능

M6 – 안정화 및 배포

목표: 엔진 안정성 확보 및 초기 배포 준비

리소스/메모리 누수 점검
모듈별 코드 정리 및 문서화
빌드 스크립트 자동화
샘플 콘텐츠 제작

250810 - DirectX 12 기반 엔진 뼈대 만들기 – M0 단계 기록

LazySonic — Sun, 10 Aug 2025 18:53:14 +0900

1. 오늘의 목표

언리얼 엔진 구조를 참고하여 DirectX 12 기반의 복셀 렌더링 엔진 준비
M0 마일스톤: “주행 가능한 최소 엔진” 완성
- Win32 창 생성
- Core / Engine 모듈 초기화 루프
- DX12 Agility SDK + DXC 설정
- RHI(D3D12) 초기화 → 화면 클리어 & Present

2. 작업 순서 & 진행 내용

(1) 프로젝트 구조 준비

VS2022 기반 프로젝트 생성
모듈 설계: Core, Engine, RHI, D3D12RHI
AppMain.cpp에서 WinMain 엔트리 작성, ESC 종료 처리

LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) {
    if (msg == WM_DESTROY) { PostQuitMessage(0); return 0; }
    if (msg == WM_KEYDOWN && wParam == VK_ESCAPE) DestroyWindow(hWnd);
    return DefWindowProc(hWnd, msg, wParam, lParam);
}

(2) Agility SDK & DXC 설정

NuGet 패키지 설치
- Microsoft.Direct3D.D3D12 (Agility SDK)
- Microsoft.Direct3D.DXC (HLSL 컴파일러)
Agility SDK 로딩 설정 (AppMainAgilityExports.cpp)

extern "C" {
__declspec(dllexport) extern const unsigned int D3D12SDKVersion = 616;
__declspec(dllexport) extern const char*       D3D12SDKPath    = u8".\\";
}

Post-Build 이벤트로 DLL 복사 설정

(3) 빌드 에러 해결 과정

#include 경로 문제 → Additional Include Directories에 $(ProjectDir)Core; $(ProjectDir)Engine 추가
WinMain 링크 오류 → 서브시스템을 Windows (/SUBSYSTEM:WINDOWS)로 변경
SAFE_HR 매크로 오류 → SAFE_HR_V(void 전용) 매크로 추가
CD3DX12_ 타입 인식 안됨* → 최신 d3dx12.h 추가 및 인클루드
D3D12/DXGI unresolved externals → #pragma comment(lib, "d3d12.lib") 등 추가

(4) RHI & D3D12 초기화

RHI 인터페이스 설계: IRHI
FD3D12RHI 구현: Device, Queue, SwapChain, RTV Heap, Fence
BeginFrame → RenderTarget Clear → EndFrame → Present

float clear[4] = {0.07f, 0.07f, 0.12f, 1.0f};
mCmd->OMSetRenderTargets(1, &rtv, FALSE, nullptr);
mCmd->ClearRenderTargetView(rtv, clear, 0, nullptr);

(5) 링크 라이브러리 역할

라이브러리 역할 실행 시 로드되는 DLL 예시 심볼

d3d12.lib	D3D12 API 함수 연결	d3d12.dll / d3d12core.dll	D3D12CreateDevice
dxgi.lib	DXGI API 함수 연결	dxgi.dll	CreateDXGIFactory2
dxguid.lib	DirectX GUID/CLSID 상수 포함	(없음)	IID_ID3D12Device

3. 오늘 해결한 주요 질문 & 답변

질문 핵심 답변

WinMain인데 main 못 찾는 LNK2019	서브시스템을 Windows로 변경
include 경로 에러	Additional Include Directories 설정
SAFE_HR 매크로 에러	void 함수 전용 SAFE_HR_V 추가
CD3DX12_* 인식 불가	d3dx12.h 추가 & 인클루드
D3D12/DXGI unresolved externals	d3d12.lib, dxgi.lib, dxguid.lib 링크

4. 결과

Debug/Release 모두 빌드 성공
창 생성 후 배경색 클리어 & Present 정상 동작
M0 단계 완료 → 다음은 WM_SIZE 처리 + 프레임 타이머 + ImGui 디버그 UI 예정

5. 배운 점

Agility SDK와 DXC 설정은 NuGet + EXE 심볼 export로 간단히 가능
Win32 서브시스템/링크 설정은 main/WinMain 호출 차이의 핵심
DirectX 라이브러리 3종(d3d12.lib, dxgi.lib, dxguid.lib)의 역할과 DLL 로딩 순서 이해
d3dx12.h 헬퍼는 필수 수준 (리소스 배리어, 핸들 계산 등)

[C/C++] 조건문 컴파일러 최적화

LazySonic — Thu, 22 May 2025 19:36:17 +0900

if문이 컴파일러가 switch로 대체할 수 있을 만큼 간단하고 내부에서 간단한 함수 콜을 한다면, 컴파일 타임에 Jump Table을 만들어 이를 기반으로 함수를 콜해주도록 최적화된다.

예를 들면, 아래와 같은 if else 문과 switch문이 있다고 가정하자.

void dispatch(int x) {
    if (x == 0) f0();
    else if (x == 1) f1();
    else if (x == 2) f2();
    else if (x == 3) f3();
}

// switch로 변환
switch (x) {
    case 0: f0(); break;
    case 1: f1(); break;
    case 2: f2(); break;
    case 3: f3(); break;
}

이는 컴파일러가 어샘블리로 다음과 같이 전환한다.

jmp [jump_table + eax * 4]

구축된 점프 테이블과 인자를 갖고, 단순하게 함수로 점프 콜 해버린다.

여기서 주의해야 할 점은 인자로 enum이 들어오는 경우 switch에서 default를 사용할 수 있는데 이 때는 다소 주의를 해야 한다.

이는, default 아래 작성되는 로직은 jump_table에 넣지 못 하기 때문인데 이런 문제로 컴파일러의 최적화 과정을 믿을 수 없다면 다음과 같은 방법을 사용하면 좋다.

void (*handlers[3])() = { handleCase0, handleCase1, handleCase2 };
handlers[x](); // 조건 없이 바로 호출

[UE5/GAS] GamePhase Ability

LazySonic — Mon, 19 May 2025 14:01:37 +0900

GamePhaseSubsystem

StartPhase : GameState에서 관리하는 ASC에 어빌리티 부여
OnBeginPhase : 이미 부여되어있던 GamePhaseAbility를 찾아, 'CancelAbilitiesByFunc' 호출을 통해 취소

GamePhaseAbility

GamePhaseSubsystem에 의해 부여되는 어빌리티

[OS] CPU 스케쥴링 (CPU Scheduling)

LazySonic — Sat, 3 May 2025 01:21:30 +0900

3️⃣ CPU 스케줄링 (CPU Scheduling)

✅ 왜 스케줄링이 필요한가?

컴퓨터 시스템은 멀티태스킹 환경에서 여러 프로세스가 동시에 실행되는 것처럼 보이지만, 실제로는 한정된 CPU가 프로세스를 순차적으로 실행합니다. 따라서 운영체제는 어떤 프로세스가 언제 CPU를 차지할지 결정해야 합니다. 이게 바로 스케줄링이에요.

✅ 스케줄링 시점

Non-preemptive (비선점):
- 현재 실행 중인 프로세스가 CPU를 자발적으로 내놓을 때만 스위칭.
Preemptive (선점형):
- OS가 강제로 CPU를 회수하여 다른 프로세스에 할당 가능.

대부분의 현대 OS는 선점형 스케줄링을 사용합니다.

✅ 주요 스케줄링 알고리즘

알고리즘 설명 특징

FCFS (First-Come First-Served)	먼저 도착한 프로세스부터 순차 실행	구현 간단 / 긴 대기시간 발생 가능
SJF (Shortest Job First)	실행 시간이 가장 짧은 프로세스를 우선 실행	평균 대기시간 최소 / 실행 시간 예측 필요
Priority Scheduling	우선순위 높은 프로세스부터 실행	기아(Starvation) 문제 발생 가능
Round Robin (RR)	고정된 시간 할당(Quantum) 후 선점하여 순환	응답 시간 개선 / Context Switch 오버헤드 발생
Multilevel Queue	여러 큐로 분류(예: 상호작용/배치) 후 각 큐 별 알고리즘 적용	복잡한 환경 최적화 가능
Multilevel Feedback Queue	우선순위 큐 + 동적 이동 (실행 패턴에 따라 큐 위치가 바뀜)	매우 유연 / 구현 복잡

✅ 평가 지표

CPU Utilization (CPU 이용률): 얼마나 CPU가 바쁘게 일하는지.
Throughput (처리량): 단위 시간당 완료된 프로세스 수.
Turnaround Time (반환 시간): 프로세스 제출 → 완료까지 걸린 시간.
Waiting Time (대기 시간): 프로세스가 Ready 상태로 기다린 총 시간.
Response Time (응답 시간): 프로세스 제출 → 첫 응답까지의 시간.

이 지표들은 서로 Trade-off 관계가 있으므로 OS의 목적에 따라 우선순위가 달라집니다.

스케줄링 평가 지표 간의 연관 공식

다음 3가지가 서로 밀접하게 연결되어 있습니다:

1️⃣ Turnaround Time (반환 시간)
2️⃣ Waiting Time (대기 시간)
3️⃣ Burst Time (실행 시간)

✅ 공식 ①

Turnaround Time (TAT)

Turnaround Time=Completion Time−Arrival Time\text{Turnaround Time} = \text{Completion Time} - \text{Arrival Time}

즉, 프로세스가 들어온 시점부터 끝나는 시점까지 전체 소요 시간입니다.

✅ 공식 ②

Waiting Time (WT)

Waiting Time=Turnaround Time−Burst Time\text{Waiting Time} = \text{Turnaround Time} - \text{Burst Time}

Burst Time (BT): CPU에서 실제로 실행된 시간.

따라서:

WT=(CT−AT)−BTWT = (CT - AT) - BT

이 공식은 대기 시간 = 전체 걸린 시간 - 실제 실행 시간이라는 의미예요.

✅ 공식 ③

Response Time (RT)

Response Time=First CPU Start Time−Arrival Time\text{Response Time} = \text{First CPU Start Time} - \text{Arrival Time}

Round Robin 등에서는 Response Time이 중요하며, 첫 응답 시점을 측정합니다.

✅ 정리된 공식 관계

지표 공식

Turnaround Time (TAT)	Completion Time (CT) - Arrival Time (AT)
Waiting Time (WT)	Turnaround Time (TAT) - Burst Time (BT)
Response Time (RT)	First Execution Start Time - Arrival Time (AT)

예제

프로세스: P1 (AT=0, BT=5)

CT = 10
AT = 0
BT = 5
TAT = 10 - 0 = 10
WT = 10 - 5 = 5
(만약 첫 실행이 3초에 시작했다면) RT = 3 - 0 = 3

✅ 결론

평가지표들은 서로 긴밀하게 연결되어 있어, 한 지표만 알면 나머지를 유추할 수 있습니다. 다만, 스케줄링 정책이나 프로세스 간 선점 여부에 따라 값이 달라질 뿐, 기본 공식은 일정합니다.

✅ 심화: 다중 프로세서 스케줄링

멀티코어 환경에서는 스케줄링이 더 복잡해집니다.

대칭형 (SMP): 모든 CPU가 OS의 스케줄링 알고리즘을 공유.
비대칭형 (AMP): 한 CPU가 스케줄링만 담당.

Load Balancing: 각 CPU에 작업을 고르게 분배해야 병목을 방지할 수 있음.

다중 프로세서 스케줄링의 Load Balancing

목표:
CPU가 여러 개 있을 때 특정 프로세서만 과부하 걸리는 걸 방지하고, 작업을 고르게 분산하여 전체 시스템 효율을 높이는 것.

✅ Load Balancing 방식

1️⃣ Central Queue 방식

설명: 모든 CPU가 하나의 공통 큐에서 작업을 가져감.
장점: 자연스럽게 부하가 균형을 이룸.
단점: 큐 자체가 병목이 될 수 있음 (Lock 경쟁).

예: 단순한 멀티코어 OS, 예제 수준의 스케줄러.

2️⃣ Local Queue + Work Stealing 방식

설명: 각 CPU는 자신만의 로컬 큐를 가지고 작업을 관리.
부하가 한쪽에 몰리면 작업이 없는 CPU가 다른 CPU에서 작업을 "훔쳐옴".
장점: 병렬성이 뛰어나고 큐 병목이 줄어듦.
단점: Stealing 시 약간의 오버헤드 발생.

예:

Linux CFS (Completely Fair Scheduler)에서 NUMA-aware 로드 밸런싱 시.
멀티스레딩 라이브러리(TBB, Go 런타임 등).

3️⃣ Periodic Balancing (주기적 균형 재조정)

설명: 스케줄러가 일정 시간마다 CPU별 로드 상태를 점검하고 불균형 시 프로세스를 재배치.
장점: 단순하지만 안정적.
단점: 너무 잦으면 오버헤드 발생.

4️⃣ Push vs Pull 전략

Push:
- 과부하가 걸린 CPU가 스스로 일부 작업을 다른 CPU로 밀어냄.
Pull:
- 빈 CPU가 적극적으로 다른 CPU에서 작업을 가져옴.

현대 OS들은 보통 Push + Pull 혼합 전략을 씁니다.

✅ 심화 예시: Linux CFS

다중 러너블 큐 (Per-CPU Runqueue)
Idle CPU는 Steal 우선 / 부하 심하면 Push도 수행
NUMA 환경에선 메모리 locality도 고려

✅ 간단 비교표

방식 특징

Central Queue	단순 / 병목 발생 가능
Local Queue + Stealing	고성능 / 구현 복잡
Periodic Balancing	간단 / 자주 하면 오버헤드
Push / Pull	균형 감시 / 유연한 분산

정리: 현대의 다중 프로세서 스케줄러는 Local Queue + Work Stealing + Periodic Rebalance 같은 복합적인 방식을 채택해 높은 병렬성과 효율을 추구합니다.

✅ 심화: 실시간 스케줄링

실시간 시스템은 데드라인이 핵심입니다.

Hard Real-Time: 데드라인 미스 절대 금지 (항공, 의료).
Soft Real-Time: 데드라인 미스 가능하지만 성능 저하 (멀티미디어).

알고리즘:

Rate Monotonic (RM)
Earliest Deadline First (EDF)

간단한 Round Robin 예시 (C++)

#include <iostream>
#include <queue>

struct Process {
    int id;
    int burst;
};

int main() {
    std::queue<Process> q;
    q.push({1, 5});
    q.push({2, 10});
    q.push({3, 7});

    int quantum = 3;

    while (!q.empty()) {
        Process p = q.front(); q.pop();
        if (p.burst > quantum) {
            std::cout << "Process " << p.id << " runs for " << quantum << "\n";
            p.burst -= quantum;
            q.push(p);
        } else {
            std::cout << "Process " << p.id << " finishes\n";
        }
    }
}

✅ 스케줄링의 핵심 요약

선점형 스케줄링은 컨텍스트 스위치를 동반하며 응답성이 좋음.
알고리즘 선택은 시스템의 특성(대화형? 배치형? 실시간?)에 따라 달라짐.
현대 OS들은 대개 Multilevel Feedback Queue 같은 복합 스케줄러를 사용.

[OS] 프로세스 관리

LazySonic — Sat, 3 May 2025 01:06:27 +0900

2️⃣ 프로세스 관리 (Process Management)

✅ 프로세스란?

**프로세스(Process)**는 실행 중인 프로그램의 인스턴스입니다. 단순한 프로그램 코드가 실제 메모리에서 실행되면서 **자원(CPU, 메모리, 파일 등)**을 할당받은 존재예요.

구성 요소:

프로그램 코드 (텍스트 섹션)
프로세스 스택 (함수 호출, 지역변수)
데이터 섹션 (글로벌 변수)
힙 (동적 할당)
프로세스 상태 정보 (레지스터, 프로그램 카운터 등)

✅ 프로세스 상태 (Process States)

New: 생성 중
Ready: 실행 준비 상태
Running: CPU에서 실행 중
Waiting (Blocked): I/O 등 대기 중
Terminated: 실행 종료

✅ 프로세스 제어 블록 (PCB)

운영체제가 각 프로세스를 관리하기 위해 사용하는 데이터 구조입니다.

포함 내용:

프로세스 ID (PID)
프로세스 상태
프로그램 카운터
CPU 레지스터
메모리 관리 정보
계정 정보 (UID 등)
I/O 상태 정보

컨텍스트 스위칭 시 이 PCB 정보가 저장/복원됩니다.

✅ 프로세스 계층 및 관계

부모/자식 프로세스:
- fork() 시스템 콜로 부모 → 자식 생성
프로세스 트리: 계층적 구조

✅ 멀티프로세싱과 멀티스레딩

구분 멀티프로세싱 멀티스레딩

정의	여러 프로세스가 동시에 실행	하나의 프로세스 내에서 여러 쓰레드 실행
메모리 공간	각자 독립적	메모리(힙, 데이터)는 공유
예시	여러 브라우저 인스턴스	웹 페이지 렌더링 + 다운로드 동시 진행

✅ 프로세스 생성 & 종료 (UNIX 기준)

생성: fork(), exec()
종료: exit()
좀비 프로세스: 부모가 자식의 종료 상태를 수거하지 않으면 생김 (wait() 필요)

✅ 쓰레드 개념 (간략)

쓰레드는 프로세스 내의 경량 실행 단위로, 프로세스와 달리 같은 주소 공간을 공유합니다. 프로세스와 다르게 오버헤드가 작아 빠른 병렬 처리가 가능합니다.

POSIX Thread (pthreads)
C++11 이후: std::thread

C++ 간단 예시

#include <iostream>
#include <thread>

void task() {
    std::cout << "Hello from thread!\n";
}

int main() {
    std::thread t(task);
    t.join();  // join 호출 안 하면 메인 종료 시 크래시
}

✅ 심화 개념

컨텍스트 스위칭 비용:
- 프로세스 간: 무겁다 (메모리 맵까지 바꿔야 함)
- 쓰레드 간: 상대적으로 가볍다
프로세스 간 통신 (IPC):
- 파이프, 소켓, 공유 메모리, 메시지 큐

"스핀락을 사용할 때, 컨텍스트 스위칭 비용은 원칙적으로 발생하지 않습니다."

하지만 조건이 있습니다.

✅ 왜 컨텍스트 스위칭 비용이 발생하지 않나?

일반적인 std::mutex나 OS 커널 수준의 뮤텍스는 락을 획득하지 못하면 **커널에 제어권을 넘기고 대기 상태(블록 상태)**로 전환되며 컨텍스트 스위치가 발생합니다.
반면 **스핀락(SpinLock)**은:
- 락을 잡을 때까지 계속 루프를 돌면서(active waiting) CPU를 점유합니다.
- 다른 쓰레드로 전환되지 않고 현재 쓰레드가 계속 CPU를 차지합니다.

따라서:

스핀락을 사용하는 동안에는 쓰레드가 블록되지 않으므로 컨텍스트 스위칭이 발생하지 않습니다.
이 때문에 락 대기 시간이 매우 짧은 상황에서는 스핀락이 mutex보다 빠를 수 있어요.

그런데 주의할 점

스핀락은 컨텍스트 스위칭은 안 하지만, CPU 자원을 낭비합니다. CPU 코어 하나가 그 락을 기다리며 계속 바쁘게 루프를 돌기 때문입니다.
운영체제의 스케줄러가 "이건 너무 오래 스핀만 돈다"라고 판단하면 강제로 다른 스레드로 전환시킬 수 있습니다. 이건 운영체제 스케줄링 정책에 따라 다릅니다만, 긴 스핀은 결국 컨텍스트 스위치를 유발할 가능성이 있습니다.

✅ 정리

질문 답변

스핀락 사용 시 컨텍스트 스위칭이 발생하는가?	아니요, 기본적으로 발생하지 않습니다.
언제든 컨텍스트 스위치가 발생할 수 있는가?	OS 스케줄러가 개입하거나 타임 슬라이스가 끝나면 발생할 수 있습니다.
락 점유 시간이 길면 어떤 문제가 생기는가?	스핀락이 비효율적이고, 결국 컨텍스트 스위칭이 발생할 수도 있습니다.

따라서, 짧은 임계구역에서는 스핀락이 유리하지만, 긴 대기 시간이 예상되면 일반 mutex 같은 커널 락을 쓰는 게 안전합니다.

[OS] 운영체제 개요

LazySonic — Sat, 3 May 2025 01:05:46 +0900

1️⃣ 운영체제 개요 (Introduction to Operating Systems)

✅ 운영체제란?

운영체제(OS)는 컴퓨터 하드웨어와 사용자 프로그램 사이에 위치하는 시스템 소프트웨어입니다. **자원 관리(Resource Management)**와 인터페이스 제공이 주된 역할이에요.

✅ 주요 기능

프로세스/스레드 관리
- CPU 스케줄링, 동기화, 교착상태 방지 등
메모리 관리
- 메모리 할당, 가상 메모리, 캐싱 등
저장장치 관리
- 파일 시스템, 디스크 스케줄링 등
입출력(I/O) 관리
- 장치 드라이버, 버퍼링 등
보호 및 보안
- 사용자 권한, 데이터 보호
사용자 인터페이스 제공
- CLI (Command Line), GUI (Graphical User Interface)

✅ 운영체제의 역할

자원 관리자 (Resource Manager):
- CPU, 메모리, 디스크, I/O 장치 같은 하드웨어 자원의 효율적 관리.
프로그램 실행 환경 제공:
- 사용자 프로그램들이 하드웨어를 직접 만지지 않도록 보호하며 실행되도록 함.
추상화 (Abstraction):
- 하드웨어 자원의 복잡성을 감춤 (예: 파일 시스템이 디스크의 실제 구조를 숨김).

✅ OS의 분류

Batch 시스템: 작업을 모아서 일괄 처리 (초창기 컴퓨터)
Time Sharing: 여러 사용자가 동시에 사용하는 시스템 (멀티태스킹)
Real-Time OS: 즉각 반응이 필요한 시스템 (항공, 의료)
멀티프로세싱 OS: 여러 CPU를 지원 (대형 서버)
분산 OS: 네트워크를 통한 자원 공유 (클러스터, 클라우드)

✅ 커널 구조

Monolithic Kernel: 커널 내 모든 기능을 하나의 큰 블록으로 구현 (Linux)
Microkernel: 최소한의 핵심만 커널에 두고 나머지는 사용자 모드에서 실행 (Minix)
Hybrid: 두 가지의 장점을 섞음 (Windows NT)

✅ 사용자/커널 모드

커널 모드: 하드웨어 직접 접근 가능 (운영체제 코드)
사용자 모드: 제한된 권한 (일반 앱)

OS는 시스템 콜(system call)을 통해 사용자 모드 ↔ 커널 모드 전환을 제공합니다.

[OS] 운영체제 커리큘럼

LazySonic — Sat, 3 May 2025 01:04:48 +0900

운영체제(OS) 강의에서 다루는 커리큘럼은 대체로 컴퓨터 구조, 병렬성, 메모리 관리, 자원 관리를 단계적으로 배우게 구성됩니다.

여기서는 일반적인 CS 학부 과정을 기준으로 커리큘럼을 설명할게요:

1️⃣ 운영체제 개요

핵심 개념:

운영체제의 정의와 역할
사용자 ↔ 하드웨어 사이의 인터페이스
OS 구조 (커널, 쉘, 사용자 모드/커널 모드)

배경:

Batch → Time Sharing → Multiprocessing → Modern OS 발전사

2️⃣ 프로세스 관리

프로세스와 쓰레드 개념
프로세스 상태 (Ready, Running, Blocked)
프로세스 제어 블록 (PCB)
컨텍스트 스위칭
쓰레드의 등장과 멀티스레딩

심화:

멀티프로세싱과 멀티스레딩 비교
Thread Pool 패턴

3️⃣ CPU 스케줄링

스케줄링 알고리즘:

FCFS (First-Come, First-Served)
SJF (Shortest Job First)
Priority Scheduling
Round Robin
Multilevel Queue

평가 지표:

응답 시간, 대기 시간, 처리량, CPU 이용률

심화:

다중 프로세서 스케줄링
실시간 스케줄링 (RTOS)

4️⃣ 동기화 문제

임계구역 문제(Critical Section Problem)
경쟁 상태(Race Condition)
동기화 도구:
- Mutex, Semaphore, Monitor, SpinLock
고전적 문제:
- 생산자-소비자 문제
- 철학자들의 식사 문제
- 독자-작가 문제

심화:

데커, 피터슨 알고리즘
Test-and-Set, Compare-and-Swap

5️⃣ 교착 상태(Deadlock)

필요 조건 (Mutual Exclusion 등)
자원 할당 그래프
Deadlock 예방, 회피 (Banker's Algorithm), 탐지, 회복

6️⃣ 메모리 관리

주소 공간 (논리, 물리 주소)
MMU (Memory Management Unit)
연속 할당:
- First Fit, Best Fit, Worst Fit
분산 및 외부 단편화

가상 메모리:

페이징, 세그먼트
페이지 교체 알고리즘:
- FIFO, LRU, Optimal
TLB (Translation Lookaside Buffer)

7️⃣ 스토리지 관리

디스크 구조 (플래터, 실린더, 섹터)
디스크 스케줄링:
- FCFS, SSTF, SCAN, C-SCAN
파일 시스템:
- 디렉토리 구조
- 파일 할당 방식 (연속, 연결, 인덱스)
- FAT, i-node

8️⃣ 입출력 시스템

I/O 장치 개요
동기 vs 비동기 I/O
인터럽트, DMA (Direct Memory Access)
버퍼링, 캐싱

9️⃣ 보안 & 보호

보안과 보호 차이
접근 제어 매트릭스
유저 인증 및 권한 관리
멀웨어 방지 개념

심화/특수 주제 (선택적으로 다룸)

멀티코어/멀티CPU 환경
분산 시스템 (RPC, 분산 파일 시스템)
클라우드 운영체제 개념
모바일 OS (안드로이드/iOS 구조)
최신: 컨테이너화(Linux cgroup, namespace)

보통 참고하는 교재

Operating System Concepts (Silberschatz) — 소위 공룡책
Modern Operating Systems (Tanenbaum)
Operating Systems: Three Easy Pieces (OSTEP) — 무료 PDF로도 유명

[컴구론] 캐시 히트와 미스 탐구

LazySonic — Thu, 1 May 2025 17:22:31 +0900

캐시 히트(Cache Hit) 와 미스(Cache Miss) ― “명령어·데이터가 어디에 있느냐가 속도를 좌우한다”

캐시가 하는 일, 10초 요약

CPU ↔ DRAM 속도 차가 수 10 배 이상 → 중간에 SRAM 캐시(L1/L2/L3) 를 끼워서 ‘자주 쓰는 데이터’를 가까운 곳에 복사해 둔다.
히트: CPU가 요구한 주소가 이미 캐시에 있음 → 수 ns 내 응답.
미스: 캐시에 없음 → DRAM(또는 하위 캐시)까지 내려가 수 10 ns~㎲ 지연 후 캐시에 라인(line) 단위로 불러와 재시도.

명령어 사이클 관점으로 보면 Memory 단계에서 AGU→MAR→(Cache) 시점에 히트/미스가 갈린다.
미스가 나면 CU가 파이프라인을 스톨하거나 OoO 코어는 다른 μop로 지연을 ‘가린다’.

지역성(locality) = “다시 쓸 확률”

종류 뜻 코드 패턴 캐시 영향

시간 지역성(Temporal)	방금 접근한 주소를 곧 또 쓴다	누적 변수 sum += a[i]·루프 카운터	동일 라인이 L1에 남아 히트율↑
공간 지역성(Spatial)	근처 주소도 곧 사용한다	① 선형 배열 순회 i=0‥N-1② 구조체 내부 연속 멤버	캐시는 64 B 라인 단위로 로드 → 옆 데이터가 “덤”으로 따라옴

규칙 “가까이·많이·다시” 액세스하는 코드는 대부분 캐시 친화적이다.

히트 vs 미스 — 작동 흐름 비교

단계 히트 (L1 Hit) 미스 (L1 Miss → L2)

① 태그 비교	태그 일치	불일치
② 데이터 반환	4 ns 내 레지스터로 포워딩	L2 Cache 요청(8–12 ns)
③ 캐시 갱신	없음	하위 캐시에서 64 B 라인 전체 상위 캐시에 복사
④ 파이프라인 영향	노 버블	Load μop → Stalled, 다른 μop 스케줄 시도
⑤ 전력 소모	수 pJ	L2/L3 버스 + DRAM 액세스 → nJ 단위 ↑

미스의 4가지 종류 (3C + Coherence)

이름 발생 원인 예시 / 해결책

Compulsory	처음 보는 주소 (Warm-up)	프리페치, 큰 라인
Capacity	전체 작업 집합 > 캐시 용량	더 큰 캐시, SW 타일링
Conflict	같은 인덱스에 다른 태그 충돌(Set 2-way↓)	연관도↑(4/8-way), 주소 재배치
Coherence	멀티코어가 같은 라인 수정	MESI 프로토콜, NUCA 디자인

성능 지표: AMAT 공식을 기억하자

AMAT = Hit Time + Miss Rate × Miss Penalty

Hit Time: L1 히트 시 지연 (e.g., 4 ns)
Miss Rate: L1 요청 중 미스 비율 (e.g., 5 %)
Miss Penalty: 미스→DRAM 왕복 지연 (e.g., 50 ns)

예) (4 ns) + 0.05 × 50 ns = 6.5 ns ⇒ 히트율을 95→97 %로만 올려도 실효 지연이 5.5 ns로 떨어진다.

캐시 친화적 코드 감각

패턴 히트↑ 이유 간단 예

연속 스캔(Sequential)	공간 지역성	for(i=0;i<N;i++) sum+=A[i];
블록 타일링	작동 집합(Block) < 캐시 용량	2 D 행렬 곱에서 for(i, j, k in tile)
구조체 패킹	더 많은 객체가 한 라인	struct 멤버 정렬 · 압축
Hot/Cold 분리	자주 쓰는 필드만 캐시 사용	게임 컴포넌트 데이터 레이아웃

파이프라인과의 상호 작용

In-Order 코어(임베디드): 미스 = 파이프라인 전면 Stall → CPI 급등
Out-of-Order 코어(데스크톱/서버): 독립 μop 먼저 실행해 숨어 있는 ILP 로 미스 레이턴시 가리기
멀티스레드(SMT): 다른 하드웨어 스레드로 슬랏을 채워 ‘빈 시간’ 활용
프리페처: CU 앞단에서 선형·스트라이드 패턴을 예측 → 미스 전에 라인 미리 로드

기억해 두면 좋은 숫자 (서버-급, 2025년 기준)

계층 용량 레이턴시(Hit) BW

L1 I/D	64 KB 각	4 cycles (≈ 1 ns)	1.5 TB/s
L2 (Private)	1 MB	12 cycles	0.7 TB/s
L3 (Shared)	32 MB	40 cycles	0.3 TB/s
DDR5 DRAM	수 GB	150 cycles (≈ 55 ns)	100 GB/s

핵심 정리

캐시 히트는 “데이터가 이미 가까이 있다” → 클럭 몇 번 안에 끝.
캐시 미스는 “데이터를 밑에서 끌어올려야 한다” → 파이프라인이 수 10 ~ 수 100 클럭 지연, 전력도 ↑.
설계자는 정책(연관도·교체·프리페치)과 용량, 개발자는 지역성·데이터 레이아웃 최적화로 Miss Rate × Miss Penalty를 줄여 성능과 전력을 모두 잡는다.

히트 ↔ 미스-흐름 (복습)

L1 Hit        : 4 cycles
L1 Miss → L2  : 12 cycles
L2 Miss → L3  : 40 cycles
L3 Miss → DRAM: 150 cycles ⚠️

AMAT = HitTime + MissRate × MissPenalty ⟶ 지역성을 살리면 MissRate가 뚝↓

Hot/Cold 분리(Hoisting) — 게임 개발 예시

문제

struct Monster {
    Vec3 position;
    float health;
    bool isAlive;
    // ↓ 드물게 쓰는 데이터
    std::string name;
    std::array<Item, 16> inventory;
    AIState brain;
};

Update Loop(60 FPS)에서는 position, health, isAlive만 매 프레임 접근
name·inventory·brain 은 이벤트 발생 시에만 사용
한 구조체에 섞여 있으므로 64 B 라인에 불필요한 Cold 데이터까지 끌어올려 L1 압박 → 미스 증가

해결 – Hot/Cold 분할

// Hot — 매 프레임 필드만
struct MonsterCore {
    Vec3  position;
    float health;
    bool  isAlive;
    uint32_t coldIndex;   // Cold 배열 인덱스
};

// Cold — 희소 액세스 필드
struct MonsterCold {
    std::string name;
    std::array<Item, 16> inventory;
    AIState brain;
};

// 게임 월드 컨테이너
std::vector<MonsterCore> monsters;        // Tightly packed  
std::vector<MonsterCold> monstersCold;    // Sparse ❄️

void UpdateMonsters(float dt)
{
    for (auto& m : monsters)
    {
        if (!m.isAlive) continue;
        m.position += ComputeVelocity(m) * dt;
        // 건강 체크 등 Hot 데이터만 사용 → L1/L2 Hit !
    }
}

Hot 배열은 연속 배열 → 공간 지역성 덕분에 한 번 미스 후 파이프라인이 대부분 히트
Cold 배열은 이벤트룩 등에서만 액세스 → 캐시 오염 최소
큰 규모(수만 엔티티)에서 프레임당 L1 miss 수가 두 자릿수 % 감소하는 것이 흔하다

요약 체크리스트

캐시 친화 코드 작성 법 왜 그런가?

연속 순회(배열 > 연결리스트)	공간 지역성, HW 프리페처가 다발 히트
타일링(행렬 2 D)	작동 집합을 L1/L2 용량 안에 고정
Hot/Cold 분리	불필요한 라인 로드·교체 감소
구조체 패킹 / SoA	구조 개수 ↑ = 같은 L1 라인에 더 많은 요소

핵심 한 줄

시간·공간 지역성을 살리고 Hot/Cold 데이터를 떼어놓으면 L1/L2 히트율이 올라가고 DRAM 미스 패널티가 줄어, 게임 루프·물리 시뮬레이션 등 프레임 결정 로직에서 눈에 띄는 성능·전력 이득을 얻는다.

[컴구론] 명령어 사이클과 인터럽트

LazySonic — Thu, 1 May 2025 17:14:09 +0900

CPU Instruction Cycle

단계 핵심 전용 레지스터 세부 흐름 (→ 는 데이터 이동) 메모

1️⃣ Fetch	PC(Program Counter) → MAR → Memory → MDR → IR	① PC 값을 MAR에 복사 (주소 버스)② I-Cache/TLB 경유하여 명령어 읽기③ 읽어온 32/64 bit 코드를 MDR(Memory Data Register) 에 임시 저장④ MDR 내용을 IR(Instruction Register) 로 이동⑤ PC ← PC + len (또는 분기·예외로 덮어쓰기)	“주소 지시 = MAR, 데이터 수신 = MDR, 보관 = IR”
2️⃣ Decode (ID)	IR, 레지스터 파일	• CU가 IR → opcode·오퍼랜드 분해• 레지스터 파일에서 src 값 읽기• 의존성·Hazard 검사, 스케줄 큐 등록	멀티-디코더, µ-op Cache
3️⃣ Execute (EX)	ALU/FPU, AGU(Address Gen Unit)	• ALU/FPU/SIMD로 산술·논리·분기 평가• Load/Store → AGU가 주소 계산: Base Reg + Offset	분기 결과 miss 시 파이프라인 flush
4️⃣ Memory (MEM)	AGU 주소 → MAR → Memory ↔ MDR	• AGU 주소를 다시 MAR에 로드• D-Cache Hit → MDR 로 데이터 수신• Store 일 경우 MDR ← 레지스터 데이터 → 메모리 기록 (쓰기 버퍼)	TLB·캐시·ECC 동작
5️⃣ Write-Back (WB)	MDR / ALU 결과	• 결과 → 레지스터 파일(RD 포트)• ALU 플래그 → 플래그 레지스터• OoO 코어는 ROB Commit 단계까지 완료	포워딩 · 리네이밍으로 의존성 가리기

그림 없이 흐름만 눈에 넣는 팁

PC → MAR → Mem → MDR → IR ─┐   (Fetch)
                           │
          RegSrc → ALU ----┤   (Execute)
                           ↓
            ALU / MDR → RegDst (Write-Back)

MAR(Memory Address Register) : “이번 버스 접근 주소”
MDR(Memory Data Register) : “메모리에서 막 주고받은 데이터”
IR(Instruction Register) : “방금 가져와 해석 중인 명령어”

단계 간 버블(지연)을 줄이는 주요 기법

Hazard 원인 대표 해결책

Data	lw r1… 바로 뒤 add r2,r1,r3	포워딩, 스톨 1클럭
Control	분기 목표 예상 실패	분기 예측기, Return Stack
Structural	IF·MEM 단계가 같은 캐시 병행 요청	I/D Cache 분리, 다중 포트

한 줄로 총정리

PC→MAR→Mem→MDR→IR 로 명령어를 집어오고, Decode·Execute 과정을 거쳐 AGU→MAR→Mem→MDR 로 데이터까지 주고받은 뒤, 결과를 레지스터에 Write-Back 한다. 이 전 경로를 파이프라인으로 겹쳐 돌리면서 슈퍼스칼라·OoO·캐시·분기예측으로 버블을 최소화하는 것이 현대 CPU 설계의 핵심이다.

인터럽트 + ISR(Interrupt Service Routine) ― “CPU가 비상 호출을 처리하는 끝-까지 흐름”

1️⃣ 인터럽트 한-줄 정의 — 왜 필요한가?

인터럽트 = “지금 실행 중이던 명령 흐름을 잠깐 멈추고, 더 급한 이벤트를 처리하라”는 하드웨어/소프트웨어 신호
예: 키보드 키 입력, SSD DMA 완료, 1 ms 타이머 Tick, 0으로 나누기 오류, 시스템 호출(int 0x80)

2️⃣ ISR 이란? (Interrupt Service Routine)

질문 답

무엇?	인터럽트가 발생했을 때 CPU가 자동으로 점프해 들어가는 작은 함수
어디에?	ISA별 인터럽트 벡터 테이블(IVT)에 등록된 시작 주소(벡터)
무엇을 하냐?	① 장치 플래그/데이터 읽기・초기화② 커널/OS에 이벤트 전달(큐에 push)③ 필요 시 후속 작업 예약(DMA 재개, Task wake-up)
제약	• 짧고 빠르게: 파이프라인 스톨을 최소화• 재진입 안전: 공유 데이터 보호(락, 원자 연산)• 스택 사용 최소: 컨텍스트 저장 분량 줄이기
복귀 방법	마지막에 iret/er et 처럼 특수 Return 명령으로 상태 복구 후 원래 PC로 점프

3️⃣ 명령어 사이클 + 인터럽트 + ISR = 11단계 “풀 경로”

# 단계 핵심 레지스터 이동(→) 일어나는 일

1-5	Fetch-Decode-Execute-Memory-Write Back	(PC→MAR→MDR→IR …)	정상 파이프라인
6	Interrupt Check	–	CU가 IRQ 라인 감지·우선순위 비교
7	Context Save	GPR/PC/FLAGS → MDR → Stack	자동 PUSH (SP 감소)
8	Vector Fetch	IVT[IRQ#] → MAR → MDR → PC	ISR 시작 주소 로드
9	ISR Execute	레지스터 ↔ ALU/메모리	장치 서비스, 플래그 클리어, OS 통지
10	Context Restore	Stack → MDR → GPR/FLAGS/PC	POP, 상태 복구
11	Return (IRET)	MDR → PC	파이프라인 재시동, 원래 코드 복귀

주의: OoO 코어에서는 단계 7 전에 ROB가 “Precise State”가 될 때까지 대기하여 정확한 인터럽트(Precise Interrupt) 를 보장합니다.

4️⃣ ARMv8-A 예시 ISR 스켈레톤

// Vector table에 등록된 타이머 IRQ 핸들러
.align 7
ISR_Timer:
    // --- Context Save (필요 최소)
    stp     x0, x1, [sp, #-16]!

    // --- 실질 서비스
    mrs     x0, cntpct_el0        // 현재 타이머 카운터 읽기
    add     x0, x0, #100000       // 다음 인터벌 설정
    msr     cntp_cval_el0, x0
    mov     w1, #0                // 인터럽트 클리어
    str     w1, [xIC]             // 장치 레지스터

    // --- Context Restore
    ldp     x0, x1, [sp], #16
    eret                        // PC·PSR 복귀

특징: 통상 수십~수백 사이클 안에 끝내도록 작성, ISR 내부에서 긴 루프·동적 할당 지양.

5️⃣ 성능·안정성을 지키는 실무 팁

항목 권장 사항

ISR 실행 시간	➜ 짧게. 무거운 작업은 작업 큐/스레드에 넘기기
중첩 인터럽트	➜ 우선순위 컨트롤러(APIC, GIC)로 관리, 필요 시 마스크
공유 데이터	➜ 락·원자 연산 또는 임계구역 금지
빈번한 IRQ	➜ 배치(Batching), 폴링 전환 고려 (예: NAPI)
디버깅	➜ perf record -e irq:* - 인터럽트 빈도 분석

한 문장으로 총정리

ISR은 인터럽트 발생 시 CPU가 뛰어드는 “미니 함수”로, 컨텍스트 자동 저장 → 벡터 점프 → 빠른 장치 서비스 → IRET 복귀 과정 속에 존재한다. 이를 명령어 파이프라인 뒤에 삽입한 인터럽트 사이클 덕분에 CPU는 외부 이벤트에 실시간으로 응답하면서도, 원래 실행 흐름과 데이터 일관성을 안전하게 유지할 수 있다.

[컴구론] ALU, 제어장치, 레지스터

LazySonic — Thu, 1 May 2025 17:05:04 +0900

ALU ‧ 제어장치(CU) ‧ 레지스터 ― “CPU 속 3대 핵심 블록” 심화 노트

회로 세부·최신 마이크로아키텍처 관점을 덧붙여 정리했습니다.

1. ALU (Arithmetic Logic Unit)

포인트 상세 설명

역할	정수 덧셈·뺄셈·증가/감소, 논리 AND/OR/XOR/NOT, 시프트·회전, 비교, 비트 카운트 등
하드웨어 핵심	• 가산기: Carry-Lookahead Adder(CLA)로 리플-캐리 지연을 O(log n)로 단축 ([PDF] Lecture 8:, [Carry Look-Ahead Adder
입력	ⓐ 두(또는 그 이상) 오퍼랜드 → 레지스터 파일에서 읽음 ⓑ 연산 선택 코드 → 제어장치가 ALU Control 라인으로 전송
출력	ⓐ 결과 → 레지스터 파일로 Write-back ⓑ 플래그 비트 → 플래그 레지스터로 전달 (분기·예외 결정)
모던 확장	• SIMD/Vector ALU (AVX-512, SVE2) : 128-2048 bit 병렬 • FMA ( a × b + c ) 유닛: FP·AI 가속 핵심 • 암호/비트 조작 확장* : RISC-V B·AES-NI

2. 제어장치 (CU, Control Unit)

구분 Hard-wired CU Micro-programmed CU

원리	상태 머신 + PLA로 고정 로직	명령어 → 마이크로코드 ROM → 제어신호
장점	속도↑, 전력↓	명령어 세트 수정·확장 용이
단점	ISA 변경 시 재설계 필요	ROM 지연, 패치 필요
현대 사용처	RISC 코어·DSP	x86 디코더, 복잡 ISA 백엔드 (Difference between Hardwired and Micro-programmed Control Unit, Hardwired v/s Micro-programmed Control Unit - GeeksforGeeks)

입·출력 신호

입력: IR(명령어), 플래그, 클럭, 외부 인터럽트·DMA 요청
출력: ALU Op, 레지스터 읽기/쓰기, 버스 RD/WR, 분기 PC mux 선택 등
파이프라인 제어: Hazard 스톨, 분기 Flush, Reorder Buffer Commit( OoO )

3. 레지스터(Registers) – “CPU 한가운데 캐시”

범주 대표 비고

프로그램 제어	PC/RIP, IR, CSR (status & control)	흐름·권한·예외 관리
데이터	GPR (x86 EAX… / ARM X0-X30)	산술·주소·임시 저장
메모리 연동	MAR, MDR/MBR	버스 인터페이스
스택·프레임	SP, BP/FP	함수 호출 규약
플래그	EFLAGS/APS-R/NZCV	ALU 상태 비트
특수·대형	SIMD(XMM/YMM/Z), Vector(V0..), System(TTBR, TPIDR)	128-2048 bit, MMU·스레드 ID
마이크로-아키텍처	물리 레지스터 + Rename Map	OoO 코어당 150-300개

대부분 현대 코어는 다중 포트 레지스터 파일(읽기 6-10, 쓰기 4-6)과 포워딩 네트워크를 갖춰 1 사이클 내 데이터 의존을 해결한다. (ARM Data Types and Registers (Part 2) - Azeria Labs, General Purpose Registers | GeeksforGeeks)

4. 세 블록이 협업하는 한 사이클 예 (RISC-V ADD x5,x1,x2)

Fetch — IR ⇠ I-Cache, PC + 4
Decode / CU — opcode=ADD → ALU_OP=ADD, src= x1/x2, dst=x5
Register Read — x1, x2 값 ALU 입력으로 포워딩
ALU Execute — 합산, 플래그 생성(ZF 등)
Write-back — 결과 → x5, CU가 분기 여부 판단(플래그 활용)

파이프라인 상태에 따라 위 단계들이 컨베이어처럼 엇갈려 흐르며, CU가 Hazard를 감시하고 ALU는 매 싸이클 다른 연산을 수행할 수 있다.

5. 학습 팁 & 실습 아이디어

무엇을 해보나 얻는 인사이트

가산기 RTL(Verilog) 시뮬레이션 + CLA 변환	리플-캐리 ↔ CLA 지연·게이트 수 비교
gdb / lldb 로 레지스터 덤프	함수 콜 전후 PC, SP, FP 변화 추적
Intel® VTune / perf 로 µop & stall 분석	ALU 포트 사용률·레지스터 재네임 관찰
RISC-V 툴체인으로 objdump	레지스터-중심 3-Address 명령 형식 체험

한 줄 정리

ALU는 “계산+플래그”, CU는 “시퀀서+신호”, 레지스터는 “초고속 기억”이다.
세 블록이 파이프라인·OoO·SIMD 같은 현대 기법과 엮이면서, 10⁹ 회/초 이상의 명령 처리가 가능해진다.

[컴구론] 명령어의 구조

LazySonic — Thu, 1 May 2025 16:57:36 +0900

0. 큰 그림 잡기

**명령어(Instruction)**는 CPU가 이해-실행할 수 있도록 비트 수준으로 인코딩된 최소 단위입니다.
가장 일반적인 틀은

┌──────────┬──────────┬────────────┐
│  Opcode  │ Operand  │  … Fields  │
└──────────┴──────────┴────────────┘

Opcode (Operation Code) – “무슨 연산을 하라”는 코드
Operand Field(s) – “어떤 데이터/주소에 대해 하라”는 정보
(선택) Address-mode bits, Immediate, Condition, Shift, Predication 등 추가 메타데이터 (Instruction Formats in Computer Architecture - Tutorialspoint)

1. 주소 개수(0-·1-·2-·3 Address)로 본 명령어 형식

주소 개수(0-·1-·2-·3 Address)란?

**명령어 인코딩에 “주소(오퍼랜드)를 몇 개까지 명시적으로 넣느냐”**를 말한다.
스택 꼭대기(TOS)·누산기(ACC)처럼 암시적(implicit) 피연산자는 개수에 포함되지 않는다.

1. 같은 식을 네 가지 형식으로 번역해 보기

목표 식 Z ← A + B

형식 기계 사고방식 어셈블리 예 메모 접근 수

0-Address(스택)	“스택에 올리고 계산”	PUSH APUSH BADD ; TOS = A+BPOP Z	3 load + 1 store
1-Address(누산기)	“ACC + M[addr]”	LOAD A ; ACC=AADD BSTORE Z	2 load + 1 store
2-Address(레지스터/메모리 혼용)	결과가 첫 피연산자에 덮어씀	MOV R1,AADD R1,B ; R1=R1+BMOV Z,R1	1 load + 1 store
3-Address(RISC)	“src1 + src2 → dst”	LD R1,ALD R2,BADD R3,R1,R2ST Z,R3	2 load + 1 store

0-Address는 스택 깊이만 관리하면 코드가 가장 짧고, 3-Address는 명령 하나가 ‘입력 2 + 출력 1’을 모두 지정해 병렬성 & 가독성이 최고다. (Instruction Formats (Zero, One, Two and Three Address Instruction))

2. 형식별 하드웨어·성능 특징

형식 하드웨어 조직 장점 단점

0-Addr	스택 레지스터 파일 (TOS 캐시)	코드 밀도↑, 디코더 단순	스택 톱니 구동 → 랜덤 접근 어려움, 반복 루프 오버헤드
1-Addr	ACC + 일반 메모리	인코딩 짧음, HW 간단	ACC 레이턴시가 곧 병목, 결과 덮어쓰기 많음
2-Addr	범용 레지스터 파일	명령 수 적음, 코드 밀도 괜찮음	피연산자 1개 파괴 → 추가 MOV 발생
3-Addr	레지스터 파일 + Load/Store 전용	레지스터 재사용 융통성, 파이프라인 쉽다	인코딩 비트 폭↑ → 코드 크기↑

3. 실존 ISA 예시

형식 대표 ISA / CPU 샘플 명령

0-Addr	JVM 바이트코드, Forth, 일부 DSP	iadd, fsub, dup
1-Addr	Intel 8080/8051, PDP-8	ADD 0x40(ACC←ACC+M[0x40]) ([PDF] Instruction Formats (Zero, One, Two and Three Address Instruction))
2-Addr	x86 (ALU), VAX	ADD [EAX], EBX (dst도 피연산자)
3-Addr	MIPS, RISC-V, ARM A-profile	ADD x3,x1,x2

4. 고급 주의 사항

혼합 사용 – x86은 메모리-to-레지스터 2-Address 모델이지만, 스택(0-Addr)인 FPU 명령도 갖는다.
VLIW·GPU – 3-Address 기반이면서 “슬롯”에 4-8개의 명령을 묶어 전송(VLIW)하거나 4-Address(FMA)처럼 연산+상수+오프셋까지 묶기도 한다.
컴파일러 관점 – SSA 중간 표현은 3-Address에 대응, 스택머신 바이트코드(JVM/WebAssembly)는 0-Address 패러다임을 따른다. JIT 단계에서 레지스터 배분이 필요.

핵심 한 줄

주소 개수 = 명령이 노출 하는 피연산자 슬롯 수. 0-Addr(스택) ↔ 3-Addr(RISC) 스펙트럼 어디에 두느냐가 코드 밀도·디코더 복잡도·병렬성을 결정한다.

2. 주소 지정(Addressing) 모음 — “오퍼랜드를 어디서 찾나?”

분류 비트 구성·동작 장점 단점

즉시(Immediate)	데이터가 명령어 안	가장 빠름	데이터 크기 제한
직접(Absolute)	필드=실제 주소	해석 단순	32-64 bit 주소 길이 부담
간접(Indirect)	필드→메모리→실주소	긴 주소 가능	메모리 2회 접근
레지스터 직접	필드=레지스터 번호	메모리 접근 X	레지스터 한정
레지스터 간접	레지스터 값=주소	짧은 코드+유연	1회 메모리만큼 지연
변위(베이스+오프셋)	Base Reg + Disp	코드 이식성, PIC	오프셋 비트 제한
PC-상대	PC + Disp (분기)	코드 위치 독립	범위 제한
묵시/스택	필드 없음, TOS 고정	코드 가장 짧음	HW가 스택 필요

3. 고정 vs 가변 길이·RISC vs CISC

ISA 길이 디코더 난이도 대표

고정 32 bit	한 번에 4 B 읽으면 완전	파이프라인 설계 단순	MIPS, RISC-V, ARMv8-A32
가변 1-15 B	Prefix·Opcode·ModRM·SIB…	x86 1-cycle 디코더 어려움 → μ-op Cache	x86-64, 68000
VLIW 64-256 bit	다수 연산을 한 “슬롯”에	HW 덜 복잡, SW스케줄러↑	Itanium, DSP
Compressed 16 bit	저전력·임베디드 코드 밀도↑	디코더 확장 필요	RISC-V C, ARM Thumb

*가변 길이 ISA(x86)*는 코드 밀도는 좋지만 디코더 전력과 분기 타겟 정렬이 복잡합니다. 반대로 고정 길이 RISC는 단순화된 디코더 덕분에 파이프라인을 깊게 하고 슈퍼스칼라 폭을 넓히기 쉽습니다. (Instruction Formats in Computer Architecture - Tutorialspoint)

4. 실전 인코딩 예시

4-1. MIPS R-Type 32 bit

31        26 25    21 20    16 15  11 10 6 5   0
┌─────────┬────────┬────────┬──────┬────┬─────┐
│ opcode  │   rs   │   rt   │  rd  │shmt│funct│
└─────────┴────────┴────────┴──────┴────┴─────┘
ADD $t0,$t1,$t2  →  000000 01001 01010 01000 00000 100000

opcode=0 ⇒ “R-type”, funct=0x20 ⇒ ADD
파이프라인은 opcode 만 읽어도 길이·필드 위치 고정이라 1-cycle Decode가 가능.

4-2. x86-64 가변 길이

66      0F      6F      44    24  10
└─prefix┘└opcode┘└ModRM┘└SIB┘└disp┘
MOVDQA XMM0, [RSP+16]

Prefix(0x66): SIMD size 바꿈
Opcode(0F 6F) + ModRM(44) + SIB(24) + Disp(10)
길이가 명령마다 달라 프런트엔드가 prefix 탐색 → 길이 계산 → 큐 과정을 거침. 최신 코어는 μ-op Cache로 복잡성을 완화. (Instruction Formats (Zero, One, Two and Three Address Instruction))

5. 형식이 CPU 성능에 미치는 영향

하드웨어 관점 형식 선택이 주는 영향

디코더 폭·전력	고정 길이 = 단순 하드와이어 / 가변 = 복잡한 테이블-루프
파이프라인 깊이	고정 길이일수록 FrontEnd 병목 완화 → 높은 GHz 가능
캐시 효율	코드 밀도↑(가변) ↔ I-Cache miss↓ vs Fetch-Align 복잡↑
분기 타깃 계산	고정=타깃 정렬 쉬움, 가변=BTB에 길이 예측 로직 필요
JIT·트랜스코더	중간 IR 변환 시 필드 위치가 명확할수록 최적화 용이

6. 최신 트렌드 & 학습 포인트

RISC-V: 기본 32 bit + 16 bit C-extension → IoT부터 서버까지 스케일.
ARMv9 SVE2/SME: 길이 불특정(128-2048 bit) 벡터 레지스터 → “Scalable ISA”.
Code-Size 압축: Apple M-시리즈는 하드웨어에서 x86->μ-op 트랜스코드로 캐시 압축.
Macro-op Fusion: x86의 CMP+Jcc → 1 μ-op으로 합쳐 디코더 대역 절감.
Security Tagging: ARM MTE, CHERI처럼 캡슐 태그를 명령 포맷에 추가해 메모리 안전성 확보.

정리 한 줄

명령어 포맷은 “어떤 비트가 무엇을 뜻하느냐”를 정의해 디코더 복잡도·코드 밀도·파이프라인 효율을 좌우하며, RISC-류의 고정 길이와 x86-류의 가변 길이는 각각 하드웨어 단순화 vs 코드 압축이라는 트레이드오프 상에서 진화하고 있습니다.