An operator to link a custom preview image has been “implemented” (bpy.ops.ed.lib_id_load_custom_preview) and will hopefully be integrated as a simple right click option, however its currently unclear what context its expecting as a new undocumented context member “active_id” is expected to be passed in. I’ve asked Julian what this operator is expecting. Assuming this works as expected and saves a custom preview image for each asset then it should be easy for the core devs or add-on makers to make this much better and give you a choice of scenes, angles etc. for your previews or for you to manually generate them yourself.
A good start and glad to see that something has actually been implemented and made it to main after what, five years, six? The only real WTF for me is that “objects and collections” and “images and sounds” are grouped together under a single heading. This doesn’t make any sense as they’re completely different things.
Hopefully cacheing will come soon as this is what will determine whether it’s actually useful for large asset libraries as currently it has to open and read each .blend file.
A “save as asset” feature that saves out each asset into its own file is the other thing that needs to be implemented as quickly as possible.
1 Like
Ugh, the way instancing is implemented is a mess. When you Make Instances Real the operator clears all parenting information for some insane reason. Makes the asset browser pretty useless for collections in a lot of cases.
There’s an option in the operator to keep the hierarchy
Thanks for the tip. Unfortunately its not making it useable. While it retains the parenting relationships it doesn’t seem to be retaining the transformations in a lot of instances, so when I’m making instances real half the objects in my collection are ending up in the wrong place, despite all being parented. This isn’t the case if I just append the collection. I’ll put in a bug report just as soon as I can work out how to reproduce the issue reliably. More broadly I think whether you want collections or objects to be linked or appended should be an option settable in preferences.
Yeah, I have noticed some issues with it in the past as well- for example, the Bend modifier tends to explode after making instances real if one of the objects in the collection instance had a bend modifier- likely has something to do with the transform issues you’re seeing.
Do you know how to import animations from the asset browser? I just saved a file with a test animation action marked as an asset on my local library, and I can see it on a new file when browsing the assets, but I can’t seem to find the way to apply that action to a new object…
Is it because it hasn’t been implemented yet, or is there any obscure step I’m missing?
I worked out what the issue was for me. Any objects in a collection that are disabled in viewport (rather than being hidden in viewport) in the original file aren’t linked in to the scene collection when you link a collection into a new file. I’ll report this as a bug and hope it isn’t intentional.
1 Like
good catch, definitely doesn’t feel intentional!
Apparently it is intentional. I got a “You’re holding it wrong” type response from Bastien Montaigne. https://developer.blender.org/T84306
So the asset browser is broken by design for collections from the off.
The answer was a bit different - it is a limitation, and until it is fixed, controlling visibility is the only workaround. The report was not rejected.
No, sorry, they’ve implemented this poorly in the context of the asset browser. If I as a user drag a collection from the asset browser into the scene I should have access to all objects in that collection. That is the absolute minimum functionality that I should expect. It is after all a collection of objects. Instead they’ve decided to use the instancing function, which means you cannot get access to all objects in a collection in certain circumstances (such as where the hide_viewport flag is set) if you then make the collection real. Instead of covering the base case, linking or appending a collection into the scene which you can then instance if you wish, they have instead jumped straight to what should be a special case, directly instancing a collection into the scene, despite knowing that doing it this way does not give a user access to all objects in a collection I’m certain circumstances.
If making an instanced collection real gave you access to all objects in a collection then this would be ok, but because there are known limitations to the instancing implementation (or more accurately the “make instances real” Operator) it isn’t a good way of handling collections in the context of the asset browser, which is what I’m concerned about.
How do you have the visibility disabled? With the Eye or with the Screen?
With the screen (actually using a script which sets the hide_viewport flag, but this is the same thing).
I know I can just set the visibility using the eye, pressing h or using object.hide_set(True) rather than doing it this way, but the point is that from an asset browser point of view it shouldn’t matter whether an object in a collection is hidden or not when it comes to bringing that collection into the scene by dragging and dropping it.
Dragging and dropping a collection from the asset browser into the scene should do the obvious thing - bring a collection and all the objects it contains into the scene, either by linking it (and all objects it contains) or appending it (and all objects it contains).
Instead what it is doing is instancing it, which is basically bringing in an evaluated version of the visible objects in the collection, rather than the collection itself. If you then want to make the instances collection real you are not guaranteed to be able to access and modify local versions of all the objects that were in the original collection.
This is just a bad design decision when it comes to an asset browser, because it is preventing you from actually accessing the objects that make up the asset (which is a collection NOT an evaluated depsgraph).
There are two possible, relatively easy fixes.
- don’t use instancing for spawning collections from the asset browser (probably the easiest)
- fix the make instances real operator so it brings in all objects in a collection .
Then it’s working as expected.
The screen was designed precisely for that, to disable things for links/appends, it’s something fully disabled, if the asset library will allow to override that or not, I don’t know, but right now it’s working as expected I’m afraid.
If you want something to be considered for export / import, but have it hidden in the viewport, you should use the eye, not the screen, that’s why there are two visibility flags, the eye and the screen, and that’s the main difference 
1 Like
Except that’s not true. If I link a collection or append a collection into a scene from an external file then the objects contained in that collection are also linked or appended unless I choose to instance a collection. This happens irrespective of whether or not objects in the original collection are hidden by having the hide_viewport flag set. So it’s either not working as intended or you’re mistaken about the difference between the eye and the screen.
To elaborate on the actual difference. The “H” key or eye symbol hides the object in the active view layer. You can have more than one view layer in a scene and an object can be hidden in one view layer but not another. Using the screen or setting the hide_viewport flag hides the object in the viewport so it isn’t affected by the per view_layer settings. Whether that flag is set or not doesn’t have anything fundamentally to do with linking or appending (or other scene level stuff), which is why if you link or append a collection into a scene it doesn’t matter if its hidden in viewport or not, it will still be linked or appended in.
I’m not arguing with you wether if it’s working or not, what I explained to you is how was it designed, it was not just for view layers, but also for linked information, it was presented that way since the begining.
If the link behaviour is not correct, then something must be wrong in the link code, because with the screen disabled that object must be ignored by the link.
Because of that I would expect that if I bring something to the library, and that something has the screen disabled, then the library will ignore it and create the asset without that object.
If that’s a proper behaviour or not, it’s another story that we can talk about, but that’s the behaviour I would expect right now.
The asset browser still needs quite a lof of work to be actually useful, not even being able to navigate folders makes it unusable for us for example
I’m not entirely sure how is it being designed, I was expecting something more useful and manageable with production in mind at different levels, but right now I’m not sure how can it be used or why is it better than having a blend file from where you link your objects.
I know it has been said that it needs a lot of work, but could be interesting to see the design route because one thing I can’t see clearly is what is the expected “final” result of the Asset Browser, no idea what is the pursued final target here.
4 Likes
Almost exactly what I thought.
I don’t know how it was designed but so far it’s barely usable. I don’t worry about smaller things missing but I think there might be core design decision flaws because it is really hard to see the final goal based on early implementation which feels very random how it should bring value to artist in daily work and make it easier to manage assets.
I worry that because of possible core design flaws we might need a complete rebuild for version 2 of asset manager in a year or so.
1 Like
Is there a way to mass import textures into asset browser ? Ive got both a 2d texture library and a 2d element library I would like to use inside of the asset browser.
Or do I have to load each manually and mark as asset ? I have literally hundred of thousands of items.
1 Like