Seeing the today’s note I see that there is some work going on for drag and drop and snapping of assets, that’s cool, congrats
However there are some points that I’m not sure if are clear, and that should probably be tackled before things like drag and drop, so I would like to ask about them:
Is it clear how the asset libraries will be managed?
Right now it seems like a local asset collection inside the same scene, I don’t see the point of having that TBH
How can an asset library be deployed and updated amongst a studio?
So if it’s a external folder, great, but right now there are a ton of different asset libraries out there, many of them are useful, will the asset browser be flexible enough to kinf of customize how will we work with them?
Will we be able to browse folders?
The second point could be more or less solved if we could be able to define a folder and browse into sub.folders, but this was not something enabled in the past, has a solution been reached for this?
Having a folder with a ton of .blends, or having a 100Gb .blend file is not something very useful or safe, or easy to update so one department can work in creating assets, and other department can work in set dressing, not even for a freelancer.
Is some of this questions solved?
The final question:
What’s the proposed way of working with the Asset Browser to be used in production?
You are approaching this from a production pipeline use-case, which is of course one of the major use-cases of the Asset Browser. But it is still not what we currently focus on, which is why you still don’t see much development on that.
Note that what I’m answering is also to be evaluated still, we’re planning an Asset Browser workshop very soon to make decisions on a number of these things. I hope we can also finally write a design overview document then.
I’m not sure I understand this question.
You can mount custom asset libraries stored on the hard drive in the preferences, as explained in the release notes.
In future there will also be more dynamic asset libraries, defined via Python (keep reading).
Different studios & markets use different solutions: Git, SVN, Mercurial, MySQL, Dropbox, … to name a few I know are being used in the wild. They all have different trade-offs, and I don’t want Blender to dictate anyone what they should use for their pipeline. Remember we are designing an Asset
Browser, not an Asset Manager.
An important part of the asset system is the Python API, which studios/markets can use to connect their systems to the Blender Asset Browser/Viewers. That way they can register custom asset libraries, custom asset types, custom asset metadata, define what happens if you change an asset library, define custom drag & drop handlers, custom UIs (e.g. for the asset “publishing” process) etc.
The designs for navigation are a big open topic, one of the main things for the workshop. I’m pretty sure we’ll replace the current categories with a tree view. However we’re quite opinionated that this hierarchy shouldn’t necessarily reflect how the assets are stored on the disk. You may want to browse libraries differently than you manage them.
More or less in short: There would be an add-on that connects the Blender asset system with the studio’s system. It can mount an asset library on the hard drive (with further access rights managed via tags in the asset metadata for example), or define a dynamic asset library tailored just for the specific user/department. It may also create some panels for further asset management tasks (like publishing assets). Eventually Blender would support asset versioning too, to avoid conflicts.
Blender should come with some kind of reference implementation so studios don’t have to do this all from scratch. I guess that would be developed with the Blender Studio.
Thanks for all this info, that was what I was asking for
Regarding the first question, what I mean could be said in this words:
¿What’s an asset library?
A .blend file with a ton of objects
A .blend file with a specific collection structure inside
A folder with a blend per asset with textures aside as independent files
A folder with a blend per asset with packed textures
These are just some examples, all of them could be valid and supported, but I’m not sure what are you targeting as an asset library right now.
On one side what you say it’s great, because it seems to allow flexibility, as you said you may not want to see your library with the same folder structure you have in the disk, but at the same time, there are situations where you may want that, and be able to navigate folders, maybe mark some as visible and some as additional data, not visible from the library.
So whatever is the solution you reach, I hope it can be flexible and can be adapted because right now there are several Asset Libraries that has some form of structure based on the disk folder structure, so to be able to add those and be able to see their contents without doing a ton of work to convert them (even if it’s just navigating folders) will be a win situation.
Of course having a different option is also a win situation, flexibility is what it’s important here i think
In my opinion It would be better to separate the placement of the assets from anything related to their origin point and always use the bounding box as the “drop target”.
In it’s current state (dropping follow the origin point), all objects have to have their origin point on the bottom (extra setup steps) then when called from the asset browser and used in; say a physics simulation, their transform will be affected by the bottom origin point which will give incorrect behavior, requiring yet more extra steps repositioning it back to center (imagine a ball rolling on it’s base XD)
By separating it and letting the bounding box do both the snapping and the dropping, both of those two extra steps would be unnecessary.
There might be a scenario where the current design is relevant, but I fail to find it, maybe others have different thoughts.
What I explain there is simply a limitation of the current, incomplete implementation. When actually dropping the object it should use whatever was used before for the bounding box preview. But I see cases where you may want to use the origin for the snapping instead, so that will probably have to be an option.