에셋 데이터베이스 워크플로 커스터마이즈

AssetDatabase 클래스를 사용해 에셋 파이프라인을 커스터마이즈하고 스크립트로 에셋에 액세스, 로드, 생성, 조작할 수 있는 툴을 생성하여 에디터의 작동 방식을 확장합니다. Editor 클래스이므로 스탠드얼론 빌드에서 런타임 시 해당 기능을 사용할 수 없습니다.

에셋 워크플로 커스터마이즈

AssetDatabase 클래스에는 Unity 에디터 자체와 동일한 방식으로 에셋에 액세스하고 작업을 수행할 수 있는 수많은 메서드가 있습니다. 에셋을 생성, 임포트, 삭제, 복사, 이동, 로드, 저장하고 에셋 데이터베이스를 검색할 수 있습니다.

즉, Unity의 에디터 스크립팅 및 에디터 창 커스터마이징을 사용하여 프로젝트의 에셋 워크플로에 간단한 조정부터 강력한 툴 및 커스터마이징까지 모든 것을 수행할 수 있습니다.

간단한 예시는 AssetDatabase.ForceReserializeAssets 메서드에 대한 기술 자료를 참조하십시오. 이 예시에서는 프로젝트를 최신 버전의 Unity로 업그레이드할 때 특정 에셋 번들을 업그레이드하는 방식을 더 세밀하게 제어할 수 있도록 에디터에 메뉴 항목을 추가하는 방법을 보여 줍니다.

사용 가능한 메서드의 전체 목록과 각 메서드에 대한 기술 자료는 AssetDatabase 스크립팅 API 페이지를 참조하십시오.

에셋 오브젝트

스크립팅 관점에서 Unity가 ‘에셋’이라고 간주하는 것은 프로젝트 창에 표시되는 것과 약간 다릅니다. 프로젝트의 Assets 폴더에 저장하는 파일은 에셋의 소스 파일이지만, Unity 에디터에서 작업하는 에셋 오브젝트와는 개념적으로 다릅니다. Unity는 에셋 파일을 임포트할 때 이를 처리하고 임포트한 결과(UnityEngine.Object에서 파생된 직렬화된 C# 오브젝트)를 생성합니다. 스크립팅 관점에서 Unity 에디터에서 스크립팅을 작성할 때 액세스할 수 있는 에셋은 이러한 임포트된 결과물입니다.

예를 들어, JPEG 또는 PNG 이미지 파일 같이 바이너리 파일로 시작할 수 있는 에셋은 UnityEngine.Object의 특화 유형인 C# 오브젝트로 전환됩니다. JPEG 또는 PNG 파일의 경우, 이는 UnityEngine.Object에서 상속하는 Texture 클래스의 직렬화된 인스턴스로 전환됩니다. 그런 다음 직렬화된 오브젝트 데이터는 Library 폴더에 아티팩트로 저장됩니다. 따라서 스크립트를 사용하여 텍스처 에셋에 액세스하면 원본 JPEG 또는 PNG 파일에 액세스하지 않고 원본 이미지 파일을 임포트할 때 생성된 직렬화된 C# 텍스처 오브젝트 버전에 액세스합니다. 임포트 프로세스 중에 Unity가 생성하는 .meta 파일은 원본 에셋 파일 바로 옆에 저장되며, 에셋의 임포트 설정을 포함하고, Unity가 원본 에셋 파일을 에셋 데이터베이스의 아티팩트와 연결할 수 있는 GUID를 포함합니다.

에셋 파일 및 아티팩트 파일 내부

Unity가 직접 생성하는 일부 에셋 파일 유형(예: .prefab, .scene, .asset, .mat)에는 소스 파일에 직렬화된 데이터가 이미 포함되어 있으므로 Unity가 생성하고 캐시하는 아티팩트 파일은 소스 파일과 매우 유사합니다. 프로젝트의 Assets 폴더에 있는 .mat 머티리얼 파일 같은 소스 파일은 사람이 읽을 수 있습니다(Asset Serialization Mode가 기본 설정인 Force Text로 설정되어 있는 경우). 이는 일반적으로 사람이 읽을 수 없는 텍스처나 오디오 같은 외부 소스에서 임포트한 바이너리 에셋 파일과는 대조적입니다.

에셋 파일에는 여러 직렬화된 오브젝트가 포함될 수 있으며, AssetDatabase 메서드로 스크립트를 작성할 때는 각 오브젝트가 하나의 ‘에셋’으로 간주될 수 있습니다. 예를 들어 .prefab 에셋 파일에는 여러 컴포넌트가 연결된 직렬화된 게임 오브젝트가 포함될 수 있습니다. 각 컴포넌트는 에셋 파일에서 오브젝트로 직렬화되어 있으므로 AssetDatabase 메서드를 사용하여 프리팹 에셋의 콘텐츠에 액세스할 때 에셋 파일 내의 컴포넌트 오브젝트는 하위 에셋으로 간주됩니다(아래에 자세히 설명).

임포트 프로세스 중에 생성된 직렬화된 오브젝트를 아티팩트라고 하며, Unity는 아티팩트를 프로젝트의 Library 폴더에 있는 에셋 데이터베이스의 임포트 아티팩트 캐시에 저장합니다. Unity가 프로젝트에 저장된 임포터 설정과 프로젝트 설정을 사용하여 소스 에셋에서 언제든지 다시 생성할 수 있으므로 아티팩트를 캐시된 데이터로 취급합니다.

Import Activity 창을 사용하여 프로젝트의 에셋에 생성된 아티팩트를 검사할 수 있으며, 이 창에서는 Unity가 생성하는 캐시된 특정 아티팩트 파일과 임포트가 발생한 시점, 소요 시간 등 기타 유용한 정보를 확인할 수 있습니다.

각 아티팩트 파일 이름은 파일 확장자가 없는 고유한 해시(GUID)입니다. Unity는 이러한 파일을 하위 폴더로 분리하며, 각 하위 폴더의 이름은 아티팩트 파일 이름의 처음 두 글자와 일치합니다.

이러한 아티팩트 파일은 바이너리 데이터를 포함하며 사람이 읽을 수 없습니다. 이러한 파일에는 에셋 데이터베이스에서 사용되는 데이터가 포함되어 있음을 파악하고 있는 것이 좋지만, Unity로 작업하는 동안 이러한 파일을 직접 보고 편집하거나 사용하지 않아도 됩니다. 대신 AssetDatabase 클래스는 에디터 내에서 에셋으로 작업하는 데 필요한 메서드를 제공합니다.

메인 에셋 및 하위 에셋

Unity는 동일한 에셋 파일 내에 직렬화된 오브젝트를 여러 개 저장할 수 있으므로 모든 에셋 파일에 메인 에셋이라는 개념이 있습니다. Unity가 머티리얼과 같은 단일 에셋이 포함된 에셋 파일을 생성할 때 메인 에셋은 항상 해당 단일 에셋입니다. 두 개 이상의 직렬화된 에셋 오브젝트가 포함된 다른 유형의 경우, SetMainObject 메서드에 달리 명시되지 않는 한 메인 에셋은 항상 파일에 추가된 첫 번째 에셋입니다.

하위 에셋이 특정 유형인 경우 에디터의 프로젝트 창에 하위 에셋이 표시되는 경우가 있습니다. 예를 들어 프로젝트 창에 ‘Space Frigate’ 모델이 포함된 이 FBX 에셋 파일을 보면 뷰가 확장되어 머티리얼과 메시가 하위 에셋으로 포함되어 있음을 알 수 있습니다.

에셋에는 다음과 같이 프로젝트 창에 표시되지 않는 하위 에셋 유형도 있을 수 있습니다. 예를 들어 위의 ‘Space Frigate’ 에셋 파일에는 실제로 프로젝트 창에 표시되는 세 개 이상의 하위 에셋이 포함되어 있습니다. 아래 스크립트에 나와 있는 것처럼 AssetDatabase 메서드를 사용하여 에셋 파일에 액세스하면 실제 에셋 수를 볼 수 있습니다.

using UnityEngine;
using UnityEditor;

public class Example : MonoBehaviour
{
    [MenuItem("AssetDatabase/InspectAssets")]

    private static void InspectAssets()
    {
        Object[] data = AssetDatabase.LoadAllAssetsAtPath("Assets/Space Frigate.fbx");

        Debug.Log(data.Length + " Assets");
        foreach (Object o in data)
        {
            Debug.Log(o);
        }
    }
}

이 경우 출력에는 임포트한 이 파일의 직렬화된 버전에 6개의 에셋이 포함되어 있다고 표시됩니다.

6 Assets
Space Frigate (UnityEngine.GameObject)
space_frigate_0 (UnityEngine.Material)
space_frigate_0 (UnityEngine.Mesh)
Space Frigate (UnityEngine.Transform)
Space Frigate (UnityEngine.MeshRenderer)
Space Frigate (UnityEngine.MeshFilter)

이는 게임 오브젝트, 머티리얼, 메시 데이터 자체, 임포트 프로세스 중에 Unity가 게임 오브젝트에 자동으로 추가한 각 컴포넌트(Transform, MeshFilter, MeshRenderer)가 각각 별도의 직렬화된 오브젝트로 간주되기 때문입니다. 따라서 이들은 에셋 파일의 하위 에셋이며, 에셋 데이터베이스 API에 관한 한 각각 별도의 에셋입니다.

에셋 임포트 순서

AssetDatabase 클래스를 사용하여 스크립트를 작성하는 경우 Unity의 임포트 프로세스 순서가 스크립트에 어떤 영향을 미칠 수 있는지 이해하는 것이 중요합니다. 그렇지 않으면 예상치 못한 결과가 발생할 수 있습니다. 순서는 다음과 같습니다.

1. 스크립트 에셋 임포트(.cs, .dll, .asmdef 파일)
2. 컴파일
3. 도메인 리로드
4. InitializeOnLoad 콜백
5. 모든 기타 에셋 임포트

스크립트는 항상 다른 모든 일반 에셋보다 먼저 임포트되고 컴파일됩니다. 에디터는 프로젝트에 커스텀 에셋 포스트 프로세서 또는 스크립트된 임포터가 있는지 알아야 하기 때문입니다. 그러면 에디터가 스크립트가 아닌 나머지 에셋을 임포트할 때 새롭거나 변경된 임포터 또는 포스트 프로세서를 사용합니다.

InitializeOnLoad 콜백은 프로젝트 시작 시 또는 스크립트 변경 시 일부 코드를 실행하는 데 사용되는 경우가 많습니다. 위 목록에서 볼 수 있듯이 이 콜백은 Unity가 도메인을 다시 로드한 후 에셋 임포트를 시작하기 전에 실행됩니다. 즉, 에셋에 액세스하기 위해 [InitializeOnLoad] 콜백을 사용하는 경우 현재 에셋 임포트 주기가 완료되기 전에 코드가 실행됩니다. 다음과 같은 예시를 확인할 수 있습니다.

• 처음 임포트하는 에셋의 경우, AssetDatabase.LoadAssetAtPath, AssetDatabase.FindAssets, Shader.Find, Resources.Load 같은 메서드는 해당 에셋을 아직 임포트하지 않았으므로 null을 반환합니다.

• 이미 한 번 이상 임포트한 에셋의 경우, AssetDatabase.LoadAssetAtPath, AssetDatabase.FindAssets, Shader.Find, Resources.Load 같은 메서드는 도메인을 다시 로드하기 전에 에셋을 수정한 경우 이전(오래된) 버전의 에셋을 반환합니다. 도메인 리로드는 일반 에셋 임포트 단계 전에 발생하기 때문입니다.

스크립트된 임포터, 에셋 프리 프로세서, 에셋 포스트 프로세서를 작성할 때는 특정 순서에 따라 다른 특정 에셋이 이미 임포트되었음을 코드에서 가정하지 말아야 합니다. 임포트할 때 Unity는 에셋을 유형별로 대기열에 그룹화합니다. 유형은 사전 정의된 순서로 임포트되지만, ScriptedImporter.GatherDependenciesFromSourceFile을 사용하지 않는 한 동일한 유형의 대기열 내에 있는 에셋은 임의 순서로 임포트됩니다. GatherDependenciesFromSourceFile을 사용하면 에셋 간에 종속성이 생성되므로 한 에셋이 수정되면 그에 의존하는 다른 에셋이 다시 임포트됩니다.