Unity는 완전한 자동 에셋 파이프 라인을 가지고 있습니다. .psd 파일이나 .fbx 파일과 같은 에셋 소스가 변경되면 Unity는 변경사항을 감지하고 자동으로 다시 파일을 임포트합니다. 파일에서 임포트된 데이터는 즉시 내부 형식으로 변환되어 저장됩니다.
이 정렬 방식은 각 사용자 작업의 흐름을 최대한 효율적이고 유연하게 만들기 위해서 설계되었습니다. 그러나 팀으로 작업할 때는 다른 사용자들이 계속 변경하는 에셋을 임포트해야 하는 상황을 맞이하게 됩니다. 거기에 더해서 데스크탑에서 모바일 빌드 타겟 플랫폼으로 전환 시 에셋을 다시 임포트해야 합니다. 이러한 전환은 큰 프로젝트일 수록 더 많은 시간을 소모합니다.
임포트한 에셋 데이터를 캐시 서버 에 캐시하는 것은 에셋을 임포트하는 시간을 현저하게 줄입니다.
각각의 에셋 임포트는 다음에 따라 캐시됩니다.
위 네 가지 중에서 하나라도 변경되면 에셋은 다시 임포트됩니다. 그렇지 않은 경우 캐시 서버에서 다운로드됩니다.
캐시 서버를 활성화(아래 사용자로서 캐시 서버를 설정하는 방법 참조)하면, 여러 프로젝트에서 에셋 임포트를 공유(즉, 임포트 작업은 하나의 컴퓨터에서 수행하고 그 결과를 다른 곳과 공유)할 수 있습니다.
일단 캐시 서버를 구성하면 이 과정은 완전히 자동이며, 추가 워크플로 요구 사항이 없습니다. 단지 프로젝트 임포트 시간을 단축할 뿐 작업을 방해하지 않습니다.
캐시 서버를 설정하는 방법은 굉장히 간단합니다. 환경설정에서 캐시 서버 사용을 선택하고 로컬 컴퓨터의 Unity 에디터 에 캐시 서버 가 어디에 있는지 알려주면 됩니다.
캐시 서버 설정은 Mac OS X는 Unity > Preferences 에서, Windows와 Linux는 Edit > Preferences 에서 찾을 수 있습니다.
캐시 서버를 원거리에 있는 컴퓨터 대신 로컬 컴퓨터에 호스트하려면 Cache Server Mode 를 Local 로 설정합니다.
이 설정은 로컬 컴퓨터에서 쉽게 캐시 서버를 설정할 수 있게 해줍니다. 하드 드라이브의 용량 제한때문에 캐시 서버를 별도의 컴퓨터에서 호스트하는 것을 권장합니다.
프로퍼티: | 기능: |
---|---|
Cache Server Mode | 사용하려는 캐시 서버 모드를 선택합니다. 이 설정은 캐시 서버 사용을 비활성화할 수 있게 하거나 원격 서버를 지정할 수 있게 하거나 캐시 서버를 로컬 컴퓨터에 설정할 수 있게 합니다. |
Disabled(디폴트) | 캐시 서버를 사용하지 않습니다. |
Remote | 원거리 컴퓨터에 호스트된 캐시 서버를 사용합니다. |
Local | 컴퓨터의 로컬 캐시 서버를 사용합니다. |
IP Address (원격 전용) |
캐시 서버를 호스트하는 원거리 컴퓨터의 IP 주소를 지정합니다. |
Check Connection (원격 전용) |
원거리 캐시 서버에 연결을 시도할 때 이 버튼을 사용합니다. |
Maximum Cache Size (GB) (로컬 전용) |
컴퓨터의 스토리지에서 캐시 서버의 최대 크기를 기가바이트 단위로 지정합니다. 최소 크기는 1GB입니다. 최대 캐시 크기는 200GB입니다. 디폴트값은 10GB입니다. |
Custom cache location | 캐시를 저장할 위치를 지정합니다. |
Check Cache Size (로컬 전용) |
로컬 캐시 서버가 얼마나 많은 스토리지를 사용하는지 알아볼 때 클릭합니다. 이 작업은 프로젝트가 크다면 완료하는 데 시간이 조금 걸릴 수 있습니다. 산출이 완료되면 “캐시 크기가 불분명합니다.” 메시지가 캐시 크기로 대체됩니다. |
Clean Cache | 캐시의 콘텐츠를 삭제합니다. |
Unity는 로컬 캐시 서버가 커스텀 위치에 있고 그 위치가 사용 불가능해졌을 때 다음과 같은 경고를 표시합니다.
로컬 캐시 디렉토리가 존재하지 않습니다 - 캐시 폴더에 접속할 수 있으며 쓰기 권한이 있는지 확인하시기 바랍니다.
관리자는 캐시된 에셋을 호스트할 캐시 서버 컴퓨터를 설정해야 합니다.
다음과 같이 해야됩니다.
캐시 서버는 매우 큰 저장 용량을 가진 안정적인 컴퓨터에 설치되어야 합니다. 여러 버전의 임포트된 리소스를 저장하기 위해 프로젝트 자체의 크기보다 훨씬 커야 합니다. 하드디스크 용량이 가득 차면 캐시 서버의 성능이 저하될 수 있습니다.
제공된 .sh
와 .cmd
스크립트는 서비스로 서버에 설치 되어야 합니다.
캐시 서버는 원자적 파일 연산을 사용하기 때문에 언제든지 안전하게 끄고 다시 시작할 수 있습니다.
기본적으로 두 캐시 서버 프로세스가 시작됩니다. 레거시 캐시 서버는 Unity 5.0 이전 버전에서 사용됩니다. 새 캐시 서버는 Unity 5.0 및 이후 버전에서 사용됩니다. 서로 다른 두 캐시 서버의 설정, 활성화, 비활성화에 관한 자세한 내용은 아래의 캐시 서버 설정을 참조하십시오.
간단하게 스크립트를 실행하여 시작하면 레거시 캐시 서버는 8125포트에, 새 캐시 서버는 8126포트에 실행합니다. 또한 스크립트와 같은 디렉토리에 “cache”와 “cache5.0” 디렉토리를 생성하고 같은 곳에 데이터를 저장합니다. 캐시 디렉토리는 기본적으로 50GB까지 커질 수 있도록 설정되어 있습니다. 데이터의 크기 또는 위치 설정은 아래와 같이 커맨드 라인 옵션을 사용하여 변경할 수 있습니다.
./RunOSX.command --path ~/mycachePath --size 2000000000
또는
./RunOSX.command --path ~/mycachePath --port 8199 --nolegacy
다음의 커맨드 라인 옵션을 사용하여 캐시 서버를 설정할 수 있습니다.
--port
를 사용해야 합니다. 새로운 캐시 서버에만 적용됩니다. 디폴트값은 8126
입니다.--path
를 사용해야 합니다. 새로운 캐시 서버에만 적용됩니다. 디폴트값은 ./cache5.0
입니다.--legacypath
를 사용해야 합니다. 레거시 캐시 서버에만 적용됩니다. 디폴트값은 ./cache
입니다.--size
를 사용해야 합니다. 최대 캐시 크기를 초과하게 되면 최근에 사용되지 않은 파일은 자동으로 폐기됩니다.--nolegacy
를 사용해야 합니다. 그렇지 않으면 레거시 캐시 서버는 8125
포트에서 시작합니다.최상의 성능을 얻기 위해 임포트된 프로젝트 폴더 전체를 망라할 수 있는 충분한 RAM이 필요합니다. 또한 빠른 하드 드라이브와 고속 이더넷 연결이 가능한 컴퓨터가 가장 좋습니다. 하드 드라이브는 충분한 여유 공간이 있는 것이 더 좋습니다. 한편, 캐시 서버의 CPU 점유율은 매우 낮습니다.
캐시 서버와 버전 관리의 주요 차이점은 캐시된 데이터가 항상 로컬 시스템에서 재구성될 수 있다는 점입니다. 이것은 퍼포먼스 개선을 위한 단순한 툴입니다. 이러한 이유로 인터넷을 통한 캐시 서버의 이용은 좋은 방법이 아닙니다. 팀이 분산되어 있다면 각 지점에 별도의 캐시 서버를 설치해야 합니다.
캐시 서버는 Linux 또는 Mac OS X 컴퓨터에서 가장 잘 실행됩니다. Windows 파일 시스템은 캐시 서버가 데이터를 저장하는 방식에 최적화되어 있지 않고 Windows의 파일 잠금 문제는 Linux 및 Mac OS X에서는 발생하지 않으며 문제를 일으킬 수 있습니다.
캐시 서버는 자동으로 일정기간 사용되지 않는 에셋을 제거합니다(물론 해당 에셋이 다시 필요해지면 다음에 사용할 때 다시 만들어 집니다).
캐시 서버는 소스/버전 관리 시스템에서 쉽게 볼 수 있도록 설계되었기 때문에 Unity의 에셋 서버만 사용하도록 제한되지 않습니다.
Unity가 에셋을 임포트하려고 할 때 모든 소스 데이터의 MD5 해시를 생성합니다.
예를 들어, 텍스처는 다음과 같이 구성되어 있습니다.
캐시 서버에 저장되어있는 것과 다른 해시라면, 에셋이 다시 임포트됩니다. 그렇지 않으면 캐시된 버전이 다운로드됩니다. 클라이언트 Unity 에디터는 필요할 때만 서버에서 에셋을 가져옵니다. 에셋이 변경될 때마다 각각의 프로젝트로 보내지는 것은 아닙니다.
캐시 서버는 종속성에 관여하지 않습니다. Unity 에셋 파이프 라인은 종속성 개념을 다루지 않습니다. 그렇게 설계된 이유는 에셋간의 종속성 충돌 문제를 피하기 위해서입니다. AssetPostprocessor클래스는 에셋 임포터를 자신에 맞게 커스터마이징하는 일반적인 기법입니다. 예를 들어, .fbx 파일의 게임 오브젝트에 이름과 태그에 따라 MeshCollider를 추가할 수 있습니다.
또한, AssetPostprocessor
를 사용하여 종속성을 쉽게 도입할 수 있습니다. 예를 들어, 에셋의 텍스트 파일 데이터를 사용해서 임포트된 게임 오브젝트에 추가적인 컴포넌트를 더할 수 있습니다. 이것은 캐시 서버에서 지원되지 않습니다. 캐시 서버를 사용하고 싶다면 프로젝트 폴더의 다른 에셋에 대한 종속성을 제거해야 합니다. 캐시 서버는 포스트 프로세서의 종속성에 대해 아무것도 모르기 때문에 변경 사항을 전혀 모르고 캐시된 버전의 에셋을 사용하게 됩니다.
실제로, 캐시 서버에서 작업을 원활히 하기 위해 에셋 포스트프로세스를 실행할 수 있는 방법은 많이 있습니다. 다음을 사용할 수 있습니다.
이미 설정된 머티리얼을 변경하면 문제가 발생할 수 있습니다. 캐시 서버를 사용할 때 Unity는 머티리얼에 대한 레퍼런스가 유효한지 확인합니다. 그러나 포스트 프로세스가 호출되지 않기 때문에 캐시 서버를 통해 임포트된 모델에서는 머티리얼의 내용이 변경될 수는 없습니다. 따라서 캐시 서버에서 임포트하는 경우와 하지 않는 경우 다른 결과를 얻게 됩니다. 이것을 방지하려면 디스크에 이미 존재하는 머티리얼을 수정하지 않는 것이 최선입니다.
서버에 캐시되지 않는 일부 에셋 데이터가 있습니다. 스크립트 파일을 캐시하는 것으로 얻을 수 있는 점이 없기 때문에 서버는 이를 무시합니다. 또한 3D 모델링 소프트웨어(Maya, 3D Max 등)에서 사용되는 네이티브 파일은 어플리케이션 단에서 FBX로 변환됩니다. 현재 에셋 서버는 기본 파일과 임포트 프로세스에서 생성된 중간 FBX 파일 전부를 캐시하지 않습니다. 하지만 모델링 소프트웨어에서 FBX로 익스포트된 파일을 Unity 프로젝트에 추가함으로써 캐시할 수 있습니다.