Asset Browser Workshop Outcomes

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.

Related Posts:

Asset Manager
Asset Manager

An early, high-level introduction to some core ideas of the design.

Pose Library v2.0
Pose Library v2.0

The new pose library design built on top of the Asset Browser.

Asset Browser Project Update
Asset Browser Project Update

Demos and overview for the current state of the project.

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:

  • Get on the same page in regards to the product vision and scope.
  • Evaluate and improve the design with a number of stakeholders. Get their approval.
  • Define targets for the 3.0 release.
  • Discuss technical specifications.

(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:

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.


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.

Rough mock-up of the Asset Browser, showing both Head and Hand poses when selecting the Poses catalog.
Read More: Managing the Catalogs

Technically the catalogs are fairly simple:

  • A catalog is just a path (like Characters/Ellie/Poses) with a symbolic ID (like "poses-ellie"). They are stored in a simple text file on disk, in the asset library.
  • Every asset stores the symbolic ID of its catalog.

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.

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:

“Primitive” Assets“Preset” Assets
Import ActionLink/AppendApply (e.g. temporary load data-block to apply settings)
ExamplesObjects, 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.

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.

Read More: How it could work

Roughly, the idea is to do this:

  • A dragged in asset data-block stores a reference to the original asset.
  • When dragging in a new asset, we find whether it is already referenced by an existing data-block. If so, we use the RNA diffing created for overrides to compare if the data-blocks are equal (e.g. a material wasn’t changed since it was dragged in from the Asset Browser).
    • If equal, avoid the duplicate.
    • If not equal, the data-block doesn’t match its referenced asset anymore, so the reference can be removed.

This would still cause duplicates when:

  • The source .blend of the asset is modified, even if the asset itself wasn’t touched.
  • The source file is moved on the hard drive.
  • The asset library identifier changes somehow.

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 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:

  • Milestone 1 (Basic, Local Asset Browser)
    Finished and polished.
  • Placement tool
    Makes it possible to adjust assets in the scene, especially after dragging them in from the asset browser.
  • Catalogs
    The regular catalogs; the dynamic catalogs are not a target but a “nice to have” for 3.0.
  • Asset linking and appending
  • Pose Libraries v2.0
  • Initial Standard Asset Library
  • Extending add-menus with assets
    E.g. extending the Add Node menu with node group assets. For Blender 3.0 this will likely be limited to a number of assets from the standard library. Future versions of Blender should make this extendable by add-ons.

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!

13 comments
  1. =====
    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?
    =====

    HARD DISAGREE. From years of experience in “other” sculpting software and image editing software, having hundreds brushes is *worthless*. A large library of brushes merely means you have to memorize an arbitrary number of brush names (or tags) any time you want to switch to “what was that one brush I used one time on that project last year?” You might as well just remake it.

    A smaller number of brush “tools” with adjustable parameters that you don’t have to “save” as a preset when switching tools (because the parameters will be “forgotten” when you switch back) is more useful than 5 presets with slight parameter variations like “groove_cut_005_strength_1” “groove_cut_005_strength_3_size_2” “groove_cut_005_strength_3_fast_falloff” “groove_cut_006_stencil_1” “groove_cut_006_stencil_2” and so on, ad nauseam.

  2. The asset browser is a great milestone for Blender. Congrats.

    But, from a user POV, you really need to make a workspace for assets. People often complain, coming from another software, about the lack of general manegement for materials/shaders. To have a way of visualizing and managing a cool list, display and preview of materials (among other things of course) is something you should be concerned in order to help usability and discoverability.

    • Yes. Exactly what I was talking about under the last asset browser post.
      That would be the basic need: “general management” as you say, a visual library I’d say.
      Marking things as assets and making them cross-file is a secondary step, not a primary in this sense.
      But devs think otherwise and they tackle the more complex idea first.

      However I’m pretty happy to have this too, and I can hardly wait to put together my own little stylized asset pack

  3. > De-duplicating Assets

    Ah, was someone reading my feature request on RightClickSelect?
    https://blender.community/c/rightclickselect/Vlfbbc/

    Here’s how I would do it:
    When appending a resource to a Blender file, if there is a name collision with an existing resource, perform a hash of both resources to compare them. If they contain identical data, then use the existing resource, if they do not contain identical data, then add the new resource with a number as per usual.

    Because this problem of duplicating assets also affects other workflows other than just dragging in resources from the asset manager. It also affects the append workflow and the copy/paste workflow when copying stuff from other files, and the result is often hundreds of materials or meshes with duplicate data needlessly created. I would prefer a solution that will work for those issues as well.

  4. Cool, can we now have these folder structures available for the outliner too and stop having to do parenting on empties ??

    • Isn’t that what collections are for?

      • omg… everyone replies that… it’s so tiring having to explain all the time that’s it’s not the same thing.
        I am talking about a REAL scene hierarchy structure, no those collections that are just sorting IDs.

        Official doc for collections:
        There can be many objects in a scene: A typical stage scene consists of furniture, props, lights, and backdrops. Blender helps you keep everything organized by allowing you to group like objects together. Objects can be grouped together without any kind of transformation relationship (unlike parenting). Collections are used to just logically organize your scene, or to facilitate one-step appending or linking between files or across scenes.

        “No transformation relation”, the point of scene hierarchy is PRECISELY the transformation relationship!
        And the problem is PRECISELY that Blender doesn’t support that.
        And parenting is a completely inconvenient and obsolete workflow that painfully helps a bit, nothing more.

        • Chill. Not everyone thinks collections are good :)
          You’re super offtopic here but I find this very important and I do agree with you so I will share my thoughts too

          I’d also really-really-really want to have a real hierarchy system ( group / symbol / composition or whatever it is named in other production software)

          But this was brought up millions of times and there wasn’t even one visible discussion or opinion about it coming from official developers. My worry is this exactly, not hearing even a word about it. So you can’t really expect it to happen in ANY foreseeable future in Blender.

          I don’t know why TBH – They could at least elaborate on the why NOT do it.

          But my other worry could be the reason: Concluding in the collection design for 2.8 ties the developers hands and they couldn’t even imagine a parallel system to that. Reworking collections as a (real) hierarchy system is impossible as it was designed with completely different – mostly visibility – focus.
          I try to use them the way I wish they would work, but the best I can do is instancing different levels of nested collections – But they all have to be hidden and in the world origin and they are F’n cumbersome to edit in the scene. It’s sad.

    • The big problem is the collection tool is _*NOT*_ what you think it is or it should be.

      The biggest mistake developers commited here is to call these “Collections” rather what they are actually: “Layers”. They are meaning to sort your objects, not for functional hieracy management, so they replaced the old 20 layer button functionality with an equivalent function that allows you to name the layers (oopss… collections) give a status, etc. . That’s a big difference between what you can see/do in other softwares.

      Wokspace for assets is a problem that still needs to be solved, and probably with the assets manager can be done something to solve it, but to be honest, i doubt they are willing to update the collection (or layer) window to support hieracy of data management.

      • Exactly my concerns.

        Dear devs, I know it’s off topic but please join this conversation (or start one somewhere)…
        We wish to know your point of view on this matter.

  5. Here are my thoughts from my limited experience with the Asset Browser.. but mostly other Softwares

    01, An Asset should be a Simplified Blend file (New Extension) …
    02, Each asset should a separate file and should be either linked or copied in…
    04, Folder structure should not have to be Reinvented…. it already does its job very well
    05, There should be Tagging system…. that way an asset will only need to be in one folder but can have multiple Tags
    03, With the New Extension for the Asset files the .blend file becomes a “project format” …. :)

    Hopefully this was helpful and Goodluck

  6. Glad to see progress in design here!

    Concerning appending assets, I would hope it would “Unmark” the appended asset once dragged in (additionally to detecting if it already exists, and works as an instancer from existing data), because sometimes if you add assets, save to the asset folder, you double the asset. This could be automatic.

    The categories system sounds great!

    And rethinking how you store blendfile data and manage them.. is all very welcome.

  7. Good to see ongoing discussion and thoughts on how the asset browser will be best implemented in Blender. Keep up the great work everyone.

In order to prevent spam, comments are closed 15 days after the post is published.
Feel free to continue the conversation on the forums.