에셋 간에도 의존성이 존재합니다. 유니티의 머티리얼은 사용되는 텍스쳐들의 주소를 알고 있어야 하고, 메쉬역시 머티리얼의 주소를 알고 있어야 합니다. 언리얼과 유니티는 이 과정에서 다른 컨셉을 갖고 있습니다. 쉬어가는 느낌으로 간단히 알아보겠습니다.
유니티
유니티는 에셋을 참조할 때 guid를 사용합니다. 프로젝트 설정의 에디터 파트에서 Serialization을 Text 모드로 사용하게 되면, meta 파일을 텍스트 편집기로 열 수 있습니다. 매우 정직하게 guid: xxxx... 로 표기되어있습니다.
이 메타파일은 텍스쳐의 메타입니다. 이 텍스쳐를 사용하게되면, 이 guid를 저장하게됩니다. 예를 들어 이 텍스쳐를 사용하는 RawImage 컴포넌트가 있는 씬을 텍스트 편집기로 열어보면 이 guid를 발견할 수 있습니다.
이 guid는 unique 하게 생성됩니다. 그리고 이 guid가 포함된 meta 파일을 삭제하게되면 구성해두었던 에셋간의 참조가 망가지게 됩니다. 협업 과정에서 meta 파일을 빼놓고 올리는 경우가 발생하는데, 그러지 않도록 조심해야합니다.
엔진단에서 참조된 에셋을 삭제하려고 할 때 주의를 주지 않습니다. 에셋 참조 인덱싱을 하고 있지 않아, 사용자가 어떤 머티리얼에서 사용되고 있는 텍스쳐를 삭제하려고 하더라도 엔진은 아무런 경고를 하지 않고 삭제해버립니다. 사용자는 나중에 그 머티리얼을 사용할 때가 되어서야 텍스쳐를 지우면 안되었었다는 걸 깨닫게됩니다. 버전 컨트롤 툴은 꼭 사용하시기 바랍니다.
언리얼
경로를 거의 그대로 사용합니다. 다만 파일을 삭제할 때, 역 참조관계를 검사할 수 있습니다. 유니티와 대조되는 기능입니다. 어떤 에셋을 지우려고 할 때, 로드된 에셋이 지울 에셋을 사용하고 있다면 참조 카운트를 계산해 어디에서 사용되고 있는지 알려줍니다. 프로젝트 내 모든 에셋을 찾을 수 있는 것은 아니고, 로드된 패키지 한정이지만 참조관계가 있는 에셋들은 비교적 가까운 경로에 위치한다는 점을 고려하면 유용할 수 있는 기능입니다.
텍스쳐를 삭제하려고 하자 하나의 머티리얼이 이 텍스쳐를 사용중이라며, 참조를 다른 텍스쳐로 대체할 것인지나 강제로 삭제할 것인지 물어봅니다. 에셋 레퍼런스와 메모리 레퍼런스를 모두 보여줍니다.
또, 리디렉터라는 시스템이 있습니다. 경로로 에셋을 관리하다보니 에셋을 옮기게되면 참조가 이어진 모든 에셋을 수정해야하는 비효율적인 상황이 발생합니다. 더구나 언로드 상태인 패키지가 있는 경우 완전히 변경사항을 적용하려면 패키지를 로드하고 수정한 뒤 저장하고 언로드해야합니다. 프로젝트가 방대해지면 에디터 사용성에 있어 속도가 현저히 느려질 여지가 있는 작업입니다. 이런 상황을 타개하기 위해 리디렉터를 사용합니다.
에셋을 다른 경로로 옮기면, 원래 자리에 리디렉터라는 객체를 생성해둡니다. 로드되어있는 에셋들은 변경되지만 언로드 되어있는 에셋들은 수정하지 않습니다. 나중에 패키지가 로드되었을 때, 원래 에셋이 있어야 할 자리에 리디렉터가 존재하고 그 리디렉터를 통해 옮겨간 에셋의 위치를 알 수 있게 됩니다.
https://docs.unrealengine.com/ko/ProductionPipelines/Redirectors/index.html
'ETC > Un[real]ity' 카테고리의 다른 글
언리얼 vs 유니티: 4. 사용하는 프로그래밍 언어 (2) | 2021.05.31 |
---|---|
언리얼 vs 유니티: 2. 에셋 관리 방식 (0) | 2021.05.31 |
언리얼 vs 유니티: 1. 우열을 가리기보다는 작업상 차이점을 중심으로 (0) | 2021.05.31 |