--- tags: Workshop --- # Daily Write-up Thursday, 27 May 2021 - Thursday: this document - [Friday](https://hackmd.io/YJRN7ZLmTo6OI43-btMucg) ### Start of workshop *Attendees:* Andrew Peel, Brecht van Lommel, Francesco Siddi, Julian Eisel, Julien Kaspar, Pablo Dobarro, Sybren Stüvel, William Reynish *Notulist:* Sybren - Julian presents the agenda for the workshop. - Status and basic history of the project: - Julian took over the general Assets project a year ago - First big goal was to get simple asset browser for local data-blocks in Blender as soon as possible. Aimed at 2.92, but lots of polishing & fixing was needed, plus it turned out to feel too basic for Julian's expectations. - In February things changed a bit, as the Asset Browser was one of three 6-8 week projects. Sybren and Francesco got on board, Campbell helped with some implementation. - New focus was the pose library, which helped in getting the asset browser used in production at the Blender Animation Studio. - Asset browser still needs polishing & some extra functionality to be release-ready. - Future of asset browser seen as an unknown target, until it was decided to have it in Blender 3.0. - The release of Blender 3.0 might be delayed by a few months, giving us the time to be more ambitious. - This workshop is the beginning of the new phase for the Asset Browser, to have clearer goals for Blender 3.0 and beyond. - Sybren gives quick overview of poselib (link to blog post) - William asks whether the poselib is add-on or core in Blender. - Sybren: Pose library is implemented partially as add-on and partially as C in Blender. This makes it possible/simple to have another add-on for a different UI or to include different things in the pose asset. - William: how easy/clear is the poselib now, when you just open Blender without anything set up already? - Sybren: It's set to the Current File library, so should be ready to go by selecting some bones and clicking the "Create Pose Asset" button. - Julian gives a sneak peek at a WIP version of the blog post (more later). #### The success of the workshop - The success of the workshop is defined as: - Get on the same page in regards to the product vision. - 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. - William: we should talk about which user stories to support. If we reach consensus here, other decisions will follow easier. - Julian agrees, has found over the last year that everybody thinks it's obvious how things should work & what they should look like, but when digging deeper people seem to come from vastly different angles (thus actually having different expectations). - 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. - Brecht: according to the schedule, the design should be presented to Ton on Monday. This could be tricky when he's not part of the overall discussion. Maybe this should be done earlier, so that we have time to address any concernerns he raises. Others agree, especially when it comes to writing to other files. #### General introduction of the design - Asset Management is very broad, from a permission system for a studio, via a full-blown revision/variant/version system with overrides, to an online paid-for repository of scene props. - This project is focused on just an Asset Browser: *A streamlined, extensible UI for creating, editing, using and sharing asset libraries.* - Julian shows demo videos from the upcoming blog post, showing off how assets could be used/consumed: - Dragging assets into scene, which show a bounding box while dragging and snap to surfaces. In his opinion, the *snapping placement & orientation* tool should become a basic Blender tool and not be specific to assets - Andrew Peel's "Particle Painter" prototype, which allows dragging a "particle asset" onto a mesh and then paint where on the mesh those particles will appear. - His work also allows you to drag a door onto a wall, which carves a hole into the wall for the door. Uses boolean modifiers. - Julian: this kind of dynamic paint tools & rich addition of objects is an enticing goal for the asset browser as well. - Andrew: At least it should be possible for add-on developers to create such functionality. - Julian: This needs a richer concept of what is an "asset" than just a single data-block. Requires something like having a call-back function defined on assets, or on some definition of asset *types*. - Julian: dragging an asset into the scene could already (download &) load the asset, without actually appending it to the current blend file; this could be used to actually show the asset while dragging as soon as it's available. - Julian shows how to create assets: - In the outliner, right click and choose "Mark As Asset". Simple to use, this also automatically creates the previews. - Preview generation could use some polishing. - Asset Browser allows editing the name, description, preview image, and tags of assets in the current file. - Asset Browser can show assets & their metadata from other files without actually loading the full asset. - Asset metadata can be expanded with custom properties, so that add-ons can enrich them. - Select asset, choose "Open Blend File". This opens the file containing that asset in a new instance of Blender. After editing the asset (or adding a new one to the same file), save the file & close Blender, and the asset list in the original file is automatically reloaded. Advantage: doesn't disrupt your current work, but still it feels a bit tacked-on. - Asset Library: is a collection of blend files in a directory. These can be defined (name + directory path) in the preferences, then become available in the asset browser. - Asset Bundle: - Officially available on blender.org - Probably will be separate download, and easily obtainable from within Blender. - The goal of the bundle will also be to provide a learning tool. For example a material shouldn't just have a nice effect, but also should demonstrate how to create and organise materials. - Pipeline & 3rd party asset service integration - Asset browser should just get the preview images, names, and some other metadata to show the assets in the UI, and some Python functionality (callbacks, subclasses) that can be provided by an add-on. - Blender Cloud add-on could serve as reference implementation for an online repository service. - Sybren: what kind of pipeline are you thinking about? - Julian: something like an Attract or Kitsu based system, for keeping track of which asset is used in which scene. - Sybren: like a project definition, and a project-specific asset library where assets are linked into the scene (instead of appending)? - Julian: yes, like that. ### Defining Success & Scope *Attendees:* same as above *Notulist:* Sybren - William wants a place to collaboratively work on some text. Julian suggests hackmd: https://hackmd.io/@blender-asset-browser/Hk5A7laKd - William proposes to read through his notes, add stuff that's missing, add notes where there is disagreement, etc. > [color=pink] NOTE: 30 minutes is a bit short for lunch, next lunches will be 45 minutes. *Attendees after lunch break:* Andy Goralczyk, Julian Eisel, Julien Kaspar, Pablo Dobarro, Sybren Stüvel, William Reynish - About the Asset Bundle: - Julian stresses that Blender should not be making any network connections without explicit action from the user. This makes it harder to show available online assets by default (like for the Asset Bundle). - Pablo D: brushes need to be versioned to Blender itself. - Julian: Yes versioning can be an issue for the bundle. For the most part it should be fine though. - The team collaborates in the [mentioned document](https://hackmd.io/@blender-asset-browser/Hk5A7laKd#User-Stories) to define the scope in terms of user stories: Which user stories will be covered by the product/project, which one not. - Check this document for further notes on this topic. *William Reynish has to leave because of work* ### Asset Types and Use-Cases *Attendees after lunch break:* Brecht Van Lommel, Julian Eisel, Julien Kaspar, Pablo Dobarro, Sybren Stüvel Notes are taken at [Collaborative Notes](https://hackmd.io/wpPacLTsQ_i8cs9GsTMjRw) so that all attendants can work together in a single document. *Attendees after break:* Brecht Van Lommel, Julian Eisel, Pablo Dobarro, Sybren Stüvel - Pablo D: how would the 3D Viewport know what to do with the dragged-in texture? How would it know to put it into a stencil texture slot vs. loading it as world HDRi? This could be defined in the workspace? - Julian is not convinced the workspace is the right place to configure this. - Pablo D: asset is datablock with meaning, so the meaning "stencil texture" vs. "material texture" should be stored there. In other words: each use of the image gets its own asset. - Sybren: why not drag the image on the "stencil texture" tool? - Pablo D: Another example then, dragging an object into the scene. The tool for manipulating the object afterwards should be aware of, or depends on, the asset type. - Julian: dragging in object should probably be kept simple (too many options to expose while dragging), just activate the "placement" tool. That tool can then reconfigure the object as it wishes (determine up-axis, orientation, etc.) - Pablo D: Material handling should also get certain options, like "replace current material" vs. "load into new material slot". - Julian: One of William's mockups of the asset browser had an option "replace existing" or "add as new". - Pablo D: this should probably be set on the asset itself, and not determined in the asset browser (for example, a rust material will 99% of the time be blended into another material). - Sybren: we discussed something similar for append vs. link as well. - Julian: this could be configured on three levels, although it does get quite complex: - Per asset library (typically personal library should always append, project library should always link). - Make this overridable per asset - Allow users to make a final decision. - Brecht: this could maybe even be defined on the datablock itself, and not be asset-specific. - Julian agrees. Also for making the up-axis for assets explicit (to make it easy to make assets that work well on walls vs. on floors). - Pablo D: shows the 2nd video of [D9380: Sculpt: Insert Mesh Brush tool](https://developer.blender.org/D9380) as example of having different assets with each their own response to mouse movement when placing them. - Brecht: this is basically a special case of having an asset that provides a script to define behaviour when it gets added to the scene. - Julian: it's probably better to declare properties of the assets on the assets, and separately from that have Blender copy certain properties to the operator that's invoked for placing/using the asset. - Sybren: I agree, because then Blender can change operators & their parameters, without having to change the assets themselves. - Pablo D: expects the majority of uses of the Asset Bundle will be these rich/generative/smart/scripted assets. - Brecht: these properties shouldn't be required for defining an asset. - We better make list of use-cases where it's ambiguous how to apply the asset (e.g. stencil vs. regular text) and look at each case individually. - Question is raised to what degree a new brush management design is even part of the project. - Julian: It's an important use-case for the asset system, just like the pose libraries. But also includes parts that require own design and development and the project doesn't plan to cover that soon. - Pablo D says that's fine, the asset browser/system is the most imporant part of it anyway. - Julian asks if this wouldn't need a global brush library that brushes would be "pushed" into by default? - Pablo D: Asset pushing not necessarily needed at first. A good brush library (can be 100s of brushes) bundled with Blender would already go a long way. 17:00: Sybren leaves for the animation module meeting. Discussion continued for a while and covered asset types, "smart assets" (assets that know which operator/tool to execute with a bunch of properties) and how all that relates to asset navigation/organization. Main outcomes were: - If assets can store some kind of type information (e.g. "I am a procedural particle system" or "I am a stencil texture") together with properties, the tool or operator name doesn't need to be stored in the asset. - Editors can just choose tools/operators based on the asset type (or let the user choose if still ambiguous). - So no special "smart" or "tool" assets needed. It's just regular preset assets with type information. - This avoids compatibility issues when operator/tool names change, and keeps data and UI separate. - There are plenty of use cases for smarter (custom?) asset types, e.g. assets to be used with a specific tool, "merged" assets, add-ons adding support for non-Blender data, ... - Julian already experimented with a asset type info system for the object snapping feature with bounding boxes: Objects register asset type info with a callback to execute when object assets are written to .blend files. There the bounding box is updated and written to custom properties in the asset metadata. - He wanted to propose this as a core desing of the asset system. Even add-ons can define custom asset type that way, with properties (e.g. default tags, default category or catalog name) and callbacks (blend writing, drag start, drop, cancelled drag, etc.) - The custom asset type itself is runtime, but enough type info has to be written to the asset so that the type can be determined (just the ID type for regular ID assets, ) - Question remains: How can we define a texture as being a stencil texture? - Preferably store this in the texture settings. - However many users may expect they can just drag some image files into some kind of "Stencils" folder. Seems a bit weak (since it relies on folder naming). - Julian wonders if this could be solved by the catalogue idea, e.g. as a special "Stencil Catalog" type, at which point the discussion moved to that topic. - Catalogs have great potential, but need to be done well. - Catalogs could basically be the way to group assets, independent of the directory structure on the hard drive. Could be hierarchical as well. - The catalog design won't be explained further here. See notes of the next session for that. - After some initial skepticism, Pablo likes the idea. Brecht also thinks it has potential. - One problem is that the catalogs *could* be confusing, as a concept and in practical use. - Julian thinks it would be fine, since most users would just drag assets into catalogs; and if they do want to go further, the system is built on simple ideas, which should be easy to understand. - The bigger problem is how catalogs can be stored. Ideally in a way that single .blends can still be shared as asset libraries without loosing the catalogs. - Tomorrow the first session is exactly where we wanted to discuss these things. So the meeting is wrapped up here.
Last changed by  
 
Asset Browser
Asset browser project team
441

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