https://epicgames.ent.box.com/s/fqcg892eel4oauqwfxh140ak8o4zb48i

FastGeo Documentation 5.8.pdf | Powered by Box

epicgames.ent.box.com

World Partition의 기본적인 셀 스트리밍 구조를 알고 있으면 이해가 훨씬 쉽습니다.

특히 "에셋을 디스크에서 읽어오는 것"과 "읽어온 오브젝트를 실제 월드에 등록하는 것"은 전혀 다른 비용이라는 점을 생각하면서 읽으면 좋습니다.

FastGeo는 UE 5.6에서 처음 공개된 Experimental 플러그인이고, 5.8 현재도 Experimental입니다.
공식 문서는 아직 많지 않아서, 이 글은 Epic 공식 문서 + UE 5.6~5.8 엔진 소스를 같이 보면서 정리했습니다.

비전공자도 전체 흐름을 따라올 수 있게 앞부분은 최대한 단순하게 쓰고, 뒤로 갈수록 엔진 구현으로 들어갑니다.

글 마지막에 공식 레퍼런스를 정리해두었습니다.

The Witcher 4 Unreal Engine 5 Tech Demo / State of Unreal 2025.
https://www.youtube.com/watch?v=FJtF3wzPSrY
출처: CD PROJEKT RED Press Center, Epic Games

https://www.youtube.com/watch?v=BdopUm1_1_E

히치(Hitch)는 나의 적!

0. "로드는 비동기라면서 왜 끊기죠?"

World Partition의 기본 아이디어는 단순합니다.

플레이어 주변을 셀(Cell)로 나누고, 가까운 셀은 로드하고, 멀어진 셀은 언로드합니다.

여기까지만 보면 문제가 없어 보입니다.

디스크에서 파일도 Async Load하고, 필요한 셀만 불러오는데 왜 오픈월드 게임을 빠르게 이동하면 한 프레임씩 툭툭 끊길까요?

이유는 파일을 읽었다고 끝이 아니기 때문입니다.

셀 안에 StaticMeshActor가 수천 개 있다면, 에셋 로딩이 끝난 뒤에도 월드에 들어오기 위해 해야 할 일이 남아 있습니다.

Actor / Component 등록
Render State 생성
Scene에 Primitive 등록
Physics State 생성
각종 UObject / Component 초기화
언로드 시 반대 방향으로 해제

즉,

Disk Async Load
      ↓
"파일은 다 읽었습니다!"
      ↓
Actor 수천 개 AddToWorld
      ↓
Component Register
      ↓
Render State / Physics State 생성
      ↓
Game Thread: 살려주세요

가 됩니다.

여기서 중요한 점은 I/O가 비동기라고 해서 월드 스트리밍의 모든 비용이 비동기가 되는 것은 아니라는 것입니다.

UE 5.6에서 Epic이 Fast Geometry Streaming Plugin을 소개하면서 강조한 것도 이 부분입니다.

더 많은 immutable static geometry를 월드에 두면서도, 런타임 스트리밍 시 빠르게 로드하고 일정한 프레임 레이트를 유지하는 것.

FastGeo는 바로 이 **"월드에 넣고 빼는 비용"**을 줄이기 위해 등장했습니다.

1. FastGeo의 발상: "얘가 꼭 Actor일 필요가 있나?"

오픈월드에 있는 물체를 생각해봅시다.

바위
절벽
건물 외벽
난간
기둥
도로 옆 장식물
멀리 있는 HLOD Proxy

얘네는 대부분 게임플레이 로직이 없습니다.

Tick도 안 합니다.
Transform도 안 바뀝니다.
블루프린트 이벤트도 없습니다.

그런데 일반적인 경로에서는 여전히 대략 이런 형태를 가집니다.

AStaticMeshActor
    └─ UStaticMeshComponent
          ├─ UObject
          ├─ Reflection
          ├─ Owner
          ├─ Component Lifecycle
          ├─ Render State
          └─ Physics State

StaticMesh 하나만 놓고 보면 아무 문제 없습니다.

문제는 이게 수천, 수만 개가 될 때입니다.

FastGeo의 아이디어는 꽤 과격하고 단순합니다.

"게임플레이에 Actor 기능을 안 쓰는데, 렌더링과 충돌에 필요한 데이터만 들고 있으면 되는 것 아닌가?"

그래서 변하지 않는 정적 콘텐츠를 일반 Actor + UActorComponent 표현에서 꺼내서 더 가벼운 FastGeo 전용 데이터 표현으로 바꿉니다.

공식 API 문서의 정의도 굉장히 짧습니다.

A system that extracts and converts a partitioned world's geometry to optimize world streaming performance.

즉 FastGeo는 새로운 메시 포맷이라기보다 World Partition의 정적 콘텐츠를 스트리밍하기 위한 다른 런타임 표현에 가깝습니다.

2. 먼저 가장 많이 헷갈리는 것: FastGeo != Nanite

이름에 Geometry가 들어가니까 Nanite와 비슷한 렌더링 기술처럼 보입니다.

아닙니다.

둘이 해결하는 문제는 다릅니다.

NaniteFastGeo

주 문제	많은 폴리곤을 어떻게 그릴까?	많은 정적 오브젝트를 어떻게 싸게 넣고 뺄까?
중심	GPU Rendering / Visibility / LOD	CPU Streaming / Runtime Representation
Actor 수명주기	직접 해결하지 않음	핵심 최적화 대상
이미 로드된 씬의 GPU 비용	직접 영향	주 목적 아님
World Partition	같이 사용할 수 있음	핵심 사용처

FastGeo Static Mesh를 엔진 소스에서 따라가보면 결국 일반 Static Mesh와 같은 FStaticMeshSceneProxy, Nanite Mesh라면 Nanite Scene Proxy 계열을 사용합니다.

즉 GPU 입장에서는 갑자기 새로운 렌더러가 생긴 것이 아닙니다.

바뀌는 것은 그 SceneProxy를 만들고 Scene에 집어넣는 앞단입니다.

쉽게 기억하면 이렇습니다.

Nanite: "이 메시를 어떻게 효율적으로 그릴까요?"
FastGeo: "이 메시가 월드에 들어오고 나갈 때 왜 이렇게 비싸죠?"

이 구분이 FastGeo에서 제일 중요합니다.

3. Actor를 없애면 뭐가 남을까? - FastGeo 내부 구조

여기부터는 엔진 소스 이야기입니다.

UE 5.6~5.8에서 FastGeo 코드는 다음 경로에 있습니다.

Engine/Plugins/Experimental/FastGeoStreaming

PCG 연동은 별도 플러그인입니다.

Engine/Plugins/Experimental/PCGInterops/PCGFastGeoInterop

1) UFastGeoContainer

FastGeo 데이터의 중심에는 UFastGeoContainer가 있습니다.

일반적인 방식이라면 Static Mesh 1,000개가 각각 Actor와 Component UObject를 가집니다.

FastGeo에서는 개별 프리미티브를 일반 UActorComponent로 두지 않고, 컨테이너 안에 더 단순한 C++ 데이터로 모읍니다.

대략적인 느낌은 이렇습니다.

기존

Actor
 └ Component UObject
Actor
 └ Component UObject
Actor
 └ Component UObject
Actor
 └ Component UObject
...

FastGeo

UFastGeoContainer
 ├ StaticMesh Data[]
 ├ ISM Data[]
 ├ HLOD Data[]
 └ ...

컨테이너 자체는 UObject지만, 내부의 FastGeo Component는 일반적인 UActorComponent가 아닙니다.

이게 CPU 절약의 핵심 중 하나입니다.

2) FFastGeoComponentCluster

FFastGeoComponentCluster는 FastGeo Component를 묶어서 관리합니다.

엔진에서는 타입별 TArray<FFastGeo...Component> 형태로 데이터를 연속적으로 모아둡니다.

여기서 "Structure of Arrays"라고 부르면 약간 애매합니다.
필드 하나하나를 별도 배열로 분리한 전형적인 SoA라기보다는, 타입별 구조체를 연속 메모리에 모아둔 형태에 가깝습니다.

중요한 건 이름이 아니라 효과입니다.

UObject Graph를 따라다니지 않아도 됩니다.
같은 타입을 한 번에 순회하기 쉽습니다.
Register / Unregister 같은 작업을 Batch 단위로 처리하기 좋습니다.
캐시 친화적인 선형 순회가 가능합니다.

PCG 공식 문서도 FastGeo Component를 일반 Actor Component보다 simpler and more compact, setup / teardown에 필요한 Game Thread 시간을 크게 줄이는 경로라고 설명합니다.

3) 사라지는 범용 기능들

일반 Component는 굉장히 편합니다.

문제는 편한 만큼 이것저것 많이 가지고 있다는 겁니다.

FastGeo는 정적 환경물에 필요 없는 범용 기능을 포기하고 가벼워집니다.

개별 Component UObject 비용
GC가 추적해야 할 UObject 수
Owner / Delegate / Event 인프라
Tick 등록
일반적인 Component Reflection / Lifecycle

당연히 공짜는 아닙니다.

이걸 버렸다는 말은 반대로 게임플레이 기능이 필요한 오브젝트에는 FastGeo를 쓰면 안 된다는 뜻이기도 합니다.

4. 진짜 중요한 것 1: Render State를 한 프레임에 다 만들지 않습니다.

Actor를 줄이는 것만으로도 이득이 있지만, FastGeo에서 더 중요한 부분은 스케줄링입니다.

예를 들어 셀 하나가 로드되면서 Render State를 만들어야 하는 Static Mesh가 3,000개 있다고 해봅시다.

기존 방식에서 이 비용이 특정 프레임에 몰리면 이렇게 됩니다.

Frame 100   5ms
Frame 101   6ms
Frame 102  42ms  <- 셀 들어옴
Frame 103   6ms
Frame 104   5ms

평균 FPS를 보면 별 문제가 없어 보이는데, 플레이어는 Frame 102의 42ms를 그대로 느낍니다.

그게 Hitch가 됩니다.

FastGeo는 Render State 생성 작업을 별도 Job으로 보내고, 한 프레임에 얼마만큼 처리할지 Budget을 둘 수 있습니다. (중요)

엔진 소스에서 핵심이 되는 CVar는 다음과 같습니다.

FastGeo.AsyncRenderStateTask.TimeBudgetMS
FastGeo.AsyncRenderStateTask.MaxNumComponentsToProcess
FastGeo.AsyncRenderStateTask.ParallelWorkerCount

개념은 간단합니다.

기존
████████████████████  한 프레임에 몰아서 처리

FastGeo
████  ████  ████  ████  여러 프레임으로 나눠 처리

총 연산량이 갑자기 0이 되는 건 아닙니다.

20ms짜리 일을 없애는 게 아니라, 20ms가 한 프레임에 박히지 않도록 4ms + 4ms + 4ms... 로 쪼개는 쪽에 가깝습니다.

내부에서는 어떻게 도나?

5.7~5.8 소스 기준으로 Async Render State Job Queue는 UE Tasks 기반의 FPipe를 사용합니다.

게임 스레드가 작업을 등록하면 Background Worker에서 FastGeo Component의 SceneProxy 생성/등록을 수행하고, 완료 후 필요한 Game Thread 마무리를 합니다.

여러 FastGeo Container가 동시에 로드될 때는 각자 마음대로 시간을 쓰는 것이 아니라, World Subsystem에서 같은 프레임 Budget을 나눠 받습니다.

처리 도중 Budget이 끝났다면?

"여기까지. 나머지는 다음 프레임으로"

하고 다시 Queue에 들어갑니다.

FastGeo가 평균 FPS보다 **최악 프레임 시간(Worst Frame Time)**에서 의미가 큰 이유입니다.

5. 진짜 중요한 것 2: Physics State도 공짜가 아닙니다.

Static Mesh에 Collision이 있으면 Render State만 만들고 끝나지 않습니다.

Chaos에도 Body를 등록해야 합니다.

FFastGeoPrimitiveComponent 계열은 UObject Component는 아니지만, 필요한 FBodyInstance 데이터를 직접 가지고 있습니다.

Collision Shape도 이상한 새 포맷을 만드는 것이 아니라 Static Mesh가 원래 가지고 있던 UBodySetup을 사용합니다.

StaticMesh Asset
    └ UBodySetup
          ↓
FastGeo Primitive
    └ FBodyInstance
          ↓
Chaos Physics Scene

여기서도 중요한 건 Physics 자체를 새로 만든 것이 아니라 등록 과정을 스트리밍에 적합하게 처리한다는 점입니다.

UE 5.6 공식 소개에서 Epic은 FastGeo와 함께 content streaming 개선으로 asynchronous physics state creation and destruction을 명시했습니다.

FastGeo 쪽에서도 Physics Body 생성/해제를 한 번에 몰아 처리하지 않고 Async Physics State Job 경로를 사용합니다.

다만 여기에는 한 가지 중요한 예외가 있습니다.

Teleport, Blocking Load처럼 "지금 당장 이 셀의 Physics가 반드시 준비되어 있어야 하는" 상황에서는 끝날 때까지 기다리는 동기화 지점이 존재합니다.

Async라고 해서 모든 Wait가 사라지지는 않습니다.

(그랬으면 프로그래머가 필요 없었겠죠.)

6. 그러면 아무 Actor나 FastGeo로 바꿔도 되나요?

안 됩니다.

FastGeo는 World Partition Runtime Cell Transformer를 통해 **"이 오브젝트를 Actor에서 제거해도 되는가?"**를 판정합니다.

UFastGeoWorldPartitionRuntimeCellTransformer가 셀 안의 Actor / Component를 검사하고 대략 세 가지 결과로 나눕니다.

Allow: FastGeo로 변환
Reject: 변환하지 않고 기존 Actor 유지
Discard: 런타임에 필요하지 않으므로 제거

이 중 우리가 가장 많이 보게 되는 건 Allow와 Reject입니다.

기본적으로 잘 맞는 것

Static Mesh Actor
고정된 환경 장식물
Packed Level Actor의 정적 요소
HLOD
움직이지 않는 ISM류

기본적으로 잘 안 맞는 것

Movable Component
Stationary Component
Blueprint Gameplay Logic이 있는 Actor
런타임 Transform 변경이 필요한 오브젝트
Component Event / Delegate에 강하게 의존하는 오브젝트
특수 Component 동작이 필요한 오브젝트

Mobility가 가장 중요한 기준입니다.

엔진 소스의 가장 명확한 Gate 중 하나가 Mobility == Static입니다.

Movable / Stationary라면 FastGeo의 설계 목적과 맞지 않습니다.

생각해보면 당연합니다.

FastGeo가 가벼운 이유는 "얘는 평생 안 움직이고, 별일도 안 일어난다"고 믿고 많은 기능을 버렸기 때문입니다.

그런데 갑자기 런타임에 움직이겠다고 하면 전제가 무너집니다.

7. "이 액터는 꼭 넣고 싶은데요" - Transformer 설정

FastGeo Transformer는 설정 파일의 Allow / Disallow Class 목록을 사용합니다.

5.8에서는 설정 파일 이름이 바뀌었습니다.

5.6 / 5.7 계열
FastGeoStreaming.ini

5.8
DefaultFastGeoStreaming.ini

이건 5.8 Release Notes에 명시된 변경사항입니다.

기본 소스 기준으로 StaticMeshActor, PackedLevelActor, WorldPartitionHLOD 등은 FastGeo 후보가 되고, Water / Landscape / SplineMesh처럼 별도 시스템과 강하게 연결된 컴포넌트는 제외되는 식입니다.

Actor Tag로 개별 제어하는 경로도 있습니다.

FastGeo     -> 포함 쪽으로 강제
NoFastGeo   -> 제외

물론 태그를 붙였다고 하드 제약을 무시하고 뭐든 변환할 수 있다는 뜻은 아닙니다.

Mobility, Blueprint Logic, 자식 액터 등 FastGeo 자체가 허용하지 않는 조건은 여전히 남습니다.

8. HLOD까지 FastGeo로 갑니다.

World Partition에서 HLOD는 굉장히 중요합니다.

멀리 있는 셀을 전부 로드해둘 수 없으니, 많은 Static Mesh를 하나의 가벼운 Proxy로 바꿔서 멀리서 보여줍니다.

HLOD Off / HLOD On 비교. 언로드된 World Partition Cell의 콘텐츠가 HLOD Proxy로 대체됩니다.
출처: Epic Games, World Partition - Hierarchical Level of Detail Documentation

FastGeo에는 FFastGeoHLOD가 있고, IWorldPartitionHLODObject 인터페이스를 구현해서 World Partition HLOD Runtime Subsystem과 연결됩니다.

즉,

원본 Static Geometry
        ↓ 멀어짐
      HLOD
        ↓
FastGeo Representation
        ↓
Streaming In / Out

이라는 구조가 가능합니다.

HLOD는 애초에 멀리서 보여주기 위한 시각적 Proxy이기 때문에 FastGeo HLOD 경로에서는 Collision도 강제로 비활성화됩니다.

Cook 시점에는 HLOD가 만든 StaticMesh의 Collision Cook Data까지 제외하는 경로가 있어 디스크/쿡 비용도 줄입니다.

이 부분은 공식 문서보다 엔진 소스에 더 구체적으로 드러납니다.

9. 5.7부터는 PCG도 "Component 꼭 만들어야 하나요?"를 묻기 시작합니다.

FastGeo 본체와 별도로 PCGFastGeoInterop 플러그인이 있습니다.

공식 설명은 아주 직설적입니다.

PCG가 Runtime Primitive를 Spawn할 때 FastGeo Component를 사용할 수 있게 해주는 Experimental Plugin.

PCG GPU Processing 문서에는 Component-less Spawning Via FastGeo라는 항목도 따로 있습니다.

기존:

PCG
 ↓
Actor Component 생성
 ↓
Primitive 등록

FastGeo Interop:

PCG
 ↓
FastGeo Component
 ↓
Primitive 등록

활성화 CVar는 다음과 같습니다.

pcg.RuntimeGeneration.ISM.ComponentlessPrimitives

Epic 문서 표현을 그대로 요약하면,

일반 Actor Component보다 단순하고 작습니다.
Setup / Tear Down Game Thread 시간이 크게 줄어듭니다.
결과 비주얼은 동일해야 합니다.

이 부분이 FastGeo의 철학을 가장 이해하기 쉽게 보여줍니다.

"그림은 똑같이 나와야 하는데, 왜 굳이 무거운 Component를 만들어야 하지?"

10. 디버깅: "그래서 대체 뭐가 FastGeo가 된 건데요?"

Experimental 기능에서 제일 위험한 접근은 이겁니다.

"플러그인 켰습니다. 빨라졌겠죠?"

아닙니다.

프로젝트의 Actor Class 구조나 Component 구성 때문에 생각보다 많은 오브젝트가 Reject될 수 있습니다.

엔진에는 FastGeo Coloration과 Transformer Debug가 있습니다.

에디터의 Actor Coloration에서 FastGeo 표시를 켜면 변환된 타입을 색으로 구분해서 볼 수 있습니다.

소스 기준 대표 색상은 다음과 같습니다.

타입	색상
ISM	Orange
HLOD ISM	Red
Static Mesh	Cyan
HLOD Static Mesh	Blue
기타	White

Transformer Debug Mode도 있습니다.

FastGeo.EnableTransformerDebugMode=1

이걸 켜면 선택한 Actor가 왜 Reject됐는지 이유를 추적할 수 있습니다.

FastGeo 최적화의 첫 단계는 CVar 튜닝이 아니라 실제 Conversion Coverage를 확인하는 것입니다.

11. 5.6 -> 5.7 -> 5.8, FastGeo는 어떻게 변했나?

5.6 - 첫 등장

FastGeo는 UE 5.6에서 처음 공개됐습니다.

Epic은 5.6의 목표 중 하나로 60 FPS 대규모 오픈월드를 내세웠고, Runtime Static Content Streaming 개선의 대표 기능으로 Fast Geometry Streaming Plugin을 소개했습니다.

The Witcher 4 Unreal Engine 5 Tech Demo에서 실제로 공개됐습니다.

The Witcher 4 UE5 Tech Demo. CD PROJEKT RED는 FastGeo Streaming이 Epic Games와 공동 개발되었으며 환경을 빠르고 부드럽게 로드한다고 설명했습니다.

Tech Demo는 PlayStation 5에서 60 FPS로 시연됐고, FastGeo 외에도 Nanite Foliage, Unreal Animation Framework, Mass AI 등 당시의 오픈월드 기술을 같이 보여줬습니다.

5.6의 FastGeo는 말 그대로 첫 Experimental 버전입니다.

기본 Container / Transformer 구조, Async Render/Physics State 처리의 뼈대가 이때 등장합니다.

5.7 - PCG와 연결

UE 5.7에서는 PCG가 Production-Ready로 올라갔고, FastGeo 쪽에서는 PCGFastGeoInterop이 의미 있는 확장입니다.

FastGeo가 단순히 "에디터에서 배치된 World Partition Static Geometry 변환"에만 머물지 않고, 런타임 Procedural Primitive 생성에도 같은 가벼운 표현을 활용하기 시작합니다.

5.8 - 이제 Static Mesh만 보는 플러그인이 아닙니다.

UE 5.8 Release Notes에서 FastGeo는 꽤 많은 변화가 들어갔습니다.

Decal Component 지원
Point Light 지원
Spot Light 지원
Rect Light 지원
Static Mesh Mesh Paint Texture 지원
Non-Primitive Component Transformation 수정
FastGeoContainer Physics 누락 수정
Root Component Mobility 보존 수정
PIE Eject 표시 문제 수정
Multi-threading 문제 수정
Crash / Threading / Deadlock / Initialization 관련 다수 수정
FastGeoStreaming.ini -> DefaultFastGeoStreaming.ini

여기서 개인적으로 가장 흥미로운 건 Light와 Decal입니다.

초기 FastGeo를 보면 "Static Mesh Streaming 최적화"처럼 보이기 쉽습니다.

그런데 Point / Spot / Rect Light와 Decal까지 들어오기 시작하면 그림이 조금 달라집니다.

초기 이미지
Static Geometry를 가볍게 스트리밍

        ↓

5.8
Static World Representation 자체를 점점 가볍게

물론 이것은 현재 구현을 보고 한 해석입니다.
Epic이 FastGeo의 장기 아키텍처를 공식적으로 이렇게 정의한 것은 아닙니다.

그리고 5.8에서도 여전히 Experimental입니다.

12. 그럼 얼마나 빨라집니까?

가장 궁금한 부분인데 공개 자료에는 아쉽게도 FastGeo 자체의 범용적인 %, ms 벤치마크가 거의 없습니다.

그래서 "FastGeo 켜면 FPS 20% 증가" 같은 식으로 보면 안 됩니다.

FastGeo가 직접 노리는 비용과 그렇지 않은 비용을 나누는 것이 좋습니다.

비용	FastGeo
Asset File I/O	핵심 대상 아님
Actor 생성 / 제거	감소
Component Setup / Teardown	감소
Render State Streaming Spike	분산 / 완화
Physics State Streaming Spike	분산 / 완화
UObject / GC Object 수	감소 가능
이미 로드된 씬의 Shader Cost	거의 별개
Nanite Rasterization	별개
정상 상태 GPU Frame Time	주 목적 아님
Cell Load / Unload Hitch	핵심 타깃

그래서 프로파일링도 평균 FPS만 보면 안 됩니다.

일부러 최악의 상황을 만들어야 합니다.

Streaming Source Teleport
빠른 차량 이동
카메라 순간 이동
여러 Cell 동시 Load / Unload
HLOD 전환이 몰리는 지역
Data Layer 전환과 Cell Streaming이 동시에 발생하는 상황

그리고 Unreal Insights에서 평균보다 Max Frame Time / Game Thread Spike를 봅니다.

정상 보행에서 60 FPS가 61 FPS가 됐는지는 별로 중요하지 않습니다.

100ms Hitch가 20ms 이하로 쪼개졌다면 FastGeo의 목표가 달성된 것입니다.

13. Experimental은 "베타보다 조금 덜 완성됨"이라는 뜻이 아닙니다.

FastGeo 공식 API 페이지에는 현재도 Shipping 시 주의하라는 Experimental 경고가 있습니다.

실제로 5.6 -> 5.8 사이만 봐도

Config 이름이 바뀌고
Interface가 리팩터링되고
Physics 누락이 수정되고
Threading / Deadlock / Crash가 계속 수정되고
지원 Component 범위가 늘어났습니다.

즉 프로덕션에 넣는다면 엔진 업그레이드마다 다시 봐야 합니다.

특히 체크할 것은 다음입니다.

실제 FastGeo Conversion Coverage
Collision / Physics Event 동작
Navigation 의존성
프로젝트 커스텀 Component
Blueprint Logic이 섞인 Environment Actor
Teleport / Blocking Streaming 상황
엔진 버전별 Config / CVar 변경

초기 버전에서는 Chaos Collision Notification과 FastGeo 관련 문제도 있었기 때문에, OnComponentHit 같은 Gameplay Event를 정적 환경물에 사용하고 있다면 버전별 검증이 필요합니다.

FastGeo의 Collision이 존재한다는 것과 일반 UPrimitiveComponent의 모든 Gameplay Semantics가 항상 같다는 것은 다른 이야기입니다.

14. 결론: FastGeo는 우리에게 무엇인가?

FastGeo를 처음 보면 "새 Geometry Renderer"처럼 느껴집니다.

하지만 실제로 코드를 보면 방향이 다릅니다.

FastGeo가 줄이려는 것은 이미 로드된 메시를 그리는 비용보다 정적 월드가 Streaming In / Out 되는 순간의 CPU 비용입니다.

이것만 기억하세요.

Actor를 줄입니다.
- Gameplay가 없는 Static Content를 더 가벼운 Runtime Representation으로 바꿉니다.
한 프레임에 일을 몰아넣지 않습니다.
- Render / Physics State Setup과 Teardown을 Async + Budget 방식으로 분산합니다.
Nanite와 역할이 다릅니다.
- Nanite는 "어떻게 그릴까?"
- FastGeo는 "어떻게 싸게 월드에 넣고 뺄까?"

한 문장으로 끝내면 이렇습니다.

FastGeo는 World Partition의 정적·비게임플레이 콘텐츠를 Actor/Component보다 가벼운 표현으로 바꾸고, Scene/Physics 등록 비용을 분산해서 Streaming Hitch를 줄이는 시스템입니다.

UE 5.6에서 첫 공개됐고, 5.7에서 PCG와 연결됐으며, 5.8에서는 Light / Decal까지 범위가 넓어졌습니다.

아직 Experimental이지만 대규모 World Partition 프로젝트를 다루고 있다면, 앞으로 UE의 Static World Streaming이 어느 방향으로 가는지 보기에는 굉장히 흥미로운 기능입니다.

Appendix. 엔진 소스에서 볼 만한 클래스

아래는 공식 사용법이라기보다 소스 탐색용입니다.
Experimental 기능이므로 버전에 따라 이름이나 구조가 바뀔 수 있습니다.

이름	역할
UFastGeoContainer	FastGeo 데이터 컨테이너
FFastGeoComponentCluster	Component Batch / Cluster 단위
IFastGeoElement	FastGeo Element 공통 Interface
FFastGeoComponent	FastGeo Component 기본 데이터
FFastGeoStaticMeshComponent	Static Mesh FastGeo 표현
FFastGeoInstancedStaticMeshComponent	ISM FastGeo 표현
FFastGeoHLOD	HLOD FastGeo 표현
UFastGeoWorldPartitionRuntimeCellTransformer	World Partition Cell 변환
FFastGeoAsyncRenderStateJobQueue	Async Render State Job Queue

소스 경로:

Engine/Plugins/Experimental/FastGeoStreaming
Engine/Plugins/Experimental/PCGInterops/PCGFastGeoInterop

Appendix. 주요 CVar / Config

이름	용도
FastGeo.Enable	FastGeo 변환 활성화
FastGeo.EnableTransformerDebugMode	Transformer Reject Reason 디버깅
FastGeo.AsyncRenderStateTask.TimeBudgetMS	Frame별 Render State 작업 시간 Budget
FastGeo.AsyncRenderStateTask.MaxNumComponentsToProcess	Frame별 Component 처리 수 제한
FastGeo.AsyncRenderStateTask.ParallelWorkerCount	Async Render State Parallel Worker 수
pcg.RuntimeGeneration.ISM.ComponentlessPrimitives	PCG FastGeo Component-less Spawning
p.Chaos.EnableAsyncInitBody	Chaos Async Body Init 관련, 버전별 Source 확인
DefaultFastGeoStreaming.ini	UE 5.8 기준 Transformer Config

참고 자료

Epic Games 공식

FastGeo Streaming - API Plugin Index
https://dev.epicgames.com/documentation/unreal-engine/API/PluginIndex/FastGeoStreaming
Unreal Engine 5.6 is now available
https://www.unrealengine.com/news/unreal-engine-5-6-is-now-available
State of Unreal 2025 - The Witcher 4 UE5 Tech Demo
https://www.unrealengine.com/news/all-the-big-news-and-announcements-from-the-state-of-unreal-2025
Streaming Improvements for Dense Worlds in The Witcher 4 UE5 Tech Demo - Unreal Fest Orlando 2025
https://dev.epicgames.com/community/learning/talks-and-demos/KWGD/streaming-improvements-for-dense-worlds-in-the-witcher-4-unreal-engine-5-tech-demo-unreal-fest-orlando-2025
Unreal Engine 5.7 is now available
https://www.unrealengine.com/news/unreal-engine-5-7-is-now-available
PCG FastGeo Interop - API Plugin Index
https://dev.epicgames.com/documentation/unreal-engine/API/PluginIndex/PCGFastGeoInterop
Using PCG with GPU Processing - Component-less Spawning Via FastGeo
https://dev.epicgames.com/documentation/unreal-engine/using-pcg-with-gpu-processing-in-unreal-engine
Unreal Engine 5.8 Release Notes - Fast Geometry Streaming
https://dev.epicgames.com/documentation/unreal-engine/unreal-engine-5-8-release-notes
Unreal Engine 5.8 is now available
https://www.unrealengine.com/news/unreal-engine-5-8-is-now-available
World Partition
https://dev.epicgames.com/documentation/unreal-engine/world-partition-in-unreal-engine
World Partition - Hierarchical Level of Detail
https://dev.epicgames.com/documentation/unreal-engine/world-partition---hierarchical-level-of-detail-in-unreal-engine

CD PROJEKT RED 공식

CD PROJEKT RED and Epic Games Present The Witcher 4 Unreal Engine 5 Tech Demo at The State of Unreal 2025
https://press.cdprojektred.com/en/news/1778/cd-projekt-red-and-epic-games-present-the-witcher-4-unreal-engine-5-tech-demo-at-the-state-of-unreal-2025
Working with Epic to Debut The Witcher 4 Unreal Engine 5 Tech Demo
https://www.cdprojektred.com/en/blog/149/working-with-epic-to-debut-the-witcher-4-unreal-engine-5-tech-demo-at-unreal-fest

엔진 소스

Engine/Plugins/Experimental/FastGeoStreaming
Engine/Plugins/Experimental/PCGInterops/PCGFastGeoInterop

저작자표시 비영리 변경금지 (새창열림)

'세미나' 카테고리의 다른 글

언리얼 레이트레이싱과 루멘 2 (0)	2026.01.14
언리얼 레이트레이싱과 루멘 (1)	2026.01.08
UE5 Substrate - 머티리얼 파이프라인의 새로운 패러다임 (0)	2025.11.24
UE5 RDG (Render Dependency Graph) 세미나 (0)	2025.11.06
메모리 프로파일링, 최적화, GC (1)	2025.05.14

gamedevlab 님의 블로그

UE 5.8 FastGeo Streaming 세미나

히치(Hitch)는 나의 적!

0. "로드는 비동기라면서 왜 끊기죠?"

1. FastGeo의 발상: "얘가 꼭 Actor일 필요가 있나?"

2. 먼저 가장 많이 헷갈리는 것: FastGeo != Nanite

3. Actor를 없애면 뭐가 남을까? - FastGeo 내부 구조

1) UFastGeoContainer

2) FFastGeoComponentCluster

3) 사라지는 범용 기능들

4. 진짜 중요한 것 1: Render State를 한 프레임에 다 만들지 않습니다.

내부에서는 어떻게 도나?

5. 진짜 중요한 것 2: Physics State도 공짜가 아닙니다.

6. 그러면 아무 Actor나 FastGeo로 바꿔도 되나요?

기본적으로 잘 맞는 것

기본적으로 잘 안 맞는 것

Mobility가 가장 중요한 기준입니다.

7. "이 액터는 꼭 넣고 싶은데요" - Transformer 설정

8. HLOD까지 FastGeo로 갑니다.

9. 5.7부터는 PCG도 "Component 꼭 만들어야 하나요?"를 묻기 시작합니다.

10. 디버깅: "그래서 대체 뭐가 FastGeo가 된 건데요?"

11. 5.6 -> 5.7 -> 5.8, FastGeo는 어떻게 변했나?

5.6 - 첫 등장

5.7 - PCG와 연결

5.8 - 이제 Static Mesh만 보는 플러그인이 아닙니다.

12. 그럼 얼마나 빨라집니까?

일부러 최악의 상황을 만들어야 합니다.

13. Experimental은 "베타보다 조금 덜 완성됨"이라는 뜻이 아닙니다.

14. 결론: FastGeo는 우리에게 무엇인가?

이것만 기억하세요.

Appendix. 엔진 소스에서 볼 만한 클래스

Appendix. 주요 CVar / Config

참고 자료

Epic Games 공식

CD PROJEKT RED 공식

엔진 소스

'세미나' 카테고리의 다른 글

티스토리툴바

UE 5.8 FastGeo Streaming 세미나

히치(Hitch)는 나의 적!

0. "로드는 비동기라면서 왜 끊기죠?"

1. FastGeo의 발상: "얘가 꼭 Actor일 필요가 있나?"

2. 먼저 가장 많이 헷갈리는 것: FastGeo != Nanite

3. Actor를 없애면 뭐가 남을까? - FastGeo 내부 구조

1) UFastGeoContainer

2) FFastGeoComponentCluster

3) 사라지는 범용 기능들

4. 진짜 중요한 것 1: Render State를 한 프레임에 다 만들지 않습니다.

내부에서는 어떻게 도나?

5. 진짜 중요한 것 2: Physics State도 공짜가 아닙니다.

6. 그러면 아무 Actor나 FastGeo로 바꿔도 되나요?

기본적으로 잘 맞는 것

기본적으로 잘 안 맞는 것

Mobility가 가장 중요한 기준입니다.

7. "이 액터는 꼭 넣고 싶은데요" - Transformer 설정

8. HLOD까지 FastGeo로 갑니다.

9. 5.7부터는 PCG도 "Component 꼭 만들어야 하나요?"를 묻기 시작합니다.

10. 디버깅: "그래서 대체 뭐가 FastGeo가 된 건데요?"

11. 5.6 -> 5.7 -> 5.8, FastGeo는 어떻게 변했나?

5.6 - 첫 등장

5.7 - PCG와 연결

5.8 - 이제 Static Mesh만 보는 플러그인이 아닙니다.

12. 그럼 얼마나 빨라집니까?

일부러 최악의 상황을 만들어야 합니다.

13. Experimental은 "베타보다 조금 덜 완성됨"이라는 뜻이 아닙니다.

14. 결론: FastGeo는 우리에게 무엇인가?

이것만 기억하세요.

Appendix. 엔진 소스에서 볼 만한 클래스

Appendix. 주요 CVar / Config

참고 자료

Epic Games 공식

CD PROJEKT RED 공식

엔진 소스

'세미나' 카테고리의 다른 글

관련글

티스토리툴바