---
# System prepended metadata

title: 'blender.org Asset Bundle: Design Notes'

---

# blender.org Asset Bundle: Design Notes

> [color=#6bbc01] *NOTE: This is **not** an approved document. Just a write-up of my personal thoughts.
> -- Julian*


## Target Audience

The primary target audience for bundled assets are beginning, and occasional Blender users. Asset bundles are a great way to help them get started with content creation.

However, note that a good set of default assets can be helpful for more expert level users as well. For example for quick scene mock-ups.

## Paradigms


* **Practicable**
  The bundled assets should actually be of use, they should be well made.
  (Seek professional artist feedback; usability tests with beginners.)
* **Help users learn**
  Bundled assets are an opportunity to help users learn.
  Users should be able to "look into the box", pick apart assets to learn about how they can create and manage such assets themselves.
  *E.g.:*
   * *A vignette can be a node group, so users can open it to see how they can create one themselves.*
   * *Tagging systems tend to look unnecessary or not worth the effort. The bundled assets can use it well to show how useful they are.*
* **Encapsulated and light-weight**
  Dragging in an asset should not change scene settings, or add many data-blocks to the scene.
  *E.g. dragging in a studio light setup shouldn't adjust the render settings. So better make it a collection, not a scene.*
* **Well organized**
  All assets should make good use of tags, descriptions and mention the license.
  *E.g. materials could have a tag with the supported render engine name, so users can filter by Eevee or Cycles materials.*
* **Compatible**
  Users will probably want to access the bundled asset library from multiple Blender releases.
  * They need to be stored centralized, with access from multiple releases. The asset browser design already allows [mounting centralized asset libraries via the Preferences](https://wiki.blender.org/wiki/Reference/Release_Notes/2.92/Asset_Browser#Mounting_Asset_Libraries).
  * The assets should be compatible with coming Blender releases. Ideally also with older Blender releases (especially >2.80).
    In future we could add additional compatibility checks (so that assets can only be added to versions supporting the feature).
  * Ideally assets would be render engine agnostic. Of course an Eevee specific material can be Eevee only, but in general materials should also work for Cycles - or other engines even. But for example an object should not depend on the render engine at all.
* **Zero cost**
  Not only should the bundle be free of charge and free to use under a CC license; it should also not bother users if they do not use the bundle ("don't pay for what you don't use").
  *E.g. the Blender download size shouldn't include 100s of megabytes just for assets.*
* **Offline**
  The asset bundle should be usable from Blender without internet connection.
  
----

## How to provide the bundle?

The asset bundle would be a single asset library (directory of .blends, or a single .blend). Here are options on how we could provide it:
* **Bundle**
  Asset .blend files part of the Blender download, like fonts or scripts. Could also be compiled into the binary.
  At some point (e.g. a background job after Blender startup) Blender ensures the bundle is in a centralized location (e.g. `~/.config/blender/assets`).
  Obvious issue: Violoates zero cost paradigm. Can easily bloat the Blender download size. Plus, assets may already be "installed" from another Blender version.
* **Parametric**
  Keep assets parametric, so they can be created "on the fly" (e.g. by a script). Blender can then dynamically create the bundle in a centralized default location as above.
* **Additional download on blender.org**
  There could be helpers to make this easy and fast to do. E.g. a button to open the download page in a web browser and a button to install the downloaded library to a default location.
* **Online repository**
  We could drop the requirement to be purely offline and just give the user an option to display default assets from an online library. Technically not supported yet, but might be an attractive, modern solution we could support soon (in a sense, best of both worlds). Of course the offline requirement has its merits.
* **Combination**
  There could be combinations of the above. E.g. some bundled asset .blends + some parametric ones created on the fly.
  
**Idea**
What if we plan to provide two ways to get the assets?
* Separate blender.org download with helpers to download & install it, plus
* online repository (opt-in) for those who can rely on their internet connection.

## How to install the bundle?

If the bundle is an additional download, how can it be installed easily within Blender? Some options:
* Have the entire library in a single .blend. Let the user manage this and mount it in the Preferences.
* Have the library as compressed archive with .blends. Let the user manage this and mount it in the Preferences.
* Add "Install.." button to locate and install archive. It will extract the archive to a default location (e.g. `~/.config/blender/assets`).

A related question:
* Should bundled assets be readonly?
  Or at least, we might consider discouraging edits and put the library in a hidden directory. Otherwise updates to the bundle might be problematic. Versioning could become an issue too (e.g. user stores asset with beta Blender version, opens it with previous LTS).

## Project Organization

* Metin Seven coordinates efforts to create the bundle.
* He can create a call for content, if needed (be aware such calls typically cause quite some overhead).
* We can also ask other artists to help out.
* To start with we can create a SVN repository for the asset bundle.
* Other design questions (e.g. how to bundle and install them) are responsibility of the new Asset Browser squad.