Unreal에서 Godot 내보내기로: 무엇을 전송하고 무엇을 다시 빌드해야 하는지

직접적인 대답: 보편적인 Unreal-to-Godot 프로젝트 내보내기 프로그램은 없습니다.

“Unreal에서 Godot로 내보내기”는 완전한 게임을 위한 원클릭 변환기가 아닙니다. 소스 소유 자산을 중립 형식(일반적으로 glTF 또는 FBX를 통한 메시 및 애니메이션, 표준 래스터 파일의 텍스처, WAV 또는 OGG의 오디오, JSON 또는 CSV의 디자인 데이터)을 통해 이동할 수 있지만 엔진 소유 시스템은 Godot에서 다시 구축하고 검증해야 합니다. 블루프린트, Unreal C++, 머티리얼, 나이아가라 효과, 레벨 로직, AI 그래프, 입력 매핑, 복제, 저장 시스템 및 플랫폼 서비스는 단지 파일을 내보냈다는 이유만으로 Godot 시스템과 동일해지지 않습니다.

작업을 파일 변환이 아닌 마이그레이션으로 처리하십시오. 알려진 Unreal 개정판을 동결하고, 팀이 합법적으로 소유한 항목을 목록화하고, 원본 DCC 소스를 보존하고, 작은 수직 슬라이스를 선택하고, 이식 가능한 콘텐츠만 내보내고, Godot에서 동작을 재구성하고, 두 프로젝트를 동일한 카메라, 상호 작용, 데이터 및 성능 검사와 비교합니다. 조각이 승인 기준을 충족할 수 없는 경우 프로젝트의 나머지 부분을 변환하기 전에 중지하십시오.

이 가이드는 SEELE AI가 기존 .uproject을 마이그레이션하거나 블루프린트 그래프를 변환하거나 기능 패리티를 보장한다고 주장하지 않습니다. 엔진 이동을 평가하는 팀을 위한 기술적 경계와 가역적 워크플로를 설명합니다.

내보내기 형식을 선택하기 전에 마이그레이션하는 이유를 결정하십시오.

팀은 런타임 공간, 라이선스 전략, 소스 액세스, 플랫폼 범위, 팀 기술, 더 단순한 2D/3D 프로젝트 또는 Godot에서 표준화하려는 욕구 등 여러 가지 이유로 이동을 고려합니다. 이러한 이유 중 어느 것도 무엇이 이전될지 알려주지 않습니다. 콘텐츠를 다루기 전에 측정 가능한 용어로 비즈니스 및 기술 목표를 작성하세요.

예를 들어 '고도로 이동'은 너무 모호합니다. 유용한 목표는 다음과 같습니다: "Godot 4에서 싱글 플레이어 데스크톱 게임의 처음 15분을 재구성하고, 라이센스가 허용되는 제작된 환경과 캐릭터 애니메이션을 보존하고, 상호 작용을 재현하고 동작을 저장하고, 동일한 시스템에서 합의된 테스트 예산 내에서 프레임 시간과 메모리를 유지합니다." 이 진술은 대상 플랫폼, 콘텐츠 조각, 행동 및 증거를 노출합니다.

또한 필요하지 않은 것을 명시하십시오. 프로토타입에는 온라인 서비스, 고급 파괴, 영화, 콘솔 인증 또는 모든 재료 변형이 필요하지 않을 수도 있습니다. 첫 번째 조각에서 제외하는 것은 쉬운 척하는 것이 아닙니다. 이는 평가가 통제되지 않은 재작성이 되는 것을 방지합니다.

일반적으로 세 가지 초기 질문이 타당성을 결정합니다.

1. 편집 가능한 소스 자산을 소유하고 계십니까? 패키지된 빌드 또는 쿠킹된 .uasset 컬렉션은 소스 메시, 텍스처, 오디오 및 프로젝트 데이터와 동일하지 않습니다.
2. 엔진별 시스템에 얼마나 많은 가치가 있습니까? 맞춤형 블루프린트 프레임워크, 플러그인, 나이아가라, 복잡한 재질, 월드 파티션 또는 Unreal 네트워킹으로 구동되는 게임은 소스 소유 자산과 단순한 동작을 갖춘 소규모 프로젝트보다 재작성 위험이 더 높습니다.
3. Godot에서 대상 플랫폼과 서비스를 지원할 수 있습니까? 공식 문서 및 공급업체 계약을 기준으로 현재 내보내기 템플릿, SDK 요구 사항, 미들웨어, 상점, 접근성, 분석 및 인증 요구 사항을 확인하세요.

이러한 질문 후에도 동기가 여전히 건전하다면 "수출업체"를 선택하기 전에 목록을 작성하십시오.

소유권 및 교체 결정을 통해 마이그레이션 인벤토리 구축

시스템 또는 자산군당 하나의 행이 있는 테이블을 생성합니다. 소스 소유자, Unreal 표현, 대상 표현, 형식, 라이센스, 자동화된 테스트, 수동 검토 및 대체를 기록합니다. 개별 파일로 시작하지 마십시오. 생산 책임부터 시작하세요.

각 행을 transfer, rebuild, replace, drop 또는 알 수 없음. "알 수 없음"은 합법적인 상태입니다. 증명 작업이 시작됩니다. 플러그인이나 마켓플레이스 자산을 양도 가능한 것으로 조용히 처리하는 것보다 안전합니다.

라이센스 검토는 인벤토리에 속합니다. Unreal Marketplace 콘텐츠, 타사 플러그인, 스캔한 자산, 오디오 라이브러리, 글꼴, SDK 및 브랜드 자료에는 Unreal 외부에서의 사용을 제한하거나 별도의 라이선스가 필요한 조건이 있을 수 있습니다. 파일이 프로젝트 폴더에 존재한다는 사실에 의존하기보다는 현재 계약을 확인하십시오.

허용되는 모든 입력에 대해 콘텐츠 해시 또는 소스 개정을 유지합니다. 마이그레이션을 수행하면 이전 파일, 중복 파일 또는 파생 파일이 노출되는 경우가 많습니다. 안정적인 소스 매니페스트가 없으면 팀은 내보내기, 가져오기 설정 또는 다른 소스 자산에서 시각적 차이가 발생했는지 알 수 없습니다.

이전 대상과 재구축 대상

휴대용 자산은 엔진 의미가 아닌 데이터를 보존합니다. 정적 메쉬는 위치, 법선, UV, 접선, 정점 색상, 때로는 재질 할당을 전달할 수 있습니다. 뼈대 형식은 뼈대, 가중치 및 애니메이션 트랙을 전달할 수 있습니다. Unreal의 액터/컴포넌트 수명주기, 블루프린트 이벤트 순서, 게임플레이 능력 시스템 동작, 네트워크 권한 또는 정확한 셰이더 파이프라인을 전달하지 않습니다.

가장 안정적인 전송은 원래 DCC 패키지에서 시작됩니다. 깨끗한 Blender, Maya 또는 기타 소스 장면을 내보내면 팀에서 단위, 축, 이름, 삼각측량, 뼈대 계층 및 텍스처 참조를 제어할 수 있습니다. Unreal에서 내보내는 것은 Unreal 자산에 다른 곳에는 없는 승인된 편집 내용이 포함되어 있을 때 유용할 수 있지만, 내보내기 프로그램에 포함된 내용과 결과를 소스에서 재현할 수 있는지 여부를 확인하세요.

Epic에서는 지원되는 콘텐츠를 glTF로 내보내기 위한 경로로 Unreal Engine glTF 내보내기를 문서화합니다. Godot는 사용 가능한 3D 장면 형식을 문서화하고 glTF 2.0을 많은 작업 흐름에 권장되는 교환 형식으로 사용합니다. 이 문서는 파일 형식 기능을 설정합니다. 그들은 전체 프로젝트 전환을 약속하지 않습니다.

형식 충성도 대신 형식 평가판을 사용하세요.

• glTF/GLB: 표준 장면 교환, PBR 지향 재질, 메시, 뼈대 및 애니메이션을 위한 강력한 첫 번째 후보입니다. 자산이 사용하는 정확한 기능을 테스트하세요.
• FBX: 기존 캐릭터 및 DCC 파이프라인에서 공통적으로 사용됩니다. 가져오기/내보내기 구현이 다르므로 내보내기 및 가져오기 버전을 고정하고 포즈, 애니메이션, 접선 및 재질 참조를 테스트합니다.
• OBJ: 단순한 정적 형상에는 유용하지만 리그, 애니메이션, 복잡한 계층 구조 또는 현대적인 재질 동작의 기본 경로로는 적합하지 않습니다.
• USD: 대규모 콘텐츠 파이프라인에 유용하지만 런타임 게임플레이를 자동으로 번역하거나 USD 단계가 최적화된 Godot 장면이 되는 것을 보장하지는 않습니다.

모든 자산군에 대해 미러링된 형상, 다중 UV 세트, 정점 색상, 단단한 가장자리, 투명 재질, 네거티브 스케일, 중첩된 변환, 루트 모션이 있는 골격 클립 및 필요한 경우 하나의 모프 대상과 같은 어려운 사례가 포함된 황금 샘플을 만듭니다. 수백 개의 자산을 이동하기 전에 의도한 내보내기 및 가져오기 버전을 통해 실행하세요.

차이점을 숨기지 않고 정적 메쉬, 텍스처 및 재료 내보내기

게임플레이에서 좌표 및 렌더링 문제를 분리하므로 정적 콘텐츠로 시작하세요. Unreal에서는 자산 경로, 소스 파일, 가져오기 설정, 빌드 설정, 재질 슬롯, 충돌, LOD, Nanite 상태 및 구성 시간 수정 사항을 기록합니다. 원본 DCC 소스가 신뢰할 수 있는 경우 거기에서 내보냅니다. Unreal이 승인된 유일한 수정 소스라면 내보내기 경로를 문서화하고 라이선스 허가를 확인하세요.

Godot 측에서는 스케일, 방향, 피벗, 계층 구조, 법선, 접선, UV 채널, 정점 색상, 재질 슬롯 및 충돌을 검사합니다. 소스 계약이 이해될 때까지 임의의 노드별 수정을 적용하지 마십시오. 영구적인 100× 배율 조정 또는 회전된 루트는 한 장면에서 무해한 것처럼 보일 수 있으며 나중에 물리, 애니메이션, 탐색 또는 도구 문제를 일으킬 수 있습니다.

자료에는 의도적인 재구성이 필요합니다. 언리얼 머티리얼 그래프에는 함수, 매개변수 컬렉션, 가상 텍스처, 런타임 가상 텍스처, 사용자 정의 HLSL, 데칼, 랜드스케이프 레이어, 지하 모델 및 플랫폼 스위치가 포함될 수 있습니다. glTF 내보내기는 지원되는 PBR 속성과 유사할 수 있습니다. 모든 그래프 결정을 보존할 수는 없습니다. 기본 색상, 법선, 거칠기, 금속성, 방출, 불투명도, UV 동작 및 예상 조명 반응을 포함하는 대상 재질 사양을 작성한 다음 Godot의 렌더러 및 셰이더 언어에 대해 다시 빌드하세요.

패킹된 텍스처는 일반적인 함정입니다. 거칠기, 금속성, 주변 폐색, 마스크 또는 높이를 저장하는 채널을 기록합니다. Godot 가져오기 설정과 사용자 정의 셰이더는 동일한 채널을 읽어야 합니다. 색상 공간 처리 유효성 검사: 데이터 텍스처는 색상 이미지로 처리되어서는 안 되며 일반 맵에는 선택한 파이프라인에 대한 올바른 규칙이 필요합니다.

중립 조명, 단일 방향 또는 환경 설정, 알려진 카메라 위치 및 대표 자료를 사용하여 고정된 비교 장면을 구축합니다. 정확한 픽셀 패리티는 렌더러 전체에서 거의 현실적이지 않습니다. 수용 여부에 대한 질문은 두 스크린샷이 수치적으로 동일한지 여부가 아니라 새로운 결과가 합의된 허용 범위 내에서 아트 방향과 게임플레이 가독성을 유지하는지 여부입니다.

스켈레탈 메시와 애니메이션을 별도의 증명으로 이동

캐릭터는 유닛, 루트 방향, 뼈대 계층, 바인딩 포즈, 뼈 이름, 스킨 가중치, 제약 조건, 애니메이션 곡선, 루트 모션, 모프 대상, 소켓 및 게임플레이 이벤트 등 여러 오류 표면을 결합합니다. 첫 번째 정적 메시 배치에 포함하지 마세요.

대표 캐릭터 1명과 클립 3개(유휴 상태, 루트 또는 내부 모션을 사용한 이동, 회전, 웅크리기, 손 뻗기 등의 극단적인 동작)를 선택하세요. 선택한 glTF 또는 FBX 경로를 통해 뼈대와 메시를 내보냅니다. Godot에서 가져온 Skeleton3D 계층 구조, 스킨, 애니메이션 트랙, 루프 설정 및 루트 변환을 검사하세요. AnimationTree 또는 프로젝트에서 선택한 아키텍처를 사용하여 런타임 상태 시스템을 다시 생성합니다. Unreal Animation Blueprint가 전송될 것이라고 기대하지 마십시오.

고정 프레임에서 관절 위치와 접촉을 비교합니다. 발, 손, 엉덩이, 어깨, 무기 소켓, 얼굴 모양 및 메시 침투를 확인합니다. 프로젝트에서 Control Rig, IK Rig, IK Retargeter, 애니메이션 노티파이, 몽타주, 모션 워핑 또는 물리 기반 보조 모션을 사용하는 경우 각각을 다시 구현하거나 교체할 동작으로 나열하세요. 구운 애니메이션은 전송될 수 있지만 절차적 런타임 동작은 전송되지 않습니다.

루트 모션에는 명시적인 소유자가 필요합니다. 변위가 애니메이션, 캐릭터 컨트롤러 또는 게임플레이 코드에서 나오는지 결정합니다. Godot에서 시각적으로 재생되는 클립은 소유권이 변경되면 네트워크 이동, 충돌 또는 저장 상태 동작에 여전히 실패할 수 있습니다.

소스 자산에서 콜드 가져오기를 재현할 수 있고, 세 개의 클립이 통과하고, 다시 가져오기로 인해 수동 대상 작업이 파괴되지 않고, 캐릭터가 게임플레이 검증에 사용된 것과 동일한 수직 슬라이스에서 실행되는 경우에만 문자 증명을 허용합니다.

블루프린트, C++, VFX, AI, 게임플레이 동작 재구성

블루프린트 그래프와 Unreal C++는 Unreal의 객체 모델, 리플렉션, 액터/컴포넌트 수명 주기, 델리게이트, 자산 시스템, 가비지 수집, 입력, 물리, 네트워킹 및 빌드 툴체인에 대해 컴파일됩니다. 텍스트 또는 그래프 내보내기는 문서 구조에 도움이 될 수 있지만 동등한 Godot 동작을 생성하지는 않습니다.

구문이 아닌 의도를 번역합니다. 각 게임플레이 기능에 대해 다음을 작성하세요.

• 권위 있는 국가와 이를 소유한 객체
• 입력, 검증 및 거부 경로;
• 업데이트 타이밍 및 순서 가정;
• 출력, 이벤트, 애니메이션/VFX/오디오 후크;
• 저장 및 로드 동작;
• 해당되는 경우 멀티플레이어 권한 및 복제;
• 자동화되거나 반복 가능한 승인 테스트.

그런 다음 동일한 계약을 구현하는 Godot 노드, 장면, 리소스, 신호, 스크립트 및 서비스 경계를 디자인하세요. 여러 구성요소가 있는 블루프린트 액터는 노드와 리소스가 있는 Godot 장면이 될 수 있지만 일대일 클래스 일치는 목표가 아닙니다. 목표는 새 팀이 유지할 수 있을 만큼 관용적이어야 합니다.

나이아가라 효과에는 레크리에이션도 필요합니다. 허용되는 경우 소스 텍스처와 메시를 전송하고 생성 속도, 수명, 힘, 충돌, 렌더링 모드, 재료 및 게임플레이 타이밍을 기록한 다음 Godot 입자 또는 셰이더로 다시 빌드하세요. Unreal AI 동작 트리, EQS 쿼리, 탐색 설정, 후처리, 오디오 미들웨어, UI 프레임워크 및 온라인 하위 시스템에도 동일하게 적용됩니다.

플레이어 경험을 정의하는 행동의 우선순위를 정하세요. 외관상 패리티는 손상된 저장 시스템, 잘못된 충돌, 입력 포커스 손실 또는 다른 적 상태를 숨겨서는 안 됩니다. 교체가 승인될 때까지 원래 Unreal 빌드를 동작 참조로 사용할 수 있도록 유지하십시오.

하나의 수직 슬라이스로 마이그레이션 입증

첫 번째 조각은 마무리할 수 있을 만큼 작고 위험한 경계를 노출할 수 있을 만큼 넓어야 합니다. 유용한 슬라이스에는 방 1개, 제어 가능한 캐릭터 1개, 애니메이션 세트 1개, 대화형 개체 1개, UI 상태 1개, 오디오 큐 1개, 저장된 값 1개, 실패 경로 1개, 패키지 대상 1개가 포함됩니다. 멀티 플레이어가 핵심 요구 사항인 경우 모든 네트워킹 증거를 연기하는 대신 가장 작고 신뢰할 수 있는 두 클라이언트 상호 작용을 포함하십시오.

테스트 환경을 동결합니다: 소스 커밋, Godot 커밋, 내보내기 버전, 가져오기 버전, 대상 컴퓨터, 해상도, 빌드 구성 및 입력 경로. 가능하다면 동일한 카메라 위치와 스크립트로 작성된 상호작용 시퀀스를 사용하세요. 결과를 매트릭스로 캡처:

다른 장면의 편집기 프레임 카운터를 비교하지 마십시오. 대표적인 패키지 빌드, 동일한 콘텐츠 및 경로, 명확한 샘플 창을 사용하세요. 셰이더 컴파일, 로딩, 메모리 및 프레임 타이밍을 별도로 기록합니다. 한 엔진이 다른 렌더러나 기능 세트를 사용하는 경우 이를 모호한 승자 주장으로 변환하는 대신 차이점을 기록해 두십시오.

실패 사례 실행: 필수 자산 제거, 잘못된 형식의 데이터 제공, 로딩 중단, 지원되는 버전에서 저장 다시 로드, 장면 변경 후 상호 작용 반복. 마이그레이션 버그는 첫 번째 행복한 경로가 아닌 다시 가져오기, 다시 시작 및 정리에 숨어 있는 경우가 많습니다.

조각이 끝나면 파일 수가 아닌 시스템별로 남은 작업을 추정합니다. 10개의 복잡한 블루프린트 프레임워크에는 수천 개의 텍스처보다 비용이 더 많이 들 수 있습니다. 결정에 재테스트, 플랫폼 통합, 도구, 문서화 및 팀 교육을 포함시키십시오.

더 작은 제품으로 마이그레이션, 유지 또는 재구축 중에서 선택하세요.

수직 슬라이스가 필요한 플랫폼, 휴대용 자산 경로, 대상 아키텍처, 성능 예산 및 팀 소유권을 입증하면 마이그레이션을 계속합니다. 중요한 미들웨어, 인증, 렌더링 요구 사항 또는 온라인 기능을 알 수 없는 경우 일시 중지합니다. 재작성 비용이 제품 가치를 초과하거나 현재 엔진 내부의 작은 변경으로 마이그레이션 목표를 달성할 수 있는 경우 중지하십시오.

프로젝트가 Unreal 네이티브 시스템에 크게 의존하고 팀이 실제 비용이나 작업 흐름 문제를 직접 해결할 수 있다면 Unreal을 유지하는 것은 실패가 아닙니다. 마찬가지로, 완전한 Godot 재구축은 모든 역사적 자산과 아키텍처 결정을 새 프로젝트에 적용하는 것보다 나을 수 있습니다. 올바른 선택은 수출업자에 대한 열정이 아닌 슬라이스로 뒷받침되는 선택입니다.

더 폭넓은 엔진 결정을 위해서는 Unreal Engine vs Godot for game development를 읽어보세요. 소스 자산 계획을 위해서는 Unreal 3D 모델 파일 형식 가이드를 사용하세요. Unreal에 머무르는 팀은 Unreal 게임 제작자를 통해 새로운 개념을 시작할 수 있습니다.

SEELE AI 핸드오프 및 제품 경계

SEELE AI는 새로운 기본 Unreal 5 게임을 생성하고, 브라우저 미리 보기를 제공하고, 최적화 및 패키징을 지원하고, 다운로드 가능한 게임 또는 패키지된 출력을 제공할 수 있습니다. 기존 .uproject 열기, 프로젝트를 Godot로 내보내기, Blueprint 또는 C++ 번역, 타사 플러그인 재생성 또는 Godot 빌드 인증을 주장하지 않습니다.

팀이 마이그레이션 여부를 결정하기 전에 새로운 Unreal 방향을 비교하는 경우 대상 플랫폼, 하나의 게임플레이 루프, 아트 방향, 필수 입력, 성능 예산, 패키징 승인 등 제한된 개요를 사용하십시오. 해당 실험을 기존 프로젝트 마이그레이션 인벤토리와 별도로 유지하세요.

Unreal Engine는 Epic Games의 상표입니다. 기술 비교를 위해 Godot를 참조했습니다. SEELE AI는 독립적이며 이 가이드는 Epic Games 또는 Godot 프로젝트의 보증을 의미하지 않습니다.

공식 출처

• Epic Games: Unreal Engine 콘텐츠를 glTF로 내보내기
• Godot 문서: 사용 가능한 3D 형식
• Godot 문서: 3D 장면 가져오기
• 에픽게임즈: FBX 콘텐츠 파이프라인

워크플로를 프로덕션에 적용하기 전에 버전 선택기와 현재 라이선스 조건을 확인하세요.

FAQ

전체 프로젝트에 대해 Unreal에서 Godot로 내보내기가 있나요?

전체 Unreal 게임을 동등한 게임플레이 및 렌더링으로 변환하는 범용 내보내기는 없습니다. 중립 형식은 지원되는 자산을 이동할 수 있지만 블루프린트, C++, 머티리얼, VFX, AI, 네트워킹, 입력, UI, 저장 동작 및 플랫폼 통합에는 타겟 측 디자인, 구현 및 검증이 필요합니다.

Unreal에서 내보내야 합니까, 아니면 원본 DCC 파일에서 내보내야 합니까?

단위, 축, 계층 구조, 뼈대 및 텍스처 참조를 보다 명확하게 제어할 수 있으므로 신뢰할 수 있는 DCC 소스가 있는 경우 이를 선호합니다. Unreal에 존재하는 승인된 변경 사항에 대해서만 Unreal에서 내보내고 정확한 내보내기 버전, 설정, 자산 소유권 및 다시 가져오기 테스트를 기록합니다.

자산을 Godot로 옮기는 데 FBX보다 GLB가 더 좋나요?

glTF/GLB는 표준 장면 교환을 위한 강력한 첫 번째 선택이며 Godot는 많은 작업 흐름에 glTF 2.0을 권장합니다. FBX는 캐릭터 및 레거시 DCC 파이프라인에 일반적으로 사용됩니다. 어려운 자산으로 두 가지를 모두 테스트하십시오. 어떤 형식도 엔진 게임플레이를 변환하지 않으며 물질적 동등성을 보장하지도 않습니다.

Unreal Blueprint를 자동으로 GDScript로 변환할 수 있나요?

자동 출력은 허용되는 생산 코드가 아닌 참조로 간주됩니다. 블루프린트 의미론은 Unreal의 라이프사이클, 컴포넌트, 리플렉션, 이벤트, 네트워킹 및 자산 시스템에 따라 달라집니다. Godot에서 게임플레이 계약을 재구축한 다음 상태 소유권, 타이밍, 실패 경로, 데이터 저장 및 멀티플레이어 권한을 검증하세요.

Unreal Marketplace 자산을 Godot로 이동할 수 있나요?

허가를 가정하지 마십시오. 모든 자산, 플러그인, 글꼴, 오디오 라이브러리 및 SDK에 대한 현재 라이선스를 검토하세요. 일부 콘텐츠는 엔진, 시트, 프로젝트 또는 재배포 조건에 따라 제한될 수 있습니다. 마이그레이션 인벤토리에 라이센스 결정을 유지하고 사용할 수 없는 것은 모두 교체하십시오.

마이그레이션할 가치가 있는지 어떻게 알 수 있나요?

대표적인 수직 슬라이스를 완성하고 시스템별로 남은 작업을 측정합니다. 대상 플랫폼, 자산 충실도, 동작, 성능, 패키징, 서비스, 팀 기술 및 라이선스 경계가 입증된 경우에만 계속하세요. 중요한 시스템을 알 수 없는 경우 성공적인 메시 가져오기에서 추정하기보다는 일시 중지하십시오.