Search Unity

새로운 에셋 임포트 파이프라인: 에셋 임포트 속도를 높이는 견고한 시스템

, 11월 7, 2019

2019.3 버전부터 신규 프로젝트에 새로운 에셋 임포트 파이프라인이 기본적으로 적용되어 더욱 신속한 플랫폼 전환 및 임포트를 위한 기반을 마련합니다. 또한 유니티는 대형 프로젝트를 위해 에셋 파이프라인의 규모를 더욱 확장하고 있습니다. 이번 포스팅에서는 새로운 개선 사항 및 유니티를 이끄는 원동력에 대해 자세히 읽어보실 수 있습니다.

프로젝트에 새로운 에셋을 추가하더라도, 에셋 임포트 파이프라인이 해당 에셋을 발견하여 임포트하기 전까지는 실제로 프로젝트에 포함되지 않습니다. 따라서 에셋 임포트 파이프라인은 프로젝트 상태를 올바르게 진단하고, 사용자가 여러 API를 통해 상태를 쿼리할 수 있도록 돕습니다.

유니티는 더욱 견고하고 확장 가능한 접근 방식을 위해 2017년에 에셋 임포트 파이프라인을 다시 작성하기 시작하였으며, 그 과정에서 사용자들이 보고한 다양한 문제를 해결하기 위해 노력했습니다. Unity 2019.3(현재 베타로 제공됨)에서는 새로운 에셋 임포트 파이프라인(에셋 임포트 파이프라인 V2)이 신규 프로젝트의 기본 설정으로 적용될 예정입니다. 기존 프로젝트의 경우 새로운 에셋 임포트 파이프라인으로 업그레이드하여 새로운 시스템을 활용할 수 있습니다.

아래에서는 새로운 파이프라인을 개발하게 된 이유에 대해 알아봅니다. 특히 유니티는 새로운 에셋 임포트 파이프라인으로 업그레이드하면서 스크립트를 다시 작성하지 않아도 새로운 시스템과 기존 API가 호환되도록 제작했습니다.

임포트 시간 단축

일상적인 개발 주기에는 많은 워크플로가 포함됩니다. 유니티는 해결에 가장 오랜 시간이 소요되는 문제들을 식별하고 그에 따른 솔루션을 적용했습니다.

에셋 임포트는 시간이 오래 걸릴 수 있는 작업이며, 소스 데이터를 Unity 에디터 또는 플랫폼에서 활용할 수 있는 형식으로 변환하는 것은 단순한 과정이 아닙니다. 예를 들어 복잡한 3D 모델을 임포트하려면 기본적으로 많은 계산이 필요하며, 애니메이션이 추가되면 훨씬 더 많은 시간이 소요될 수 있습니다.

이 문제를 해결하기 위해서는 3가지 핵심 개념을 살펴보아야 합니다.

임포트 결과

에셋 유형 대부분은 Unity에서 소스 파일로부터 데이터를 변환해야 하며, 이는 프로젝트의 타겟 플랫폼에 따라 달라집니다. 그 결과는 PVRTC, ASTC 또는 ETC 등 호환 가능한 GPU 포맷에 따라 다양합니다.

그 이유는 대부분의 파일 포맷이 스토리지 공간을 절약하는 데 최적화되어 있는 반면, 게임 또는 기타 실시간 애플리케이션에서는 에셋 데이터가 CPU, 그래픽스 또는 오디오 하드웨어 등의 하드웨어에서 즉시 사용할 수 있는 형식이어야 하기 때문입니다.

예를 들어, Unity가 PNG 이미지 파일을 텍스처로 임포트하는 경우, 런타임에서는 원본 PNG 포맷 데이터를 사용하지 않습니다. 대신 텍스처가 임포트될 때 Unity는 프로젝트의 Library 폴더에 다른 형식으로 이미지의 대체 버전을 만듭니다. 이 임포트된 버전은 엔진에서 텍스처 클래스에 의해 사용되며, 실시간 디스플레이를 위해 GPU에 업로드됩니다. 이를 임포트 결과라고 합니다.

결정론적 분명성

임포트할 때 서로 다른 하드웨어를 사용하더라도 동일한 임포트 결과가 도출되어야 합니다. 주어진 입력 사항에 대해 동일한 결과가 도출되도록 하는 방법론을 결정론적 분명성(Determinism)이라고 합니다.

종속성 추적

에셋 임포트 파이프라인은 각 에셋의 모든 종속성을 추적하며 모든 에셋의 임포트된 버전의 캐시를 보관합니다. 에셋의 임포트 종속성은 임포트 결과에 영향을 미칠 수 있는 모든 데이터를 말합니다. 즉, 에셋의 임포트 종속성이 변경되는 경우 임포트된 에셋의 캐시된 버전이 최신 상태가 아니게 되며, 변경 사항을 반영하기 위해 해당 에셋을 다시 임포트해야 합니다.

새로운 에셋 임포트 파이프라인

상황에 따라 임포트 시간이 오래 걸리는 경우가 있습니다. 유니티는 신규 프로젝트 임포트신속한 플랫폼 전환이라는 두 가지 워크플로를 통해 문제를 해결했습니다.

신규 프로젝트 임포트

프로젝트를 처음 설정하는 경우에는 Library 폴더가 삭제된 것과 동일한 상태입니다. 즉, 에셋 임포트 파이프라인에 의해 에셋 폴더의 모든 에셋이 나열되고 임포트되어야 합니다. 이는 특성상 비용이 많이 드는 작업입니다. 하지만 임포트 프로세스가 결정론적 분명성을 띠며 여러 컴퓨터에서 안정적으로 작동하도록 하면, 소스 에셋 및 임포트 결과의 크기에 따라 임포트 결과를 얻는 데 걸리는 시간을 수백 배까지 단축할 수 있습니다.

따라서 새로운 Unity Accelerator를 사용하여 클라우드를 통해 연결된 모든 사용자들의 임포트 결과를 캐시하고, 사용자 개인이 복잡한 프로세싱을 거치는 대신 서버에서 직접 임포트 결과를 다운로드할 수 있도록 합니다.

신속한 플랫폼 전환

Unity 2019.2(기존의 에셋 임포트 파이프라인 사용)까지 Library 폴더는 전역 고유 식별자(GUID)를 파일 이름으로 사용하는 에셋으로 구성되었습니다. 따라서 플랫폼 간 전환이 이루어지면 Library 폴더의 임포트 결과가 무효화되며, 그로 인해 플랫폼을 전환할 때마다 다시 임포트해야 합니다.

에셋 임포트 파이프라인 V1

플랫폼 간 전환을 여러 번 해야 한다면 프로젝트 크기에 따라 이러한 과정에 하루에도 수 시간이 소요될 수 있습니다.

컴퓨터에 각 플랫폼마다 프로젝트의 복사본을 저장하는 것과 같은 나름의 해결책을 사용할 수도 있지만, 그 방식은 확장성이 떨어집니다.

새로운 에셋 임포트 파이프라인에서는 GUID와 파일 이름 간의 매핑이 삭제되었습니다. 특정 에셋의 종속성이 추적되기 때문에 모두 한꺼번에 해시 처리하여 에셋의 임포트 결과에 대한 수정 버전을 만들 수 있습니다. 그러면 에셋마다 여러 수정 버전을 만들 수 있으며, 그에 따라 GUID와 파일 이름 간 매핑을 적용하지 않아도 되며 서로 다른 구성에서 모두 활용할 수 있는 임포트 결과를 얻을 수 있습니다. 결과적으로 플랫폼 간 전환이 이루어질 때 플랫폼에 따른 임포트 결과가 이미 존재하도록 하여, 에셋 임포트 파이프라인 V1보다 훨씬 빠른 속도로 플랫폼 간에 전환을 수행할 수 있습니다.

에셋 임포트 파이프라인 V2

잠재적 단점

사용자가 에셋을 수정하면 Unity가 여러 신규 파일을 생성하여 디스크의 스토리지 공간을 더 많이 차지하게 됩니다. 따라서 이 문제를 해결하기 위해 에디터가 재시작될 때 사용되지 않는 임포트 결과를 삭제하도록 했습니다. 또한 플랫폼별 최신 임포트 결과를 추적하여 신속한 플랫폼 전환이 이루어지는 동시에 오래된 임포트 결과는 삭제되고 저장 공간을 더 확보할 수 있도록 했습니다.

새로운 에셋 임포트 파이프라인으로 업그레이드하는 방법

새로운 에셋 임포트 파이프라인은 Unity 2019.3 베타에서 사용할 수 있습니다. 기존 프로젝트가 있는 경우, 에디터의 프로젝트 설정(Project Settings) 을 사용하여 새로운 에셋 임포트 파이프라인으로 업그레이드할 수 있습니다.


버전 2를 선택하면 이제부터 해당 프로젝트에서 새로운 에셋 임포트 파이프라인을 사용할 수 있습니다. 프로젝트를 재시작하면 에셋이 새로운 에셋 임포트 파이프라인 코드를 사용하여 다시 임포트됩니다. 이렇게 하면 Library 폴더를 지우지 않고도 지운 것과 같은 효과를 낼 수 있습니다. 에셋 임포트 파이프라인 V2로 전환하면 V2가 자체 폴더 구조를 생성하여 임포트 결과를 저장하기 때문에 기존 에셋 임포트 파이프라인의 임포트 결과가 삭제되지 않습니다.

사용자가 Unity 2019.2 또는 이전 버전에서 생성한 프로젝트는 여전히 기존 에셋 임포트 파이프라인을 사용하도록 기본 설정되어 있습니다. 이러한 프로젝트를 Unity 2019.3에서 처음으로 실행하면 새로운 에셋 임포트 파이프라인으로 업그레이드할 수 있는 옵션이 제공됩니다. 이를 거절하면 프로젝트가 계속해서 기존의 에셋 임포트 파이프라인을 사용하게 됩니다. 또한, 선택된 버전이 프로젝트의 EditorSettings.asset 파일에 저장되므로 버전을 관리할 수 있습니다.

새로운 에셋 임포트 파이프라인으로 생성한 신규 프로젝트

Unity 2019.3 이후 버전에서 신규 프로젝트를 생성하는 경우 새로운 에셋 임포트 파이프라인이 기본 적용되어 사용자가 생성하는 모든 신규 프로젝트에서 사용됩니다.

향후 개선 사항

유나이트 코펜하겐 2019에서 코어 R&D 팀이 두 개 세션을 진행했습니다. 제가 진행한 세션은 이 블로그에서 소개한 주제와 관련된 개괄적인 내용과 에셋 관리 전략을 소개합니다. 더불어 조나스 드루센(Jonas Drewsen)은 에셋 파이프라인의 확장 가능성을 높이고 프로젝트 안정성을 보장하는 향후 기능 업데이트를 소개했습니다.

Unity 2019.3 베타 체험

Unity 2019.3 베타를 설치하여 새로운 에셋 임포트 파이프라인을 사용해 보고 포럼을 통해 소중한 의견을 공유해 주세요. 의문 사항이 있다면 Twitter를 통해 연락 주셔도 됩니다.

20 replies on “새로운 에셋 임포트 파이프라인: 에셋 임포트 속도를 높이는 견고한 시스템”

Sadly, at least part of the initial import is still done single-threaded, and – in the case of *.blend files – by firing up a process (!) for each imported file. For a project with roughly 300 *.blend-files weighing in at 200 MB, the editor’s import time is about 2 minutes, with simple batching this time drops to less than 10 seconds.

A very simple solution for the possible downside “storage space” is to use compression – even for image-heavy projects, the “Artifacts” folder compresses remarkably well (3-4x with lz4).

Switching versioned branches is part of my daily work too. Is the new pipeline able to speed this up? My first guess is it will not because this would mean it needs to keep imported data of files that do not exist for a period of time (different branch) unless I’m missing something.

Thanks for the work and blog-post on the import pipeline!

I have a question about “remove unused Import Results when Unity restarts”. I don’t fully understand this. When becomes an import result unused? Is this related to deleting assets from the Assets directory and the import results weren’t deleted in V1? Or is there some clever logic that even detects “this target platform specific import result wasn’t used for 28 days, I need to delete this now!”?

Yep, spam comment above again, because you still havent bothered to put a spam filter on comments section of blogs despite these being publically facing. So what, you want the outside world to see unity as a company that cant even manage spam? Add a filter already, you have one on the forum, implement one here.

Thanks for your feedback, Isaac. We do have a spam filter in place and are actively working to improve. I will be removing this spam comment and, in turn, your reply.

I really appreciate you’re trying to optimize loading speeds. Workflow speed has always been a big selling point for me. I have been a bit worried about some design-decisions last years, such as including too many packages per default on new projects, increasing loading times and complexity, and cluttering my assets view with packages. I prefer the possibility to start from a clean state, where I’m in total control, which used to be the case.

Do you see any possibility of Unity reducing project file size and file count in the future? I’ve always been a bit baffled by how a simple project with a few textures and models suddenly take up 3 Gb and include 30 000 files, making it time-consuming to backup in e.g. Dropbox.

It seems like textures occupy huge amounts of space, which I can understand if they’re re-generated as a less compressed format. However, I don’t really understand how the file count can grow so high, even if I count one extra meta file per asset.

Do you think it would be possible for Unity to store textures in a format that take up less space, at least during development? And find another way to save meta-data to assets without having to create so many files?

I understand the complexity of changing an existing system, just wanted to let you know my thoughts on workflow optimization as a long-time Unity user.

Hi hannes, you should only backup the Assets, Packages and ProjectSettings folders, and possibly use GIT, instead of dropbox

Will this affect the “Local Identifier In File” GUID? We use that property to track the persistant GUID of each GO (using the Transform’s GUID).

If so, will Unity expose access to a more robust persistant GUID system for us to use?

It will not affect the behaviour of local identifier in file.

That said Unity 19.3 now has GlobalObjectIdentifier which is very useful for uniquely identifying a specific object with a stable persistent ID.

Once a version is released, only bugfixes are added to the version. We don’t backport new features.

Hi Warren,
iOS 9 market share worldwide has been shrinking to such a low level that it doesn’t make sense for us to continue supporting some optimizations & workarounds that were in Unity for this specific version. We can clean up the code and focus our attention to the newer versions.

Comments are closed.