가시성 파이프라인

아래 함수를 통해 3단계를 통해 가시성을 판단한다.

• FVisibilityViewPacket::BeginInitVisibility
  • FrustumCull
    • 프러스텀 + 거리
  • OcclusionCull
    • HZB / 쿼리
  • ComputeRelevence
    • 드로우/패스 분류

가시성 판단에는 아래 4가지 기법을 사용한다.

• 비트맵 기반

  • 각 뷰가 씬의 프리미티브 수만큼 비트를 가진 Map을 만들고 단계별로 비트를 끔
  • View.PrimitiveVisibilityMap

• 워드 단위 병렬 분할

  • 프리미티브를 32개(1DWORD) 단위로 묶어 태스크에 배분
    • https://kim-dj.tistory.com/13
  • WorkerThread x NumFrustumCullTaskPerThread기준으로 태스크 수 결정

• CommandPipe 단계로 연결

  • 프러스텀 컬이 끝난 32개 플록을 곧바로 오클루전 큐로 흘려보냄
  • 따라서, 프러스텀 중 오클루전 이미 시작

• AlwaysVisible 최적화

  • PrimitivesAlwaysVisibleOffset 이후의 프리미티브는 컬링 테스트 제외

FrustumCull

View별로 WORD 블록을 돌면서 비트별로 판정한다. 여러 테스트를 진행하며, 비용 낮은 -> 높은 테스트 순서로 진행한다.

1. Hide/Show 필터

• SceneVisibility.cpp:625
• View 내부 데이터, 플래그로 판단

2. 프러스텀 교차 판정

프리미티브가 View Frusutm 내부에 있는지 확인

• SceneVisibility.cpp:599
• 프러스텀 내부에 존재하는지 확인한다

Custum Culling

• 커스텀 Visibility 훅

  Sphere test (옵션)

• Radius와 비교해 빠르게 안보이는 Primitive 마킹
  • 평면과 Primitive의 Radius를 비교
    • https://mathworld.wolfram.com/Point-PlaneDistance.html
  • SIMD를 통해 4개 평면 한번에 계산
    • https://rhksgml78.tistory.com/304

Box vs 8-plane

• IntersectBox8Plane
  • 평면이 정확히 8개일 때 실행
  • 루프와 경계 브랜치를 제거한 버전
  • 두 SIMD 그룹(4평면씩)으로 실행
  • 옥트리를 통해 내부 판정을 가속할 수 있음

3. 거리 컬링

• 프러스텀 컬링 통과 시에만 테스트

OcclusionCull

프리미티브가 다른 물체에 가려지지 않았는지 확인 프러스텀+거리 통과시에만 테스트한다.

이전 프레인 쿼리 결과를 이번 프레임 테스트에 사용하는 것이 특징이다. (temporal)

• 테스트 결과를 기다리지 않음으로 Wait 시간 제거

가림 판정

• 판정 방법은 총 3개가 있음

  • OcclusionFeedback

    • GPU가 지난 프레임에 이 프리미티브의 픽셀을 실제로 그렸는지를 기록한 피드백 버퍼로 판정

  • HZBOcclusion

    • 이전 프레임 Mipmap Depth Depth로 만든 HZB에 BBox를 한번에 테스트

      • https://ebs12373.tistory.com/123

      • 바운드 박스를 스크린공간으로 투영 -> 박스의 가장 가까운 깊이 계산

      • 밉레벨 선택

        • 사각형이 약 2×2 텍셀만 덮는 밉 레벨을 고름
          • 텍셀 4개만 읽으면 됨

    • GPU: HZB에 가림 테스트 해서 결과 텍스처에 write

    • CPU: readback을 잠궈 ResultsBuffer 포인터에 연결

  • occlusion query

    • 픽셀 샘플을 통해 통과 픽셀이 0개라면 가려짐으로 판정
    • 매번 모든 Primitive를 쿼리할 순 없으니 화면점유율로 재쿼리 확률을 계산

이전 프레임 정보 저장

• 이전 프레임 HZB 저장

• 오클루전 쿼리 정보 저장

쿼리요청

• 오클루전 쿼리는 GPU가 담당하기 때문에 Renderer에서 쿼리 요청을 담당
  • InstanceOcclusionQueryMask에 결과 저장 (다음 프레임 사용)
• 모든 쿼리를 할 수 없으니 LastPixelsPercentage, LastProvenVisibleTime등을 통해 쿼리 여부를 결정

쿼리 결과사용

• PrimitiveOcclusionHistory에 이전 테스트 요청 시 사용했던 Index를 저장해뒀다가 결과 조회시 사용

Relevance

컬링을 통과한 보여줄 프리미티브를 어떤 렌더 패스로 어떻게 그릴지 분류하는 단계이다. PrimitiveSceneProxy가 머티리얼+설정값을 보고 FPrimitiveViewRelevance에 값을 채운다.

Draw Type

• NotDrawRelevant
  • !bDrawRelevance가 설정되어 DrawCommand 제외
• Static+Draw/Shadow
  • LOD 결정 후 StaticMeshVibilityMap에 마킹
    • 캐시된 DrawCommand 사용
• Dynamic
  • AddDynamicPrimitive로 GDME 대상 등록

참고문헌

• https://dev.epicgames.com/documentation/unreal-engine/visibility-and-occlusion-culling-in-unreal-engine?lang=ko

문제 상황

포워드 렌더 시 각 메시를 래스터화 한다. 이때, 픽셀에 영향을 미치는 라이트를 순회하게 되면서 픽셀 수 × 픽셀당 라이트 수에 비례하는 비용이 발생한다. 따라서, 최종적으로 보이지 않는 픽셀까지 라이팅을 수행하는 불필요한 연산이 발생한다.

해결 방안

디퍼드에서는 해당 계산을 분리한다.

1. Base Pass

• 메시를 한 번 래스터화하면서 라이팅은 수행하지 않는다.
• 대신 머티리얼 속성(베이스 컬러, 노멀, 메탈릭, 스페큘러, 러프니스, 셰이딩 모델 등)을 화면 크기의 여러 렌더 타깃(G-Buffer)에 저장한다.

2. Lights

• G-Buffer를 읽어 화면 공간(Screen Space)에서 라이팅을 수행한다.
• 각 화면 픽셀의 G-Buffer 정보를 이용해 모든 라이트의 영향을 계산하고 결과를 누적하여 최종 색상을 생성한다.
• 이 과정은 이미 화면에 보이는 픽셀만 대상으로 수행되므로, 기하(Geometry)의 복잡도와 독립적으로 라이팅을 처리할 수 있다.

최종 문제 해결

라이팅 비용은 화면에 보이는 픽셀 수와 라이트 수에 주로 영향을 받으며, 메시를 다시 렌더링하지 않기 때문에 기하 복잡도와 분리된다.

DeferredShadingSceneRenderer::Render Pipeline

1. InitViews

• 프레임 시작에서 뷰 별로 가시성을 결정
• 프러스텀, 오클루전 등을 통해 가시여부 판단
• 동적 셰도우, 라이트가시성, 메시 드로우 커멘드 준비 뷰 유니폼 버퍼 구성

2. PrePass

• 불투명 지오메트리의 깊이만 먼저 그려 깊이 버퍼를 채움
• 이후 BasePass에서 가려질 픽셀의 PS를 GPU의 early-Z 테스트에서 사전 컬링
  • BasePass의 오버드로우를 줄임

3. BasePass

• 불투면/마스트 메시를 래스터화하면서 라이팅하지 않고 머티리얼 속성을 MRT(Multiple RenderTargets)로 GBuffer에 출력

4. ShadowDepths

• 라이팅 전 그림자 정보를 준비하는 단계
• 각 그림자 캐스팅 라이트에 대해 라이트 시점의 깊이를 그려 셰도우 깊이맵을 만듦 (Virtual Shadow Map)
• 라이팅 단계에서 라이트 별로 이 깊이 맵을 샘플링해 가시성을 구함

5. Light

• GBuffer를 읽어 화면 공간에서 라이트를 SceneColor에 가산 누적
• 픽셀당 한번의 GBuffer 디코드 + 라이트별 누적 계산이 필요

6. Translucency

• GBuffer에 반투명을 인코딩할 수 없으니 (여러 표면이 한 픽셀에 겹침) Forward 방식으로 그림
• 라이팅 된 후 SceneColor 에 블렌딩 하는 방식

7. PostProcess

• 라이팅 된 HDR Scene Color에 적용되는 패스
• MotionBlur, DOF, Bloom, ToneMapping 등

1. AVolume

볼륨은 3D 영역을 구획하는 액터로 실제 기하 정보는 부모 클래스인 ABrush에 존재한다.

2. UBrushComponent

ABrush가 실제로 사용하는 PrimitiveComponent로 렌더링/물리(충돌)을 담당한다.

Model을 하드레퍼런싱 하고 있는데, Model 정보가 변경 되면 내부 정보를 싱크 맞추기 위해 업데이트한다.

2.1. UBodySetup

Physics가 사용하는 Collision정보이다. UBrushComponent::BuildSimpleBrushCollision() 를 통해 Model 정보를 빌드한다.

2.2. FKAggregateGeom

단순 Collision Shape 집합으로 Box, Sphere, Capsule, Convex로 구분해 분류한다. 해당 정보를 통해 Chaos 물리를 사용한다.

리프까지 내려간 뒤 AddConvex를 하는것을 볼 수 있다.

3. UModel

Brush의 실제 BSP 지오메트리 저장소로 모든 Polygon정보와 BSPTree를 구성한다.

3.1. UPolys

원본 Polygon 정보를 그대로 보관한다. 이는 지오메트리 편집 시 사용된다. (따라서 에디터 전용이다.)

해당 정보를 FBspNode로 변환하여 런타임에 사용된다.

3.2. FBspNode

BSP Tree의 노드로 UPolys를 BspBuild하여 Node로 저장한다.

3.3. BspBuild과정

4. BSP(Binary Space Partitioning)

공간 전체를 평면 하나로 두 쪽으로 자르는 일을 재귀적으로 반복해서, 공간을 이진 트리로 표현하는 기법

4.1. 재귀 분할 = 이진 트리

평면 하나는 공간을 정확히 두 반공간(front/back)으로 나눈다. 각 반공간을 또 자르면 트리가 되고, 내부 노드는 분할 평면, 리프는 더 이상 자르지 않은 공간 조각이 된다. 평면으로만 잘랐으므로 리프 영역은 항상 볼록(convex)하다.

4.2. 점 위치 판정

"점 P가 어느 조각에 있나?"는 루트부터 평면 부호 검사(앞? 뒤?)만 반복하면 리프에 떨어진다. 전체 폴리곤을 뒤질 필요 없이 트리 깊이만큼의 내적 연산으로 끝난다. 볼륨 내부 판정(EncompassesPoint)류 쿼리의 원형이다.

4.3. CSG(Constructive Solid Geometry)

브러시를 월드에서 빼는(Subtract) 연산을 생각하자. 브러시 폴리곤들을 월드 BSP에 흘려보내면 각 조각이 "월드 솔리드 내부에 있음 / 빈 공간에 있음"으로 분류된다. Subtract에서는 솔리드 내부에 들어간 브러시 폴리 조각이 뒤집혀 새 표면이 되고, 반대로 브러시 내부에 들어간 월드 폴리 조각은 제거된다.

4.4 볼록 분해

리프가 항상 볼록하다는 성질의 실용적 결과: 오목한 임의 형상도 BSP를 만들고 솔리드 리프만 모으면 겹침 없는 볼록 조각 목록이 된다. 물리 엔진(Chaos)은 볼록체를 좋아하므로, 이것이 브러시/볼륨 충돌 캐시(FKConvexElem)를 만드는 방법이다.

4.5. 스플리터 선택

언리얼식 BSP는 분할 평면을 따로 두지 않고 입력 폴리곤 자신을 스플리터로 쓴다(auto-partitioning). 그래서 어떤 폴리곤을 먼저 고르느냐가 트리 품질을 좌우한다. 스플리터 평면에 걸치는 폴리곤은 둘로 쪼개져(SP_Split) 개수가 늘고, 분할을 아끼면 트리가 한쪽으로 길어진다. UE의 FindBestSplit이 이 둘을 Balance 가중치로 점수화해 고른다.

용어정리

1. Streaming Source

스트리밍의 중심이 되는 소스로, APlayerController가 IWorldPartitionStreamingSourceProvider를 상속받아 사용된다.

만약 커스텀 소스를 만들고 싶다면 UWorldPartitionStreamingSourceComponent를 붙이면 된다.

1.1. 소스 제공자 인터페이스

소스는 "제공자(provider)"가 매 프레임 내놓는다. 인터페이스는 단수/복수 두 진입점을 가진다.

struct IWorldPartitionStreamingSourceProvider
{
    virtual bool GetStreamingSource(FWorldPartitionStreamingSource& OutSource) const;
    virtual bool GetStreamingSources(TArray<FWorldPartitionStreamingSource>& OutSources) const; // 기본: 단수 호출해 배열에 담음
    virtual const UObject* GetStreamingSourceOwner() const;
};

기본 GetStreamingSources는 단수 GetStreamingSource를 호출해 배열 한 칸에 담는 구현이다. 즉 대부분의 제공자는 단수만 구현하면 된다.

1.2. FWorldPartitionStreamingSource

소스 하나는 위치/회전/반경/우선순위/타깃 상태를 가진 단일 스트리밍 요청이다.

여기서 가장 중요한 건 TargetState다. enum은 딱 두 값뿐이다.

enum class EStreamingSourceTargetState : uint8 { Loaded, Activated };

• Loaded — 셀을 메모리에 올려두되 월드에 추가하지 않음(액터가 틱/렌더되지 않음). 예: 근처지만 아직 안 보이는 영역을 미리 준비.
• Activated — 로드 + 월드에 추가(가시). 실제로 보고 상호작용하는 영역.

1.3. shape

소스의 영향 범위는 FSphericalSector(구면 부채꼴)로 표현된다. 중심/반경/축/각도를 가지며, 각도가 360이면 완전한 구다.

struct FSphericalSector { /* Center, Radius, Axis, Angle ... */ };

shape를 실제로 만드는 함수는 FStreamingSourceShapeHelper::ForEachShape다.

• 소스에 Shapes가 비어 있으면, 기본 반경 + ExtraRadius로 단일 구 shape를 만든다.
• Shapes가 있으면, 각 shape마다 반경(bUseGridLoadingRange면 그리드 로딩 반경 × LoadingRangeScale, 아니면 Radius), 각도(bIsSector면 SectorAngle, 아니면 360), 축을 계산해 FSphericalSector를 만든다.
• bForce2D(2D 투영)면 Yaw만 남기고 Z를 0으로 만든다.

또한 소스는 특정 그리드만 노릴 수 있다. IsSourceAffectingGrid가 Include/Exclude 규칙으로 그리드를 걸러낸 뒤에야 shape를 만든다 앞 편에서 본 SpatialHash의 GetCells가 바로 이 그리드명 버전 ForEachShape를 호출한다(소스와 셀 생성부가 맞물리는 경계)

1.4. 소스 수집

정책은 소스를 직접 만들지 않고 서브시스템에서 받는다.

CanStream이 거짓이면 소스를 비우고, 최적화가 켜져 있고 소스 해시가 직전과 같으면 배열 전체를 다시 받지 않고 Velocity만 갱신한다(예측 로딩용).

2. UWorldPartitionStreamingPolicy

셀의 상태를 제어하는 역할.

셀의 상태

• 로드 (Load)
• 언로드 (Unload)
• 활성화 (Activate)
• 비활성화 (Deactivate)

정책 자신은 상태 머신의 제어자일 뿐, 실제 레벨 조작은 셀 ULevelStreaming으로 내려간다.

2.1. 셀의 외부 상태는 3단계다

로드/언로드/활성/비활성은 "행위(전이)"이고, 셀이 실제로 놓이는 "상태"는 3단계 enum이다.

enum class EWorldPartitionRuntimeCellState : uint8 { Unloaded, Loaded, Activated };

이 순서 Unloaded < Loaded < Activated는 코드가 의존하는 불변식이며 static_assert로 강제된다(...RuntimeCell.h:229). 뒤에서 볼 완료 판정의 CellState < QueryState 비교가 이 순서를 전제로 한다.

• Load: 셀을 로드하되 월드에 추가하지 않음 → Loaded
• Activate: 로드 + 월드에 추가(가시) → Activated
• Deactivate: 월드에서 제거하되 로드는 유지 → Activated → Loaded (강등)
• Unload: 완전 언로드 → Unloaded

2.2. LevelStreaming을 통한 상태

중요한 포인트. 셀의 현재 상태는 정책이 직접 저장하는 게 아니라, 셀이 감싼 ULevelStreaming의 실제 상태(ELevelStreamingState)에서 유도된다.

UWorldPartitionRuntimeLevelStreamingCell::GetCurrentState:

• LoadedVisible → Activated
• LoadedNotVisible 이상 → Loaded
• LevelStreaming이 없으면 → bIsAlwaysLoaded면 Activated, 아니면 Unloaded

3. UWorldPartitionRuntimeCell

3.1. 로드/언로드

셀 본체는 추상 클래스이고, 전이 함수는 전부 순수 가상이다. 구현은 UWorldPartitionRuntimeLevelStreamingCell이 맡는다.

셀은 이 밖에 bIsAlwaysLoaded(항상 로드 → 언로드 안 함), bIsSpatiallyLoaded, DataLayers, bIsHLOD, bBlockOnSlowLoading, RuntimeCellData(거리/우선순위 캐싱) 같은 멤버를 가진다.

3.2. ULevelStreaming

전이는 전부 ULevelStreaming에 위임된다

UWorldPartitionRuntimeLevelStreamingCell은 네 전이를 모두 UWorldPartitionLevelStreamingDynamic에 위임한다.

그리고 ULevelStreamingDynamic의 전이는 결국 세 플래그 세팅으로 끝난다.

즉 "셀을 활성화한다"는 결국 bShouldBeLoaded = bShouldBeVisible = true로 만드는 것이고, 실제 레벨 추가/제거는 언리얼의 기존 레벨 스트리밍(UWorld::UpdateLevelStreaming → AddToWorld/RemoveFromWorld)이 처리한다. World Partition은 그 위에 "어떤 셀을 언제 그 상태로 만들지"를 얹은 층이다.

4. UpdateStreamingState

서브시스템이 매 프레임 해당 함수를 호출한다.

RuntimeHash->ForEachStreamingCellsSources가 소스가 커버하는 셀을 훑고, 콜백이 소스의 TargetState에 따라 FrameLoadCells / FrameActivateCells로 분류한다

같은 셀이 로드/활성 양쪽에 걸리면 FrameLoadCells = FrameLoadCells.Difference(FrameActivateCells)로 활성 쪽만 남긴다

현재 상태와 이번 프레임 희망을 비교해 네 집합을 만든다.

예산(MaxCellsToLoad)이 한정돼 있으므로 SortCompare로 순서를 정한다.

• 소스 우선순위(낮을수록 먼저)
• 계층 레벨(높을수록 먼저)
• 셀 priority
• 공간 정렬 우선순위(거리·각도)

5. 실제로 전이를 호출하는 건 누구인가

정책은 "목록을 만들 뿐", 전이 함수를 직접 부르는 건 정책의 SetCellState*와 서브시스템이다.

호출 주체를 정리하면:

• 활성/로드: 서브시스템 UpdateStreamingStateInternal이 GetCellsToUpdate로 모은 셀을 정렬·예산화해 SetCellStateToActivated/SetCellStateToLoaded 호출
• 언로드/서버 강등: 정책의 PostUpdateStreamingStateInternal_GameThread가 직접 SetCellsStateToUnloaded 처리

즉 로드/활성은 예산 제한을 받고(프레임당 N개), 언로드는 곧바로 처리된다.

6. Activate 과정

Activate()를 불렀다고 해서 그 프레임에 바로 화면에 뜨는 게 아니다. 레벨이 실제로 월드에 추가되어 보이게 되면 ULevelStreaming이 OnLevelShown/OnLevelHidden 델리게이트를 쏘고, 이게 셀의 OnCellShown/OnCellHidden을 거쳐 정책까지 전파된다.

그래서 정책은 활성 셀을 FActivatedCells 안에서 Cells(활성 요청됨)와 PendingAddToWorldCells(요청됐지만 아직 안 보임)로 나눠 추적한다 스트리밍이 끝났는지 판정할 때 이 구분이 중요하다.

7. 완료 판정과 블로킹 로딩

7.1. IsStreamingCompleted

IsStreamingCompleted(소스)는 비공간 셀(데이터 레이어)과 각 소스 기반 공간 질의를 차례로 검사한다. 셀의 현재 상태가 질의 상태와 다르면(스킵 불가 조건에서) 미완료로 본다.

7.2. 블로킹 로딩

스트리밍이 너무 느려서 플레이어가 아직 안 로드된 영역으로 넘어가버릴 위험이 있으면, 프레임을 멈추고서라도 로드를 끝내야 한다.

• 성능이 Critical 이상이고 블록 대상이면 UpdateStreamingPerformance가 World->bRequestedBlockOnAsyncLoading = true로 만들어 다음 프레임 블로킹 로딩을 요청
• 반대로 성능 저하 중에는 CanAddCellToWorld가 비블로킹 셀의 월드 추가를 막아 급한 셀부터 처리
• 어떤 소스/셀이 블로킹 대상인지는 소스의 bBlockOnSlowLoading과 셀의 bBlockOnSlowLoading 플래그로 정함

쿠킹 시 or 에디터에서 실행 시 해당로직이 실행된다. 해당 문서에서는 PIE에서 실행될 때를 다룬다.

1. GenerateStreaming 호출

PIE가 호출되면서 GenerateStreaming 함수가 호출된다.

컨테이너 컬렉션을 구성한 뒤 GenerateContainerStreaming()으로 넘긴다.

이후 두 가지 큰 작업이 순서대로 일어난다

• Preparation Phase(클러스터/ActorSet 준비)
• RuntimeHash 스트리밍 생성(셀 배치).

2. Preparation Phase

해당 단계에서는 ActorDesc를 클러스터링 하는 과정을 거친다.

2.1. 클러스터링 조건

ActorDesc로 넣어둔 References Actor들을 클러스터링 한다.

2.2. 클러스터링 알고리즘

참조를 양방향 간선으로 만든 무방향 그래프 구성하고 명시적 스택 기반 반복 DFS로 연결 요소 수집한다.

지금까지 내용을 정리하자면 아래 그림과 같다.

2.3. 셀 배치

이후 ActorSetInstance 를 통해 ActorSet 단위로 Bound등을 검사해서 그리드 셀에 배치한다.

셀에 배치하는 규칙은 런타임 해시 규칙에 따라 다르다. virtual bool GenerateStreaming 를 따라가면 셀배치 로직을 확인할 수 있다.

UWorldPartitionRuntimeSpatialHash 클래스를 보면 CellSize크기로 나눠진 cell에 배치가능한지 불가능하다면 Level을 올리며 배치가능한 Cell을 찾고 있다 Level이 1오를 수 록 CellSize는 2배가 된다

언리얼에서 월드파티션을 사용하지 않는 Level이라면 일반적으로 Level 패키지에 Actor를 포함한다. 하지만 월드파티션을 사용하는 Level은 월드 크기가 일반적인 케이스보다 N배 크고 포함되는 Actor도 많다.

이로 인해 Level에 포함해서 에디터에서 한번에 로드한다면 메모리 크래시가 발생하고 Level단위로 저장되기 때문에 분산 작업이 불가한 문제가 있다.

따라서, 액터 인스턴스의 데이터를 외부 파일에 저장하는 방법을 사용한다. (One File Per Actor, OFPA)

참고 문서: https://dev.epicgames.com/documentation/unreal-engine/one-file-per-actor-in-unreal-engine

해당 인스턴스를 로드하지 않고 정보를 가져오기 위한 메타 데이터를 WorldPartitionActorDesc로 구현한다. 이는 에디터 전용이다.

2. WorldPartitionActorDesc

아래 정보들을 통해 액터의 로드/언로드를 제어한다. 또한 액터를 직접 로드하지 않더라도 메타데이터를 통해 연산하기도 한다.

액터 저장 시 업데이트 되고 FAssetData에 저장된다.

2.1. FWorldPartitionActorDescInstance

UE5.4부터 Transient한 데이터를 분리해서 다루기 위해 FWorldPartitionActorDescInstance 클래스가 추가되었다. 실제로 데이터 Get과 같은 인터페이스 함수는 해당 클래스에서 처리한다.

엔진 업뎃했더니 함수가 다 없어져서 고생했었다...

3. UActorDescContainer

ActorDesc의 Add, Remove, Update 등에 대한 액션을 처리하고 관리하는 컨테이너 클래스

Transient 하게 존재한다.

3.1. UActorDescContainerInstance

Container가 Transient한데 Instance 클래스가 존재한다.

해당 클래스는 추상화 되는 구간이다. ActorDescContinerInstance 베이스 클래스가 존재한다.

이를 상속받은 LevelInstanceContainerActorInstance가 존재한다.

따라서 어떤 Level(레벨 시스템)에 소속한 ActorDesc인지에 따라 액션을 다르게 처리하기 위한 클래스임을 알 수 있다. 또한 레벨 인스턴스처럼 Package는 1개이지만 N곳에 인스턴싱된 액터를 사용할 때 Instance를 N개 만들어서 제어할 수 있다.

4. UActorContainerSubsystem

UActorDescContainer를 관리하며, InvalidMapAssets을 통해 레벨이 존재하지 않지만 남은 고아 Actor 정보를 가지고 있다.

게임 오디오 엔진 미들웨어로, 게임에서 사운드 재생을 제어하기 위한 도구다. 이를 사용하므로서 아래와 같은 이점이 있다.

• 복잡한 사운드 로직을 게임로직과 분리 가능
• 사운드 디자이너가 직업 사운드 로직 작업 가능
  • 역할 분리

Wwise 적용하기

1. Wwise 설치

먼저 Wwise를 설치하여야한다.

1.1. Audiokinetic Launcher 설치

공홈에서 런처를 다운받는다 https://www.audiokinetic.com/ko/download/

1.2. Wwise를 설치

Wwise 탭에서 설치한다.

1.3. Unreal에 플러그인 추가

공식 가이드 문서가 있다. https://www.audiokinetic.com/ko/public-library/2025.1.7_9143/?id=index.html&source=UE4&utm_source=chatgpt.com

이게 더 직관적이다.. https://www.audiokinetic.com/ko/community/blog/how-to-play-sounds-from-wwise-in-unreal-engine/#project-3

1.4 테스트하기

Wwise 에디터에서 wav 파일을 임포트하고 event화하였다. 그리고 사운드 뱅크에 추가하였다.

언리얼 에디터에서 사운드 뱅크를 동기화하면 에셋이 만들어진다.

볼륨 진입하면 Ak Event 실행하게 만들었다.

마치며

• Wwise Unreal Integration을 적용
• Wwise Authoring에서 생성한 Audio Event와 SoundBank를 Unreal Runtime에서 호출할 수 있는 기본 오디오 파이프라인을 구축

작업 흐름

Wwise Authoring
    ↓
Audio Import
    ↓
Event 생성
    ↓
SoundBank Generate
    ↓
Unreal Wwise Integration
    ↓
AkAudioEvent 참조
    ↓
C++ PostEvent 호출
    ↓
Runtime Sound Playback

드디어 애니메이션을 실행시킨다. 언리얼의 애니메이션 기능을 하나씩 붙여보려고 한다. 해당 문서에서는 AnimSequence 실행과 RootMotion 적용을 다룬다.

구현 내용

0. Skinned Mesh

0번으로 스킨 메시가 렌더링 되어야한다. 이미 이전에 렌더링되도록 만든것 아닌가라는 의문이 든다면 스킨 메시에 대해서 공부해보자.

스켈레탈 메시는 아래 사진 우측과 같이 본이 트리 구조로 이루어져있다. 본은 부모본에 Attach된 상태라고 인지하면 쉽다. 부모 본에 상대적인 위치를 가지고 있어 부모 본의 Transform에 변형이 가해진다면 자식 본들도 상태 Transform이 변경된다.

또한 이러한 본에 의해 메시 버텍스들이 움직이게 된다. 메시 버텍스 하나 당 N개의 본의 영향을 받을 수 있고 가중치가 설정되어 있다. 이거 때문에 스킨메시의 버텍스 포지션 구하는 방법이다른 것이다!

스켈레탈 컴포넌트와 프록시의 로직에서 BoneMatrix를 추가하고 VS를 다른 쉐이더를 사용하도록 처리했다. 아래는 본인덱스(4개 사용)에 따라 매트릭스를 계산해 버텍스 포지션 설정하는 것이다.

// 매트릭스 계산
float4x4 MakeSkinMatrix(uint4 idx, float4 w)
{
    return gBones[idx.x] * w.x +
           gBones[idx.y] * w.y +
           gBones[idx.z] * w.z +
           gBones[idx.w] * w.w;
}

// VS
VSOut VSMain(VSIn vin)
{
    VSOut o;

    float4x4 skin = MakeSkinMatrix(vin.boneIdx, vin.weight);

    float3 skPos = mul(float4(vin.pos, 1), skin).xyz;
    float3 skN   = mul(vin.n, (float3x3)skin);
    float3 skT   = mul(vin.tangent.xyz, (float3x3)skin);

    float4 posW  = mul(float4(skPos,1), gWorld);
    o.pos        = mul(float4(skPos,1), gWorldViewProj);
    o.posWS      = posW.xyz;

    float3x3 world3    = (float3x3)gWorld;
    float3x3 normalMat = transpose(Inverse3x3(world3));

    float3 N = normalize(mul(skN, normalMat));
    float3 T = normalize(mul(skT, world3));
    T = normalize(T - N * dot(N,T));

    float sign = vin.tangent.w;
    o.normalWS  = N;
    o.tangentWS = float4(T, sign);
    o.bitanWS   = normalize(cross(N,T)) * sign;

    o.uv = vin.uv;
    return o;
}

1. AnimSequence

일단 FBX 파일 중 애니메이션이 들어있는 파일을 AnimSequenceAsset으로 임포트한 뒤 사용하였다.

1) AnimSequenceAsset

• 프레임, 본 마다 Transform 정보를 저장
• 정적 데이터 역할을 하기 때문에 런타임에 데이터 정보가 변하지 않기를 기대

2) AnimInstance

• 애니메이션 관련 런타임 로직을 담당할 객체
• AS를 실행할 때 AnimSequenceAsset을 바라보며 정적데이터를 통해 런타임 Bone 데이터를 Modify하는 역할을 수행
  • AnimInstance에 LocalPose 변수를 둬서 해당 변수를 변경하는 방식

    // 본별 Transform 보간 -> 행렬로 변환하여 LocalPose에 저장
    for (uint32_t b = 0; b < m_BoneCount; ++b)
    {
        const Transform& k0 = sec.Keys[(size_t)f0 * m_BoneCount + b];
        const Transform& k1 = sec.Keys[(size_t)f1 * m_BoneCount + b];

        Transform blended = Transform::Lerp(k0, k1, alpha);

        DirectX::XMFLOAT4X4 M;
        DirectX::XMStoreFloat4x4(&M, XMMatrixTranspose(blended.ToMatrix()));
        m_LocalPose[b] = M;
    }

• AnimInstance에서 계산한 LocalPose값을 SkeletalMesh에서 적용

  void SkeletalMeshComponent::BuildFinalPalette_FromLocalPose(const std::vector<DirectX::XMFLOAT4X4>& localPose)
  {
    //.. 생략
  
    // 로컬 Transform을 월드 Transform으로 변경
    BuildGlobalPose_FromLocalPose(localPose);
  
    // FinalPalette
    for (uint32_t i = 0; i < n; ++i)
    {
        const auto& off = skel.Bones[i].Offset;
        m_FinalPalette[i] = MulM(MulM(skel.GlobalInverse, m_GlobalPose[i]), off);
        XMStoreFloat4x4(&m_FinalPalette[i], XMLoadFloat4x4(&m_FinalPalette[i]));
    }
  

}

끼얏호우 잘동작한다 !!
>사실 이렇게 바로 잘 동작하지 않았고 Matrix 때문에 꼬여서 디버깅을 많이했다. FBX는 Col-Major를 사용해서 matrix를 transpose해서 가져오고 있다. 이때, 어디까지 Col-Major를 사용하고 어디까지 Row-Major를 사용할지에 대해 정확하게 정하지 않은 상태에서 작업을 하다보니 한쪽에서 매트릭스가 꼬이는 사태가 발생했고 이를 디버깅하기 매우 어려웠다...(사실 코드 보고 알았다)

>다음부터 작업할 땐 꼭 해당 정책을 정해야 겠다고 다짐했다 또한 Transpose하는 부분에선 꼭 이유를 적어둬야겠다. 내 코드니깐 알아보지 다른사람 작업이었으면 못찾았을 것 같다.

![](https://velog.velcdn.com/images/jm450_/post/f100852d-5067-403c-9f96-c320c51030c8/image.gif)

### 3) RootMotion 구현
성질이 급해서 movementComponent도 없으면서 RootMotion을 구현했다... 일단 물리는 생각하지 않고 RootComponent의 Transform 변경해주는 기능만 만들어뒀다.

캐릭터의 머티리얼이 날아간 이유는... 믹사모 캐릭터에는 루트본이 없다.... 그래서 언리얼에서 루트본 추가하고 FBX로 Export하니깐 머티리얼이 다 날아가있다... 일단 이 이슈는 나중에 보기로하고 작업을 진행했다.

- 루트 모션을 실행하기 위해선 RootBone의 Transform을 본에서 제거해줘야한다. (RootComp에서 소모하기 위함)
  ```cpp
  void AnimInstance::ApplyRootLockToLocalPose(const AnimSection& sec)
{
    //...생략

    switch (sec.RootLockMode)
    {
    case ERootLockMode::RefPose:
        if (root < m_Skeleton->RefLocalPose.size())
            m_LocalPose[root] = m_Skeleton->RefLocalPose[root];
        break;

    case ERootLockMode::AnimFirstFrame:
        if (!m_bHasFirstRootInSection)
        {
            m_FirstRootInSection = SampleBoneTransform(sec, root, 0.f);
            m_bHasFirstRootInSection = true;
        }
        XMStoreFloat4x4(&m_LocalPose[root], m_FirstRootInSection.ToMatrix());
        break;

    case ERootLockMode::Zero:
    default:
        XMStoreFloat4x4(&m_LocalPose[root], XMMatrixIdentity());
        break;
    }
}

• 그리고 루트의 델타 Transform을 추출해 MovementComponent에서 Root로 적용시킨다

  void CharacterMovementComponent::ConsumeAndApplyRootMotion(float dt)
  {
    //... 생략
  
    const Transform deltaMeshSpace = anim->ConsumeExtractedRootMotion();
    const Transform deltaRootSpace = ConvertMeshSpaceDeltaToRootSpace(deltaMeshSpace, sk);
    const Transform deltaScaled = ScaleRootMotionTranslationByRootScale(deltaRootSpace, root);
    MoveWithCollision(deltaScaled);
  }

사실 렌더러는 퐁쉐이딩만 하도록 대충 만들어두려고 했는데 보이는게 안이쁘니깐 애니메이션 작업도 흥미가 안생기더라... 그래서 PBR을 구현해보기로 했다. 인터넷에 자료가 많아서 많이 따라갔다.

개념

PBR (Physically Based Rendering)

1. PBR 개요

PBR은 물리 기반(혹은 물리 근사)으로 빛-재질 상호작용을 모델링해, 환경/조명 변화에 대해 일관된 결과를 얻는 렌더링 방식이다. 실시간 PBR에서 핵심 구성은 보통 아래 3가지로 설명한다.

• Microfacet Model: 표면을 “아주 작은 거울 조각”들의 집합으로 보고 반사를 모델링
• Energy Conservation: 반사 + 확산으로 나가는 에너지가 들어오는 에너지를 초과하지 않도록 제한
• BRDF: 입사/출사 방향에 따른 반사 비율을 정의하는 함수(특히 Cook-Torrance)

2. Microfacet Model (미세면 모델)

개념 표면은 완전히 매끈하지 않고, 미세한 면(거울 조각)들이 다양한 방향을 가진다고 가정한다.

• Normal Map: 픽셀마다 microfacet의 “평균 법선 방향”을 바꾼다.
• Roughness: microfacet 법선 분포의 폭(퍼짐)을 바꾼다.
  • roughness ↓ : 하이라이트가 작고 날카로움
  • roughness ↑ : 하이라이트가 넓고 흐림

픽셀 법선(N) 구성 흐름 실무적으로는 “기본 법선(지오메트리)” 위에 “노멀맵(탄젠트 공간)”을 적용해 최종 월드 법선을 만든다.

1) 버텍스 노멀 보간으로 픽셀 노멀 얻기

• VS에서 월드 공간 normal을 넘기면 PS에서 보간된 픽셀 normal을 얻을 수 있음.

2) 노멀맵을 샘플링해 TBN으로 월드 공간 변환

• 노멀맵은 보통 Tangent Space 기준
• 샘플한 노멀(nTS)을 TBN으로 변환해 월드 노멀로 만든다.
• 이때 TBN의 N은 1)에서 얻은 보간 노멀을 사용

  float3 ApplyNormalMap(float2 uv, float3 N, float3 T, float3 B)
  {
    float3 nTS = DecodeNormalTS(gTexNormal.Sample(CommonSampler, uv).xyz);
    float3x3 TBN = float3x3(normalize(T), normalize(B), normalize(N));
    return normalize(mul(nTS, TBN)); // tangent->world
  }

3) D(NDF): Roughness로 분포 폭 제어 (GGX) Cook-Torrance 스페큘러의 첫 요소는 D (Normal Distribution Function). 여기서 roughness가 하이라이트의 모양/크기에 가장 크게 영향을 준다.

• 사용 기법: DistributionGGX

• NdotH: N과 H(half vector)의 내적

• roughness ↑ → 분포가 넓어짐 → 하이라이트가 퍼짐

  // D: GGX(Trowbridge-Reitz) Normal Distribution Function
  // - microfacet들의 법선이 하프벡터 H 방향으로 얼마나 모여있는지(분포)를 근사
  // - roughness ↓  -> 분포가 좁아짐(하이라이트 작고 날카로움)
  // - roughness ↑  -> 분포가 넓어짐(하이라이트 넓고 흐림)
  float DistributionGGX(float NdotH, float roughness)
  {
    // UE4 관례: roughness를 제곱해서 'a'로 사용 (반응을 더 자연스럽게 만듦)
    // a가 작을수록 매우 매끈한 표면에 해당
    float a  = roughness * roughness;
    float a2 = a * a;
  
    // GGX 분모: ((N·H)^2 (a^2 - 1) + 1)^2
    // NdotH가 1(=H가 N과 거의 같은 방향)일 때 D가 크게 나와 하이라이트가 생김
    float denom = (NdotH * NdotH) * (a2 - 1.0f) + 1.0f;
  
    // 정규화까지 포함한 GGX NDF
    return a2 / max(PI * denom * denom, 1e-6);
  }

  3. Energy Conservation (에너지 보존)

• 개념* 표면에서 나가는 빛(반사 + 확산)은 들어오는 빛을 넘을 수 없다. Cook-Torrance는 보통 Specular 비율(kS)과 Diffuse 비율(kD)로 나눠 이를 만족시킨다.

• kS: 반사(specular)로 나가는 비율

• kD: 확산(diffuse)로 나가는 비율

• 보통 트레이드오프: kD = 1 - kS

• Metallic workflow에서는 금속일수록 diffuse가 사라짐:

  • metallic = 1 → diffuse 거의 0
  • metallic = 0 → dielectric → diffuse 유지

Fresnel: kS(반사 비율)를 각도로 결정 Fresnel은 시선/입사 각도에 따라 반사가 증가하는 현상. 실시간에서는 보통 Schlick 근사를 사용한다.

• F0: 정면(수직)에서의 기본 반사율
  • 비금속: 대략 0.04 (4%)
  • 금속: 반사 자체가 색을 띠므로 baseColor가 F0 역할을 함
• metalness 워크플로우의 F0:
  • F0 = lerp(0.04, baseColor, metallic)
• Schlick:
  • F = F0 + (1 - F0) * (1 - cosTheta)^5
  • cosTheta는 보통 dot(V, H) 계열 사용

    float NdotL = saturate(dot(N, L));
    float NdotV = saturate(dot(N, V));
    float NdotH = saturate(dot(N, H));
    float VdotH = saturate(dot(V, H));
    

float3 F0 = lerp(float3(0.04, 0.04, 0.04), baseColor, metallic);

float3 F = FresnelSchlick(VdotH, F0);

float3 kS = F; float3 kD = (1.0f - kS) * (1.0f - metallic);

### 4. BRDF (Bidirectional Reflectance Distribution Function)
**개념**
BRDF는 **입사 방향(wi)와 출사 방향(wo)**에 따라 반사되는 빛의 비율을 반환하는 함수다.
Cook-Torrance BRDF는 보통 다음처럼 구성한다.
- Diffuse(확산): Lambert
  - `diffuse = baseColor / PI`
  - 에너지 보존을 위해 `kD`를 곱해 사용
- Specular(반사): Cook-Torrance
  - `pec = (D * G * F) / (4 * NdotV * NdotL)`
  - D: microfacet 분포 (GGX)
  - G: microfacet 가림(Geometry)
  - F: Fresnel (Schlick)

**Geometry(G): microfacet 가림(Shadowing/Masking)**
거칠수록 미세 요철이 서로를 더 가려서 스페큘러 기여가 줄어든다.
- View 방향에서 가림: Masking
- Light 방향에서 가림: Shadowing
- Smith 형태로 결합:
  - `G(N,V,L) = G1(N,V) * G1(N,L)`

float GeometrySchlickGGX(float NdotV, float roughness) // NdotL이 들어올 수 있음 { float r = roughness + 1.0f; float k = (r * r) / 8.0f; // direct lighting용 return NdotV / max(NdotV * (1.0f - k) + k, 1e-6); }

// G1: Schlick-GGX (direct lighting용 k 사용) float GeometrySchlickGGX(float NdotV, float roughness) { float r = roughness + 1.0f; float k = (r * r) / 8.0f; // direct lighting용 return NdotV / max(NdotV * (1.0f - k) + k, 1e-6); }

// Smith: view 방향 가림 * light 방향 가림 float GeometrySmith(float NdotV, float NdotL, float roughness) { float ggxV = GeometrySchlickGGX(NdotV, roughness); float ggxL = GeometrySchlickGGX(NdotL, roughness); return ggxV * ggxL; }

// Cook-Torrance specular BRDF 조립은 EvaluatePBR_Direct 내부에서: // spec = (DGF) / (4NdotVNdotL) // diffuse = baseColor/PI (에너지 보존 위해 kD 곱) // 최종: (diffuse + spec) * radiance * NdotL

# 작업 결과

스켈레탈 메시

![](https://velog.velcdn.com/images/jm450_/post/09d9259d-3e8c-47de-b6d3-faab17a987d7/image.png)

스태틱 메시
![](https://velog.velcdn.com/images/jm450_/post/46cf53a0-4926-4f94-8fc7-a949bba76aae/image.png)

요즘 DX11로 애니메이션 기능들을 하나씩 만들어보고있다. 그 중 최근에 RootMotion을 구현했는데, 취준 때 루트모션과 비슷한 기능인 모션워핑을 사용한 경험이 생각났다. 모션 워핑에서는 어떻게 루트 모션을 사용했고, 달성한 결과는 무엇인지 알아보자.

[UE5] Assassin14 - Motion Warping을 사용한 암살1: https://velog.io/@jm450_/UE5-Assassin13-Motion-Warping%EC%9D%84-%EC%82%AC%EC%9A%A9%ED%95%9C-Assassination

[UE5] Assassin14 - Motion Warping을 사용한 암살2: https://velog.io/@jm450_/UE5-Assassin13-Motion-Warping%EC%9D%84-%EC%82%AC%EC%9A%A9%ED%95%9C-%EC%95%94%EC%82%B42

2. 모션 워핑

Motion Warping은 캐릭터의 루트 모션이 워프 타깃과 일치하도록 애니메이션의 특정 구간을 동적으로 정렬해주는 기능이다.

1) 사용자 인터페이스

애님 몽타주

언제부터 언제까지 워핑할지를 AnimNotifyState(모션 워핑) 로 워핑 구간을 만든다.

• 애님에서 RootTransform의 변화값이 있는 구간으로 설정해 자연스러운 이동을 설정 가능
• Notify 프로퍼티
  • Root Motion Modifier 타입
    • Scale: 스케일을 “균등하게” 바꿔서 맞추는 워프
      • Skew Warp: 워핑 구간 끝에 레벨상의 위치/회전이 타깃과 딱 맞도록 루트모션을 워프
  • Warp Target Name: 블루프린트에서 연결할 “타깃 이름”(이름이 반드시 일치해야 함)
  • Warp Translation / Warp Rotation: 이동/회전 워핑을 각각 켤지
  • Ignore ZAxis: 이동 워핑에서 Z를 무시할지
  • Rotation Type
    • Default: 타깃의 회전과 일치
    • Facing: 타깃을 “바라보도록” 회전
  • Warp Rotation Time Multiplier: 회전이 얼마나 빨리 목표 회전에 도달할지(예: 2초 구간에서 0.5면 1초만에 회전 완료)

모션 워핑 컴포넌트

“워프 타깃(목표 위치/회전)이 어디인지”를 이름으로 등록(Add/Update Warp Target) 한다.

AnimNotifyState를 동적으로 추가할 수도 있다.

• 하지만 WarpTarget도 동적으로 정하는데 구간도 동적으로 넣어줘야할까?
• 에셋 관리하는 입장에선 불안할 것 같다.
• 조건에 따라 넣어줘야 된다면 Notify에 Condition을 추가하는 방식으로 확장하는게 더 좋을 것 같다.

주의할 점

해당 기능은 RootMotion을 기반으로 동작하기 때문에 RootMotion을 활성화해줘야한다.

2) 내부 로직 보기

AnimNotifyState_MotionWarping 생성자를 보면 RootMotionModifier_SkewWarp를 사용하는 것을 알 수 있다.

Modifier는 MotionWarpingComponent가 관리한다

MotionWarpingComponent는 CharacterMovmentComponent, Character 등과 연결하기 위한 Adapter를 가지고 있고 해당 인스턴스의 이벤트를 받아 RootMotion을 Modify한다.

• Adapter를 쓰는 이유는 이동을 담당하는 Component가 여러개 인데, 여러개의 Componenet의 기능을 공통 인터페이스로 사용하기 위함이다
• 궁금한 사람은 MovementComponent, MoverComponent를 보길 바람
  • Mover가 5.x에 나왔던걸로 기억하는데 두 기능 유지보수 하느라 에픽애들 좀 고생하는 것 같다. 예전엔 이슈도 많았는데 이젠 꼼꼼히 챙기는듯... (사실 안써봐서 잘모름)

ProcessRootMotionPreConvertToWorld 쪽 로직을 타면서 Modify된다.

이런식으로 MovementComp(또는 Mover)에서 RootMotion 데이터를 저장할 때 딜리게이트를 Broadcast하여 다른 시스템에서 PreProcess할 기회를 준다.

모션 워핑에서는 Pre 시점에 연결해서 PreProcess하고 있음

이후에는 RootMotion이 적용되는 것과 같다.

• RootMotionParams 데이터로 설정되고

  • 최종 RootMotion의 AnimTransform에 Accumulate 된다.
  • Translation은 Velocity로 적용
  • Rotation은 추가해서 MovementUpdate로 적용

• 궁금한 사람은 void UCharacterMovementComponent::PerformMovement(float DeltaSeconds) 참고

3) 의견

기능적으로는 RootMotion에서 추가되는데, 코드적으로는 많이 분리해서 만들어둔 플러그인 기능이다. RootMotion의 장점은 AnimSequence에서 잡은 키값을 그대로 Character에 적용함으로서 캐릭터 움직임을 현실적으로 할 수 있다는 장점이 있다.

반면에 모션 워핑의 경우 TargetTransform으로 이동시키는 기능이다보니 Transform계산을 코드 내부에서 하고 있고 이 부분에서 연출적으로 어색한 부분이 생길 수 밖에 없는 구조이다. 따라서 해당 기능을 사용한다면 걸음 같은 RootMotion Transform의 정확도가 중요한 애님보다 특정위치까지 점프해서 도달하는 등 역동적인 애님에 효과적인 기능이 될 수 있다. 전투 시스템에서 많이 사용할 수 있을 것으로 기대된다.

데이터 유지보수 관점에서 보면 모션 워핑 Notify를 사용함에도 RootMotion을 활성화 하지 않았다면 Warning Message를 출력하고 모션 워핑 이름도 휴먼에러가 날 수 있기 때문에 규칙화해서 넣어두면 ComboBox로 선택할 수 있는 구조로 만드는게 좋을 것 같다. Settings같은 곳에 넣어두고 매핑된 이름만 사용하는 구조다. Settings에서 지울 때는 이미 이름을 사용하고 있는곳을 찾아서 제거할지 다이얼로그 띄워줘 데이터를 클린하게 핸들링 할 수 있어야된다.

결론적으론 제한적으로 사용할 수 밖에 없는 기능이고(자연스러운 연출적 관점) 그대로 사용하기엔 데이터 유지보수에서 어려운 부분이 있기 때문에 사용 전 규칙을 정하는 과정이 필요해보인다.

StaticMesh를 렌더할 수 있도록 엔진을 만들었다. 해당 엔진에 FBX 파일을 임포트하여, StaticMesh로 변환한 뒤 렌더하는 기능을 구현한다.

아이디어

• IMGUI를 통해 모델 파일경로 입력
• Assimp을 통해 FBX 파일 읽기
• 읽어온 ai 데이터를 엔진 데이터로 변환
  • MeshAsset
  • MaterialInstance

서브 메시 개념은 생각하지 못해 이후에 도입했습니다.

구현 내용

1. Assimp 임포트

1.1. 임포트 플래그

Assimp에서 제공하는 플래그를 통해 내가 만든 엔진 구조에 맞게 읽음

• aiProcess_Triangulate
  • 모든 면을 삼각형으로 변환
• aiProcess_JoinIdenticalVertices
  • 동일 버텍스 병합
• aiProcess_ImproveCacheLocality
  • GPU 캐시 효율 향상을 위한 인덱스 재정렬
• aiProcess_SortByPType
  • Primitive 타입별 정리
• aiProcess_FlipUVs
  • UV 반전
• aiProcess_ConvertToLeftHanded
  • 좌수계 변환

1.2. Assimp 데이터 구조

aiScene Assimp::Importer::ReadFile()의 결과는 aiScene*이며, 이 객체가 임포트된 모델의 루트 컨테이너다.

주요 멤버

• scene->mRootNode : 노드 트리의 루트
• scene->mMeshes[] : 메시 배열(실제 geometry 데이터)
• scene->mMaterials[] : 머티리얼 배열
• scene->mNumTextures / mTextures[] : embedded texture(내장 텍스처) 배열

이걸 봤을 때 Mesh와 Material이 배열인걸 보고 뭔가 잘못됐다 생각함. 내 엔진은 StaticMeshComp 1--1 MeshData 1--1 Material 1대1구조임

** aiNode ** Assimp 구조에서 노드(aiNode)는 트랜스폼을 가진다. 반면, 메시 데이터는 scene->mMeshes[idx]에 있다.

• 노드는 node->mMeshes[]로 참조하는 mesh index를 보유
• 실제 버텍스/인덱스는 scene->mMeshes[meshIndex]에 존재
• 따라서 FBX 같은 포맷은 보통 node 트리를 순회하면서 누적 트랜스폼을 적용해야 제대로 보인다.

최종 코드에서는 DFS로 노드를 순회하며 누적 트랜스폼을 만든다:

• global = parent * node->mTransformation
• 각 node가 가진 mesh index에 대해 scene->mMeshes[meshIndex]를 처리

2. Mesh 빌드

2.1. 버텍스 생성

• Position: p' = global * p
• Normal: inverse-transpose(upper3x3(global)) 적용 후 normalize

이를 통해 노드 트랜스폼(특히 스케일/회전)이 포함된 올바른 월드 공간 지오메트리를 얻는다.

2.2. 머지 시 고려할 점

기존 엔진 구조로 임포트 하기 위해 하나의 aiMesh만 사용해 임포트 하였더니 특정 부위가 정상적으로 구성되지 않은 것을 확인했다.

aiNode가 N개 이고, 다른 meshIndex를 사용하는 경우였다. 이를 고려해 ChildNode를 순회하며 버텍스를 생성해줘야한다.

ChildNode의 버텍스 정보는 캐싱해둬야 한다. 자세한 내용은 Material에서 다룬다.

3. Material 빌드

3.1. Texture 로드

텍스쳐 경로에 따라 처리 로직을 나눈다

텍스쳐가 FBX에 포함되어 있는 경우

• if (const aiTexture* at = scene->GetEmbeddedTexture(t8.c_str()))를 통해 가져오기 시도
• CreateSRVFromEmbeddedRawBGRA8를 통해 SRV 변환

scene->mTextures를 레퍼런스 하는 경우

• texture path string이 "*index" 형태인지 검사
• scene->mTextures접근하여 CreateSRVFromEmbeddedRawBGRA8를 통해 SRV 변환

외부 경로인지 확인

• 경로에 파일이 있는지 확인하여 로드
• DirectX::CreateWICTextureFromFile

3.2. 로드시 고려할 점

위에서 봤듯이 scene->mMaterials[]은 배열이다. 각각의 메시가 참조하는 머티리얼이 다르다. 따라서 엔진에서도 메시를 작은 단위 (굳이 노드가 아니여도 됨)로 나누고 작은 단위의 메시 마다 머티리얼 참조를 할 수 있는 구조를 만들어야한다.

나는 하나의 머티리얼만 사용하는 줄 알고 0번을 레퍼런스 하도록 구현했었는데 아래와 같이 0번 머티리얼을 사용하지 않는 메시의 머티리얼이 비정상적인 것을 볼 수 있다

이를 해결하기 위해 아래와 같이 대응했다

• 메시를 Section으로 나눌 수 있도록 데이터 구조 변경
• Section 마다 MaterialIndex를 가지고 있도록 변경
• MaterialInstance를 Array로 가지고 있도록 변경
• Section마다 나눠 DrawCall

결과

1. 메시 NormalVector 임포트 잘 되었는지 확인

2. 메시 데이터 및 머티리얼 임포트 확인

• 오른쪽
  • 최종 결과
• 왼쪽
  • 제공된 FBX 파일
• 중간
  • 임포트 실패 과정...

재귀적으로 유클리드 공간을 초평면상의 볼록 집합으로 분할하는 알고리즘

• 하나의 공간을 두 개씩 나누어 가는 과정을 재귀적으로 실행
• 맵 렌더링, 충돌 감지 등에 최적화를 위해 사용

공간 분할 실행 흐름

1. 하나의 분할 평면을 선택
2. 하나의 분할 평면을 두 개의 하위 공간으로 분할
3. 각 하위 공간에 대해 1~2 과정을 재귀적으로 반복
4. 원하는 기준 (최종 목적)에 도달할 때 까지 해당 과정을 수행

   해당 과정을 거쳐 만들어진 트리를 BSP 트리 라고 부르며, 노드는 분할 평면 정보를 리프노드는 최종적으로 분할이 완료된 공간 정보를 담게된다.

재귀 종료 조건

BSP는 다양한 용도로 사용되고, 용도에 따라 언제까지 재귀를 실행할지 결정해야 한다.

1. 렌더링 최적화

용도 시야에 보이는 부분만 효율적으로 렌더링하기 위해 공간 분할하여 가시성을 판단

종료 조건 각 리프 노드가 시야 계산이 필요없는 수준, 렌더링 퀄리티에 영향을 미치지 않는 수준이 된다면, 더 이상 분할할 필요가 없음

2. 충돌 검출

용도 물리 엔진에서 객체 충돌을 빠르게 판단하기 위해 공간 분할

종료 조건 분할된 리프 공간 내부에 포함된 오브젝트 수가 일정 수준 이하가 되면 더 이상 분할하지 않음

3. 레이 트레이싱

용도 광선을 쏠 때 충돌 가능성이 있는 폴리곤 오브젝트간 빠르게 찾기 위해 BSP 트리를 사용

종료 조건 광선 검출에 필요한 정확도를 만족할 만큼의 분할이 이루어지면 어 이상 분할하지 않음

언리얼은 게임 객체를 처리하기 위한 강력한 시스템을 가지고 있다. 언리얼의 객체에 대한 기본 클래스는 UObject이다. UCLASS 매크로는 UObject처리 시스템이 이를 인식할 수 있도록 UObject에서 파생된 클래스에 태그를 지정하는 데 사용할 수 있다.

UCLASS

UClass 매크로는 언리얼 기반 타입을 설명하는 UCLASS에 대한 레퍼런스를 UObject에 제공합니다. 각 UClass는 클래스 디폴트 오브젝트(CDO, Class Default Object)라는 하나의 오브젝트를 유지합니다. CDO는 기본적으로 클래스 생성자에 의해 생성되고 이후에는 수정되지 않는 디폴트 템플릿 오브젝트 입니다.

UCLASS와 CDO는 보토 읽기 전용으로 간주되어야 하지만, 주어진 오브젝트 인스턴스에 대해 얻을 수 있습니다. 오브젝트 인스턴스에 대한 UCLASS는 GetClass함수를 사용하여 언제든지 엑세스할 수 있습니다.

UCLASS에는 클래스를 정의하는 프로퍼티와 함수 세트가 포함되어 있습니다. 이는 표준 C++ 코드에 사용할 수 잇는 일반 C++함수 및 변수이지만, 오브젝트 시스템 내에서 행동하는 방식을 제어하는 언리얼 엔진 전용 메타데이터가 태그로 지정되어 있습니다.

UObject 클래스에는 UFUNCTION 또는 UPROPERTY 지정자로 리플렉션이 표시되지 않은 네이티브 전용 프로퍼티가 포함될 수 있습니다. 그러나 지정자 매크로로 표시된 함수와 프로퍼티만 해당 UCLASS 내에 나열됩니다.

프로퍼티 및 함수 타입

UObject는 모든 타입의 함수 또는 멤버 변수(프로퍼티라고도 함)를 가질 수 있습니다. 그러나 언리얼 엔진이 이러한 변수나 함수를 인식하고 조작하려면 특수 매크로로 표시하고 특정 타입 표준을 준수해야 합니다.

UObject 생성

UObject는 생성자 실행인자를 지원하지 않습니다. 모든 C++ UObject는 엔진 시작 시 초기화되며, 엔진은 디폴트 생성자를 호출합니다. 디폴트 생성자가 없으면 UObject가 컴파일되지 않습니다. UObject 생성자는 가벼워야 하고 디폴트값과 서브오브젝트를 구성하는 데에만 사용되어야 하며, 생성 시 다른 함수 기능을 호출해서는 안 됩니다. UObject는 런타임에 NewObject를 사용하거나 생성자의 경우 CreateDefaultSubobject를 사용하여 생성해야 합니다.

UObject는 절대로 new 연산자를 사용하면 안 됩니다. 모든 UObject는 언리얼 엔진으로 관리되는 메모리이며 가비지 컬렉션됩니다. new 또는 delete를 사용하여 메모리를 수동으로 관리하면 메모리가 손상될 수 있습니다.

언리얼 헤더 툴

UObject 파생 타입이 제공하는 기능을 활용하려면 해당 타입에 대한 헤더 파일에 전처리 단계를 실행하여 필요한 정보를 대조해야 합니다. 이 전처리 단계는 UnrealHeaderTool, 줄여서 UHT에서 수행합니다. UObject 파생 타입에는 준수해야 하는 특정 구조가 있습니다.

헤더 파일 포맷

소스(.cpp) 파일의 UObject 구현은 다른 C++ 클래스와 같지만, 헤더(.h) 파일의 정의는 언리얼 엔진에서 제대로 작동하려면 특정 기본 구조를 준수해야 합니다. 에디터의 New C++ Class 명령을 사용하는 것은 올바른 포맷의 헤더 파일을 구성하는 가장 쉬운 방법입니다. UObject 파생 클래스의 이름이 UMyObject이고 이 클래스가 생성된 프로젝트가 MyProject라고 할 때 UObject 파생 클래스의 기본 헤더 파일은 다음과 같습니다.

    #pragma once

    #include 'Object.h'
    #include 'MyObject.generated.h'

    UCLASS()
    class MYPROJECT_API UMyObject : public UObject
    {
        GENERATED_BODY()

    };

언리얼 관련 부분은 다음과 같습니다.

#include "MyObject.generated.h"

이 줄은 파일의 마지막 #include 지시문이 될 것입니다. 이 헤더 파일이 다른 클래스에 대해 알아야 하는 경우 해당 클래스를 파일의 어느 곳에서나 포워드 선언하거나 MyObject.generated.h 위에 포함할 수 있습니다.

UCLASS()

UCLASS 매크로는 언리얼 엔진에 UMyObject 가 표시되도록 합니다. 매크로는 클래스에 대해 어떤 기능을 켜거나 끌지 결정하는 다양한 클래스 지정자를 지원합니다.

class MYPROJECT_API UMyObject : public UObject

MyProject가 UMyObject 클래스를 다른 모듈에 노출시키기를 원한다면 MYPROJECT_API 를 지정해야 합니다. 이는 게임 프로젝트에 포함될 모듈이나 플러그인에 가장 유용하며 여러 프로젝트에 걸쳐 이식 가능하고 자체 포함된 함수 기능을 제공하기 위해 의도적으로 클래스를 노출합니다.

GENERATED_BODY()

GENERATED_BODY 매크로는 실행인자를 사용하지 않지만 엔진에 필요한 인프라를 지원하기 위해 클래스를 구성합니다. 모든 UCLASS 및 USTRUCT 에 필요합니다.

오브젝트 업데이트하기

티킹(Ticking)은 언리얼 엔진에서 오브젝트가 업데이트되는 방식을 말합니다. 모든 액터에는 프레임마다 티킹할 수 있는 기능이 있어 필요한 업데이트 계산이나 액션을 수행할 수 있습니다.

액터 및 액터 컴포넌트(ActorComponents)에는 등록 시 자동으로 호출되는 틱(Tick) 함수가 있지만, UObjects 에는 기본 업데이트 기능이 없습니다. 프로젝트에 필요한 경우 상속 클래스 지정자를 사용해 FTickableGameObject 클래스에서 상속하여 추가할 수 있습니다. 그런 다음 엔진이 각 프레임을 호출하는 Tick() 함수를 구현할 수 있습니다.

오브젝트 파괴하기

오브젝트가 더 이상 레퍼런스되지 않을 때 가비지 컬렉션 시스템이 자동으로 오브젝트를 파괴합니다. 즉, UPROPERTY 포인터, 엔진 컨테이너, TStrongObjectPtr 또는 클래스 인스턴스가 강한 참조를 가져서는 안 된다는 뜻입니다.

위크 포인터는 오브젝트가 가비지 컬렉션되는지 여부에 영향을 미치지 않습니다.

가비지 컬렉터를 실행하면, 참조되지 않은 오브젝트를 발견하면 메모리에서 제거합니다. 또한 MarkPendingKill() 함수를 오브젝트에서 바로 호출할 수 있습니다. 이 함수는 오브젝트에 대한 모든 포인터를 NULL 로 설정하고 글로벌 검색에서 오브젝트를 제거합니다. 오브젝트는 다음 가비지 컬렉션 패스에서 완전히 삭제됩니다.

스마트 포인터는 UObject와 함께 사용하기 위한 것이 아닙니다.

Object->MarkPendingKill() 은 Obj->MarkAsGarbage() 로 대체되었습니다. 이 새로운 함수는 이제 오래된 오브젝트를 추적하는 용도로만 사용됩니다. gc.PendingKillEnabled=true 인 경우 PendingKill 로 표시된 오브젝트는 자동으로 null이 되고 가비지 컬렉터에 의해 삭제됩니다.

강한 참조가 있으면 UObject가 유지됩니다. 이러한 레퍼런스가 UObject를 활성 상태로 유지하는 것을 원하지 않는 경우 해당 레퍼런스가 위크 포인터를 사용하도록 변환하거나 (퍼포먼스가 중요한 경우) 프로그래머가 수동으로 삭제하는 노멀 포인터여야 합니다.

특정 점에서 객체까지의 거리를 0~1로 나타낸 것이다. 아래 사진에서 원의 표면에 있는 점의 값은 1, 우측상단 점의 값은 0이다.

표면에서 멀어질 수록 0에 가까워지고 가까울 수록 밝게, 멀 수록 어둡게 표현한 것이다. 멀다(어둡다, 0) - 가깝다(밝다, 1)

이제 객체 내부에서도 거리 값을 설정해봅시다. 객체의 표면이 아닌 중심을 기준으로 거리값을 설정한다.

Distance Field 사용처

렌더링 범위 설정

SDF를 통해 셰이더에서 렌더링 범위를 설정할 수 있습니다.

원을 아래 값을 통해 렌더링 해봅시다. 최소 거리 값: 0.499 최대 거리 값: 0.5

Glow 표현

거리 값에 따라 표현이 달라지는 것이 활용하여 글로우한 표현을 할 수 있습니다. 최소, 최대 거리 값 차이가 커질 수록 더 흐릿한 이미지를 얻을 수 있으니 이를 활용할 수 있습니다.

예시를 봅시다.

TextureSample로 가장 흐릿한 이미지를 사용합니다. 흐릿한 이미지의 흐릿한 부분만 필요하니, 필요없는 부분은 빼줍니다. 최소/최대 차이 값으로 흐릿한 이미지의 거리값을 나눠줍니다. 나눠진 값을 사용하여 Glow 표현을 완성합니다. (파란 부분)

머티리얼에서 값을 설정할 수도 있고,

UMG에서 사용한다면 애니메이션을 통해 값을 변경하여 동적인 표현도 가능합니다.

Signed Distance Field 사용처

외곽선 그리기

절대값을 취한 뒤 외곡선 두께를 빼서 뒤집으면 양파 껍질처럼 외곽선을 그릴 수 있습니다.

패턴 및 다양한 효과 제작

sine을 통해 패턴을 그릴 수도 있고

컬러 채널을 사용하는 SDF를 만들고, N개의 아이콘에서 사용할 채널 값을 다르게 하여 하나의 SDF로 뽑으면 변형된 이미지를 렌더링할 수 있습니다. UMG에서 애니메이션으로 프로퍼티 값을 조정하면 멋진 위젯 애니메이션이 됩니다.

Signed Distance Field Value Range

값 범위는 일반적으로 0~1를 사용한다.

• 0 <= Value < 0.5: 객체 내부
• Value == 0.5: 객체 표면
• 0.5 < Value <= 1: 객체 외부

직관성을 위해 -1 ~ 1로 재 맵핑하여 사용할 수 있다. 변환법: (Value-0.5) * 2

• -1 <= Value < 0: 객체 내부
• Value == 0: 객체 표면
• 1 < Value <= 1: 객체 외부

음/양 분리 외에 채널을 분리하여 사용하는 경우도 있다고 한다.

참고 자료

https://joyrok.com/What-Are-SDFs-Anyway

• UMG 기반으로 에디터 UI를 추가 가능 UEditorUtilityWidget : public UUserWidget
• 커스텀 에디터 탭을 만들 수 있음

• FSoftObjectPath: 에셋의 전체이름이 저장된 스트링 구조체
• TSoftObjectPtr: FSoftObjectPath를 감싸는 TWeakObjectPtr

2. Asset Registry& Object Library

• AssetRegistry: 에셋의 메타데이터를 저장해 에셋에 대한 검색 및 질의를 가능하게 해주는 시스템
  • 에디터에서 컨텐츠 브라우저에 정보를 표시하기 위해 사용
  • 게임플레이 코드에서 현재 로드되지 않은 게임플레이 에셋에 대한 메타데이터 질의를 하는데 사용 가능
  • 검색 가능하게 만들기 위해 AssetRegistrySearchable 프로퍼티 태그를 추가해야 한다
• ObjectLibrary: 로드된 오브젝트 리스트와 로드 되지 않은 오브젝트는 FAssetData리스트로 가지고 있는 오브젝트
  • ObjectLibrary에 특정 경로로 로드하면 해당 경로에 있는 모든 에셋이 로드 됨

3. StreamableManager와 비동기 로드

• FStreamableMananger: 비동기 로딩을 수행

언리얼 엔진에서 제공되는 커스텀 가능한 UI 프레임워크다. slate는 서술형 문법을 사용하여 프로그래머가 인디렉션 레이어를 추가하지 않고 쉽게 UI를 제작 가능한 기능을 제공한다. 또한 Composition을 통해 반복적으로 사용되는 요소들을 빠르게 배치할 수 있도록 구성되어 있다.

2. Widget과 Slate

언리얼에서 UI를 제작할 때 UMG를 사용해 제작한다. 그렇다면 Slate와 Widget은 뭐가 다른 것일까? 사실 Widget은 Slate의 껍데기(Container)일 뿐이다. 실질적으로 화면에 보여주기 위한 기능들은 Slate에 있고 Widget은 Slate를 제어하기 위한 데이터를 가지고 있을 뿐이다. 우리는 SetText()같은 함수들로 Widget의 데이터를 제어하고 있을 뿐이다.

3. 왜 역할을 분리했을까?

결국 Slate가 실질적으로 View의 역할을 하고있는데 Widget으로 왜 Warpping하고 있는 것일까? 이건 MVC 구조를 이해하고 있다면 쉽게 이해할 수 있다.

Slate는 보여줄 데이터를 직접 가지고 있지 않고 필요할 때 마다 딜리게이트를 브로드캐스트해 값을 가져온다. (TreeView에서 Getchildren을 사용하면 이해가 바로 된다.) 따라서 Slate는 화면에 보여주는 역할(View), 데이터를 전달하는 역할(Controller)을 수행하고 Widget은 데이터를 가지고 있는 역할(Model)을 수행한다.

그렇기 때문에 Slate는 피드백 루프 방식이 아닌 폴링을 통해 화면에 그려준다.

세줄 요약

• 언리얼에서 UI는 Slate로 컴포지션화 하여 빠르게 만들 수 있다.
• Widget은 Slate를 가지고 있어 실질적으로 화면에 보여지는 것은 Slate다.
• Slate는 데이터를 가지고 있지 않고 필요할 때 마다 딜리게이트로 Widget의 데이터를 가져온다.

Scrolling한 위젯들을 가상화시키는게 언리얼이 추구하는 방향성 같은데 관련해서 ListView(Tile, Tree도 있음)이 위젯을 풀링하는 방식도 궁금하다. 이건 대충 이해하긴 했는데 다음에 포스팅하면서 정리하겠다.

• C++오브젝트 사으이 멤버 함수를 안전한 방식으로 호출 가능
• 오브젝트의 멤버 함수에 동적으로 바인딩 가능
• 값 복사 시 동적으로 Heap에 메모리를 할당해야 되기 때문에 참조 전달을 지향

2. 이벤트(Event)

• MultiCastDelegate와 일반적으로 비슷하지만 Event를 선언한 클래스만이 Broadcast, IsBound, Clear함수를 호출 가능
  • 함수를 접근을 제한하여 접근권을 확보할 때 사용 가능

• 대상 원본 객체를 대리하여 대신 처리하게 함으로써 로직의 흐름을 제어하는 행동 패턴
• client -> Proxy -> Subject 순서로 접근

2. Proxy Pattern을 사용하는 이유

• Subject가 민감한 정보를 가지고 있거나 인스턴스화 하기 무겁거나 추가 기능을 가미하고 싶은데, 원본 객체를 수정할 수 없는 상황일 때를 극복하기 위해

3. Proxy Pattern 구조

• proxy와 subject는 동일한 인터페이스를 가지고 있음
  • 다른 인터페이스와 완전히 호환되도록 바꿀 수 있음