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

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

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

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

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

간단한 예시는 AssetDatabase.ForceReserializeAssets 메서드에 대한 문서를 참조하십시오.프로젝트를 최신 버전의 Unity로 업그레이드할 때 특정 에셋 번들이 업그레이드되는 방법을 보다 효과적으로 제어해주는 메뉴 항목을 에디터에 추가하는 방법을 볼 수 있습니다

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

에셋 오브젝트

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

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

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

.prefab, .scene, .asset, .mat 등 Unity가 자체적으로 생성하는 일부 타입의 에셋 파일에는 이미 소스 파일에 직렬화된 데이터가 포함되어 있으므로 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을 사용하면 에셋 간에 종속성이 생성되므로 한 에셋이 수정되면 이에 종속된 다른 에셋이 다시 임포트됩니다.