When a parent item was renamed, the `TreeView` was doing everything as
expected, however `AssetCatalogService::update_catalog_path` is supposed
to also update the catalog paths of all sub-catalogs [which it does --
but it does not tag sub-catalogs as having unsaved changes, resulting in
wrong saving of catalogs afterwards, meaning the parent item was saved
with the old name and a new item with the new name was created].
Now also tag sub-catalogs for having unsaved changes.
This should also go into 3.3 LTS
Pull Request: https://projects.blender.org/blender/blender/pulls/107121
No user visible changes expected.
For brush assets, we need a way to store a reference to a brush in .blend files, so that the last active brush can be restored from the file. See #101908. It seems like a generally useful thing to have.
Adds a new DNA struct to store a "weak" asset reference, that is, a reference that can break under a number of circumstances, but should work reliably enough under normal usage. There's no way to reliably reference an asset currently, so this works on a "best effort" basis. It can break when assets are moved inside the asset library, asset libraries are unregistered from the Preferences, or a file is opened on a different machine with different Preferences, for example. It can also break currently if an asset library is renamed.
It contains:
- Information to identify the asset library the asset can be found in.
- A relative "identifier" (currently a relative path) for the asset within the asset library.
There's further code to resolve a weak reference to file paths and Blender library paths.
Part of #101908.
Co-authored-by: Bastien Montagne <bastien@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/105603
The goal is to solve confusion of the "All rights reserved" for licensing
code under an open-source license.
The phrase "All rights reserved" comes from a historical convention that
required this phrase for the copyright protection to apply. This convention
is no longer relevant.
However, even though the phrase has no meaning in establishing the copyright
it has not lost meaning in terms of licensing.
This change makes it so code under the Blender Foundation copyright does
not use "all rights reserved". This is also how the GPL license itself
states how to apply it to the source code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software ...
This change does not change copyright notice in cases when the copyright
is dual (BF and an author), or just an author of the code. It also does
mot change copyright which is inherited from NaN Holding BV as it needs
some further investigation about what is the proper way to handle it.
For example
```
OIIOOutputDriver::~OIIOOutputDriver()
{
}
```
becomes
```
OIIOOutputDriver::~OIIOOutputDriver() {}
```
Saves quite some vertical space, which is especially handy for
constructors.
Pull Request: https://projects.blender.org/blender/blender/pulls/105594
Various UI code would store the `AssetHandle` in a way that turns out to
be unsafe. The file-data is part of the file browser caching system that
releases file-data when a certain maximum of items is in the cache. So
even while just iterating over the assets, earlier iterated asset
handles may become invalid. Now asset handles are really treated as
volatile, short lived objects.
For the asset-view, the fix was more involved. There we need an RNA
collection of asset-handles, because the UI list code requires that. So
we create a dummy collection and get the asset handles as needed by
index. This again meant that I had to keep the index of the collection
and the asset-list in sync, so all filtering had to be moved to the UI
list.
I tried duplicating the file-data out of the cache instead, but that
caused problems with managing the memory/ownership of the preview
images.
`AssetHandle` should be removed and replaced by `AssetRepresentation`,
but this would be an even more disruptive change (breaking API
compatibility too).
Fixes#104305, #105535.
Pull Request: #105773
This adds some simple null checks to avoid the crash. It might still
be good to improve the error message, but also does not seem as
important as avoiding the crash. Typically, users should not run into
this issue because the assets are shipped with Blender.
The default import method for an asset library can now be determined in
the Preferences. The Asset Browser has a new "Follow Preferences" option
for the importing. The essentials asset library still only uses "Append
(Reuse Data)".
This is part of #104686, which aims at improving the import method
selection, especially for the introduction of the new essentials library
(which doesn't support certain import methods). Further changes are
coming to improve the UI, see #104686.
Pull Request: #104688
This patch adds an "Essentials" asset library that is bundled with Blender.
Also see #103620. At build time, the `lib/assets/publish` folder is copied
to `datafiles/assets` in the build directory.
In the UI, the "Essentials" library can be accessed like other custom asset
libraries with the exception that assets from that library cannot be linked.
The immediate impact of this is that Blender now comes with some geometry
node groups for procedural hair grooming.
Pull Request #104474
This is needed to be able to query asset library information from an
asset. This again is relevant especially for the "All" asset library,
where you can't just directly access the library itself, which is
different for different assets.
The current design is that an asset representation is owned by exactly
one asset library, so having this pointer is perfectly compatible with
the design.
Reviewed by: Julian Eisel
Adds a new built-in asset library that contains all other asset
libraries visible in the asset library selector menu. This also means
all their asset catalogs will be displayed as a single merged tree. The
asset catalogs are not editable, since this would require support for
writing multiple catalog definition files, which isn't there yet.
Often it's not relevant where an asset comes from. Users just want to be
able to get an asset quickly, comparable to how people use a search
engine to browse images or the web itself, instead of first going to a
dedicated platform. They don't want to bother with first choosing where
they want the result to come from.
This especially is needed for the Asset Shelf (T102879) that is being
developed for the brush assets project (T101895). With this, users will
have access to all their brushes efficiently from the 3D view, without
much browsing.
Did an informal review of the asset system bits with Sybren.
The catalog tree is a unit on its own, and should be tested separately.
This makes the testing files smaller and more focused, which can help
maintaining them.
This manages setting up asset library directories for testing, which is
useful for testing multiple asset library related compontents. So move
it to a common header. No reason to squeeze everything into one file
then.
No user visible changes expected.
`AssetIdentifier` holds information to uniquely identify and locate an
asset. More information:
https://wiki.blender.org/wiki/Source/Architecture/Asset_System/Back_End#Asset_Identifier
For the start this is tied quite a bit to file paths, so that external
assets are assumed to be in the file system.
This is needed to support an "All" asset library (see T102879), which
would contain assets from different locations. Currently the location of
an asset is queried via the file browser backend, which however requires
a common root location. It also moves us further away from the file
browser towards the asset system (see T87235) and allows us to remove
some hacks (see following commit).
No user visible changes expected.
If an asset library is located on disk, store the path to it in the
asset library data. This is called the "root path" now.
With this we can construct an asset identifier, which is introduced in
the following commit.
(Probably requires ASan for a reliable crash.)
Steps to reproduce were:
* Enter Geometry Nodes Workspace
* Press "New" button in the geometry nodes editor header
* Right-click the data-block selector -> "Mark as Asset"
* Change 3D View to Asset Browser
* Create a catalog
* Drag new Geometry Nodes asset into the catalog
* Save the file
* Press Shift+A in the geometry nodes editor
There was a general issue here with keeping catalog pointers around
during the add menu building. The way it does things, catalogs may be
reloaded in between.
Since the Current File asset library isn't loaded in a separate thread,
the use-after-free would always happen in between. For other libraries
it could still happen, but apparently didn't by chance.
A `using FooPtr = std::unique_ptr<Foo>` isn't that useful usually, just
saves a few character stokes. It obfuscates the underlying type, which
is usually relevant information. Plus, `Ptr` for a unique pointer is
misleading (should be `UPtr` or similar).
Move "using" declarations and member variables to the top of the class.
See https://wiki.blender.org/wiki/Style_Guide/C_Cpp#Class_Layout.
Changes access specifiers of some variables from public/protected to
private, there was no point in not having them private.
- Move main comment on class to header comment where it's more visible.
- Improve comment.
- Move stdlib includes first, like we do it usually
- Separate includes my code module
- Remove unnecessary forward declarations
Steps to reproduce were:
- Open an asset browser
- Open an asset library with assets in it
- Load a different file (e.g. File -> New -> General)
Didn't see a nice way to fix this with the current pre file load handler
callback we use for freeing asset libraries. Using this is cleaner, but
for now, the relationship between UI and asset system is too close
still, so better do explicit freeing at the right point in time.
- Move code to manage storage to own class in own file, separates
concerns and different levels of abstraction better.
- Store local ID assets separately in the storage class for more
efficient lookups (e.g. for ID remapping).
- Make API function names and comments more complete.
Using a vector to store assets means we have to lookup the position of
the asset to be able to remove/free it. Use a `blender::Set` instead for
(nearly?) constant time removal.
Adds a new `source/blender/asset_system` directory and moves asset
related files from BKE to it. More asset related code can follow
(e.g. asset indexing, ED_assetlist stuff) but needs further work to
untangle it. I also kept `BKE_asset.h` and `asset.cc` as is, since they
deal with asset DNA data mostly, thus make sense in BKE.
Motivation:
- Makes the asset system design more present (term wasn't even used in
code before).
- An `asset_system` directory is quite descriptive (trivial to identify
core asset system features) and makes it easy to find asset code.
- Asset system is mostly runtime data, with little relation to other
`Main`/BKE/DNA types.
- There's a lot of stuff in BKE already. It shouldn't be just a dump for
all stuff that seems core enough.
- Being its own directly helps us be more mindful about encapsulating
the module well, and avoiding dependencies on other modules.
- We can be more free with splitting files here than in BKE.
- In future there might be an asset system BPY module, which would then
map quite nicely to the `asset_system` directory.
Checked with some other core devs, consensus seems that this makes
sense.
