직접적인 답변: 범용 Unreal-to-Godot 프로젝트 내보내기는 없습니다
“Unreal to Godot exporter”는 완전한 게임을 위한 원클릭 변환기가 아닙니다. 소스 소유 에셋은 중립 형식을 통해 이동할 수 있습니다. 일반적으로 메시와 애니메이션은 glTF 또는 FBX를 통해, 텍스처는 표준 래스터 파일로, 오디오는 WAV 또는 OGG로, 디자인 데이터는 JSON 또는 CSV로 이동합니다. 하지만 엔진 소유 시스템은 Godot에서 재구축하고 검증해야 합니다. Blueprints, Unreal C++, 머티리얼, Niagara 효과, 레벨 로직, AI 그래프, 입력 매핑, 복제, 저장 시스템 및 플랫폼 서비스는 파일을 내보냈다는 이유만으로 동등한 Godot 시스템이 되지 않습니다.
작업을 파일 변환이 아닌 마이그레이션으로 다루세요. 알려진 Unreal 리비전을 고정하고, 팀이 법적으로 소유한 항목을 인벤토리화하며, 원본 DCC 소스를 보존하고, 작은 수직 슬라이스를 선택하고, 이식 가능한 콘텐츠만 내보내며, Godot에서 동작을 재구축하고, 동일한 카메라, 상호작용, 데이터 및 성능 검사로 두 프로젝트를 비교하세요. 슬라이스가 승인 기준을 충족하지 못하면 프로젝트의 나머지를 변환하기 전에 중단하세요.
이 가이드는 SEELE AI가 기존 프로젝트를 마이그레이션한다고 주장하지 않습니다 .uproject, Blueprint 그래프를 번역하거나 기능 동등성을 보장합니다. 이 가이드는 엔진 이전을 평가하는 팀을 위한 기술적 경계와 되돌릴 수 있는 워크플로를 설명합니다.
내보내기 형식을 선택하기 전에 마이그레이션 이유를 결정하세요
팀은 런타임 용량, 라이선스 전략, 소스 접근성, 플랫폼 범위, 팀 역량, 더 단순한 2D/3D 프로젝트 또는 Godot 표준화의 필요성 등 여러 이유로 이전을 고려합니다. 이러한 이유 중 어느 것도 무엇이 이전될지를 알려주지 않습니다. 콘텐츠를 건드리기 전에 비즈니스 및 기술 목표를 측정 가능한 용어로 작성하세요.
예를 들어 “Godot으로 이전”은 너무 모호합니다. 유용한 목표는 다음과 같습니다. “Godot 4에서 싱글플레이어 데스크톱 게임의 첫 15분을 재구축하고, 라이선스가 허용하는 범위에서 제작된 환경과 캐릭터 애니메이션을 보존하며, 상호작용 및 저장 동작을 재현하고, 동일한 장비에서 합의된 테스트 예산 내의 프레임 시간과 메모리를 유지한다.” 이 문장은 대상 플랫폼, 콘텐츠 슬라이스, 동작 및 증거를 드러냅니다.
필요하지 않은 항목도 명시하세요. 프로토타입에는 온라인 서비스, 고급 파괴 효과, 시네마틱, 콘솔 인증 또는 모든 머티리얼 변형이 필요하지 않을 수 있습니다. 첫 번째 슬라이스에서 이를 제외하는 것은 그것들이 쉽다고 가장하는 것이 아니라 평가가 통제되지 않는 재작성으로 변하는 것을 방지합니다.
초기 세 가지 질문이 일반적으로 실행 가능성을 결정합니다:
- 편집 가능한 소스 에셋을 소유하고 있나요? 패키징된 빌드 또는 쿠킹된
.uasset컬렉션은 소스 메시, 텍스처, 오디오 및 프로젝트 데이터와 동일하지 않습니다. - 엔진 종속 시스템에 얼마나 많은 가치가 있나요? 커스텀 Blueprint 프레임워크, 플러그인, Niagara, 복잡한 머티리얼, World Partition 또는 Unreal 네트워킹으로 구동되는 게임은 소스 소유 에셋과 단순한 동작을 가진 소규모 프로젝트보다 재작성 위험이 더 큽니다.
- Godot에서 대상 플랫폼과 서비스를 지원할 수 있나요? 공식 문서 및 공급업체 계약을 기준으로 현재 내보내기 템플릿, SDK 요구 사항, 미들웨어, 스토어프런트, 접근성, 분석 및 인증 요구 사항을 확인하세요.
그 질문들 이후에도 동기가 타당하다면, 어떤 “exporter”를 선택하기 전에 인벤토리를 구축하세요.
소유권 및 대체 결정을 포함한 마이그레이션 인벤토리 구축
시스템 또는 에셋 패밀리당 한 행으로 표를 만드세요. 소스 소유자, Unreal 표현, 대상 표현, 형식, 라이선스, 자동화 테스트, 수동 검토 및 대안을 기록하세요. 개별 파일로 시작하지 말고 프로덕션 책임으로 시작하세요.
| 영역 | 예상 소스 | 이식 경로 | Godot 작업 | 주요 위험 | |---|---|---|---|---| | 정적 지오메트리 | DCC 소스 또는 Unreal 메시 | glTF/GLB 또는 FBX | 임포트 설정, 충돌, LOD 전략 | 트랜스폼, 탄젠트, 머티리얼 | | 스켈레탈 캐릭터 | DCC 소스, 스켈레톤, 클립 | 테스트 후 glTF/FBX | 스켈레톤 매핑, AnimationTree, 리타게팅 정책 | 바인드 포즈, 루트 모션, 제약 조건 | | 텍스처 | 제작된 이미지 | PNG, TGA, EXR 또는 기타 승인된 소스 | 색 공간, 압축, 임포트 플래그 | 패킹 채널, 버추얼 텍스처 | | 머티리얼 | Unreal 그래프와 소스 텍스처 | 소스 텍스처 및 문서화된 의도 | 셰이더/머티리얼 재구축 | 그래프 동등성 없음 | | 게임플레이 | Blueprint 및 C++ | 설계 사양 및 테스트 | GDScript, C# 또는 네이티브 확장 | 의미론적 재작성 | | VFX | Niagara 에셋 | 텍스처/메시 소스 및 동작 참조 | GPUParticles/CPUParticles 또는 커스텀 셰이더 | 타이밍 및 시각적 불일치 | | 오디오 | 소스 녹음 | WAV/OGG 및 이벤트 맵 | 버스, 스트림, 트리거 | 미들웨어 및 이벤트 로직 | | 데이터 | DataTables/config | JSON, CSV, 리소스 | 스키마 및 검증 | ID, 기본값, 현지화 | | 레벨 | 액터 및 컴포넌트 | 선택적 씬 데이터 또는 수동 재구성 | Godot 씬/노드 | 계층 구조 및 좌표 드리프트 | | 온라인/플랫폼 | 플러그인 및 서비스 | 엔진 파일이 아닌 계약 | 새 SDK/서비스 통합 | 기능 가용성 및 인증 |
각 행을 다음으로 표시하세요 transfer, rebuild, replace, drop, 또는 unknown“. “알 수 없음”은 정당한 상태이며, 검증 작업을 유발합니다. 플러그인이나 Marketplace 에셋을 이전 가능하다고 조용히 간주하는 것보다 안전합니다.
라이선스 검토는 인벤토리에 포함되어야 합니다. Unreal Marketplace 콘텐츠, 타사 플러그인, 스캔 에셋, 오디오 라이브러리, 폰트, SDK 및 브랜드 머티리얼에는 Unreal 외부 사용을 제한하거나 별도 라이선스를 요구하는 조건이 있을 수 있습니다. 파일이 프로젝트 폴더에 존재한다는 사실에 의존하지 말고 현재 계약을 확인하세요.
승인된 모든 입력에 대해 콘텐츠 해시 또는 소스 리비전을 유지하세요. 마이그레이션 과정에서는 오래된 파일, 중복 파일 또는 파생 파일이 드러나는 경우가 많습니다. 안정적인 소스 매니페스트가 없으면 팀은 시각적 차이가 익스포터, 가져오기 설정 또는 다른 소스 에셋에서 비롯된 것인지 알 수 없습니다.
이전되는 항목과 재구축해야 하는 항목
이식 가능한 에셋은 데이터를 보존하지만 엔진 의미론은 보존하지 않습니다. 정적 메시는 위치, 노멀, UV, 탄젠트, 버텍스 색상 및 경우에 따라 머티리얼 할당을 담을 수 있습니다. 스켈레탈 형식은 본, 가중치 및 애니메이션 트랙을 담을 수 있습니다. 그러나 Unreal의 액터/컴포넌트 라이프사이클, Blueprint 이벤트 순서, Gameplay Ability System 동작, 네트워크 권한 또는 정확한 셰이더 파이프라인은 담지 않습니다.
가장 신뢰할 수 있는 전송은 원본 DCC 패키지에서 시작됩니다. 깨끗한 Blender, Maya 또는 기타 소스 씬을 내보내면 팀이 단위, 축, 이름, 삼각분할, 스켈레톤 계층 구조 및 텍스처 참조를 제어할 수 있습니다. Unreal 에셋에 다른 곳에는 없는 승인된 편집 내용이 포함된 경우 Unreal에서 내보내는 것이 유용할 수 있지만, exporter에 포함되는 내용과 결과를 소스에서 재현할 수 있는지 확인하세요.
Epic은 다음을 문서화합니다 Unreal Engine glTF Exporter 지원되는 콘텐츠를 glTF로 내보내는 경로로 사용합니다. Godot는 다음을 문서화합니다 사용 가능한 3D 씬 형식, 많은 워크플로에서 권장되는 교환 형식인 glTF 2.0과 함께. 이 문서는 파일 형식 기능을 확립하지만 전체 프로젝트 변환을 약속하지는 않습니다.
형식 충성도 대신 형식 시험을 사용하세요:
- glTF/GLB: 표준 씬 교환, PBR 지향 머티리얼, 메시, 스켈레톤 및 애니메이션을 위한 강력한 첫 후보입니다. 에셋에서 사용하는 정확한 기능을 테스트하세요.
- FBX: 기존 캐릭터 및 DCC 파이프라인에서 일반적입니다. 가져오기/내보내기 구현은 다르므로 내보내기 도구 및 가져오기 도구 버전을 고정하고 바인드 포즈, 애니메이션, 탄젠트 및 머티리얼 참조를 테스트하세요.
- OBJ: 간단한 정적 지오메트리에는 유용하지만, 리그, 애니메이션, 복잡한 계층 구조 또는 최신 머티리얼 동작의 기본 경로로는 부적합합니다.
- USD: 대규모 콘텐츠 파이프라인에서는 유용하지만, 런타임 게임플레이를 자동으로 변환하거나 USD 스테이지가 최적화된 Godot 씬이 된다는 것을 보장하지는 않습니다.
모든 에셋 패밀리에 대해 어려운 사례가 포함된 골든 샘플을 만드세요. 미러링된 지오메트리, 여러 UV 세트, 버텍스 색상, 하드 엣지, 투명 머티리얼, 음수 스케일, 중첩된 트랜스폼, 루트 모션이 있는 스켈레탈 클립 및 필요한 경우 하나의 모프 타깃을 포함하세요. 수백 개의 에셋을 이동하기 전에 의도한 내보내기 및 가져오기 버전으로 이를 실행하세요.
차이점을 숨기지 않고 정적 메시, 텍스처 및 머티리얼 내보내기
정적 콘텐츠부터 시작하세요. 이는 게임플레이와 좌표 및 렌더링 문제를 분리하기 때문입니다. Unreal에서는 에셋 경로, 소스 파일, 임포트 설정, 빌드 설정, 머티리얼 슬롯, 충돌, LOD, Nanite 상태 및 생성 시점 수정 사항을 기록하세요. 원본 DCC 소스가 권위 있는 경우 այնտեղ에서 내보내세요. Unreal이 수정 사항의 유일한 승인된 소스인 경우, 내보내기 경로를 문서화하고 라이선스 권한을 확인하세요.
Godot 측에서는 스케일, 방향, 피벗, 계층 구조, 노멀, 탄젠트, UV 채널, 버텍스 색상, 머티리얼 슬롯 및 충돌을 검사하세요. 소스 계약을 이해하기 전에는 임의의 노드별 보정을 적용하지 마세요. 영구적인 100× 스케일 조정이나 회전된 루트는 한 씬에서는 무해해 보일 수 있지만 나중에 물리, 애니메이션, 내비게이션 또는 도구 문제를 만들 수 있습니다.
머티리얼은 의도적인 재구성이 필요합니다. Unreal 머티리얼 그래프에는 함수, 파라미터 컬렉션, 버추얼 텍스처, 런타임 버추얼 텍스처, 커스텀 HLSL, 데칼, 랜드스케이프 레이어, 서브서피스 모델 및 플랫폼 스위치가 포함될 수 있습니다. glTF 내보내기는 지원되는 PBR 속성을 근사할 수 있지만 모든 그래프 결정을 보존할 수는 없습니다. 기본 색상, 노멀, 러프니스, 메탈릭, 발광, 불투명도, UV 동작 및 예상 조명 반응을 포함한 대상 머티리얼 사양을 작성한 다음 Godot의 렌더러와 셰이더 언어에 맞춰 다시 구축하세요.
패킹 텍스처는 흔한 함정입니다. 어떤 채널이 러프니스, 메탈릭, 앰비언트 오클루전, 마스크 또는 높이를 저장하는지 기록하세요. Godot 임포트 설정과 커스텀 셰이더는 동일한 채널을 읽어야 합니다. 색 공간 처리도 검증하세요. 데이터 텍스처를 색상 이미지로 취급해서는 안 되며, 노멀 맵에는 선택한 파이프라인에 맞는 올바른 규칙이 필요합니다.
중립 조명, 하나의 디렉셔널 또는 환경 설정, 알려진 카메라 위치 및 대표적인 머티리얼로 고정 비교 씬을 만드세요. 렌더러 간 정확한 픽셀 일치는 현실적이지 않은 경우가 많습니다. 승인 질문은 두 스크린샷이 수치적으로 동일한지가 아니라, 새 결과가 합의된 허용 오차 내에서 아트 디렉션과 게임플레이 가독성을 보존하는지입니다.
스켈레탈 메시와 애니메이션을 별도의 검증 항목으로 이전하세요
캐릭터는 단위, 루트 방향, 스켈레톤 계층, 바인드 포즈, 본 이름, 스킨 가중치, 제약 조건, 애니메이션 커브, 루트 모션, 모프 타겟, 소켓 및 게임플레이 이벤트 등 여러 실패 지점을 결합합니다. 첫 번째 정적 메시 배치에 포함하지 마세요.
대표 캐릭터 하나와 세 개의 클립을 선택하세요: 아이들, 루트 모션 또는 제자리 모션이 있는 이동, 그리고 회전, 웅크리기 또는 손 뻗기 같은 극단적인 액션입니다. 선택한 glTF 또는 FBX 경로를 통해 스켈레톤과 메시를 내보내세요. Godot에서 가져온 Skeleton3D 계층, 스킨, 애니메이션 트랙, 루프 설정 및 루트 트랜스폼을 검사하세요. AnimationTree 또는 프로젝트에서 선택한 아키텍처를 사용해 런타임 상태 머신을 다시 만드세요. Unreal Animation Blueprint가 이전될 것이라고 기대하지 마세요.
고정된 프레임에서 관절 위치와 접촉을 비교하세요. 발, 손, 엉덩이, 어깨, 무기 소켓, 얼굴 형태 및 메시 관통을 확인하세요. 프로젝트에서 Control Rig, IK Rig, IK Retargeter, 애니메이션 노티파이, 몽타주, 모션 워핑 또는 물리 기반 보조 모션을 사용하는 경우, 각각을 재구현하거나 대체해야 하는 동작으로 나열하세요. 베이크된 애니메이션은 이전될 수 있지만 절차적 런타임 동작은 그렇지 않습니다.
루트 모션에는 명시적인 소유자가 필요합니다. 변위가 애니메이션, 캐릭터 컨트롤러 또는 게임플레이 코드 중 어디에서 오는지 결정하세요. Godot에서 시각적으로 재생되는 클립도 소유권이 변경되면 네트워크 이동, 충돌 또는 저장 상태 동작에서 실패할 수 있습니다.
소스 에셋에서 콜드 임포트를 재현할 수 있고, 세 개의 클립이 통과하며, 재임포트가 수동 대상 작업을 파괴하지 않고, 캐릭터가 게임플레이 검증에 사용된 동일한 수직 슬라이스에서 실행될 때에만 캐릭터 증명을 승인하세요.
Blueprint, C++, VFX, AI 및 게임플레이 동작 재구축
Blueprint 그래프와 Unreal C++는 Unreal의 오브젝트 모델, 리플렉션, 액터/컴포넌트 라이프사이클, 델리게이트, 에셋 시스템, 가비지 컬렉션, 입력, 물리, 네트워킹 및 빌드 툴체인에 대해 컴파일됩니다. 텍스트 또는 그래프 내보내기는 구조 문서화에 도움이 될 수 있지만, 동등한 Godot 동작을 만들지는 않습니다.
구문이 아니라 의도를 번역하세요. 각 게임플레이 기능에 대해 다음을 작성하세요:
- 권위 있는 상태와 이를 소유하는 오브젝트;
- 입력, 검증 및 거부 경로;
- 업데이트 타이밍 및 순서 가정;
- 출력, 이벤트, 애니메이션/VFX/오디오 훅;
- 저장 및 로드 동작;
- 해당하는 경우 멀티플레이어 권한 및 복제;
- 자동화되거나 반복 가능한 승인 테스트.
그런 다음 동일한 계약을 구현하는 Godot 노드, 씬, 리소스, 시그널, 스크립트 및 서비스 경계를 설계하세요. 여러 컴포넌트를 가진 Blueprint Actor는 노드와 리소스를 갖춘 Godot 씬이 될 수 있지만, 일대일 클래스 매칭은 목표가 아닙니다. 새 팀이 유지 관리할 수 있을 만큼 대상 구조가 관용적이어야 합니다.
Niagara 효과도 재구성이 필요합니다. 허용되는 경우 소스 텍스처와 메시를 이전하고, 생성 속도, 수명, 힘, 충돌, 렌더 모드, 머티리얼 및 게임플레이 타이밍을 기록한 다음 Godot 파티클 또는 셰이더로 재구축하세요. Unreal AI 비헤이비어 트리, EQS 쿼리, 내비게이션 설정, 포스트 프로세싱, 오디오 미들웨어, UI 프레임워크 및 온라인 서브시스템도 마찬가지입니다.
플레이어 경험을 정의하는 동작을 우선시하세요. 외관상 동등성이 손상된 저장 시스템, 잘못된 충돌, 사라진 입력 포커스 또는 달라진 적 상태를 가려서는 안 됩니다. 대체 버전이 승인될 때까지 원본 Unreal 빌드를 동작 참조로 유지하세요.
하나의 버티컬 슬라이스로 마이그레이션을 검증하세요
첫 번째 슬라이스는 완료할 수 있을 만큼 작고 위험한 경계를 드러낼 만큼 넓어야 합니다. 유용한 슬라이스에는 방 하나, 조작 가능한 캐릭터 하나, 애니메이션 세트 하나, 상호작용 오브젝트 하나, UI 상태 하나, 오디오 큐 하나, 저장된 값 하나, 실패 경로 하나 및 패키징된 타겟 하나가 포함됩니다. 멀티플레이어가 핵심 요구 사항이라면 모든 네트워킹 증거를 미루는 대신 최소한의 권한 있는 2클라이언트 상호작용을 포함하세요.
테스트 환경을 고정하세요: 소스 커밋, Godot 커밋, exporter 버전, importer 버전, 대상 머신, 해상도, 빌드 구성 및 입력 경로. 가능한 경우 동일한 카메라 위치와 스크립트화된 상호작용 시퀀스를 사용하세요. 다음 매트릭스에 결과를 기록하세요:
| 검사 항목 | Unreal 기준선 | Godot 대상 | 통과 조건 | |---|---|---|---| | 씬 규모 | 알려진 기준 오브젝트 | 동일한 기준 | 충돌과 카메라가 일치 | | 캐릭터 | 고정된 클립 3개 | 재구축된 상태 머신 | 접촉 및 소유권 통과 | | 상호작용 | 열기/닫기 또는 줍기 | 동일한 결과 | 유효 및 무효 입력 처리 | | 저장 | 영구 값 1개 | 동일한 시나리오 | 재시작 및 버전 규칙 후에도 유지 | | 비주얼 | 승인된 기준 뷰 | 대상 뷰 | 아트 검토에서 차이 허용 | | 성능 | 측정된 경로 | 동일한 경로 | 합의된 프레임/메모리 예산 | | 빌드 | 콜드 패키징 실행 | 대상 내보내기 | 에디터 복구 없이 재현 가능 |
서로 다른 씬의 에디터 프레임 카운터를 비교하지 마세요. 대표적인 패키징 빌드, 동일한 콘텐츠와 경로, 명확한 샘플 기간을 사용하세요. 셰이더 컴파일, 로딩, 메모리 및 프레임 타이밍을 별도로 기록하세요. 한 엔진이 다른 렌더러나 기능 세트를 사용한다면 이를 모호한 승자 주장으로 바꾸지 말고 차이점으로 기록하세요.
실패 사례를 실행하세요: 필수 에셋 제거, 잘못된 형식의 데이터 제공, 로딩 중단, 지원되는 버전에서 저장 파일 다시 로드, 씬 변경 후 상호작용 반복. 마이그레이션 버그는 첫 번째 정상 경로가 아니라 재가져오기, 재시작 및 정리 과정에 숨어 있는 경우가 많습니다.
슬라이스가 끝나면 파일 수가 아니라 시스템별로 남은 작업을 추정하세요. 복잡한 Blueprint 프레임워크 10개는 수천 개의 텍스처보다 비용이 더 많이 들 수 있습니다. 재테스트, 플랫폼 통합, 툴링, 문서화 및 팀 교육을 결정에 포함하세요.
마이그레이션, 유지 또는 더 작은 제품 재구축 중 선택하기
버티컬 슬라이스가 필요한 플랫폼, 이식 가능한 에셋 경로, 대상 아키텍처, 성능 예산 및 팀 소유권을 입증하면 마이그레이션을 계속하세요. 핵심 미들웨어, 인증, 렌더링 요구 사항 또는 온라인 기능이 불확실한 경우 중단하세요. 재작성 비용이 제품 가치를 초과하거나 현재 엔진 내의 더 작은 변경으로 마이그레이션 목표를 달성할 수 있다면 중지하세요.
프로젝트가 Unreal 네이티브 시스템에 크게 의존하고 팀이 실제 비용 또는 워크플로 문제를 직접 해결할 수 있다면 Unreal을 유지하는 것은 실패가 아닙니다. 마찬가지로 모든 과거 에셋과 아키텍처 결정을 새 프로젝트로 가져가는 것보다 깔끔한 Godot 재구축이 더 나을 수 있습니다. 올바른 선택은 내보내기에 대한 열정이 아니라 슬라이스로 뒷받침되는 선택입니다.
더 폭넓은 엔진 결정을 위해 다음을 읽어보세요 게임 개발을 위한 Unreal Engine vs Godot. 소스 에셋 계획에는 다음을 사용하세요 Unreal 3D 모델 파일 형식 가이드. Unreal을 유지하는 팀은 다음을 통해 새 콘셉트를 시작할 수 있습니다 Unreal 게임 제작자.
SEELE AI 인계 및 제품 범위
SEELE AI는 다음을 생성할 수 있습니다 새로운 네이티브 Unreal 5 프로젝트, 브라우저 미리보기를 제공하고, 최적화 및 패키징을 지원하며, 다운로드 가능한 프로젝트 또는 패키징된 결과물을 제공합니다. 기존 .uproject, 프로젝트를 Godot으로 내보내고, Blueprints 또는 C++를 번역하고, 서드파티 플러그인을 재구축하거나, Godot 빌드를 인증합니다.
팀이 마이그레이션 여부를 결정하기 전에 새로운 Unreal 방향을 비교하고 있다면, 타겟 플랫폼, 하나의 게임플레이 루프, 아트 디렉션, 필요한 입력, 성능 예산 및 패키징 승인 기준을 포함한 범위가 제한된 브리프를 사용하세요. 해당 실험은 기존 프로젝트 마이그레이션 인벤토리와 분리해 두세요.
Unreal Engine은 Epic Games의 상표입니다. Godot은 기술 비교를 위해 언급됩니다. SEELE AI는 독립적이며 이 가이드는 Epic Games 또는 Godot 프로젝트의 보증을 의미하지 않습니다.
공식 소스
- Epic Games: Unreal Engine 콘텐츠를 glTF로 내보내기
- Godot 문서: 사용 가능한 3D 형식
- Godot 문서: 3D 씬 가져오기
- Epic Games: FBX 콘텐츠 파이프라인
프로덕션에 워크플로를 적용하기 전에 버전 선택기와 현재 라이선스 조건을 확인하세요.
FAQ
전체 프로젝트를 위한 Unreal에서 Godot로의 exporter가 있나요?
동등한 게임플레이와 렌더링으로 전체 Unreal 프로젝트를 변환하는 범용 exporter는 없습니다. 중립 형식은 지원되는 에셋을 이동할 수 있지만 Blueprint, C++, 머티리얼, VFX, AI, 네트워킹, 입력, UI, 저장 동작 및 플랫폼 통합에는 대상 측 설계, 구현 및 검증이 필요합니다.
Unreal에서 내보내야 하나요, 아니면 원본 DCC 파일에서 내보내야 하나요?
권위 있는 DCC 소스가 존재한다면 단위, 축, 계층 구조, 스켈레톤 및 텍스처 참조를 더 명확하게 제어할 수 있으므로 이를 우선하세요. Unreal에서만 존재하는 승인된 변경 사항에 한해서만 Unreal에서 내보내고, 정확한 exporter 버전, 설정, 에셋 소유권 및 재임포트 테스트를 기록하세요.
Godot으로 에셋을 옮길 때 GLB가 FBX보다 더 나은가요?
glTF/GLB는 표준 씬 교환을 위한 강력한 첫 선택이며, Godot는 많은 워크플로에서 glTF 2.0을 권장합니다. FBX는 캐릭터 및 레거시 DCC 파이프라인에서 여전히 일반적입니다. 까다로운 에셋으로 두 형식을 모두 테스트하세요. 어느 형식도 엔진 게임플레이를 변환하거나 머티리얼 동등성을 보장하지 않습니다.
Unreal Blueprints를 GDScript로 자동 변환할 수 있나요?
자동 출력은 승인된 프로덕션 코드가 아니라 참고 자료로 취급하세요. Blueprint 의미론은 Unreal의 라이프사이클, 컴포넌트, 리플렉션, 이벤트, 네트워킹 및 에셋 시스템에 따라 달라집니다. Godot에서 게임플레이 계약을 재구축한 후 상태 소유권, 타이밍, 실패 경로, 저장 데이터 및 멀티플레이어 권한을 검증하세요.
Unreal Marketplace 에셋을 Godot으로 옮길 수 있나요?
권한이 있다고 가정하지 마세요. 모든 에셋, 플러그인, 글꼴, 오디오 라이브러리 및 SDK의 현재 라이선스를 검토하세요. 일부 콘텐츠는 엔진, 시트, 프로젝트 또는 재배포 조건에 의해 제한될 수 있습니다. 마이그레이션 인벤토리에 라이선스 결정을 기록하고 사용할 수 없는 항목은 교체하세요.
마이그레이션할 가치가 있는지 어떻게 알 수 있나요?
대표적인 버티컬 슬라이스를 완성하고 시스템별로 남은 작업을 측정하세요. 대상 플랫폼, 에셋 품질, 동작, 성능, 패키징, 서비스, 팀 역량 및 라이선스 경계가 입증된 경우에만 계속 진행하세요. 핵심 시스템이 여전히 불확실하다면 성공적인 메시 임포트 결과를 바탕으로 추정하지 말고 중단하세요.
