---
# System prepended metadata

title: 'Daily Write-up Monday, 31 May 2021'
tags: [Workshop]

---

---
tags: Workshop
---

# Daily Write-up Monday, 31 May 2021

- [Friday](https://hackmd.io/YJRN7ZLmTo6OI43-btMucg)
- Monday: this document


### Virtual-Folders & Catalogs

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

* Virtual-Folders can be a hierarchy that is separate from how files are stored on disk, catalogs are filtering presets that can be stored hierarchical as well. See Friday's write-up for details.
* Better name needed, at least for *Virtual Folders*
    * "Folders" is commonly used for actual file storage on disk (or in online storage), would be confusing to use that term for something that is exactly not that.
    * Better to have a clearly different term.
    * Some ideas were discussed. Some of the 
* Decision: For now we'll use *Catalog* (used to be *Virtual Folders*) and *Dynamic Catalog* (used to be just *Catalog*)
* We'll only support simple catalogs for now, so only filter by asset type, tags and name.
* Should use "Catalog" (American spelling), not "Catalogue" (British spelling).

### Online Service Migration

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

* An online service like BlenderKit should be able to plan the migration process, or even start it when 3.0 is out.
* Ideally 3.0 already has basic online asset library support.
* Mostly needed for BlenderKit: An API function to call "Mark Asset" on any given data-block.
* Also: A API function to set the custom preview from an image file and a way to batch convert assets.
* It should be relatively easy to do the migration to the Blender Asset Browser then.
* Some features may be lost for the start, like the tooltip that shows the asset details in BlenderKit.

### Asset Pushing

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

* Distinction between:
    * Already being in the library and wanting to add new assets.
    * Being outside of a library and wanting to copy an asset to the library.
* The latter needs to deal with dependencies.
* Pablo: How does this work with brushes?
    * Julian: 
* Discussion digressed, to be continued.
  
### Asset Identifiers/References

*Attendees:* Andrew Peel, Julian Eisel, Julien Kaspar, Pablo Dobarro, Sybren Stüvel, Vilhém Duha

* The  switcher needs to store asset references somehow
* UUIDs could solve most issues with identifying/referencing assets 
* Possible Asset identifiers:
    * Path of the asset file + asset name.
    * URIs (especially useful for online asset libraries)
    * UUIDs
    * Combination (e.g. URI consisting out of base URI and a UUID hash, like `library://SpriteFright/char/rex/rex_poses_approved.blend/Actions/RexSmile?uuid=ca335747-8487-496b-ab33-e4bb5259abb0`)
* To identify an asset, we also need to know which library it comes from
    * Can we keep this local somhow
* Decision:
    * Use a URI with the asset library identifier plus the relative asset path inside the library.
    * UUIDs tend to break too much. We can add them later still with a solid implementation.
    
*Attendees:* Bastien Montagne, Brecht Van Lommel, Julian Eisel, Sybren Stüvel

* Collections and dynamic collections design was discussed and presented. 
    * Generally agreement is that the design seems useful and can work.
    * We need to present this to Ton, also to decide on some technical questions (mainly: can we touch an external .blend file to change a property or should we not do this?)
    * Some pictures for a short presentation will be prepared.
* How can favorites be stored?
    * Initial idea was to just store a boolean/flag in the asset metadata, that won't work since you'd want this to be stored for you personally.
    * So favorites have to be stored locally, e.g. like or as part of the Preferences.
    * That requires some kind of config that stores asset identifiers.
* *Last Used* assets (dynamic catalog?)
    * Would be nice to have as well, can use the same storing mechanism.
    


### Deduplicating Assets

*Attendees:* Andrew Peel, Julian Eisel, Julien Kaspar, Pablo Dobarro, Sybren Stüvel, Vilhém Duha

* Deduplication seems important to users: If they drag the same material on multiple objects, they don't want the material to be duplicated. That just adds too much memory.
* Not simple to solve, it relies on a way to identify assets (see above)
* Store the URI in the dragged in asset, until it was modified.
    * Depsgraph or undo have to handle this after modifications.
    * Plus, check users of the data-block if they should be "untagged"/"unlink". (So changing a texture used by a material will also remove the "link" to the source asset.)
* Use URI to identify assets that were dragged in already.

    
### Initializing the Default Brush Library

*Attendees:* Andrew Peel, Julian Eisel, Julien Kaspar, Pablo Dobarro, Sybren Stüvel, Vilhém Duha

* Plan is to dynamically create the brush library, so the brushes are created from code if not present.
* Pablo: If we dynamically create the library, could it break the existing library somehow?
* Julian: No, it would only add them if there are no brushes in the expected place (directory doesn't exist, or there's no .blend with brush assets).
    * Maybe there should be an operator to reset the default brushes (ensures they are there).
    * Or should the default brushes be read-only? (Don't allow moving, deleting or renaming.)
    * Decision: Make them read-only.