스마트 메시 명명 규칙: 3D 아티스트를 위한 전문가 가이드

이미지를 3D 모델로

복잡한 3D 파이프라인을 관리해 온 수년 동안, 저는 규율 있는 명명 규칙이 프로덕션 혼란을 방지하는 가장 효과적이고 로우테크적인 해결책임을 깨달았습니다. 좋은 시스템은 화려함에 관한 것이 아니라, 모든 에셋에 대해 예측 가능하고 검색 가능하며 자동화 가능한 구조를 만드는 것에 관한 것입니다. 이 가이드는 혼자 작업하든 대규모 스튜디오에서 작업하든, 프로젝트를 더 빠르고 적은 좌절로 완료하고자 하는 아티스트 및 테크니컬 디렉터를 위한 것입니다. 저는 제가 지키는 원칙, 매일 사용하는 템플릿, 그리고 현대적인 AI 지원 워크플로우에 이를 적용하는 방법을 공유할 것입니다.

주요 내용:

• 견고한 명명 규칙은 선택 사항이 아닌 기본이며, 반복 작업, 협업 및 자동화 능력에 직접적인 영향을 미칩니다.
• 최고의 시스템은 접두사, 접미사 및 구분 기호를 전략적으로 사용하여 설명적이고 일관적이며 기계가 읽을 수 있습니다.
• 명명 전략은 간단한 소품 목록에서 복잡한 캐릭터 리깅 및 환경 세트에 이르기까지 문제없이 확장되어야 합니다.
• Tripo AI와 같은 최신 AI 도구는 텍스처링 및 애니메이션을 위한 깨끗하고 사용 가능한 출력을 보장하기 위해 입력 명명에 더욱 엄격한 요구 사항을 요구합니다.
• 간단한 스크립트와 팀의 동의를 통한 강제 적용은 문서상의 좋은 문서를 살아있는 파이프라인 표준으로 바꾸는 요소입니다.

명명 규칙이 3D 파이프라인의 핵심인 이유

잘못된 명명의 실제 비용

"final_final_v7_really.ma"를 찾거나 300개의 에셋이 있는 장면에서 "geo_01"이 무엇을 의미하는지 해독하려다 프로덕션에서 낭비한 시간을 세는 것은 불가능합니다. 잘못된 명명은 즉각적이고 가시적인 비용을 발생시킵니다. 에셋을 기다리는 아티스트로 인한 마감 기한 누락, 잘못된 참조로 인한 깨진 리그 및 재료, 그리고 프로젝트 폴더를 끊임없이 발굴해야 하는 정신적 소모 등이 있습니다. 초기 프로젝트 중 하나에서 잘못 명명된 텍스처 세트로 인해 수십 개의 에셋을 마지막 순간에 다시 내보내야 했고, 이는 우리의 마일스톤을 이틀 연기시켰습니다. 오류는 간단했지만 파급 효과는 엄청났습니다.

좋은 명명이 프로젝트와 함께 확장되는 방식

단일 소품에 효과적인 것이 전체 게임 레벨이나 애니메이션 영화 시퀀스에서는 전혀 작동하지 않습니다. 확장 가능한 명명 시스템은 프로젝트의 골격입니다. 복잡성이 증가함에 따라 모든 것을 함께 유지합니다. 에셋이 어떻게 그룹화되고, 참조되고, 처리될지 의도적으로 생각하여 명명할 때 강력한 워크플로우를 가능하게 합니다. 배치 작업, 자동화된 LOD 생성 및 원활한 엔진 통합은 모두 예측 가능한 에셋 이름에 의존합니다. 저는 즉시 주요 질문에 답할 수 있도록 이름을 구성합니다. 무엇인가요? 어떤 부분인가요? 어떤 버전인가요?

파이프라인 악몽에서 배운 것

가장 고통스러운 교훈은 명명이 나중에 생각된 프로젝트에서 나왔습니다. 최악의 경우는 세 명의 아티스트가 동일한 에셋 유형에 대해 완전히 다른 시스템을 사용했던 협업 환경 프로젝트였습니다. 작업을 병합하는 것은 수작업으로 오류가 발생하기 쉬운 악몽이었습니다. 저는 단 하나의 폴리곤이 모델링되기 전에 규칙이 수립되어야 하며, 모든 사람이 볼 수 있는 곳에 문서화되어야 한다는 것을 배웠습니다. "파이프라인 악몽"은 거의 항상 본질적으로 정보 관리 실패입니다.

메시 및 재료 명명의 핵심 원칙

제가 항상 따르는 5가지 황금률

이것들은 단순한 제안이 아니라 제 시스템의 협상 불가능한 기반입니다.

1. 설명적이고 명확하게: SM_Prop_DeskLamp_Wood_01은 즉시 이해할 수 있습니다. Lamp04는 그렇지 않습니다.
2. 일관된 구분 기호 사용: 밑줄(_) 또는 하이픈(-)을 선택하고 일관되게 사용하세요. 공백은 절대 사용하지 마세요. 저는 가독성을 위해 밑줄을 사용합니다.
3. 전략적인 접두사 사용: 접두사는 에셋을 즉시 분류합니다. SK_는 스켈레톤, GRP_는 그룹, MAT_는 재료, TEX_는 텍스처를 나타냅니다.
4. 버전 포함: 항상 _v02와 같은 버전 번호를 추가하세요. 최종본의 경우 _F 또는 게시 날짜를 사용합니다.
5. 기계와 사람을 위해 설계: 이름은 스크립트(예: 배치 처리용)로 파싱할 수 있어야 하며 아티스트가 읽을 수 있어야 합니다.

단계별: 블록아웃부터 최종본까지의 명명 워크플로우

제 명명은 에셋의 성숙도에 따라 발전하여 "blockout_geo"가 실수로 최종 게임에 들어가지 않도록 방지합니다.

• 블록아웃 단계: BLO_Env_TownHall_Main. BLO_ 접두사는 스케일 및 레이아웃을 위한 임시 지오메트리임을 나타냅니다.
• 하이폴리 모델링: HP_Prop_MetalBarrel_01. HP_는 베이킹을 위한 스컬프팅 또는 고해상도 메시를 나타냅니다.
• 게임 레디/로우폴리: SM_Prop_MetalBarrel_01. "static mesh"를 위한 SM_. 이것은 최종 인-엔진 에셋입니다.
• 재료: M_Prop_Metal_Barrel_Rusted. M_ 접두사, 그 뒤에 유형, 특정 에셋 및 설명이 옵니다.
• 텍스처: T_Prop_MetalBarrel_01_Albedo, T_Prop_MetalBarrel_01_Normal. 일관된 기본 이름은 모든 맵을 연결합니다.

접두사, 접미사 및 구분 기호에 대한 모범 사례

이것은 명명 언어의 문법입니다. 다음은 제 표준 어휘입니다.

• 일반적인 접두사: SK_ (스켈레톤), RIG_ (리그), ANIM_ (애니메이션), FX_ (이펙트), COL_ (충돌 메시).
• 일반적인 접미사: _LOD0 (세부 수준 0), _UV1 (UV 세트), _FRONT (방향), _GRP (부모 그룹).
• 구분 기호 논리: 저는 논리적 블록을 구분하기 위해 밑줄(_)을 사용합니다: [접두사]_[유형]_[이름]_[설명]_[버전]. 예를 들어, 최종 스켈레톤의 경우 SK_Char_Hero_Soldier_F입니다.

시스템 구현: 간단한 프로젝트에서 복잡한 프로젝트까지

오늘 바로 사용할 수 있는 시작 템플릿

시작을 너무 복잡하게 만들지 마세요. 소품 및 환경에 이 간단한 템플릿을 사용하세요.

[에셋유형]_[카테고리]_[고유이름]_[변형/버전]

• 예시: SM_Prop_Chair_Wooden_01, SM_Env_Wall_Stone_Broken_v02
• 재료의 경우: M_[표면유형]_[기본이름] (예: M_Metal_WornIron, M_Fabric_Leather).
• 실행 항목: 다음 5개 에셋에 이를 적용하세요. 일관성은 즉각적인 보람을 안겨줄 것입니다.

캐릭터, 소품 및 환경에 대한 규칙 조정

다른 에셋군은 다른 요구 사항을 가집니다. 제 시스템은 그에 따라 분기됩니다.

• 캐릭터: 여기서는 계층 구조가 중요합니다. 저는 리그와 메시를 그들의 관계를 반영하는 방식으로 명명합니다.
  • SK_Char_Hero_Main: 루트 스켈레톤.
  • SM_Char_Hero_Body: 메인 메시.
  • SM_Char_Hero_Helmet: 부착된 소품 메시.
  • M_Char_Hero_Skin, M_Char_Hero_Armor: 관련 재료.
• 환경: 위치와 모듈성에 초점을 맞춥니다.
  • SM_Env_City_Module_Wall_4m
  • SM_Env_City_Prop_NewspaperBox
• 소품: 명확한 카테고리(Elec_, Foliage_, Weapon_)를 사용합니다.

AI 도구 및 자동화된 워크플로우와 통합

현대 AI 생성 도구는 엄격한 명명을 더욱 중요하게 만듭니다. Tripo AI에서 기본 메시를 생성할 때, 제가 사용하는 설명적인 프롬프트는 종종 에셋 이름의 핵심이 됩니다. 더 중요한 것은, 생성된 텍스처와 재료가 깔끔하게 통합되려면 동일한 규칙을 따라야 한다는 것입니다. 저는 Tripo에서 SM_Creature_CrystalBeetle을 생성한 다음, 내보낸 텍스처가 T_Creature_CrystalBeetle_BaseColor 등으로 명명되도록 하여 제 재료 빌더 스크립트가 자동으로 셰이더를 조립할 수 있도록 합니다. AI는 생성을 가속화하지만, 견고한 명명 파이프라인은 결과물이 프로덕션에 즉시 사용 가능하도록 보장합니다.

명명 표준 유지 및 강제 적용

일관성을 위해 사용하는 도구 및 스크립트

수동 강제 적용은 지속 불가능합니다. 저는 파일 저장 또는 내보내기 시 실행되는 간단한 사용자 지정 스크립트(Python 또는 Maya의 fileInfo와 같은 DCC 특정 도구를 통해)를 사용합니다. 이 스크립트는 다음을 수행할 수 있습니다.

• 유효하지 않은 문자(공백!)를 확인합니다.
• 접두사 사용을 검증합니다.
• 규칙에 따라 에셋을 일괄적으로 이름을 변경합니다(예: 선택한 모든 메시에 SM_ 추가).
• 기본 스프레드시트 기능조차도 프로덕션 시작 전에 이름 목록을 생성하고 검증하는 데 도움이 될 수 있습니다.

협업: 팀 전체가 같은 생각을 하도록 하기

규칙은 모든 사람이 사용해야만 작동합니다. 저는 모든 프로젝트의 Slack 채널과 공유 드라이브에 고정된 한 페이지짜리 "치트 시트" PDF를 만듭니다. 프로젝트 시작 시 15분 브리핑을 통해 에셋 목록의 구체적인 예를 사용하여 설명합니다. 핵심은 이를 위에서 내려온 임의의 규칙이 아니라 그들을 위한 시간 절약 및 버그 방지 도구로 제시하는 것입니다.

검토 및 반복: 시스템을 계속 활성화하기

어떤 시스템도 첫날부터 완벽하지 않습니다. 저는 각 주요 프로젝트 단계가 끝날 때마다 짧은 "파이프라인 점검"을 예약합니다. 우리는 어떤 이름이 혼란스러웠는지? 맞지 않는 새로운 에셋 유형을 만났는지? 등을 묻습니다. 그런 다음 살아있는 문서를 업데이트합니다. 목표는 팀의 필요에 따라 발전하고, 좌절스러운 제약보다는 유용한 도구로 남는 시스템입니다.