There's quite a few libraries that depend on dna_type_offsets.h
but had gotten to it by just adding the folder that contains it to
their includes INC section without declaring a dependency to
bf_dna in the LIB section.
which occasionally lead to the lib building before bf_dna and the
header being missing, while this generally gets fixed in CMake by
adding bf_dna to the LIB section of the lib, however until last
week all libraries in the LIB section were linked as INTERFACE so
adding it in there did not resolve the build issue.
To make things still build, we sprinkled add_dependencies wherever
we needed it to force a build order.
This diff :
Declares public include folders for the bf_dna target so there's
no more fudging the INC section required to get to them.
Removes all dna related paths from the INC section for all
libraries.
Adds an alias target bf:dna to signify it has been updated to
modern cmake
Declares a dependency on bf::dna for all libraries that require it
Removes (almost) all calls to add_dependencies for bf_dna
Future work:
Because of the manual dependency management that was done, there is
now some "clutter" with libs depending on bf_dna that realistically
don't. Example bf_intern_opencolorio itself has no dependency on
bf_dna at all, doesn't need it, doesn't use it. However the
dna include folder had been added to it in the past since bf_blenlib
uses dna headers in some of its public headers and
bf_intern_opencolorio does use those blenlib headers.
Given bf_blenlib now correctly declares the dependency on bf_dna
as public bf_intern_opencolorio will get the dna header directory
automatically from CMake, hence some cleanup could be done for
bf_intern_opencolorio
Because 99% of the changes in this diff have been automated, this diff
does not seek to address these issues as there is no easy way to
determine why a certain dependency is in place. A developer will have
to make a pass a this at some later point in time. As I'd rather not
mix automated and manual labour.
There are a few libraries that could not be automatically processed
(ie bf_blendthumb) that also will need this manual look-over.
Pull Request: https://projects.blender.org/blender/blender/pulls/109835
This PR adds a new operator to run a node group on object geometry.
Only curves sculpt mode is supported for now, to simplify the design.
A new geometry node editor context to edit operator groups is also
added. This allows changing any node group, rather than only node
groups that are part of the active modifier context.
3D viewport menus are added with any geometry node group
asset in a catalog that contains the `Operator` tag. Currently Blender
must be restarted to refresh the list of available operators.
This is only the first phase of the node group operator feature.
Many more features will be added in next steps.
See #101778
Pull Request: https://projects.blender.org/blender/blender/pulls/108947
`AssetHandle` is meant as temporary design and should be replaced by
`AssetRepresentation`. This moves us another step closer to that.
Rather than taking data from the volatile asset handle and storing that
in the drag data, store the (more persistent) asset representation there
and access data from it where needed.
No user visible changes expected.
This brings us another step closer to replacing the temporary asset
handle design with the proper asset representation design. I held off
with this a bit because we eventually want to support non-ID assets, but
for now it is fine to consider all assets to be IDs. In future the asset
system can make the necessary distinctions still.
Now only the preview is handled via asset handle still.
No user visible changes expected.
This is needed in #104831 but makes sense to expose publicly in the
asset system APIs either way. So committing this to the main branch
already.
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
Include the term "overwrite" so users of this function are aware
this function will delete the destination file (unlike LIBC rename).
- Add BLI_rename_overwrite (previously called BLI_rename).
- BLI_rename is now a wrapper for rename.
Use BLI_rename when renaming in the file selector.
This option is true by default, but it can be changed for
any asset library (that may be using Link as import method).
This also fix "Reset to Default Value" for the Import Method
since this was originally not using the defaults.
Pull Request: https://projects.blender.org/blender/blender/pulls/107345
Keep these operations separate to simplify path handling logic & docs.
Many callers passed NULL and there were times paths were passed in which
didn't make any sense (where the paths had already been made absolute).
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.
