This article tries to summarize the more complete design doc and presents current state of the “Asset Project” in Blender.
The main idea of current work is to keep Blender’s library system and build asset management over it, using “Asset Engines”, which will be python add-ons communicating with Blender through an “AE API”, in a similar way to our “Render Engine API” used e.g. by Cycles, POVRay, and other external renderers.
To simplify, those asset engines are here to provide to Blender lists of available items (they also include filtering & sorting), and ensure relevant .blend files are available for Blender at append/link time (or when opening a file). More advanced/complex pre- and post-processing may be executed through optional callbacks.
This allows us to not define “what is an asset” in Blender – Blender only knows about datablocks. Assets are defined by the engines themselves. The only addition to current Blender’s data model is a way to keep track of assets, variants and revisions (through UUIDs).
Work Landed in Master
A first rather big task has been to enhance filebrowser code and make it ready (i.e. generic enough) for assets listing. Final stages have been merged in master for Blender 2.76 – main immediate benefits include the ability to list content of several directories and/or .blend files at once, the ability to append/link several datablocks at once, a much quicker generation of thumbnails (when enabled), and a globally reduced memory footprint (especially when listing directories whit huge number of entries and enabling thumbnails).
Previews were also added to some more datablocks (objects, groups, scenes), and behavior of materials/textures previews generation was fixed.
Work Done in Branches and TODO’s
Fixing Missing-libs Issue
Currently, if you open a .blend file linking some data from a missing library, that linked data is totally lost (unless you do not save the main file). Work has been done to rather add placeholders datablocks when the real one cannot be linked from a library for some reason. This allows to keep editing the main .blend, and either fix the library path in the Outliner or make missing lib files available again at expected location, save and reload main .blend file, and get expected linked data again.
In addition, to remove the needed ‘save & reload file’ step, work is in progress to allow hot-replacing of a data block by another in Blender, this should allow to just fix broken lib path and automatically reload missing data.
Asset Engine Experiment – Amber
Amber is the experimental asset engine developed in parallel with the AE API. It also aims at being a simple, file-system based engine distributed as an add-on with Blender, once asset engine work is ready to be released!
It is based on file system storage with a JSON file to define assets & meta-data (like tags, descriptions, …).
Currently the basic browsing/importing part is up and running – in the picture above you can see three file browsers and a text block:
- The first browser (a “normal” one) shows the content of the test-case Amber repository (you’ll note the `__amber_db.json` file which defines an Amber repository).
- The second browser (an “Amber” one) shows that same directory as reported by our asset engine.
- The third browser (an “Amber” one too) shows the “filtering by tags” of Amber in action (the “character” tag is inclusive-selected).
- The text block shows an excerpt of the `__amber_db.json` content, with the definition of one asset and the definition of tags.
You can find that test-repo in that archive.
There are quite a few topics to be implemented yet to consider this work to be (even barely) usable, mostly:
- Add the “reload” ability (which also depends on the “missing-libs” work actually), such that Blender can query asset engines for updates (on file load or from user request).
- Currently you have to generate that JSON file by hand, which isn’t terribly fun. This will be addressed once the loading/reloading part is reasonably finished, though.
Conclusion (For Now)
Foundations of the future asset handling are mostly defined (if not coded) now, though we still have much work ahead before having anything really usable in production. Once again, this is a very condensed summarizing, please see the design task (and all sub-tasks and branches linked from there) for more in-depth and technical doc and discussions. And please do build and test the branches if you want to play with what’s already done – the earlier the testing and feedback, the better the final release!