Daily Write-up Monday, 31 May 2021

--- 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.