---
tags: Workshop
---

# Daily Write-up Friday, 28 May 2021

- [Thursday](https://hackmd.io/inagPQH0QR-rFfnoJhZg5Q)
- Friday: this document

### Start of workshop

*Attendees:* Brecht Van Lommel, Julian Eisel, Julien Kaspar, Pablo Dobarro, Pablo Vazquez, Sybren Stüvel, Vilhém Duha

Continued yesterday's discussion about specific use cases, see the [Collaborative Notes](/wpPacLTsQ_i8cs9GsTMjRw).

### Organisation & Navigation

Julian: Currently categories based on ID type, and that's not enough. For example, "Node Trees" need to be split up into shading & geometry nodes. Same for "Lights"; the combination of lights & HDRi lighting need to live together. Same for poses, poses for a character need to be grouped together and not mixed with other characters.

Pablo V: Indeed, for example, where do the "World" settings go? Environment? Lighting? Scene? Similarly, where do light probes go?

Julian: assets should go into some container, but may need to appear into multiple contaners at once.

Pablo D: assets should be able to go into multiple catalogs, and we should have nested catalogs. Opening a catalog shows the union of all assets in sub-catalogs.

Pablo V: the hierarchy view should maybe reflect the on-disk hierarchy of directories.

Julian: hierarchies are super useful, but can be hard to manage.

Vilhém: we could use tags for this.

Julian: Catalogs are not directories, but are a preset of filter settings. By dragging an asset into a catalog, a specific tag is added to that asset that refers to the catalog. This tag is visible, and coloured differently. Behind the scenes it uses some UUID to ensure renaming the category doesn't break this connection.

Pablo V: does this mean that user-definable tags aren't available?

Julian: yes, those are definitely useful, and can be used in those filter settings that a certain catalog searches for.

Pablo V: Having this category-specific UUID would also allow translating category names.

Sybren: explains categorised tags like `char:rex` to indicate the character.

Julian: can become redundant when we have catalogs, because those also already identify the character, the body part, etc.

Sybren: How would the pose library use the catalogs to select poses for a character?

Julian: Could use the catalog hierarchy + asset types.

Vilhém: Free-form tags could work, but setting some standards for how to tag is useful.

Pablo D: +1 for standards, to have some common tagging style that can be used by different asset libraries from different suppliers.

Julian: Yes, and regardless, the catalog system should work without such standards in place. Everybody agrees.

### Editing catalogs & organisation

Sybren: We have to discuss how to manipulate the origanisation of assets. Writing only to the current blend file means that the a library cannot be edited as a whole.

Julian: hierarchy on disk should not be reflected in how assets are displayed & navigated. Sometimes this is nice, so it could be an option, but the organisation system should not rely on this.

Vilhém: we could let the file browser show the on-disk structure of the asset library, and not make this a mode of the asset browser. Pablo D agrees.

Pablo D: users will complain if on-disk structure is not visible.

Pablo V: dropping images into a folder that I know is part of the asset library will be much faster than opening a new blend file, and dropping the images in there.

Pablo D: Blender could do this automatically when you drag images on top of it.

### Organisation of Folders & Assets

Pablo D: when user has selected a higher-level folder in the hierarchy, the browser should show all assets contained in that hierarchy.

Sybren: in that case, selecting assets should highlight the lowest-level folders these are stored in, otherwise you loose the sense of location of these assets.

Sybren: Where are the catalogs defined? Some may be user preference, but others could be part of the asset library. Maybe some would even be blend file specific.

Julian: Blender Kit could come with its own catalogs, and you may want to add to those via user settings as well.

Vilém: it should be stored per asset, which catalogs it is contained in.

Julian:
- Catalog defs could be stored in JSON file at top of asset library.
- Could also be stored in the blend file itself (could also thus be in the assets themselves)

Pablo D: we could have both, and show them in different sections.

Sybren: I think it may be nicer to merge these section.

Julian: explains the blender project idea (bottom of [T73366: Asset Manager “Basics”](https://developer.blender.org/T73366))

Julian: where do we show self-made dynamic catalogs?
- Between other sections (like in "Objects")
- In a separate top-level section (like "quick-searches" or "dynamic folders" or something similar)

Pablo D: we could pin a certain sub-tree of the hierarchy in a workspace, for example sculpting brushes in the sculpting workspace.

Sybren: we could use the categorised-tags for creating hierarchies, by saying all tags `char:....` are at the highest level, and then `bodypart:...` tags underneath that.

Pablo D: we could make the catalog system change properties of the assets to match what that particular catalog filters on.

Vilhém: question is when you decide something should go into a category. It's like a suggestion system, where dragging onto a catalog would make suggestions to match the other assets in that catalog.

Sybren: it's not guaranteed that all catalog filters are compatible, i.e. that there are combination of filters that are incompatible. As a suggestion system it would be powerful, but it shouldn't be the core way in which assets are organised.

Brecht: maybe Blender should just reject dragging on "too smart" catalogs. Not too nice, though.

Sybren: maybe separate simple hierarchy of folders (easily drag & drop) from dynamic catalogs.

Vilhém: we shouldn't discount simply searching for things, because that works very well. For example, Google.

Pablo V: the more ways you have to navigate / organise, the more you have to maintain. Maybe stick to file view & one other organisation; make it a mode that can be switched like the dope sheet vs. graph editor in the animation editor.

Sybren: Where do we store the tree of catalogs?

Brecht: I don't think it's an issue to edit various blend files to update these catalogs.

Vilhém: Assets could store the last catalog they were in, so that if the catalog for their catalog tag doesn't exist, it can be created on the fly.

Juian: Catalog would have:
- Name
- Path in hierarchy
- UUID to uniquely identify it, which is then used as "catalog tag"

Sybren: can we allow renaming tags across multiple blend files?

Brecht: maybe we should split up:
- Directory/file based organisation
- Smart filters that just provide a separate view on the assets.

Sybren: users shouldn't have to rely on OS file browsers to manage their assets. So, renaming catalogs should then rename directories as well.

Julian: you thus can't move assets from one directory to another, because that would imply writing to another blend file. Also note that the asset browser doesn't show individual blend files in a directory, but only the assets contained in those.

Pablo V: when relying on file structures we also can't show a single asset in multiple locations of the hierarchy.

Sybren: For non-blend files we could store the metadata in XMP sidecar files. This is generally liked.

#### Terminology
- **Catalog**: Saved filter settings, with a name, and possibly a parent catalog for hierarchical organisation. A single asset can appear in multiple catalogs. Catalog variations:
- Simple: search for one or more tags, which can be added to any asset that's dragged onto the catalog for inclusion.
- Complex: search for multiple tags, free-text search, boolean operators to also exclude things
- Scripted: Python code that accepts list of assets and returns filtered list, or simply returns a boolean (do/don't include) per asset.

- **Virtual Folder**: Hierarchical structure (name will probably change).
- *Not* the actual directory structure on disk!
- A single asset only has a single folder it is contained in.
- Browsing a higher level of the hierarchy shows all asset contained in subfolders.

#### Open Questions

- Storage of folder structure:
- [color=red] As directories on the filesystem.
- Very hard to move assets around when there are multiple assets per blend file.
- Moving assets breaks library linking.
- [color=green] Virtual folders
- Defined in config file at top of the asset library that lists the virtual folders.
- each virtual folder gets a symbolic name (or UUID), also defined in the config
- assets reference individual virtual folders by symbolic name
- assets remember last virtual folder path, in case the symbolic name is unavailable (for example when exchanging single blend file)
- virtual folders can be renamed without breaking library linking
- asset types can define their default virtual folder name, based on the asset type (e.g. the ID like "Object", or a more specific asset type derived from the ID like "Geometry Node Tree")

- Storage of assets:
- Browser is transparent to files, so all assets in all blend files in a certain directory are shown as one group.
- One blend file per asset (+ its dependencies) makes it possible to move assets to other places in the on-disk directory hierarchy. We *could* support this in such cases.
- Multiple assets in one blend file is certainly supported.
- An operator to export a data-block or asset to a separate .blend file could be added.
- Similarly, one that "explodes" the data-blocks or assets into individual .blend files.

- Moving assets between folders
- Simple with virtual folders, just change "virtual folder ID" of the moved assets (by drag & drop, for example).
- Assets in the current file as well as their containing virtual folders should be highlighted. Even when not in the *Current File* library. These assets can be edited.
- The assets should be gotten via the Main data-base then (mixed file & main reading).
- Moving assets that are not in the current blend file could be done by rewriting just one string property (the virtual folder ID).

- Storage of metadata of non-blend data, possible ways of doing it:
- LIB data-block that references the file
- XMP sidecar file (very common for photography, as it allows writing metadata for any file without having to know that file's structure)
- Metadata of the file itself (when the format is known, like EXIF or embedded XMP in JPEG and TIFF files).

- Importing of non-blend files:
- Outside of Blender, put into an asset library folder, then perform a "synchronize" or "import" step in Blender itself to make them available as assets.
- Drag the files onto the asset browser, and have Blender copy them to an appropriate location inside the asset library.