드디어 애니메이션을 실행시킨다. 언리얼의 애니메이션 기능을 하나씩 붙여보려고 한다. 해당 문서에서는 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는 동일한 인터페이스를 가지고 있음
  • 다른 인터페이스와 완전히 호환되도록 바꿀 수 있음