3D Gaussian Splatting을 실시간 게임 배경 에셋으로 변환하는 파이프라인
3D Gaussian Splatting 캡처 데이터를 게임용 배경으로 전환하는 방법을 정리한다. PLY 정리, 셀 분할, 메시·임포스터 베이크, 셰이더 렌더링, LOD와 메모리 예산까지 실무 기준으로 설명한다.
핵심 요약
3D Gaussian Splatting(3DGS) 데이터로 촬영 장면의 외관을 재현할 수 있지만, Gaussian 수와 화면 점유 면적이 커지면 투명도 정렬, 메모리, 스트리밍 비용을 점검해야 한다. 스플랫 수만큼 드로우콜이 발생하는 것은 아니며 호출 수는 렌더러의 배칭과 청크 구성에 따라 달라진다. 이 글에서는 원본 Gaussian을 공간 셀로 분할하고 중요 구역은 Gaussian 렌더러로 유지하며 원거리와 충돌 구역은 메시·텍스처·임포스터로 베이크하는 하이브리드 파이프라인을 하나의 설계안으로 제시한다.
3D Gaussian Splatting은 왜 게임 에셋으로 바로 쓰기 어려운가?
3DGS의 한 점은 일반적인 포인트가 아니라 위치, 공분산, 불투명도, 색 또는 구면조화함수(SH) 계수를 가진 타원체 Gaussian이다. 화면에서는 이를 타원형 스플랫으로 투영하고 알파 합성해 장면을 재구성한다.
여기서 (\mu)는 중심 위치이고 (\Sigma)는 크기와 회전을 포함한 공분산 행렬이다. 원본 데이터가 가진 시각적 장점은 곧 런타임 부담이기도 하다.
| 항목 | 3DGS 원본 | 일반 게임 배경 에셋 |
|---|---|---|
| 기본 단위 | Gaussian 스플랫 | 삼각형, 텍스처, 머티리얼 |
| 외관 표현 | SH 기반 뷰 의존 색상 가능 | PBR 머티리얼과 라이트 |
| 가시성 | 알파 블렌딩과 정렬이 중요 | 깊이 버퍼와 불투명 패스 중심 |
| 충돌·내비게이션 | 별도 표면 추출 또는 전용 처리 필요 | 적합한 메시로 생성 가능 |
| 스트리밍 | Gaussian 청크와 계수 관리 필요 | 메시 LOD·텍스처 밉맵이 성숙 |
특히 식생, 얇은 철망, 먼 배경처럼 복잡한 실루엣은 스플랫이 강하지만 플레이어가 가까이 다가가거나 동적 광원이 바뀌는 구역에서는 메시 기반 표현이 더 안정적이다.
어떤 변환 전략을 선택해야 할까?
프로젝트 전체를 하나의 방식으로 처리하기보다 카메라 거리와 상호작용 여부로 자산을 분류한다.
| 구역 | 권장 표현 | 이유 |
|---|---|---|
| 플레이어 이동·충돌 구역 | 리토폴로지 메시 + PBR 텍스처 | 충돌, 그림자, 동적 조명에 대응 |
| 가까운 장식 배경 | 제한된 Gaussian 청크 | 복잡한 외관을 적은 제작 시간으로 보존 |
| 중거리 건물·절벽 | 단순 메시 + 베이크 텍스처 | 안정적인 LOD와 오클루전 처리 |
| 원거리 스카이라인 | 다중 시점 임포스터 또는 카드 | 낮은 메모리와 드로우콜 |
하이브리드 변환 흐름
flowchart LR
A[촬영 이미지와 카메라] --> B[3DGS 학습 결과 PLY]
B --> C[정리와 공간 셀 분할]
C --> D[근거리 Gaussian 청크]
C --> E[메시 추출과 리토폴로지]
E --> F[PBR 텍스처 베이크]
C --> G[원거리 임포스터 베이크]
D --> H[게임 엔진 스트리밍]
F --> H
G --> H이 흐름의 핵심은 “원본을 최대한 보존”하는 일이 아니라 “플레이 중 필요한 정보만 적절한 표현으로 옮기는 일”이다.
3D Gaussian Splatting 데이터를 게임 배경으로 어떻게 변환할까?
1. 원본 PLY를 정리하고 좌표계를 고정한다
원본 3DGS 구현의 Gaussian 모델은 PLY에 위치, 스케일, 회전, opacity, SH 계수를 저장한다. 이 구현의 저장값은 스케일에 로그, 불투명도에 로짓 표현을 사용하므로 실제 스케일은 지수 함수, 실제 불투명도는 시그모이드로 복원해 비교한다. 다른 도구의 PLY가 같은 인코딩이라고 가정하지 말고 내보내기 규약을 확인한다. 먼저 다음 기준으로 불필요한 Gaussian을 점검한다.
- 복원한 불투명도가 매우 낮은 항목을 제거 후보로 삼고, 영상 기여도를 비교해 판단한다. 낮은 불투명도만으로 노이즈라고 단정하지 않는다.
- 지나치게 큰 scale을 가진 항목을 점검한다. 하늘이나 반사면을 덮는 커다란 타원체는 카메라 이동 시 얼룩처럼 보일 수 있다.
- 바닥 원점과 미터 단위를 확정한다. DCC 도구와 엔진 사이의 축 방향도 이 단계에서 통일한다.
- 플레이 영역 밖의 데이터는 월드 좌표 기준 셀로 나눈다.
예를 들어 32 m 셀을 사용하면 카메라 주변의 셀을 로드하고 먼 셀은 임포스터 또는 더 적은 Gaussian LOD로 교체하도록 설계할 수 있다. 셀 경계에 걸친 Gaussian은 중심점만으로 나누면 팝이 생길 수 있으므로 렌더링에 사용할 범위가 셀 경계를 넘는 항목은 경계 전용 청크에 두거나 인접 셀에서도 참조한다. 복제한 항목을 한 프레임에 여러 번 합성하면 불투명도가 달라지므로 고유 ID로 중복 렌더링을 방지한다.
2. 화면 오차 기준으로 Gaussian LOD를 만든다
Gaussian의 월드 스케일만 보고 삭제하면 가까운 카메라에서 구멍이 생길 수 있다. 카메라 거리와 투영 크기로 화면 기여도를 계산하는 편이 안전하다.
원근 카메라에서 양수 깊이 z를 사용하고 대표 반경이 깊이에 비해 작다고 가정하면 대략적인 화면 반경을 다음처럼 잡을 수 있다. 이는 비등방성 Gaussian의 정확한 화면 공분산 계산을 대신하는 식이 아니다.
- (f): 픽셀 단위 초점 거리
- (r_{world}): Gaussian의 대표 반경
- (z): 카메라 공간 깊이
r_px가 1 px보다 충분히 작고 opacity도 낮다면 하위 LOD에서 제거하거나 인접 Gaussian에 병합한다. 단순한 거리 컷보다 화면 품질을 예측하기 좋다. LOD를 만들 때는 각 셀마다 최소 2단계를 두고 전환 구간에서는 0.2~0.5초 페이드로 교체하면 눈에 띄는 팝을 줄일 수 있다.
3. 근거리용 Gaussian 렌더러를 구현한다
엔진별 구현은 달라도 렌더링 순서는 비슷하다. Compute Shader에서 프러스텀 컬링과 타일 분류를 하고 그래픽 패스에서 카메라를 향한 타원 스플랫을 그린다. 인스턴스당 전체 3D 행렬을 넘기기보다 위치, 로그 스케일, 쿼터니언, opacity, SH 계수를 구조화 버퍼에 압축해 둔다.
다음 HLSL 예시는 픽셀 공간에서 단순화한 2D Gaussian 알파 계산을 보여 주는 함수 조각이다. 완성된 셰이더의 입력·버텍스 단계는 생략했다. 실제 구현에서는 투영의 야코비안과 뷰 변환을 사용해 3D 공분산을 화면 공간 2D 공분산으로 변환하고 그 역행렬을 사용한다. 아래 역공분산은 픽셀 단위 오프셋과 일치하는 좌표계이며 양의 정부호라고 가정한다.
struct SplatData
{
float3 position;
float opacity;
float3 color;
float2x2 invCov2D;
};
float EvaluateGaussian(float2 pixelOffset, float2x2 invCov2D)
{
float2 q = mul(pixelOffset, invCov2D);
float mahalanobis = dot(q, pixelOffset);
return exp(-0.5 * mahalanobis);
}
float4 Fragment(float2 pixelOffset, SplatData splat) : SV_Target
{
float weight = EvaluateGaussian(pixelOffset, splat.invCov2D);
float alpha = saturate(splat.opacity * weight);
clip(alpha - 1.0 / 255.0);
return float4(splat.color * alpha, alpha);
}이 함수는 RGB에 알파를 미리 곱한 값을 출력하므로 Unity ShaderLab에서는 Blend One OneMinusSrcAlpha 같은 프리멀티플라이 블렌드 상태와 맞춰야 한다. 여기에 SrcAlpha를 적용하면 RGB에 알파가 다시 곱해진다. 이 합성도 순서에 의존하므로 깊이 기준 정렬을 고려한다. Unity 블렌드 설정 문서를 참고한다. 많은 스플랫을 다루는 경로에서는 weighted blended order-independent transparency 같은 근사 합성도 검토할 수 있지만 원래의 정렬 기반 합성과 동일한 결과를 보장하지 않으므로 최종 화면을 비교해 선택한다.
4. 충돌과 동적 라이팅이 필요한 곳은 메시로 베이크한다
원본 3DGS 데이터에는 일반적인 게임 메시의 표면 토폴로지, 라이트맵 UV, 내비게이션 메시가 포함되어 있지 않다. 원본 촬영 이미지와 카메라 포즈가 있다면 포토그래메트리 또는 별도 메싱 단계로 표면 메시를 얻고 리토폴로지와 UV 작업을 진행한다. 기하에서 normal이나 ambient occlusion을 베이크할 수 있지만, 촬영된 색을 옮기는 것만으로 조명이 제거된 albedo나 roughness가 복원되지는 않는다. 이런 재질 정보에는 별도 추정·측정·제작 과정이 필요하다.
주의할 점은 3DGS의 색상에 이미 촬영 당시의 그림자와 간접광이 포함될 수 있다는 점이다. 이를 그대로 albedo에 넣고 게임의 동적 조명을 더하면 조명이 이중으로 들어간다. 다음 중 하나를 명확히 선택한다.
- 고정 조명 배경: 촬영 외관을 emissive 또는 조명 포함 베이스 컬러에 가깝게 취급한다.
- 동적 조명 배경: 가능한 한 조명 성분을 분리한 텍스처를 만들고 PBR 머티리얼에서 엔진 조명을 받게 한다.
- 혼합 방식: 멀리 있는 배경은 조명 포함 표현으로 유지하고 플레이어 주변만 동적 조명 PBR로 교체한다.
성능 예산은 무엇을 측정해야 하는가?
Gaussian 개수만 세면 병목을 놓치기 쉽다. 다음 수치를 동일한 카메라 경로에서 기록한다.
| 측정 항목 | 확인할 문제 | 개선 방법 |
|---|---|---|
| 가시 Gaussian 수 | 대역폭·래스터 부하 | 프러스텀 컬링, 검증된 불투명 깊이를 사용하는 HZB 오클루전, 셀 LOD |
| 화면 스플랫 면적 합 | 오버드로우 | 반경 컷, 타일 빈도 제한, 깊이 구간 분리 |
| 청크당 GPU 메모리 | 스트리밍 끊김 | SH 차수 축소, 양자화, 청크 크기 조정 |
| 투명 패스 시간 | 알파 정렬 비용 | 불투명 메시 전환, OIT 품질 비교 |
| 프레임 간 로드량 | 카메라 이동 시 스터터 | 선로딩 반경, 비동기 업로드, 프리패치 |
SH 차수를 낮추는 것도 실용적인 선택이다. 뷰 의존 반사가 중요하지 않은 원거리 배경은 고차 SH를 유지할 이유가 적다. 고차 계수를 없앨 때는 정면 카메라만 보지 말고 실제 플레이 가능한 시점 범위에서 색 변화와 하이라이트 손실을 확인한다.
품질 문제는 어떻게 디버깅할까?
검은 테두리와 후광은 왜 생기는가?
주된 원인은 프리멀티플라이 알파 불일치, 스플랫 경계의 지나친 컷오프, 배경색을 포함한 캡처 데이터다. 렌더 타깃과 블렌드 상태가 프리멀티플라이 방식을 일관되게 쓰는지 확인하고 color * alpha를 출력하는 경로와 그렇지 않은 경로를 섞지 않는다. 경계 컷오프는 너무 높으면 구멍이 나고 너무 낮으면 오버드로우가 커지므로 품질 프로파일별로 별도 값을 둔다.
카메라 이동에서 반짝임은 왜 생기는가?
카메라 거리나 초점 거리가 바뀌면 3DGS의 샘플링 배율이 달라져 앨리어싱과 팽창·침식 아티팩트가 생길 수 있다. Mip-Splatting은 이를 완화하기 위해 3D 평활 필터와 2D Mip 필터를 제안한다. 화면 반경 기반 LOD나 최소 공분산 제한만으로 같은 품질을 보장한다고 가정하지 말고 실제 확대·축소 결과를 비교한다. TAA를 함께 사용하는 엔진에서는 모션 벡터와 깊이의 호환성도 검사한다. Unity URP 공식 문서는 모션 벡터의 누락·부정확성이 잔상 등 아티팩트를 일으킬 수 있다고 설명한다. 사용자 정의 스플랫 렌더러도 카메라 이동과 오브젝트 이동을 나눠 테스트한다.
자주 묻는 질문 (FAQ)
3D Gaussian Splatting만으로 충돌 가능한 게임 맵을 만들 수 있나?
Gaussian은 일반적인 삼각형 표면 토폴로지가 아니므로 기존 메시 기반 충돌체와 내비게이션을 사용하려면 별도 메시를 추출하거나 제작해야 한다. 전용 충돌·경로 탐색 알고리즘을 구현하는 경우는 별도 설계가 필요하다. 이 글의 파이프라인에서는 시각 배경을 Gaussian으로 유지하고 단순 충돌 메시를 함께 둔다.
모바일에서도 3DGS 배경을 실시간으로 쓸 수 있나?
가능하지만 원본 품질을 그대로 기대하면 안 된다. 작은 청크, 강한 컬링, 낮은 SH 차수, 제한된 스플랫 수가 필요하며 대개는 메시와 임포스터 비중을 높이는 편이 안전하다.
메시 변환만 하면 3DGS를 쓸 이유가 없는가?
그렇지 않다. 촬영 장면의 식생, 파손 표면, 먼 배경에서 Gaussian 표현을 원본 외관의 참고 자료나 혼합 렌더링용으로 활용할 수 있다. 제작 시간이 줄어드는지는 촬영 품질과 후처리 작업량에 따라 평가해야 한다. 구역마다 필요한 표현을 선택하는 것이 이 파이프라인의 목적이다.
정리
3D Gaussian Splatting은 게임 배경 제작을 대체하는 만능 포맷이 아니라 캡처 기반 외관을 빠르게 확보하는 강력한 소스 데이터다. PLY를 정리한 뒤 공간 셀과 화면 오차로 LOD를 구성하고 근거리는 메시·PBR·충돌체로 전환하며 중·원거리는 Gaussian과 임포스터를 혼합하면 품질과 런타임 비용을 함께 관리할 수 있다.
마지막 검증은 에디터 정지 화면이 아니라 실제 플레이 경로에서 해야 한다. 걷기, 달리기, 빠른 카메라 회전, 시간대 변화, 스트리밍 경계 통과를 포함한 프로파일링이 변환 파이프라인의 완성도를 결정한다.
