Pre-Workshop Notes

--- tags: Workshop --- # Pre-Workshop Notes Topics and notes written down in preparation for the workshop. ## What do we want to achieve? What does success look like? What is the role of the asset manager? What outcome for users do we want to bring? Are we building a general data-block manager? (A: No, that is a related but different project.) People have vastly different ideas of what an asset system is for. ## Asset Types Besides "primitives" and "presets", there may be other types: * **Merged assets** * **Add-on defined asset types** Add-ons should be able to register custom asset types. The Asset Browser just needs some meta-data to be able to show it: Name, preview image, callbacks to draw the meta-data UI and to handle drag & drop (or "Apply Asset"). * **Non-Blender data** Users may often just want to access files from the asset browser that are not referenced by a Blender asset data-block. (Media files, import/export files, scripts, HDRIs, Matcaps, ...) * Option to show non-data-block assets? * **Settings presets** The current script based presets in Blender: Render settings, encoding settings, etc. * **"Generative" assets** Assets that you can select from the browser to paint grass, for example. Similar to selecting a brush, which may also select a tool (depending on our definition of a brush). Could be just preset assets (including the tool/operator name?) that reference an other asset, like a geometry node tree. Also, can we find better names than "primitives" and "presets"? ### Asset Types for a Specific Purpose Some assets are created for a specific purpose. E.g. a texture may be created for use as a paint stencil texture. How can the asset system know about this, and link/append/apply the asset the correct way based on that? (Note: For the asset view UI template, you can pass in filter settings, but that may not go far enough.) ## Internal Representation & Lazy Loading - LIB datablock handling can be extended to allow lazy loading, i.e. first produce placeholder data, then replace with actual asset data once the asset has been loaded. - LIB datablock to represent non-Blender data? I.e. another way to do the "virtual data-block". - URIs can be used to identify assets in a filesystem-independent way that's also extendible by add-ons. - More info in [Asset System: Data Storage, Reading & UI Access](https://hackmd.io/913I6EUpT2uWdFuRKiKl8A). ## Categories & Grouping Categorizing by ID types is too limiting (e.g. all node trees appear under "Shading"). For grouping of assets, catalogs or tags were proposed. Catalogs: A snapshot of filter settings (e.g. all materials with the tag "Eevee"), stored for easy access. With a special *Category Tag* (displays with the name of the category), an asset can be forced to be in a catalog. Assets can be visible in multiple catalogs, they are really just a snapshot of filter settings. Notes: * Showing many categories and catalogs in the left navigation bar is a space issue. A more compact solution would be preferred. * Other apps use a tree view to navigate asset types. * Asset Browser representation should be independend of hard drive hierarchy. * Best avoid multiple grouping systems (catalogs, tag selection UI as opposed to simple filtering by tags, directories, bookmarks, ...) Example categories: * Objects, collections, shading nodes, geometry nodes, ... * Poses * Brushes * Workspaces * "Script" presets * Add-on defined categories for add-on defined asset types Which term to use? What expresses the functionality the best? - Catalogs - Dynamic Folders - Something else? #### Navigation Depending on which kind of ways we provide to group assets, there may have to be some design additions for navigation. E.g. if we support displaying assets in the directory hierarchy, we may need buttons to go up the hierarchy, backwards, forwards, change the file path and the like (File Browser navigation). ## Creating assets "Mark Asset" and "Clear Asset" are confusing names. Might expose our technical definition of an asset too much (a data-block with asset metadata). "Add to Asset Library"/"Remove from Asset Library" instead? Should the operators be exposed in the context menu of editors? #### Asset "Pushing" Storing assets in a separate library. ## Asset Bundle * Review bundle [guidelines and specifications](https://wiki.blender.org/wiki/Reference/Release_Notes/Blender_Asset_Bundle). ## Terms and Definitions * Asset * Asset Library * Asset Repository * Asset System * Asset Browser * Asset View * Catalog ## Asset System and BPY Could be discussed outside of the workshop. ## Previews * Needed: Better ways to set custom ones. * Ton's suggestion: Previews from scene. Maybe a per-asset-library asset-preview.blend? * Which preview size can we afford? * How to deal with Retina vs. non-Retina screens? ## Asset Design Overview Document ## Other * **Custom sorting** * **De-duplication** Testers report it as problem that dragging in an asset always creates a new instance. Dragging in a material twice should make it use the same data-block. Technically difficult. Do we want this? Can good grouping or sorting systems help out (e.g. sort by a specific tag category?) * **Asset Placement** General placement tool * Enabled after dragging in asset? * **Paint tool?** * Paint geometry ("generative" asset types) * **Tag types** Normal string tags (e.g. "foo"), key-value tags ("foo:bar"), category tags ("category-name", updates when catalog is renamed). * ***Apply Asset* button** * **Material Editor?** Some people expect the Asset Browser to handle this. Out-of-scope, but an interesting topic. * **Extend Add (Shift+A) menu?** Quite important for the Node Editor. Useful for 3D View too. * **Workspace add menu** * **Asset Data-block deletion** What should happen if a data-block is deleted that is an asset? * **Metadata editing UI** Should there be a UI for users to add custom metadata fields? E.g. an author or license field. * **Default Metadata** Which default metadata should assets support and display in the UI? Author, description, tags, license, ... * **Blender Project** * **Icons needed?** * Asset * Category * "Open Containing Blend File" * **Revisioning** * Storing multiple revisions (and showing only the latest by default) requires relations between assets. * Relatively simple in a relational database, but requires more thought for data-blocks in Blender. * The same relation system could be used to add things like variants (like a "normal" and a "burnt" book).