--- tags: Workshop --- # Daily Write-up Tuesday, 1 June 2021 - [Monday](TODO://hackmd.io/inagPQH0QR-rFfnoJhZg5Q) - Tuesday: this document ## Terminology * *Mark Asset*, *Clear Asset* * Julian doesn't like the names, we might confuse artists with our technical definition of an asset (the fact that data-blocks need to be explicitly tagged as assets), artists use the term *asset* very loosely. * Would be nice to instead describe the action in terms of building an asset library. Like "Add to Asset Library". * Issue is that this doesn't describe well that the asset stays where it is, i.e. is not copied to an external asset library. * Julian doesn't see terms significantly better than *Mark* and *Clear Asset* either, it's a difficult one. * They are not symmetrical operations, clear asset deletes all asset metadata the user might have set up (hence *Clear*, not *Unmark*). * We could keep the metadata stored in the ID, so clearing becomes non-destructive. Sybren is not a fan of that though. * Decision: For now use *Mark as Asset* and *Clear Asset*. * We can still try to come up with something better, ideas welcome. * *Asset Library* * Directory with .blend files (one or multiple ones). Recursive (includes subdirectories) * Virtual Library * No single .blend file libraries for now. * The UI should always clearly differntiate between asset and data-block libraries. * *Repository* * Typically online data-bases, or an SVN repository. * Can be made available to Blender as Asset Library. * Naming scheme * Julian suggests the terms used and their framing have big impact on how artists perceive the usability, and on the user experience generally. * Relatively technical terms like "Repository" are nice to have avoided, to avoid the framing of a technical UI. * *Tool* vs. *Tool Preset* vs. Brush * Pablo is opinionated that with the new brush management workflow, tools become redundant and you'd only effectively switch tool presets. Tools wouldn't exist in the UI anymore then, so we could just as well call tool-presets/brushes to be the tools. * Was disussed a bit, others don't really agree, but Pablo thinks this is very important in his big picture for sculpt/paint as well as 3D editing in general. * It's not in scope of the asset project to redefine the tool workflow, this is more for the planned usability workshop. * Therefore it doesn't make much sense to just assume a design change will happen. * Meanwhile we'll keep using the term "Brush" for what we imagine presets for sculpt/paint tools will become. * The new brush workflow is not a target for 3.0 anyway. ## Asset Bundle * Pablo: Differentiate between 3 things: * Standard library * Default assets * Demo files * Standard library: * Could be made available similar to `bpy.data`. * Assets made for creation of content, would not go into the final result as-is. * Includes Brushes, base meshes (e.g. sculpt base meshes, zipper, ...), base network utilities (e.g. old modifiers), ... * Default Assets: * Assets that can become part of the final render as-is. * E.g. characters, trees, furniture, lighting setups, shaders, ... * Julian: Where are workspaces and studio-lights, matcaps, etc going to be stored? * Should likely become part of the standard library. ## Network directories * Has to be done asynchronosly * Otherwise waiting times are a deal-breaker. * Julian: As long as the initial directory and library reading is asynchronous, it should be fine. We don't re-read files unless there's an explicit refresh. ## Blender 3.0 Outlined in an own document: - [Asset Workshop: 3.0 Targets](/zYhe7PnaSeuwVrcdg5aTtQ) ## Evalute Definition for the Success of the Workshop - The success of the workshop is defined as: - Get on the same page in regards to the product vision. - User stories were covered to get a clear idea about the scope of the project. - Evaluate and improve the Asset Browser design with all people involved and a number of stakeholders, and have their approval. - Mostly there. Some more stakeholders should give feedback still. - Define targets for the 3.0 release. - Sign off technical specifications. - Ton signed off a good chunk of the catalog system. - We discussed a number of things for the Python API. - But: No proper design review of technical specifications. - We have a clearer picture now and can design the specifications better. - Sybren: we should come up with a detailed design for asset data flow, so how assets are written to which blend file, that takes into account Ton's view on how this should be done. - Asset "pushing" not covered, but besides that yes.
Last changed by  
 
Asset Browser
Asset browser project team
368

Read more

Task List Harley :)

Main Topics Generally the idea is that Harley helps on small, preapproved tasks (which tend to be neglected) falling into the following categories. Triaging Assets:Asset browser polishing. Helping out with brush assets. UI module: UI project organization (classifying reports, organize workboard, organize meetings, etc.)

3/15/2023
Asset URIs

file:///home/guest/Blender/Assets library://MyMaterials/interior/couch.blend/Materials/leather addon://blender-cloud/HDRIs/5d08c2cb804c3eb269e42a43

3/7/2023
Asset System: Asset Library Loader

Moved to T103188: Asset System: Asset Library Loader. All loader methods should be expected to run in a thread. Loaders may instantiate and use other loaders. E.g. a CurrentFileAssetLibraryLoader. class AbstractAssetLibraryLoader { /** The asset library to load into. */ AssetLibrary &library_; public:

12/13/2022
Asset Types & Traits

Resolving a definite type for an asset is difficult. Instead, the following proposes a way to define type related characteristics (traits) of an asset, which can then be mapped to precise behavior. What is the Type of an Asset? The type of an asset is a vague concept. Some considerations: Is it the ID type? If so, we wouldn't be able to tell apart a compositor node tree from a geometry node tree. Or a mesh object from a curve object. So just ID type often isn't granular enough. Nor does that cover assets that are not IDs (files, USD assets, presets, etc.). How much should it matter to the user if an image is already a Blender data-block or just an image on the hard drive? Or if an object is already native Blender data or will go through an importer after dragging in. What matters most is the object itself, the format it happens to be stored in is irrelevant to a degree. An image could be a reference image, a bump map, a stencil texture, ... The fact that an asset is an image may not matter much to the user, what the image represents and thus what it can be used for does. So the proposal is to avoid the concept of a single static type. Instead, differentiate assets using type related characteristics, so called traits.

9/12/2022
Read more from Asset Browser
Published on HackMD