Developers Julian Eisel and Sybren Stüvel present outcomes of the recently held asset workshop, which started a new phase for the Asset Browser project. The Asset Browser is one of the main targets for the Blender 3.0 release – and it’s a complex one that has been discussed in various forms over the past decade. […]
Developers Julian Eisel and Sybren Stüvel present outcomes of the recently held asset workshop, which started a new phase for the Asset Browser project.
The Asset Browser is one of the main targets for the Blender 3.0 release – and it’s a complex one that has been discussed in various forms over the past decade. That’s reason enough to give it extra attention in the form of a dedicated workshop, which took place 27 May – 1 June. The aim was to work out the future of the asset system for the upcoming Blender 3.0 release and beyond.
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.
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.
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.)
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:
As an artist, I can access textures/models/materials from an online store in the asset browser.
On the other hand, this story will intentionally not be covered:
As a production lead, I can approve submitted assets for production-wide use.
Reason: This is a pipeline specific asset management feature that should be handled by the studio’s custom tools. That said, Blender’s asset system will add the framework to get such tools to work (e.g. a studio could use Blender’s asset tags or the custom properties of the asset metadata for this).
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.
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:
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/Hands. The other way around is useful too: Trees from
small_trees.blend can be merged into a single
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.
Technically the catalogs are fairly simple:
Characters/Ellie/Poses) with a symbolic ID (like
"poses-ellie"). They are stored in a simple text file on disk, in the asset library.
Renaming a catalog is thus as simple as changing its path in that text file (which of course Blender will make simple to do in its UI). All assets that refer to that catalog are automatically shown at the new location. This doesn’t even require any changes to any blend files! This has a great advantage: moving assets around in the catalogs does not break library linking. Furthermore, you can split up the assets of a single blend file into various catalogs, without having to worry about what happens with the data in the blend file — it stays where it is.
Moving only a few assets from one catalog to another, and leaving some others behind, that will require changes to the blend files. For this, open the Blend file that contains them, and change which catalogs the assets belong to. As a rule, Blender only works with the file it has open at that moment. There are a number of reasons for this, for example it keeps things like Undo working properly, and you don’t have to be afraid of making mistakes. We realize that this approach has its downsides, and that it can become cumbersome when there is a small number of assets per blend file. After all, you may even have only a single asset per blend file.
Updating a different blend file that is not currently open in Blender to work on, is not allowed for Blender itself. However, add-ons could do this. The advantage of storing only the symbolic ID of a catalog is that moving such an asset only requires a change to that particular property. Similar edits to blend files are made by the Blender Asset Tracer, which can change file paths when files have been moved around, which shows that this is firmly in the realm of possible tech. For a larger scope, potentially useful outside the scope of asset management, a completely new application could be made, tailored for TDs managing relations between blend files in a production.
The downside of storing the catalog definitions in the asset library, as opposed to its Blend files, is that the catalog information may get lost when sharing a single Blend from the library. This could be addressed in various ways. E.g. assets could store the last catalog they were seen in as a hint. This may break easily but should be mostly fine in practice. Alternatively, assets not assigned to a catalog could just go to a default catalog based on the asset type (e.g. stencil textures could go to
Textures/Stencils). So even though the exact catalog setup is lost, things stay in a useful state. Either way, there should probably be some way to export a list of assets (possibly a subset of an existing asset library) as new asset library. This would also include the relevant catalog definitions then.
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.
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:
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:
The application templates system will have to be expanded to support mounting a bundled asset library.
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:
Again, this is a project on its own, so this section just scratches the surface.
There are a couple of terms that we wanted to refine or reconsider.
We differentiate between “primitive” and “preset” assets:
|“Primitive” Assets||“Preset” Assets|
|Import Action||Link/Append||Apply (e.g. temporary load data-block to apply settings)|
|Examples||Objects, collections, materials, node-groups, …||Poses, brushes, matcaps, UI presets (encoding settings, render dimensions, etc.), …|
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.
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:
This could be expressed with Uniform Resource Identifiers (URIs), for example:
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.
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.
Roughly, the idea is to do this:
This would still cause duplicates when:
So it’s not perfect, but should be enough to avoid a lot of data bloat. We can still make it better if needed.
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:
There is of course a lot more to discuss still. Here are some of the more noteworthy topics.
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.
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.
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.
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.
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.
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.
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.
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.Julian Eisel
The project entered a new phase and the workshop was the perfect start for it. Liftoff confirmed!
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!Source: Blender