Brush Asset - Technical Design - Draft #101942

New Issue

Bastien Montagne · 2022-10-20T12:40:31+02:00

Bastien Montagne commented

2022-10-20 12:40:31 +02:00

Note

WIP...

This task is to design and keep track of how the new Draft system will be implemented as part of the new Brush Asset system.

Draft is a special, per-user .blend file, which can be edited by Blender while other (regular) blend files are opened, It acts as some sort of powerful non-volatile copy/paste buffer, and is based on the Asset library system.

Draft Basics

Some key characteristics:

Draft is a .blend file in the usersettings path.
Data should never be (permanently) linked from Draft. Runtime-only linking is allowed (not directly by the user though), as well as appending.
Only assets are accessible from the Draft, through the Asset system. There is no direct 'low-level' appending/linking possible for the user.

Blender needs to be able to:

Open a .blend file in a secondary Main, different than the current active one.
Manipulate data-blocks in that secondary Main (on a basic level: Move IDs between Mains, add/delete IDs in secondary main, ...).
Save a secondary Main into a .blend file.
A locking mechanism is likely mandatory, to prevent several instances of Blender modifying the Draft file simultaneously. Maybe simply an additional draft.blend.lock empty file alongside the draft.blend one? -- #103935 (Add File Locking Support to BLI_fileops), we probably can just have a write-to-temp + atomic-file-move process for now (what is already done for 'normal' .blend files).

Some open questions:

Is Draft fully independent, or can it use linking from other sources (e.g. dependencies from Brushes, like textures, could be linked from the original asset repository file)? Probably fully independent would be simpler and safer. On the other end, it means there would be no storing of overrides in the draft, which is quite an important limitation).
- If Draft is not fully self-contained. how do we handle paths to linked IDs and non-embedded data (like images)? Current idea would be to store paths relative to the draft file itself. That way, draft can be e.g. synced or shared between different systems as long as the relative directory layout of draft and asset repositories still matches.
Are more than one Draft repository supported? E.g. 'projects' could also have their own Draft?
Different instances of Blender need to update automatically on Draft changes. This probably implies (re-)investigating FS change events API for our GHOST (integrating inotify on linux, fsevents on OSX, etc.)? Needs to be its own design task.
There is most likely needs for some level of management on the Draft.
- Cleaning up unused non-asset IDs. Manually or automatically?
- Deleting some assets?
- Purging (deleting everything)?
- ...

Brush Handling in Draft

The handling of brushes in Draft is not directly exposed to the user, they only interact with the Draft through a limited set of higher level operations.
Draft has two main purposes:

To allow user to store their tweaked/modified versions of Brushes from (readonly) asset libraries.
As the source of data when authoring an asset library, when user want to publish their modified brush assets.

Save & Save As

Save and Save As store a liboverride of the original brush asset in the draft. That way, non-edited settings still get updated in case the original asset data is updated.
In that case, dependency IDs (textures etc.) are not stored in the Draft, they are still linked from the asset repository. unless they were made local already in the working .blend file. Paths to linked IDs are relative to the Draft .blend file.

Save will update an existing override in the draft, if any. Save As always create a new override with a new name (or replace an existing one in case of name collision).

Meta data of the new draft asset are copied from the original linked asset.

Duplicate

Duplicate stores a fully independent copy of the original brush asset and its dependencies into the Draft. Do we also need 'Duplicate As'? Or is Duplicate always 'as' since we never overwrite and existing ID in Draft in that case?

Handling of dependencies ID is similar to append or reuse (i.e. if a copy of the original linked ID is already found in the Draft, it is reused).

Using Draft Asset

Using a Draft Brush happens exactly as any other brush asset.

Importing From - AKA Publishing

To 'publish' a draft asset, user 'append or reuse' it into their asset library file. They can then edit it as any regular asset.

Draft Beyond Brushes

While this is not a target for the Brush Asset project, Draft usage could be generalized to any type of data that can become an asset, and be used as an advanced copy/stage/paste buffer.

> **Note** > WIP... This task is to design and keep track of how the new Draft system will be implemented as part of the new Brush Asset system. Draft is a special, per-user .blend file, which can be edited by Blender while other (regular) blend files are opened, It acts as some sort of powerful non-volatile copy/paste buffer, and is based on the Asset library system. ## Draft Basics Some key characteristics: * Draft is a .blend file in the usersettings path. * Data should never be (permanently) linked from Draft. Runtime-only linking is allowed (not directly by the user though), as well as appending. * Only assets are accessible from the Draft, through the Asset system. There is no direct 'low-level' appending/linking possible for the user. Blender needs to be able to: * Open a .blend file in a secondary Main, different than the current active one. * Manipulate data-blocks in that secondary Main (on a basic level: Move IDs between Mains, add/delete IDs in secondary main, ...). * Save a secondary Main into a .blend file. * A locking mechanism is likely mandatory, to prevent several instances of Blender modifying the Draft file simultaneously. *Maybe simply an additional `draft.blend.lock` empty file alongside the `draft.blend` one?* -- #103935 (Add File Locking Support to BLI_fileops), we probably can just have a write-to-temp + atomic-file-move process for now (what is already done for 'normal' .blend files). Some open questions: * Is Draft fully independent, or can it use linking from other sources (e.g. dependencies from Brushes, like textures, could be linked from the original asset repository file)? *Probably fully independent would be simpler and safer. On the other end, it means there would be no storing of overrides in the draft, which is quite an important limitation).* * If Draft is not fully self-contained. how do we handle paths to linked IDs and non-embedded data (like images)? *Current idea would be to store paths relative to the draft file itself. That way, draft can be e.g. synced or shared between different systems as long as the relative directory layout of draft and asset repositories still matches.* * Are more than one Draft repository supported? E.g. 'projects' could also have their own Draft? * Different instances of Blender need to update automatically on Draft changes. This probably implies (re-)investigating FS change events API for our GHOST (integrating `inotify` on linux, `fsevents` on OSX, etc.)? Needs to be its own design task. * There is most likely needs for some level of management on the Draft. * Cleaning up unused non-asset IDs. Manually or automatically? * Deleting some assets? * Purging (deleting everything)? * ... ## Brush Handling in Draft The handling of brushes in Draft is not directly exposed to the user, they only interact with the Draft through a limited set of higher level operations. Draft has two main purposes: * To allow user to store their tweaked/modified versions of Brushes from (readonly) asset libraries. * As the source of data when authoring an asset library, when user want to publish their modified brush assets. ### Save & Save As Save and Save As store a liboverride of the original brush asset in the draft. That way, non-edited settings still get updated in case the original asset data is updated. In that case, dependency IDs (textures etc.) are not stored in the Draft, they are still linked from the asset repository. unless they were made local already in the working .blend file. Paths to linked IDs are relative to the Draft .blend file. Save will update an existing override in the draft, if any. Save As always create a new override with a new name (or replace an existing one in case of name collision). Meta data of the new draft asset are copied from the original linked asset. ### Duplicate Duplicate stores a fully independent copy of the original brush asset and its dependencies into the Draft. *Do we also need 'Duplicate As'? Or is Duplicate always 'as' since we never overwrite and existing ID in Draft in that case?* Handling of dependencies ID is similar to `append or reuse` (i.e. if a copy of the original linked ID is already found in the Draft, it is reused). ### Using Draft Asset Using a Draft Brush happens exactly as any other brush asset. ### Importing From - AKA Publishing To 'publish' a draft asset, user 'append or reuse' it into their asset library file. They can then edit it as any regular asset. ## Draft Beyond Brushes While this is not a target for the Brush Asset project, Draft usage could be generalized to any type of data that can become an asset, and be used as an advanced copy/stage/paste buffer.

Bastien Montagne commented

2022-10-20 12:40:31 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Bastien Montagne commented

2022-10-20 12:40:31 +02:00

Added subscribers: @mont29, @lichtwerk, @AlexeyAdamitsky, @AndyCuccaro, @JulienKaspar, @JulianEisel, @dfelinto

Paul Larson commented

2022-10-24 17:28:47 +02:00

Added subscriber: @GeorgiaPacific

Julien Kaspar added this to the Sculpt, Paint & Texture project 2023-02-08 10:20:48 +01:00

Bastien Montagne modified the project from Sculpt, Paint & Texture to Core

2023-02-09 15:42:54 +01:00

Bastien Montagne removed this from the Core project 2023-02-09 18:20:29 +01:00

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Brush Asset - Technical Design - Draft #101942

Draft Basics

Brush Handling in Draft

Save & Save As

Duplicate

Using Draft Asset

Importing From - AKA Publishing

Draft Beyond Brushes