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
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).
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.
