Asset Catalogs

    Similar to 集合, catalogs can be nested i.e. you can have a main catalog that contains several nested catalogs. For example, this allows you to have a catalog of assets for “Furniture” with sub-catalogs of “Tables”, “Chairs”, “Lamps”, etc…

    For more technical information, see .

    Example file system and catalog structures.

    There can be as many catalogs as you want, but an asset can be assigned to a single catalog at a time. This is similar to a file system, where a file is only in one directory (ignoring advanced things like symbolic links).

    Catalogs themselves can be nested and moved by dragging and dropping. Moving a catalog will not modify the assets it contains; they will simply move along to the new location of the catalog.

    Selecting a catalog in the Asset Browser will show all assets in that catalog and in child catalogs. So, in the preceding example, selecting will also show assets from Characters/Ellie/Poses/Head and Characters/Ellie/Poses/Hands.

    ../../_images/asset_browser-assign_catalog.png

    Assigning a selection of “Scale material” assets to a catalog.

    Tip

    You can assign an asset to the “Unassigned” catalog, this will remove it from any existing catalogs.

    Each catalog consists of a catalog path, a UUID, and a simple name. Normally you would only deal with the catalog path; the rest is for internal Blender use and/or for emergency situations.

    The path of a catalog determines where in the catalog hierarchy the catalog is shown. Examples are Characters/Ellie/Poses/Hand or Kitbash/City/Skyscrapers, which would result in the following catalog tree. The highlighted catalog has path .

    Example tree of asset catalogs.

    UUID

    Each catalog has a , which is normally hidden from the user interface (enable Developer Extras and the experimental Asset Debug Info option to see them). This is what is stored in the asset, and what determines the “identity” of the catalog. As a result, a catalog can be renamed or moved around (i.e. you can change its path), and all assets that are contained in it will move along with it. This only requires a change to the catalog itself, and not to any asset blend-file.

    Each catalog has an optional simple name. This name is stored along with the UUID in each asset. The purpose is to make it possible for humans to recognize the catalog the asset was assigned to, even when the catalog definition file (see below) is lost.

    Like the UUID, the simple name is normally hidden from the user interface. Enable Developer Extras in the interface preferences to make it visible in the Asset Browser.

    Which File to Write To

    Asset catalogs can be saved independently of the blend-file; the catalog editor has its own “Save” button.

    Catalog Definition Files (CDFs) are relatively simple text files, encoded in UTF-8. Each CDF consists of a version indicator, and a line of text per catalog. Each catalog line is colon-separated, of the form {UUID}:{path}:{simple name}.

    例子

    This is an example of a valid catalog definition file:

    Catalog paths follow the following rules:

    • Only as separator (no \; think less filesystem path and more URL).

    • Not empty (it’s required for a valid catalog).

    • No empty components (so not a//b; a/b is fine).

    • 非法字符: :, .