오늘 한것

  • 과제 4번 재조립 분석
  • AI 기반 3D 모델 생성 후 Unreal Engine에서 사용할 스켈레탈 메시 및 애니메이션 제작 파이프라인 조사

Static Mesh

  • 단순 3D 모델
  • 애니메이션 없음
  • 건물, 소품, 배경 등에 사용

Skeletal Mesh

  • Bone 구조 포함
  • 애니메이션 가능
  • 캐릭터, 차량, 몬스터 등에 사용

Rigging

  • 메시와 Bone을 연결하는 작업

Weight Paint

  • Bone이 영향을 주는 영역을 설정하는 작업

Control Rig

  • Unreal Engine 내부에서 애니메이션 및 리깅을 제어하는 기능

SetupAttachment

1. 부모 컴포넌트에만 붙이기

MeshComp->SetupAttachment(RootComponent);

MeshCompRootComponent의 자식으로 붙인다

2. 부모 컴포넌트의 특정 소켓에 붙이기

CameraComp->SetupAttachment(SpringArmComp, USpringArmComponent::SocketName);

CameraCompSpringArmComp에 붙이되, 스프링 암이 제공하는 특정 소켓 위치에 붙인다

3. 캐릭터 Mesh의 특정 소켓에 붙이기

WeaponComp->SetupAttachment(GetMesh(), TEXT("WeaponSocket"));

WeaponComp를 캐릭터 Mesh에 붙이되, "WeaponSocket"이라는 소켓 위치에 붙인다


소켓과 컴포넌트 차이

소켓

소켓은 주로 Mesh나 SpringArm 같은 부모 안에 있는 이름 붙은 위치

캐릭터 손 본에 WeaponSocket이라는 지점을 만들어 둔다 그러면 무기나 이펙트를 그 위치에 붙일 수 있어요. 즉, 소켓은 붙일 자리입니다.

컴포넌트

컴포넌트는 액터를 구성하는 실제 기능 단위

  • CameraComponent → 화면을 보는 기능
  • StaticMeshComponent → 물체를 보이게 하는 기능
  • BoxComponent → 충돌 영역 기능
  • SpringArmComponent → 카메라 거리 조절 기능 즉, 컴포넌트는 실제로 동작하는 부품입니다.

전방 선언(Forward Declaration)

컴파일 시간을 줄이고, 헤더 의존성(파일 간 의존성을 줄이기 위해서)을 낮추기 위해 사용

이 클래스의 자세한 내용은 지금 몰라도 되지만, 그런 이름의 클래스가 존재한다는 것만 컴파일러에게 알려주는 것

class UCapsuleComponent;
class USkeletalMeshComponent;

아래처럼 포인터로만 선언하고 있기 때문

UCapsuleComponent* CapsuleComp;
USkeletalMeshComponent* MeshComp;
  • #include
    → “설명서 전체를 가져오기”

  • class UCapsuleComponent;
    → “그런 부품이 있다는 이름만 적어두기”

원래는 include가 필요하지만, 헤더에서 포인터로만 들고 있을 때는 컴파일 부담을 줄이기 위해 전방 선언을 쓴다

그래서 헤더에서는 최대한 가볍게 이름만 알려주고, 실제 기능을 쓰는 .cpp에서 include하는 방식이 자주 사용됩니다.


structclass 차이

기본 접근 권한 : 둘 다 변수와 함수를 가질 수 있음.

  • struct는 기본이 public
  • class는 기본이 private

즉, struct는 보통 데이터를 담는 용도로 많이 쓰고,
class데이터와 동작을 함께 관리하는 객체로 많이 씁니다.


포인터 *

UInputAction* LookAction에서 LookActionInput Action 에셋을 직접 들고 있는 게 아니라, 그 에셋이 있는 위치를 가리키는 변수 LookAction입력 액션 에셋을 계속 가리켜야 해서 포인터

참조 &

const FInputActionValue& Value에서 Value는 입력 이벤트가 발생했을 때 전달되는 그 순간의 입력값을 함수 안에서 잠깐 읽기 위한 이름이에요. Value입력 순간에 전달된 값을 복사 없이 읽기만 해서 참조

구분포인터 *참조 &
느낌주소를 들고 있음기존 값을 빌려 봄
예시 역할에셋을 연결해둠입력값을 잠깐 읽음
비유주소 메모지같이 보는 종이
비어 있을 수 있음가능보통 불가능하게 다룸

문제

AI 기반 3D 생성 서비스인 mesi.ai를 이용하여 게임용 에셋을 제작하려고 하였다.

하지만 생성 결과물을 확인해보니 정적인 형태의 스태틱 메시(Static Mesh)는 생성되는 것으로 보이나, 언리얼 엔진에서 애니메이션을 적용할 수 있는 스켈레탈 메시(Skeletal Mesh) 형태로 생성되는지는 확인이 어려웠다.

오류

현재 확인된 사항은 다음과 같다.

  • mesi.ai는 3D 모델 생성 기능은 제공하는 것으로 보임
  • 생성된 결과물이 스켈레톤(Bone) 구조를 포함하는지 확인되지 않음
  • 스켈레톤이 없는 경우 언리얼 엔진에서 애니메이션 적용이 불가능함
  • 대부분의 AI 3D 생성 서비스는 메시 생성에는 강하지만 리깅(Rigging) 및 웨이트(Weight) 작업은 완전하지 않은 경우가 많음
  • 따라서 생성된 결과물이 실제 게임에서 바로 사용 가능한 Skeletal Mesh인지 검증이 필요함

조사 내용

현재 게임 개발용 캐릭터 및 차량 에셋 제작 파이프라인으로 다음 흐름을 검토 중이다.

AI 모델 생성 ↓ Blender ↓ Unreal Engine ↓ Animation / Control Rig ↓ Gameplay 적용

이 방식은 AI가 생성한 모델을 중간 단계에서 검수 및 수정할 수 있다는 장점이 있다.

대안 검토

Tripo AI

조사 대상

  • AI 기반 3D 모델 생성
  • FBX Export 지원
  • 게임용 모델 생성 가능
  • 차량 및 캐릭터 생성 사례 존재

추가 확인 필요

  • Skeletal Mesh 생성 가능 여부
  • 자동 리깅 지원 여부
  • 언리얼 엔진 호환성
  • 생성 결과물 품질

해결

AI만으로 게임에 바로 사용할 수 있는 완성형 Skeletal Mesh를 얻기는 아직 어려워 보인다. 따라서 현재 가장 현실적인 파이프라인은

AI 모델 생성 ↓ Blender에서 구조 확인 및 수정 ↓ FBX Export ↓ Unreal Engine Import ↓ Control Rig 및 Animation 적용 방식으로 판단된다.


내일 할 일

  • Tripo AI에서 차량 생성 테스트
  • 생성 결과물의 Bone 포함 여부 확인
  • FBX Export 가능 여부 확인
  • Blender Import 테스트
  • Unreal Engine Import 테스트
  • Chaos Vehicle 시스템 적용 가능 여부 확인
  • Skeletal Mesh와 Static Mesh 차이 실습

TIL NBC