청록색 보급상자 사진으로 회전 가능한 3D 모델을 만들었다고 가정해봅시다. 황동 모서리도 반짝이고 주황색 잠금장치도 보입니다. 이제 게임에 넣기만 하면 끝일까요? 손잡이 뒤가 막혀 있거나, 바닥을 통과하거나, 다른 조명에서 금속이 플라스틱처럼 보인다면 아직은 입체 초안입니다.
이 글은 2026년 10월 31일 확인한 공식 문서에 근거한 제작 가이드입니다. 생성 서비스를 직접 비교 실행하거나 실제 메시·게임 엔진 성능을 측정한 리뷰가 아닙니다. 예시는 움직이지 않는 정적 소품 한 개로 한정합니다. 뚜껑 개폐, 리깅, 파괴와 캐릭터 변형은 별도 제작 범위입니다. 삽화는 모두 AI로 만든 개념도이며 실제 생성 메시, 와이어프레임 검사 결과나 엔진 스크린샷이 아닙니다.
1. 첫 입력은 사진보다 ‘어떤 물건인가’라는 계약이다
입체화하기 전에 보급상자의 고정값을 적습니다. 청록색 몸체, 황동 모서리, 검정색 윗손잡이 하나, 주황색 정면 잠금장치 하나입니다. 서로 다른 컷에서 손잡이 수나 잠금장치 위치가 바뀌면 같은 물체의 추가 정보가 아니라 충돌하는 지시가 됩니다. 먼저 승인된 기준 이미지를 정하고 원본은 따로 보관하세요.
정면 3/4 사진은 정면과 측면 관계를 설명하기 쉽습니다. 물체 전체가 보이고 주변 물건과 분리되어야 합니다. 강한 반사가 경계를 가리거나 그림자가 부품처럼 보이지 않는지 확인하세요. 입력을 보정했다면 실제 재질까지 바뀌지 않았는지도 봅니다.
사진 한 장에 없는 뒷면은 관찰된 사실이 아닙니다. 실제 제품을 옮긴다면 뒤·옆 사진과 치수를 직접 확보하세요. 오리지널 게임 소품이라면 뒷면의 모양을 창작해도 되지만, ‘실물 복원’이 아니라 승인한 디자인 결정이라고 기록합니다. 다른 각도의 AI 이미지도 사진에 없던 사실을 검증해 주지는 않습니다.
| 먼저 정할 항목 | 보급상자 예시 | 확인할 이유 |
|---|---|---|
| 용도 | 바닥에 놓는 정적 소품 | 움직이는 부품을 별도 제작할지 결정 |
| 정체성 | 청록 몸체·황동 모서리·검정 손잡이·주황 잠금장치 | 형상과 개수의 흔들림 발견 |
| 실제 크기 | 너비 0.6m라는 가상 설정 | 임포트 후 스케일 대조 |
| 유지할 형상 | 손잡이 구멍·바닥·잠금장치 실루엣 | 낮춘 메시에서 사라지면 안 되는 요소 |
| 산출물 | 편집 원본·게임 메시·재질·검수 기록 | 미리보기 이미지와 실제 파일 구분 |
표의 크기는 설명용 예시입니다. 기획 이미지부터 만들고 싶다면 아래 입력 콘셉트 이미지용 요청문을 활용할 수 있습니다. 3D 파일을 만드는 코드는 아닙니다.
오리지널 SF 보급상자 한 개. 청록색 직육면체 몸체, 황동 모서리 보호대,
검정 윗손잡이 하나, 주황 정면 잠금장치 하나. 물체 전체가 보이는 3/4 시점,
중립적인 부드러운 조명과 단순한 배경. 손잡이의 빈 공간과 바닥 구조가 명확하게.
사람·글자·로고·추가 상자 없이, 과장된 원근이나 가려진 주요 부품 없이.
2. 생성기의 기능과 내가 받을 결과를 분리한다
Meshy Image to 3D 문서는 사진·콘셉트·스케치 입력과 High Detail, Smart Topology 같은 선택을 설명합니다. 이미지 보정이 켜져 있으면 입력을 다시 그리는 과정에서 디테일이 달라질 수 있으므로, 정해진 디자인을 옮기는 작업에서는 결과와 원본을 대조해야 합니다. 높은 디테일이 낮은 실행 비용이나 정확한 숨은 면을 뜻하지는 않습니다.
Tripo의 공식 기능 안내는 모델 생성, 분리, 리토폴로지, UV, 텍스처, 리깅과 내보내기를 서로 조합하는 공정으로 나눕니다. 이것이 중요한 힌트입니다. 한 서비스 안에 버튼이 모여 있어도 메시 생성과 재질·최적화·엔진 검수는 같은 성공 조건이 아닙니다. ‘게임용’이라는 제품 설명을 내 프로젝트에서의 합격 증거로 대체해서는 안 됩니다.
로컬 실행은 Microsoft TRELLIS.2 공식 저장소도 검토할 수 있습니다. 이미지에서 3D와 PBR 속성을 만들지만 공식 환경은 Linux와 충분한 NVIDIA GPU 메모리를 전제로 합니다. 공개 가중치가 모든 노트북에서 바로 실행되거나 설치·전력 비용까지 없다는 뜻은 아닙니다. 직접 실행한 결과는 아닙니다.
회색 메시와 텍스처 결과를 나눠 봅니다. 색을 끄자 잠금장치가 사라진다면 표면에만 그려졌을 수 있습니다. 가까이 보거나 집을 물체인지에 따라 실제 돌출이 필요한 부분을 정하세요. 생성·다운로드·상업 이용 조건은 계정과 모델별 최신 약관에서 확인하고 승인 예산 안에서 시험합니다.
3. 면을 줄이는 것과 올바른 구조를 만드는 것은 다르다
단순화는 대체로 면 수를 줄여 처리량을 낮추는 데 목적이 있습니다. 리메시는 면의 배치를 다시 만들고, 리토폴로지는 이후 편집·변형·제작 목적에 맞는 구조로 정리하는 작업입니다. 도구마다 이름과 범위가 다르므로 명칭보다 결과의 실루엣, 구멍, 표면 흐름과 수정 가능성을 봐야 합니다. 사각형 비중이 높다는 이유만으로 좋은 에셋이 되는 것도 아닙니다.
Meshy Remesh 문서는 목표 면 수와 토폴로지 선택, 원본을 보존한 별도 결과와 디테일 손실 점검을 설명합니다. 선택할 수 있는 옵션은 생성 모델과 후처리 경로에 따라 다릅니다. 삼각형 메시를 만드는 모드에 사각형 옵션이 당연히 있다고 가정하거나, 목표 면 수를 정확한 결과 면 수로 단정하지 마세요.
상자는 뚜껑 경계, 손잡이 구멍, 모서리와 잠금장치를 비교합니다. 손잡이가 몸체에 붙거나 평면 음영이 울고 작은 부품이 사라졌다면 보존할 부분을 다시 정하세요. 원본 고밀도 메시와 게임용 파생본은 별도로 저장합니다.
이 예시는 정적 상자이므로 팔꿈치처럼 접히는 관절의 면 흐름을 검증하지 않습니다. 나중에 뚜껑을 열고 싶다면 뚜껑을 별도 오브젝트로 나누고 회전축·내부 면·충돌까지 새 계약을 세워야 합니다. 외형만 맞춘 한 덩어리를 곧바로 애니메이션 가능한 모델로 부르지 마세요.

4. UV·PBR·셰이딩은 파일을 넘긴 뒤 다시 확인한다
UV는 3D 표면에 2D 텍스처를 배치하는 좌표입니다. 체크 무늬를 입혀 늘어난 칸이나 끊기는 경계를 보면 색이 화려할 때 놓친 문제를 찾기 쉽습니다. 보급상자 정면의 잠금장치와 모서리에서 해상도·방향이 심하게 달라지는지 보고, 실제 플레이 거리에서도 알아볼 수 있는지 확인하세요.
PBR은 재질을 물리 기반 렌더링 체계에 맞춰 표현하는 방식이지 모든 엔진에서 똑같이 보인다는 보증이 아닙니다. 색, 금속성, 거칠기와 노멀 같은 데이터의 역할을 분리하고, 목적 셰이더가 기대하는 텍스처 채널과 색 공간을 확인합니다. 황동의 밝은 반사가 색 이미지에 고정되어 있으면 광원을 움직였을 때 어색해질 수 있습니다. 중립 조명과 다른 방향의 조명에서 비교하는 이유입니다.
Meshy의 파일 형식 안내는 GLB에 텍스처를 포함하는 경로와 FBX·OBJ의 별도 텍스처 파일 관리를 구분합니다. 따라서 확장자만 바꿔 받은 뒤 ‘모델이 하얗다’고 생성 실패로 결론내리기 전에 텍스처 누락과 재질 연결을 확인하세요. Unity에서 GLB가 무조건 기본 임포트된다고 가정하지 말고 프로젝트의 지원 도구를 확인합니다. 엔진이 받는 형식으로 작은 샘플부터 왕복하는 것이 안전합니다.

5. 엔진의 합격 기준은 스케일·피벗·충돌·장면 비용이다
Blender 같은 편집 도구에서 좋아 보였다는 사실은 엔진 임포트 검사를 대신하지 않습니다. Unity 모델 임포트 문서에는 스케일, 축 변환, 메시·노멀과 콜라이더 관련 설정이 구분되어 있습니다. 해당 버전과 렌더 파이프라인에서 확인하세요. 예시 상자의 너비를 기준 자와 비교하고, 바닥 중앙 피벗이 배치·회전에 맞는지, 앞 방향이 기획과 같은지 확인합니다.
보이는 메시와 충돌 모양도 분리합니다. 장식까지 복잡한 충돌로 복제할 필요가 없다면 상자형 콜라이더로 시작합니다. 손잡이 구멍을 플레이에 사용한다면 단순 근사가 충분한지 별도로 시험하세요. 고정 배치와 집기·쌓기를 구분해 실제 행동으로 검사합니다.
Unity의 모델 최적화 안내는 폴리곤뿐 아니라 재질 수와 실제 렌더링 정점도 고려하도록 설명합니다. UV·노멀 경계 때문에 엔진의 정점 수가 모델링 도구 표시보다 늘어날 수도 있습니다. 모델 하나의 면 수만으로 프레임 속도를 약속할 수 없습니다. 같은 소품을 여러 개 배치한 목표 장면에서 텍스처 메모리, 렌더링 비용과 로딩을 실제로 측정해야 합니다.
| 검사 | 남길 증거 | 실패할 때 먼저 볼 것 |
|---|---|---|
| 크기·방향·피벗 | 기준 자와 배치한 장면 | 단위·축·원점·중복 스케일 |
| 재질 | 서로 다른 광원의 같은 시점 | 텍스처 경로·채널·노멀·셰이더 |
| 충돌 | 접근·지나가기·배치 테스트 | 콜라이더 형태와 오프셋 |
| 형상·거리 | 가까운 컷과 실제 플레이 거리 | 실루엣 손실·자잘한 디테일 |
| 실행 비용 | 목표 기기·장면의 프로파일 기록 | 인스턴스 수·재질·텍스처·메시 |

6. 초보자는 30분짜리 파일럿의 성공 범위를 줄인다
다음은 AIZIGOO가 제안하는 시간 제한 실험이며 완료 시간이나 품질을 보장하는 공식 성능 수치가 아닙니다. 생성 대기·설치 시간이 길면 멈추고 이어갈 항목을 기록하세요. 한 번에 상자 하나, 후보 하나, 대상 엔진 하나로 시작합니다.
입력 계약과 파일 이름을 정하고, 생성본이 있으면 색을 끈 상태로 모든 면을 확인합니다. 원본을 보존한 최적화 파생본을 만들고 UV·재질을 점검한 뒤 테스트 장면에 옮깁니다. 크기·방향·접촉을 통과, 수정 필요, 미검증으로 나누세요. 시간이 부족하면 다음 단계의 파일과 문제 목록을 결과로 남깁니다.
예를 들어 면 수 1만, 텍스처 1K, 재질 하나를 초기 시험 예산으로 놓을 수 있습니다. 이 수치는 설명용 가정이며 모바일·PC 공통 권장값이나 공급사의 성능 인증이 아닙니다. 상자가 차지하는 화면 크기와 등장 개수에 따라 올리거나 낮추고, 예산을 바꾸었다면 같은 테스트 장면에서 다시 비교하세요. 사용 가능한 결과 한 개의 비용에는 생성뿐 아니라 실패 재시도, 정리와 검수 시간도 포함합니다.

최종 인계에는 입력 이미지, 원본·게임 메시, 텍스처·재질, 엔진 버전과 임포트 설정, 권리·출처와 미해결 문제를 담습니다. 뒷면을 보지 않았다면 형태 검수 미완료이고, 목표 기기에서 측정하지 않았다면 성능은 미검증입니다. 확인 범위를 남겨 후반의 재작업을 줄이세요.
AI 3D는 아이디어에서 입체 초안까지의 거리를 줄입니다. 받은 파일, 확인한 사실, 아직 모르는 부분을 설명할 수 있어야 멋진 미리보기와 실제 제작 자산을 구분할 수 있습니다.
확인한 공식 자료
- Meshy: Image to 3D
- Meshy: Remesh
- Tripo: 기능과 제작 공정
- Microsoft: TRELLIS.2
- Meshy: 내보내기 형식
- Unity 6.2: 모델 임포트
- Unity 6.2: 모델 최적화
문서 확인일은 2026년 10월 31일입니다. 제품 기능·모델 선택·지역·계정·요금·라이선스는 변할 수 있으며, 실제 프로젝트 버전에 맞춰 다시 확인해야 합니다.