Page MenuHome

Asset Manager “Basics”
Confirmed, NormalPublicTO DO

Tokens
"Love" token, awarded by Juangra_Membata."Love" token, awarded by KtRN."Burninate" token, awarded by Dir-Surya."Burninate" token, awarded by Altha."Like" token, awarded by nfguler."Love" token, awarded by Schamph."Love" token, awarded by stormrider."Love" token, awarded by ILJI."Love" token, awarded by Fureloka."Burninate" token, awarded by cgeugene."Love" token, awarded by AonoZan."Love" token, awarded by drx."Baby Tequila" token, awarded by lordodin."Love" token, awarded by harvester."Burninate" token, awarded by Taros."Dat Boi" token, awarded by shader."Love" token, awarded by samytichadou."Love" token, awarded by kpavicic."Love" token, awarded by viadvena."Love" token, awarded by kynu."Like" token, awarded by klutz."Love" token, awarded by pablovazquez."Love" token, awarded by filedescriptor."Love" token, awarded by kvick."Love" token, awarded by pierogo."Love" token, awarded by Scio."Love" token, awarded by printerkiller."Like" token, awarded by higgsas."Love" token, awarded by Alumx."Love" token, awarded by RyanJEC."Burninate" token, awarded by sopranoo."Love" token, awarded by Peine_Perdue."Love" token, awarded by merwin."Love" token, awarded by jc4d."Love" token, awarded by greyoak."Love" token, awarded by RodDavis."Burninate" token, awarded by aliasguru."Love" token, awarded by mistajuliax."Love" token, awarded by Eric_Medlen."Love" token, awarded by juantxo."Hungry Hippo" token, awarded by lopoIsaac."Like" token, awarded by Constantina32."Burninate" token, awarded by Goldwaters."Love" token, awarded by brilliant_ape."100" token, awarded by anonym."Love" token, awarded by Shimoon."Love" token, awarded by einsteinchen."Like" token, awarded by Maged_afra."Love" token, awarded by Bit."Love" token, awarded by aditiapratama."Love" token, awarded by nunoconceicao."Love" token, awarded by xdanic."Love" token, awarded by ReinhardK."Like" token, awarded by Fracture128."Love" token, awarded by symstract."Like" token, awarded by Ztreem."Like" token, awarded by Frozen_Death_Knight."Love" token, awarded by CobraA."Like" token, awarded by MetinSeven."Love" token, awarded by andruxa696."Love" token, awarded by Alrob."Love" token, awarded by Tetone."Love" token, awarded by xrg."Burninate" token, awarded by billreynish.
Assigned To
None
Authored By
Dalai Felinto (dfelinto)
Jan 24 2020, 5:16 PM

Description

Status: Milestone 1 is ready to go.


Team

Commissioner: @Ton Roosendaal (ton)
Project leader: @Julian Eisel (Severin)
Project members: @William Reynish (billreynish)

Description

Big picture:
An asset, in Blender, can be both models/meshes, armatures, materials, textures, rigs, scripts, node groups, Collections and so on.

The Asset Manager then, at a high level, is about adding the ability to manage and browsing data, and also a platform for anyone to extend and write their own managers. It's both an API and a set of concrete, built-in asset managers.

This is in the same way that the Blender Render API is simply an API, but we also include some built-in renderers with Blender (Cycles and Eevee)

Use cases:
The built-in asset managers will mainly serve two use-cases:

  • As a way to store, browse and load user-created content for use as a starting point for new projects and scenes
  • As a way to manage inter-linked projects, such as movies with linked characters, sets and prop

Design:

Missing: Technical design of how Amber will store data & metadata

Engineer plan: ?

Work plan

Milestone 1 - Basic, local Asset Manager

This will build on the work already done for the asset manager, but makes some design changes.

  • Datablock Metadata
    • Is asset, description, tags, author and preview image
    • Make/edit asset popup from outliner, datablock browsers
    • Preview render is immediately created along with initial asset metadata
    • Option to show only assets in link/append file browser
  • Asset Browser
    • New editor, internally based on file browser
    • Display contents of local folder assets
    • Drag & drop asset into scene, or click Append Asset button
    • Add/remove asset to/from local folder using drag & drop
    • Add asset to local folder from outliner, datablock browsers
    • Search and filter by tag
    • Metadata display and editing
    • Right click asset to open containing folder (and edit in new blender instance?)
  • Library Asset Storage
    • Repository is folder containing .blend files (with one or more assets) and other file types like images
    • Bundled Library asset repository as part of Blender install
    • User Library assets repository
      • By default, drag & dropping an asset to this library saves the asset in an individual .blend file or other file format
      • Manually saving .blend files in folder is also possible, with multiple assets in one .blend if desired
      • This folder will be shared across all installed Blender versions (unlike e.g. add-ons which are per version)
    • Preferences: additional user defined asset folders
    • Indexing for performance
      • Cache metadata and preview images for fast opening asset browser
      • Index updated in background when opening asset browser (compare file dates..)
      • Is purely a cache and can be safely deleted
    • Nested folders: asset browser shows nested files as flat list (maybe folder name as tag)
    • Datablock dependencies
      • Indirect datablocks get appended (no auto dedup to start)
      • External files can use pack, append, then unpack (into e.g. textures/ folder next to .blend)

Milestone ?: Online Repository

Here we want to be able to append assets from an online repository like the Blender Cloud, BlenderKit and similar.

There would be a Python API to register custom asset repositories as part of add-ons. The main operations would be to provide a list of assets and metadata, provide .blend with an asset to append/link into the scene, and functions to add/remove/update an asset.

Milestone ?: Usability

Once the asset manager is working for the basics and the UI can do its job, we can start to make things nice. This includes better handling of thumbnails, re-configuring the ID browser to allow for asset browsing, a nice UI widget for managing tags and tag-based filtering.

A key part of making the UX nice, is to make it effortless to drag assets into the scene. When dragging in objects & meshes, they should be able to snap to surfaces. When dragging in materials, the underlying target objects should highlight on rollover. You should be able to add multiple assets at a time.

Milestone ?: Collection Variations

Not strictly part of the asset manager since this would be a core feature of Blender also usable without the asset manager. We would like to support variations for all datablock types, but the first step could be collections (it's effectively like automatically toggling visibility on subcollections to show only one).

Once this is in the place, the asset manager will need to be modified to understand variations.

Milestone ?: Project Repositories

Up to this point the asset manager will handle only the use case of appending files from a local or online repository. The next step would be making it works also for projects.

  • The root project directory would contain a .blender_project file indicating that it is a project (similar to e.g. .git)
  • When opening a .blend file within the project folder, Blender will automatically know which project it is part of
  • Folder structure, file names and file saving are left to the user. The asset browser will not add or remove .blend files in the project. That's all done using File > Save and file browsers as usual.
  • The assert browser will have a "Project" repository that can be chosen, which will show all assets within the project
  • The user will have to mark relevant datablocks as assets in each .blend file in the project so it shows up in the asset browser.
  • Assets can be linked between files within the same project. This is different from other repositories, where only append is possible. Linking between projects or to other repositories should not be possible, a project must be self-contained and not link to any .blend file outside of it.
  • The project folder would be indexed exactly like other asset folders.

The idea here is that we don't want to make many assumptions about how users might structure their project. It should be possible to simply add or remove files, reorganize project directories, and the asset browser should keep working. It will merely provide a view on the existing project structure, and functions to create links to other assets in the project. It will not introduce an alternative linking system as an earlier iteration of the asset manager design did.

This system does not preclude a studio from making an add-on that takes more control over file saving, version control, partial repository checkouts and so on. Such an add-on would likely need to integrate in various places in the Blender user interface, one of which can be the asset browser. For example it might include a custom asset repository to browse assets that are not on the artist's computer, and right before the user links an asset into the scene, download the corresponding .blend file.

But for most projects that are not e.g. feature films, the built-in project repository and automatic indexing system should already be quite powerful.

Notes: The original work has been carried on in the following branches.


Relevant links:

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

If feasible I'd request that whenever possible relative paths be used in library definitions, both in "indexes", user defined folders or paths to assets.

This helps make assets more resistant to change, so that paths don't break or require re-indexing if for example a drive letters change, or when accessing from network or different computers, assets in a removable drive, etc.

Another possibility is to store both (relative and absolute in parallel) like Inkscape currently does for external images, if one breaks the other may be used as backup.

If feasible I'd request that whenever possible relative paths be used in library definitions, both in "indexes", user defined folders or paths to assets.

+1 to relative paths for local files, with full path as backup.

I realize the design is not finalized but can we get some clarification on:

Individual .blend file per asset in local folders (support loading multiple in a .blend too)

You mean to say that you would store every asset in .blend format instead of its native format? (.png, .tga, .wav, .mp3, etc.)

Or does this subsequent point mean that for, say, a folder full of brush alphas there would be a structure like bark.blend, bark.tga, scales.blend, scales.tif, star.blend, star.png, and so on?

External files can use pack, append, then unpack (into e.g. textures/ folder next to .blend)

@Chris Kohl (ckohl_art), I've updated the description to be more specific, hopefully that clears it up.

Andrew Peel has published an interesting video on Youtube: Asset Libraries in Blender 2 83

Why is that Technical Doc link closed for the reason of "Invalid"?

Andrew Peel has published an interesting video on Youtube: Asset Libraries in Blender 2 83

Some parts indeed, but it seems he's more interested in building blocks. Not so much about the asset manager itself. Though his functionality he showed of the manager itself look quite solid. All those other functions in his video already exist in other addons which already ship with Blender. It feels like re-inventing the wheel if im honest

Andrew Peel has published an interesting video on Youtube: Asset Libraries in Blender 2 83

That is amazing, I hope the devs take many if not all suggestions from this video

Like i said, check Blender now and there are addons which have more advanced implementation of what he is showing. THere are already 3 addons with building elements like this ; Archimesh, Archipack, JARCH viz. Check those out

I've been thinking about assets lately, and I was wondering if they shouldn't actually be implemented entirely as it's own separate type of datablock.

An asset will actually be a datablock appendable/linkable/browsable as a folder like all others, which among other things would contain the following data/fields:

  • Name - Name of the datablock
  • Description - A short note or usage instructions
  • Author - Name of the authors
  • Tags - For categorization and search/filtering purposes
  • Datablock - The actual data it will be containing, (a pointer, it is technically called?) to another datablock, like a collection to instance (containing a character), a material, a single object, or a shader node, or eventually an object with a geometry node setup (when everything nodes comes)
  • Thumbnail - Either an automatically generated thumbnail, or if overriden an optional custom image (or if possible sequence) of the datablock for preview purposes
  • Parent Asset - Maybe Variations could just be regular assets that would have a pointer(?) field pointing to another asset datablock they were a variation of, that way we avoid conflicts and can have an arbitrary number of them without convoluted setup processes

The file browser would then have this dedicated mode to browse Asset datablocks.

Ben (KtRN) added a subscriber: Ben (KtRN).