Brush Assets Design #116338

New Issue

Brecht Van Lommel · 2023-12-19T13:01:40+01:00

Brecht Van Lommel commented

2023-12-19 13:01:40 +01:00

Rough draft of the latest iteration of the brush assets design.

To be updated as we go during development, and then moved to the developer docs.

Storage

No separate drafts storage, everything goes to the default user library. Asset libraries in the preferences get a boolean indicating which is the default library to save to.

Duplicated brush assets are saved in <Asset Library>/Saved/Brushes/brush_name.asset.blend. When saving the asset, only a single datablock and its dependencies are saved, no workspaces or scenes. These types of .asset.blend files are the ones where assets can be updated and deleted.

Additional datablocks used by the asset, like textures and images, are also pushed to this file. Images will be packed, to make the asset file self contained.

Editing Considerations

Updating and deleting assets is not undoable. Therefore at least deleting should show a confirmation popup. Updating could get a popup when updating by dragging an asset on top of an existing one in the asset browser, as there is some risk of doing this accidentally.

Update and delete operations for regular blend files would be disabled, and show a tooltip or dialog like the following:

This is a read-only asset from characters/bob/bob.blend.
It can be edited by opening the file.

Arguably, if a blend file was placed in the user library (not project library), its only purpose is to contain appendable assets and it should be editable, so this could be considered for a following iteration.

If we support pushing assets to arbitrary blend files, we should clearly communicate the consequences and ask for confirmation. For example a dialog like:

Update Asset?
This will modify the asset in characters/bob/bob.blend.
The entire file will be upgraded from Blender 3.6 to 4.2.

Delete asset would remove the asset metadata from the datablock, instead of deleting it.

Regardless of restrictions on pushing, we should communicate when a blend file that was opened in Blender is part of an asset library. The window title should show the asset library name, or alternatively the project name when support for that is added.

Multiple Libraries

Essential and extensions add-ons would always be read-only. But other asset libraries in the preferences would support asset pushing.

To choose the asset library, there two ways of doing it:

A single asset library is marked as default, to indicate the library to save brushes and other assets to.
The duplicate asset operator offers an option to choose which library to save to with a small sub menu, or popup menu for drag & drop.

We can get user feedback to figure out which is most convenient.

Hide & Replace

Users may want to hide or replace brushes from the essentials asset library, or potentially other asset libraries. This may be because they want to use a different set of brushes than the default essentials, or because they want to change the default of one or two settings.

The plan is to accomplish this as follows.

Assets metadata gets asset weak reference indicating another asset it replaces.
When this is present, the original asset gets hidden automatically.
Hiding an essentials assets would be accomplished by this replacement, along with assigning it to a special Trash catalog.
The Trash catalog will also be used to make deleting assets undoable in general.

Indexing

Asset library indexes do not store previews, this would need to be changed for effiency.

In fact we should considering making a search index for the entire libraries, because the current system is more like a metadata file per .blend, and not optimized for dealing with many .blend files and datablocks. This will become more important for project asset libraries.

An sqlite database per asset library would be a better solution, for efficient queries and incremental updates. This would be a true search index that can be safely deleted and regenerated. Not a file that may be the source of truth for some data, as is the case for current asset index files.

A first iteration of brush assets does not strictly have to have this optimization, particularly if we make an exception for brushes and save them in a single .blend file.

Other Datablocks

While this is focusing specifically on the brush use case, the intent is to extend this same system to node groups, materials, etc.

Rough draft of the latest iteration of the brush assets design. To be updated as we go during development, and then moved to the developer docs. ## Storage No separate drafts storage, everything goes to the default user library. Asset libraries in the preferences get a boolean indicating which is the default library to save to. Duplicated brush assets are saved in `<Asset Library>/Saved/Brushes/brush_name.asset.blend`. When saving the asset, only a single datablock and its dependencies are saved, no workspaces or scenes. These types of `.asset.blend` files are the ones where assets can be updated and deleted. Additional datablocks used by the asset, like textures and images, are also pushed to this file. Images will be packed, to make the asset file self contained. ## Editing Considerations Updating and deleting assets is not undoable. Therefore at least deleting should show a confirmation popup. Updating could get a popup when updating by dragging an asset on top of an existing one in the asset browser, as there is some risk of doing this accidentally. Update and delete operations for regular blend files would be disabled, and show a tooltip or dialog like the following: > This is a read-only asset from characters/bob/bob.blend. > It can be edited by opening the file. Arguably, if a blend file was placed in the user library (not project library), its only purpose is to contain appendable assets and it should be editable, so this could be considered for a following iteration. If we support pushing assets to arbitrary blend files, we should clearly communicate the consequences and ask for confirmation. For example a dialog like: > Update Asset? > This will modify the asset in characters/bob/bob.blend. > The entire file will be upgraded from Blender 3.6 to 4.2. Delete asset would remove the asset metadata from the datablock, instead of deleting it. Regardless of restrictions on pushing, we should communicate when a blend file that was opened in Blender is part of an asset library. The window title should show the asset library name, or alternatively the project name when support for that is added. ## Multiple Libraries Essential and extensions add-ons would always be read-only. But other asset libraries in the preferences would support asset pushing. To choose the asset library, there two ways of doing it: * A single asset library is marked as default, to indicate the library to save brushes and other assets to. * The duplicate asset operator offers an option to choose which library to save to with a small sub menu, or popup menu for drag & drop. We can get user feedback to figure out which is most convenient. ## Hide & Replace Users may want to hide or replace brushes from the essentials asset library, or potentially other asset libraries. This may be because they want to use a different set of brushes than the default essentials, or because they want to change the default of one or two settings. The plan is to accomplish this as follows. * Assets metadata gets asset weak reference indicating another asset it replaces. * When this is present, the original asset gets hidden automatically. * Hiding an essentials assets would be accomplished by this replacement, along with assigning it to a special Trash catalog. * The Trash catalog will also be used to make deleting assets undoable in general. ## Indexing Asset library indexes do not store previews, this would need to be changed for effiency. In fact we should considering making a search index for the entire libraries, because the current system is more like a metadata file per .blend, and not optimized for dealing with many .blend files and datablocks. This will become more important for project asset libraries. An sqlite database per asset library would be a better solution, for efficient queries and incremental updates. This would be a true search index that can be safely deleted and regenerated. Not a file that may be the source of truth for some data, as is the case for current asset index files. A first iteration of brush assets does not strictly have to have this optimization, particularly if we make an exception for brushes and save them in a single `.blend` file. ## Other Datablocks While this is focusing specifically on the brush use case, the intent is to extend this same system to node groups, materials, etc.

Brecht Van Lommel added the

Type

Design

label 2023-12-19 13:01:40 +01:00

Brecht Van Lommel added this to the Brush Assets & Asset Shelf project 2023-12-19 13:01:42 +01:00

Brecht Van Lommel changed title from ~~Brush Asset Design~~ to Brush Assets Design

2023-12-19 13:01:48 +01:00

Brecht Van Lommel referenced this issue

2023-12-19 13:03:33 +01:00

Brush Assets: Tasks #116337

Nika Kutsniashvili commented

2023-12-19 13:08:00 +01:00

I want to take Asset Libraties panel from File Paths to its own category in preferences and did so in my local build. I think its a good time to do that. Theyre too important to be hidden like that and new category in preferences called "Asset Libraries" can be a place where we put new properties for brush assets.

Can I post that PR? Would you be interested? @brecht

I want to take Asset Libraties panel from File Paths to its own category in preferences and did so in my local build. I think its a good time to do that. Theyre too important to be hidden like that and new category in preferences called "Asset Libraries" can be a place where we put new properties for brush assets. Can I post that PR? Would you be interested? @brecht

Brecht Van Lommel commented

2023-12-19 13:13:48 +01:00

It seems good, but we'll likely only commit such a PR for Blender 4.2. There will also be preferences changes related to the extensions project, and I prefer to see how all the pieces fit together rather than having an intermediate state for one release.

Hans Goudey referenced this issue

2024-01-17 20:00:22 +01:00

Brush Asset - Technical Design - Draft #101942

Hans Goudey referenced this issue

2024-01-17 20:00:39 +01:00

Brush Assets: Create polished mockup for the Draft operators #106898

Hans Goudey referenced this issue

2024-01-17 20:01:32 +01:00

Brush assets project #106303

Brecht Van Lommel referenced this issue

2024-02-28 14:36:04 +01:00

Brush Assets: Tasks #116337