Asset Browser Workshop Outcomes

A number of documents were created for the workshop, including daily write-ups which give more detailed insights into the discussions.

This is going to be a longer post full of information – the workshop was actually productive! :) If you are interested in the short term outcomes, check out the list of Blender 3.0 targets in the end of this post.

Status

Blender 3.0 alpha builds already include an experimental version of the Asset Browser. While there is plenty of polishing and fixing to do still, the core functionality is there. To further explore and evaluate the design, the Pose Libraries v2.0 project reworked pose libraries based on the Asset Browser. This is actually being battle tested in a separate branch, in the Blender Studio’s Sprite Fright production.

So there is already a rather basic Asset Browser and a mostly feature complete pose library system. How do we move forward from here? Can we get things done for Blender 3.0? What will that look like? And where do we want to go after that? It’s time to take the Asset Browser project to the next phase.

The asset workshop marks the start of this new phase.

Workshop Goals

At the beginning of the workshop, the workshop goals were defined as:

(The term product is used in this post to describe the overall outcome we work towards, which may be done through multiple projects.)

Product Scope

Before digging into designs, it was important to get everybody on the same page in regards to what we are building. We started by brainstorming about the outcomes we expect, or we think others may expect. Out of those expectations we wrote down a number of user stories that we could individually discuss and decide if they should (eventually) be covered by the product or not.

For example, this story should be covered:

On the other hand, this story will intentionally not be covered:

The entire list of user stories is a great way to see what to expect from what we are building. It’s highly recommended to check it out, since it’s not discussed in length here.

---

Asset Navigation & Organization

One of the main topics of the workshop was how asset libraries can be organized and navigated in the Asset Browser. Currently it categorizes assets by data-block type (object, material, image, etc.) only, which has a number of issues:

• It doesn’t scale well. Imagine navigating libraries with 100s of objects.
• It doesn’t allow good grouping of assets. E.g. scene light collections can not be displayed together with HDRi’s.
• Data-block types aren’t granular enough. E.g. node groups can be of multiple sub-types; currently geometry node groups show up under the “Shading” category. Similarly, textures may be created for use as stencils, not just as regular textures.

Catalogs

Instead we decided there needs to be a customizable hierarchy. The directories on your hard drive are one. However, we made a distinction: The way you want to browse assets may not always be how you store assets on disk. We designed a “virtual” hierarchy to manage assets, independent of disk storage, such that assets can be grouped together into catalogs.

This illustrates why you may want to browse assets differently than storing them. The poses from ellie_poses.blend can be split into the catalogs Characters/Ellie/Poses/Head and Characters/Ellie/Poses/Hands. The other way around is useful too: Trees from big_trees.blend and small_trees.blend can be merged into a single Props/Trees catalog.

An asset can be in only one such catalog. One important difference from directories is seen when you select a parent catalog. In a directory on disk you would only see the files in that particular directory. Selecting a catalog with sub-catalogs makes all assets from the entire sub-tree visible. As a concrete example, when you select the Poses catalog above it would show both the head and the hand poses.

Dynamic Catalogs

It is very useful to filter assets by tags, names, or other characteristics. Having to set them up every time can be annoying. Instead, there should be a way to store filter settings as presets and have fast access to them. We named these filter presets Dynamic Catalogs. These can also be hierarchical, but are merely filter setting based. As a result, an asset can be visible in multiple dynamic catalogs.

Normal (non-dynamic) catalogs can only be stored inside the asset library. They are set up as part of creating an asset library (e.g. by a TD in a studio). Dynamic catalogs can be defined inside the asset library itself as well, but they can also be created by the user of an asset library and stored in their Preferences.

Asset Bundle

The asset bundle already got a little introduction in the Asset Browser Project Update post. During the workshop the topic was thought through some more.

Three things should be clearly separated:

• Demo Files:
  blender.org already provides a number of demo files for showcasing Blender functionality and some great art done with Blender. These have no direct relation to the asset bundles and can stay downloadable as they are now.
• Standard Asset Library:
  A number of assets as rather atomic building blocks to get started with using Blender. These would typically be utilities or starting points, but wouldn’t be used as-is in final renders.
  For example: modifier node groups (replacing the old modifiers), default brushes, default workspaces, viewport studio lights, matcaps, base meshes, encoding presets, render presets, quick effects, basic utility node groups, …
• blender.org Asset Bundle(s):
  More high level, less atomic assets that may go into the final render as-is. They would help quickly getting started to produce content.
  For example: Characters, furniture, metal materials, fur materials, lighting setups, HDRIs, rigs, grass particles, textures, …
  You should be able to dissect some of these assets, to learn something about how Blender works and how you can create such assets yourself.

The standard asset library would come with each Blender download. It would not be possible to modify (edit, move, delete) these assets, they are basically a part of Blender. The blender.org bundle on the other hand might become a separate download, to avoid bloating the regular download size of Blender.

None of these would replace 3rd party asset services/markets. The blender.org asset bundle wouldn’t be a fully fledged asset bundle, just a number of useful assets.

Another idea are per application template asset bundles. For example:

• A “3D Printing” template that sets up Blender for simple 3D printing use, including add-ons, the workspaces, and a number of ready-to-print assets.
• A “2D Animation Tutorial” template guiding you through the interface, including pre-rigged characters ready to animate (so you don’t have to learn anything about rigging just to get started).

The application templates system will have to be expanded to support mounting a bundled asset library.

Brush Management & The Asset Browser

The way brushes are managed in Blender is in dire need of a complete overhaul. The plan is to tackle this is a separate project, so it is not something to expect in the Blender 3.0 release. Nevertheless the Asset Browser is designed to work as a basis for better brush management. Just like it acts as the basis for the new pose library system.

Currently, brushes are local to each Blend file. Sharing brushes across Blend files or projects means having to append them – not a convenient workflow, to put it mildly. Brushes should be shared across Blender files and projects, similar to the Preferences or Workspaces.

Brushes could simply be stored in an asset library. Maybe Blender should come with a default path for this library, and maybe custom brushes would get stored in this library by default. This would involve “pushing” assets into an external library though, which is a topic for further discussion.

With a good tool and tool preset design, you’d rarely have to modify parameters of a brush. That is because you have a whole number of well designed presets at hand, probably a few hundreds shipping with Blender already. Instead of switching brushes, tools or changing settings, you select some kind of preset asset. Why would you even care what that preset changes exactly (tool, parameters, brush, material, stencil, …) as long as it predictably gives you the result you want? And you need to be able to organize and navigate in these hundreds of brushes efficiently. This is once more where the catalog design really shines. In fact, brushes would live in a 3 layer design:

1. Asset Library
   Often 100s of brushes, for all kinds of purposes.
2. Catalogs
   Organize the asset library into smaller chunks that make navigating simple & efficient. Dynamic (filter setting based) catalogs can be defined by both the asset library creator and its user.
3. Brush Picker
   A UI element (maybe multiple) providing a number of brush “slots”, which brushes can be assigned to for quick access via a popup or shortcut.

Again, this is a project on its own, so this section just scratches the surface.

Terminology

There are a couple of terms that we wanted to refine or reconsider.

• Mark Asset, Clear Asset
  Better terms were discussed (e.g. something like Add to Asset Library), but for a number of reasons none of them seemed appropriate. Decision was to just do a slight change: Use Mark as Asset and Clear Asset for now. Would still be good to find something better.
• Asset Library
  A directory on disk, containing blend files with assets. This will be expanded to include non-blend file assets (like image files), and non-disk locations (like an online service).
• Tool / Tool Presets / Brushes
  The goal is to present artists with tools they can use directly, so the distinction between tools, tool presets, and brushes becomes fuzzy. For some tools, selecting the tool by itself makes sense (like the measure tool), whereas other tools behave wildly different depending on their settings (like the cloth sculpting tool). In the latter case, each of these settings could be considered a “tool” by itself and be presented with its own icon on a tool picker. Or maybe it’s a tool preset then, or a brush? This needs further discussion outside of the asset project.

Asset Types

We differentiate between “primitive” and “preset” assets:

In the future, the asset type definition will be expanded. Non-blender assets, such as image or audio files, should be supported. For such files, asset metadata is then stored in XMP sidecar files. Importers (USD, glTF, FBX, …) could add support for their file types as assets this way too. Furthermore, it should become possible to enrich an asset with a Python script, which can then provide code to be run when the asset is used.

It could be argued that there are also “generative” assets, e.g. one that allows painting grass onto surfaces, or to add windows and doors to walls (cutting out holes as needed). Technically these would probably be implemented as a preset assets executing custom python code.

Asset Identifiers/References

Internally, we need to be able to reference assets somehow. Multiple assets inside an asset library may have the same name, and they may move around and be renamed. Possibly the only proper way to get this to work perfectly would be some kind of Universally Unique Identifier (UUID). However, UUIDs are quite difficult to implement reliably; for example, duplicating a Blend file shouldn’t cause duplicated UUIDs for the assets inside. A totally reliable UUID system is tricky to get to work and so we decided against it.

Instead the identifiers could be constructed out of the following components:

• An asset library identifier.
• An asset identifier, which could be just the (asset library relative) file path + data-block name for local assets, or something custom for advanced setups through add-ons.

This could be expressed with Uniform Resource Identifiers (URIs), for example:

• library://MyMaterials/interior/couch.blend/Materials/leather
• addon://blender-cloud/HDRIs/5d08c2cb804c3eb269e42a43

It’s not clear yet if we actually need full URIs. For the most part just the asset identifier alone is all that’s needed. But this is roughly the direction we want to go in.

De-duplicating Assets

Dragging in the same material on multiple objects shouldn’t cause the same material to be added over and over again. That is an easy way to bloat your memory usage with duplicated high-resolution textures. It would be good if Blender could somehow recognize that a dragged in asset already exists as data-block in the file and avoid adding it again. It should just reuse the existing data-block.

Getting this to work isn’t that simple. It’s quite related to being able to identify assets reliably, as discussed above. But it doesn’t need to work in 100% of cases. We do have an idea on how it could work.

Online Service Migration

Online asset services should be able to migrate to the Asset Browser using Blender’s asset system soon. Or at least they should be able to get a good idea of how they could do it. Check how we generally approach pipeline and asset service integration in the previous Asset Browser Status Update post.

The specifics of the Python API weren’t discussed during the workshop, but the sections above about organization & navigation, asset types and asset identifiers/references will be important for the API as well. Roughly, asset services should be able to do the following:

• Register their own asset libraries (not necessarily stored on hard drive).
• Define or extend asset catalogs.
• Fill or extend (custom) asset libraries with their own assets – that means providing basic data (asset names, type information, previews, metadata) and callbacks for Blender to create an interactive “view” into an asset data-base.
• Create custom asset types (e.g. a “door” asset that adds the door geometry and cuts a hole into the wall it’s dragged onto).
• Do custom drawing while dragging in assets.
• Register custom handlers (e.g. callbacks for when a specific asset type gets saved).
• Register their own asset metadata using custom properties (e.g. a bounding box and an up-vector to visualize an object dragged into the 3D View).
• Extend the Asset Browser UI with own operators, icons and asset metadata fields.
• Register custom asset drop operators for editors.
• Perform asynchronous loading of the actual asset data-block.
• Maybe: Asset “proxy” loading, so a simplified version of an asset can be displayed while the high-res one is downloaded.

---

Open Topics

There is of course a lot more to discuss still. Here are some of the more noteworthy topics.

Asset Pushing

The approach that Blender supports natively involves placing the blend file with the asset in an asset library directory, and marking the asset as such. Asset pushing is a different way of getting assets into the asset library, where you’re working on some file and want to copy the asset from that file into the library. This is a concept that appears deceptively simple. In certain cases it is actually simple, but often enough it gets quite complex. Say you want to push an object into an external asset library. Should that also copy the materials? What about the texture images referenced by those materials? What about objects referenced by custom properties? And in which files would they have to go? Do they all go into one big assets.blend, individual Blend files, or into a directory per asset type? Blender should not be making such decisions for you. Apart from all those questions about what should be copied where, there is another limitation. As described above in the Managing Catalogs section, Blender itself is not allowed to write to blend files other than the one you’re currently working on.

For specific cases, these things are all solvable. For example, perhaps the pose library could get some configuration option that says which character’s poses should go into which blend file. Or maybe it gets some hook that other add-ons can hook into to configure this, such that every studio pipeline can manage this to their heart’s content. Furthermore, add-ons can write to other blend files, so they could make the decisions for users. Plenty of possibilities, as you can see.

There are definitely cases where artists don’t care much about how their assets are stored, how dependencies are handled etc. For example when managing brushes: Users just want their brushes to be stored in a way they can access them from anywhere, it’s not the kind of thing you want to spend a lot of effort on managing. Even for general user asset libraries (as opposed to project asset libraries) this may be the case for many users, although here things get more controversial. So this topic is quite important to discuss still, if not to say: the elephant in the room.

Projects

To support bigger setups, like used in the Sprite Fright production, there are ongoing discussions about making Blender aware of projects. This is elaborated on in T73366 Asset Manager Basics. In short, a Blender project is defined by a special configuration file in the project’s top-level directory. This file can then define a project asset library, which can then be used by everybody on the project when working on a file in the project directory. Not only should this aid in collaboration, it should also make it easy to switch between projects and always have the right assets available to you.

Tools, Tool Presets, Brushes

As written above in the Terminology section, Tool / Tool Presets / Brushes are still being discussed. It’s mostly a matter of deciding where exactly the line between “a tool” and “its settings” are drawn, how this is presented in the user interface, and how this relates to the use of the Asset Browser vs. dedicated tool pickers.

Technical Specifications & Python API

During the workshop a lot was talked about technical solutions, as well as how Python could extend the asset system. Things are still quite early though, so there is a lot more we could discuss. Some basics were explained in the previous Asset Browser Project Update post and above’s section about Online Service Integration. More info can be found in the main design task (T87235 Asset System Technical Design) and its sub-tasks.

Further Use Cases

The Asset Browser will have huge impact on much of Blender. Just like pose libraries and brush management may be based on the asset system, there are other use cases for it. For example, better media management for video editing in the Sequencer, a number of non-atomic geometry nodes assets, deep integration into the Grease Pencil workflow, parametric modelling with assets, particle painting with assets, presets for “everything”, … It is way too much for the core asset project team to handle. We rely on other modules to follow the project and come up with their own plans and proposals to make use of the asset system where it makes sense. Of course we have to communicate designs well and welcome their feedback, questions and are ready to help.

---

Organizing Further Work

So far the asset projects were quite developer driven. For the upcoming work we want to broaden engagement a bit. That means, involving stakeholders more and communicating designs better.

There will be an asset meeting every 2 weeks, open for everybody to join. The exact day & time still needs to be decided, and will be published in the #asset-project channel on Blender Chat.

Blender 3.0 Targets

Finally! Here’s what we want to get into the Blender 3.0 release:

An extended version of the targets is available in the workshop documents. It includes “nice to have” targets and noteworthy parts that are explicitly not release targets. We recommend checking this out as well.

What does the team say?

Last but not least, let’s hear a few words from the workshop team. Why did they join and how do they feel about the outcome?

There are many big projects and changes in motion right now and the asset browser is one of them that is at the very center. For me it was important to join in and understand what the scope and possibilities are and also to give my feedback on how every part of Blender can benefit from this feature, like managing Blender presets (brushes, tools, templates, etc). Since so many voices from different fields were joining in and had similar ambitions I am very happy with the outcome.

Julien Kaspar

The asset browser is the first step towards having a tool management system, required for handling the complexity of the new sculpting and painting tools. Thanks to the workshop it is now clear how to define, store and browse these tools and presets to later build better and more configurable UIs when working with Blender. Having the asset browser will also let us ship Blender with an asset library of preconfigured tools, properly classified and organized using catalogs and dynamic catalogs. This will allow users to discover a lot of existing functionality that would otherwise be almost inaccessible due to highly complex tool configurations.

Pablo Dobarro

The asset browser is the most complex project I have ever worked on, it’s a true challenge. It’s easy to feel overwhelmed, even if I’ve been quite confident in what we were building so far. It was great to finally share ideas and designs with more stakeholders, think the big picture through again as a team, and to finally have concrete plans for 3.0.
The project entered a new phase and the workshop was the perfect start for it. Liftoff confirmed! :)

Julian Eisel

The workshop was a great way to hear all the different perspectives on Blender’s asset system. It’s great that we now have a much clearer picture of where to take it next. I’m proud of the animators having a more powerful & easy to use pose library at the tip of their fingers right now, without having to download a 3rd party add-on. I also trust in the concept of regular & dynamic catalogs, I think it’s one of the important milestones.

Sybren A. Stüvel

---

Back to work now. There is a lot to do!