• 사용자의 소프트웨어가 Unity와 일관적으로 작동하게 하기 위해 사용자 시스템과 프로젝트 유닛(unit)을 설정합니다. 예) Metric
  • 스케일 작업은 조명(lighting) 및 물리 시뮬레션에 모두 중요할 수 있습니다;
  • 예를 들면, Max 시스템의 기본단위는 인치이고 Maya 는 센티미터 입니다.
  • Unity는 FBX와 3D 응용프로그램 파일의 들여오기에 대해 다른 스케일을 가지고 있습니다. 인스펙터(Inspector)에서 FBX 들여오기 스케일 설정을 확인합니다.
  • 의문이 가면 사용자의 씬(scene)에서 metre 규브의 내보내기를 실행하여 Unity에서 맞춥니다.
• 애니메이션 프레임 속도의 기본값은 패키지 마다 다를 수 있고, 사용자 파이프 라인에 걸쳐 일관적으로 설정하는 것이 좋습니다. 예: 30fps

• 사용자 씬(scene) 내의 오브젝트에 의미 있고 고유한 이름을 부여합니다. 이렇게 하면 사용자 프로젝트 내 특정 메쉬을 찾아내고 문제를 해결하는데 도움이 될 수 있습니다:
• 특수 문자의 사용을 피합니다. ()?”£$n 등.
• 오브젝트와 파일에 간단하고 의미 있는 이름을 사용합니다 (나중에 중복 허용).
• 가능한 사용자의 계층을 간단한 구조로 유지합니다.
• 사용자의 3D 응용프로그램에 큰 프로젝트를 사용한다면, 사용자의 Unity 프로젝트 디렉터리 밖에 작업 파일을 두는 것을 고려하십시오. 이렇게 하면 시간을 소비하는 업데이트나 불필요한 데이터를 가져오는 것을 피할 수 있습니다.

의미 있는 이름을 부여하면 원하는 것을 신속하게 찾을 수 있습니다

*효율적인 위상(topology)으로 빌드합니다. 다각형은 사용자가 꼭 필요한 경우에만 사용하십시오.

• 만일 다각형이 너무 많다면 사용자의 기하구조를 최적화 하십시오. 많은 캐릭터 모델은 지능적으로 최적화 하거나 혹은 특히 다음에서 빌드/소스(sourced) 되었다면 아티스트에 의해 재 빌드 할 필요까지 있을 수 있습니다:
  • 3D 캡쳐 데이터
  • Poser
  • Zbrush
  • 여타 랜더링을 위해 디자인 된 고밀도 Nurbs/패치 모델
• 사용자가 지원할 수 있는 건물, 풍경, 조형물 내 균등한 간격의 다각형은 조명을 확산하게 도와주고 어색한 단점을 피할 수 있게 해 줍니다.
• 아주 긴 삼각형을 피합니다.

framerate heaven으로 가는 계단

사용자가 오브젝트를 구축하는 데 사용하는 방법은, 특히 최적화되지 않을 경우 여러 다각형 상에서 엄청난 노력을 요할 수 있습니다. 같은 모양의 메쉬를 보면: 156개의 삼각형(오른쪽) 대 726개(왼쪽), 726개가 더 많은 다각형으로 들리지만, 이것이 한 레벨에 40번 쓰였다면, 사용자는 이것이 절감이란 것을 알게 될 것입니다. 유용한 경험상의 법칙은 간단하게 시작하고 필요할 때 상세사항을 추가해 나가는 것 입니다. 다각형을 떼어내는 것 보다는 추가하는 것이 항상 더 쉽기 때문입니다.

텍스처 더욱 효율적이고 는 만일 구체적인 텍스처 크기로 작성되었다면 빌드 시에 재 스케일(rescaling)이 필요하지 않습니다. 예: 최대 4096×4096의 2승, 예를 들어 512×512 혹은 256×1024 등. (2048×2048 은 많은 그래픽카드/플랫폼의 최대 픽셀 수 입니다). 고품질의 텍스처를 생성하는 데는 많은 기술이 온라인으로 존재하고, 이 가이드라인의 일부는 사용자가 프로젝트에서 가장 효율적인 결과물을 얻을 수 있게 도와줍니다:

• Unity 프로젝트 외에 있는 고 해상도의 소스(soruce) 파일로 작업하는 것은 추천할 만한 작업 방법입니다(PSD 나 Gimp 파일로, 사용자가 언제나 다운 사이즈를 할 수 있으나 반대작업은 불가합니다.
• 사용자 씬(scene)에서 필요로 하는 텍스처 해상도 출력물을 사용 (e.g. 복사본의 저장, 예를 들어 256×256로 최적화 된 PNG 나 TGA 파일) 해당 텍스처가 어디에서 보여질 것이며 어디로 매핑 되는가에 따라 사용자가 결정할 수 있습니다.
• 사용자의 Unity 프로젝트에서 결과 텍스처 파일을 함께 저장합니다. 예: \Assets\textures
• 사용자가 저장/내보내기를 실행할 때 사용자의 3D 작업 파일이 일관성을 위해 같은 텍스처를 가리키는지 확인합니다.
• 사용자의 텍스처에서 사용 가능한 공간을 활용하되, 같은 텍스처의 다른 부분을 필요로 하는 다른 물질이 그 텍스처를 여러 번 로딩하여 사용할 수 있다는 것에 주의합니다.
• 알파(cutout)와 다른 셰이더를 필요로 할 수 있는 요소의 경우, 텍스처를 분리합니다. 예를 들어, 아래의 단독 텍스처(왼쪽)은 3개의 아래(오른쪽) 더 작은 텍스처로 대체되었습니다.

1 texture (왼쪽) vs 3 textures (오른쪽)

• 표시 없이 반복하는 기울어진 텍스처(tiling textures)을 활용하십시오. 그러면 사용자는 공간에서 더 나은 해상도를 반복할 수 있습니다.
• 쉽게 보일 수 있는 반복 요소를 사용자의 비트맵에서 제거하고, 대조(contrast)에 유의합니다. 만일 사용자가 상세사항을 추가하고 싶다면, decals와 오브젝트를 사용하여 그 반복을 중단시킵니다.

Tiling textures ftw

• Unity는 출력 플랫폼을 위하여 압축을 처리하므로, 사용자의 소스가(source) 이미 정확한 해상동의 JPG가 아니라면, 사용자의 텍스처에 무손실(lossless) 포맷을 사용하는 것이 바람직합니다.
• 텍스처 페이지를 사진에서 생성할 때, 그 페이지를 반복 가능한 개별 모듈의 섹션으로 줄입니다. 예를 들어, 사용자는 텍스처 공간을 소비하는 동일한 12개의 창은 필요하지 않습니다. 이렇게 하면 사용자는 해당 한 창에 대한 픽셀 정보를 좀 더 상세하게 가질 수 있습니다.

이 창이 모두 필요할까요?

• 사용자의 씬(scene)에서 이름과 재질(material)을 정리합니다. 이렇게 하면 사용자는 사용자의 재질을 Unity 내에 들여왔을 때 좀 더 쉽게 찾을 수 있습니다.
• 사용자는 다음 중으로부터 Unity에서 재질 생성을 선택할 수 있습니다:

<modelname>-< material name> 혹은: <texture name> – 사용자가 원하는 것을 알고 있어야 합니다.

• 사용자의 원래 패키지에서 재질(material) 설정은 Unity로 들여오기가 되지 않을 것 입니다:

Diffuse Colour, Diffuse texture 및 Names 은 지원하지 않습니다. 셰이더(Shader) model, 반사(specular), 정상(normal), 기타 보조 텍스처와 물질 재질(substance material ) 설정은 인식/수입 되지 않습니다. (3.5에서 도입)

Unity는 2가지 타입의 파일을 사용할 수 있습니다: 저장된 3D 응용프로그램 파일과 내보내기한 3D 포맷. 사용자가 이중 어느 것을 사용할 지 결정하는 것은 매우 중요합니다:

변환을 통해 Unity는 들여오기를 할 수 있습니다: Max, Maya, Blender, Cinema4D, Modo, Lightwave & cheetah3D 파일들, 예: MAX, .MB, .MA 등. http://unity3d.com/support/documentation/Manual/HOWTO-importObject.html

_이점_:

• 신속한 반복 과정 (저장과 Unity 업데이트 save and Unity updates)
• 초기에 간단함.

_단점_:

• 프로젝트를 사용하는 모든 장비에 해당 소프트웨어에 대한 라이선스 본이 설치되어야 함.
• 파일이 불필요한 데이터로 비대해 질 수 있음.
• 대형 파일이 Unity 업데이트를 지연시킬 수 있음.
• 검사의 축소. 문제해결이 더 난해해짐.

Unity는 FBX, OBJ, 3DS, DAE & DXF 파일들도 읽을 수 있습니다. 내보내기(export)에 대한 일반적인 가이드를 보려면, 다음을 참조합니다: http://unity3d.com/support/documentation/Manual/HOWTO-exportFBX.html

_이점_:

• 사용자가 필요한 데이터만 내보내기 함
• Unity 이전에 사용자 데이터(3D 패키지로 재 불러오기)를 검증.
• 더 작은 파일 생성.
• 모듈화된 접근 법을 장려.

_단점_:

• 파이프라인, 프로토타입(prototyping), 반복이 느려질 수 있음.
• 소스(작업파일)과 게임데이터(내보내기 한 FBX) 사이에 버전관리가 난해해짐.

• 출처: 유니티코리아위키 (CC BY-NC-SA 2.0)