Implements a crash dialog for Windows.
The crash popup provides the following actions:
- Restart: reopen Blender from the last saved or auto-saved time
- Report a Bug: forward to Blender bug tracker
- View Crash Log: open the .txt file with the crash log
- Close: Closes without any further action
Pull Request: https://projects.blender.org/blender/blender/pulls/129974
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/136134
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
The compositor backdrop is still visible even after a new completely
different file is loaded. This is because compositor contexts cache
things like the backdrop, and contexts are stored on interactive
compositor renders, which are not freed until Blender is closed. To fix
this, we cleanup the interactive compositor renders that were created
upon file load.
Pull Request: https://projects.blender.org/blender/blender/pulls/135390
Code in readfile that copies over brush assets (and related data) from
the old Main to the new one cannot use the namemap reliably, due to how
the linked IDs of the library get temporarily spread between both Mains.
Since in theory there should be no need for name uniqueness processing
in this case anyway, for now disable the relevant code when the library
is re-used.
NOTE: Issue reported in #135315, revealed by recent refactor in
00f406c34c and 16e552298c.
NOTE: This fix is a bit hackish, but seems to be the simplest most
straight-forward way to address the problem. More invasive solution can
be investigated if this proves to still be problematic.
NOTE: While 4.4 also has the same invalid handling, this PR should
likely not be ported to it, as previous BKE_main_namemap code was more
permissive with such invalid behaviors, and there is no known bad
consequences in practice.
Pull Request: https://projects.blender.org/blender/blender/pulls/135362
Note: This commit is essentially non-behavioral change, expect in some
fairly rare edge cases.
This commit does a few things:
* Move the whole BKE_main_namemap code to modern C++.
* Split API calls to work with the global namemap, or the local ones.
* Simplify and make the code easier to follow and understand.
* Reduce 'default' memory usage by using growing BitVector for numeric
suffix management, instead of a fixed 1K items.
* Fix inconsistent handling of 'same base name and numeric suffix,
different name' issues (e.g. 'Foo.1' and 'Foo.001'), see
`re_create_equivalent_numeric_suffixes` new unittest.
* Fix completely broken handling of `global` namemaps. This was
(probably!) OK so far because of their currently very limited
use-cases.
It also adds a few minor improvements to existing behavior (essentially
in exotic rare edge cases):
* Names that get too long are now only shortened by one char at a time,
trying to modify the requested base name as little as possible.
* Names that are short, but for which all the manageable numeric suffixes
are already in use, are extended with an (increasing) number, instead
of being shortened.
This work also allowed to detect a few (apparently harmless?) bugs in
existing code, which have been fixed already in 4.4 and main, or in this
commit as well when they depend on changes in namemap code itself.
About performances: This commit introduces a minor slow-down. Some tests
heavily relying on this code (like `bl_id_management` and `blendkernel`
e.g.) get slightly slower (resp. about 1% and 5%). This seems to come
mostly from the added complexity to handle correctly multiple different
names with the same base and numeric suffix value ('Foo.1' and
'Foo.001', but also in the global namemap context where IDs from
different libraries can have the same name).
Pull Request: https://projects.blender.org/blender/blender/pulls/135199
Move `Library.runtime` to be a pointer, move the related
`LibraryRuntime` struct to `BKE_library.hh`. Similar to e.g.
Mesh.runtime, that pointer is expected to always be valid, and is
allocated at readtime or when creating a new Library ID.
Related smaller changes:
* Write code now uses standard ID writing codepath for Library IDs too.
* Runtime pointer is reset to nullptr before writing.
* Looking up a library by its absolute path is now handled through a
dedicated utils, `search_filepath_abs`, instead of using
`BLI_findstring`.
Pull Request: https://projects.blender.org/blender/blender/pulls/134188
Compilers do not seem to agree on valid printf format for `int64_t`,
recent clang 19 on linux requires `%ld`, while older compilers like the
buildbot ones of clang 15 on OSX ask for `%lld`.
So instead, cast the value to `int32_t`. Other solution may have been to
use `PRId64`, but this is fairly bad for readability.
Check done by PartiaWriteContext writing code to ensure there is no
library ID written which filepath is the same as the destination
blendfile path of the context, was flacky in case there would be
multiple library IDs with that same path.
While this is not expected situation currently, it will likely change in
the future, so handle that properly, and generate a CLOG warning.
The handling of library for IDs added to a PartiaWriteContext in 'make
local' mode (i.e. to make them local in the written blendfile) was
flacky, leading to invalid removal of the ID name from the library ID
namemap in G_MAIN.
Now simply esure there is a local copy of the library too when adding an
ID to the context, even if it will be made local there.
Previously, the owner-id on localized node trees, like the one created in
`GPU_material_from_nodetree` would have `bNodeTree::owner_id` set, even though
they were independent. The leads to asserts when using `BKE_id_owner_get` on the
localized node tree.
The `node_tree_localize` already took a `ID *new_owner_id` parameter. However,
if it was `nullptr` it was ignored instead actually clearing the `owner_id`.
This patch changes the parameter to `std::optional<ID *> new_owner_id`. Now,
`std::nullopt` means that the value is ignored and when `nullptr` is passed in,
the `owner_id` will be cleared on the localized tree.
Since `node_tree_localize` indirectly uses other functions, the same function
signature change is done in `BKE_libblock_copy_in_lib` and `BKE_id_copy_in_lib`.
The callers have been updated to pass in `nullopt` instead of `nullptr`.
Pull Request: https://projects.blender.org/blender/blender/pulls/133002
Move the `ID_TAG_ID_LINK_PLACEHOLDER` bit of `id->tag` to
`id->runtime.readfile_data->tags.is_id_link_placeholder`. It also
introduces the necessary stucts and allocation/freeing code.
Old code:
```cpp
if (id_tag & ID_TAG_ID_LINK_PLACEHOLDER) {
```
New code:
```cpp
if (readfile_id_runtime_tags(id).is_id_link_placeholder) {
```
where `readfile_id_runtime_tags(id)` is a getter for
`id->runtime.readfile_data->tags` that is null-safe for
`id->runtime.readfile_data`. The `readfile_data` is not allocated in
these cases:
1. When reading undo steps, because that doesn't have to deal with
versioning or linking (which are the sole purposes for this
struct).
2. When linking from another file (for example from the 'Link...'
operator). The just-linked IDs will have the `readfile_data`
struct, but already-loaded IDs will already have had those freed.
No functional changes intended.
Pull Request: https://projects.blender.org/blender/blender/pulls/132169
Design Task: #131695
The new --disable-liboverride-auto-resync commandline option will prevent
running liboverride auto-resync immediately after loading a blendfile.
This is an alternative way to setting the User Preferences Debug option
`No Override Auto Resync`.
-------
Some quick performances tests:
Loading a Gold production file goes from 26.5s to 25.9s.
Combined with the recent `--disable-depsgraph-on-file-load` option, it
goes from 3.5s to 2.9s, so another nice extra 15% speedup when only
bare-metal blendfile loading is needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/132017
Give the `IDWALK_…` enum an explicit name: `LibraryForeachIDFlag`. This way
the flags are type-safe, and it's known where values come from. This is
much preferred (at least by me) to just having `int flags`.
Uses of `0` have been replaced with `IDWALK_NOP` as that has the same value
and is of the right type.
One invalid use of `IDWALK_CB_NOP` was detected by this change, and is
replaced by `IDWALK_NOP`.
This change might be incomplete; I gave the enum a name, and then fixed
the compiler errors.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/131865
Two commits that basically do the same thing for two `enum`s: give
them a name.
- the `IDWALK_…` enum → `LibraryForeachIDFlag`.
- the `IDWALK_CB_…` enum → `LibraryForeachIDCallbackFlag`.
This way the flags are type-safe, and it's known where values come
from. This is much preferred (at least by me) to just having `int
flags`.
Uses of `0` have been replaced with `IDWALK_NOP` and `IDWALK_CB_NOP`,
as those have the same value and are of the right type.
One invalid use of `IDWALK_NOP` was detected by this change, and is
replaced by `IDWALK_CB_NOP`. And another one in the opposite
direction.
This change might be incomplete; I gave the enum a name, fixed the
compiler errors, and then also updated assignments like `int cb_flag =
cb_data->cb_flag`. I might have missed some assignments to `int`
though.
No functional changes.
----------
I intend to land this PR as its two separate commits. I just put them in the same PR so the buildbot can handle them in one go, and we don't have a stack of highly relatled PRs.
In the future this could also apply to the `IDWALK_RET_…` enum. This one I left out, though, because a proper cleanup there would also have to include their ambiguity on whether they are bitflags (like the enums in this PR) or not. Their values and the code in `BKE_lib_query_foreachid_process()` implies they are bitflags, but in practice they are never or'ed together and just used as discrete values.
Pull Request: https://projects.blender.org/blender/blender/pulls/131803
Either initial fix (9405bd25d6) was not fully correct (and properly
tested), or something else changed since then, but the handling of
liboverrides in copy/paste of poses would not be correct for local
overrides.
Instead of relying on generic `BKE_lib_id_make_local` to also work
for local liboverrides, add some more logic in `PartialWriteContext::make_local`
to properly handle local liboverrides when the override data needs to get
removed in the copy buffer blendfile.
NOTE: Not super-happy with how make local and removal of liboverrides
somewhat mix together currently. Will need to revisit once again that
whole process at some point.
Brushes and changes done to them are preserved now when loading
different files (until Blender closes). Unpin and clear the material
assigned to the brush when loading a different file, since this material
is local to the previous file.
Pull Request: https://projects.blender.org/blender/blender/pulls/128080
Do copy asset data when copying an ID into the PartialWriteContext.
Currently there does not seem to be any use-case where this would not be
the desired behavior. This can be made an optional behavior in the
future if needed.
In grease pencil draw mode, enable the Draw, Erase and Utilities
catalogs by default for the asset shelf, meaning they will show up as
tabs in the shelf. For grease pencil sculpt mode it's the Contrast,
Transform and Utilities mode (consistent with mesh sculpt mode).
This makes the assets of the corresponding types easily available, even
without requiring the "Filter Brushes by Tool" asset shelf option
enabled. It also makes the catalogs and the contained brushes more
discoverable as an organization helper.
These catalogs were added in 09bd5a5777.
This commit adds low-level logic in BKE to support three behaviors in
case of name conflict when renaming an ID:
1. Always tweak new name of the renamed ID (never modify the other ID
name).
2. Always set requested name in renamed ID, modifying as needed the
other ID name.
3. Only modify the other ID name if it shares the same root name with the
current renamed ID's name.
It also adds quite some changes to IDTemplate, Outliner code, and
RNA-defined UILayout code, and the lower-level UI button API, to allow
for the new behavior defined in the design (i.e. option three from above list).
When renaming from the UI either 'fails' (falls back to adjusted name) or forces
renaming another ID, an INFO report is displayed.
This commit also fixes several issues in existing code, especially
regarding undo handling in rename operations (which could lead to saving
the wrong name in undo step, and/or over-generating undo steps).
API wise, the bahavior when directly assigning a name to the `ID.name`
property remains unchanged (option one from the list above). But a new
API call `ID.rename` has been added, which offers all three behaviors.
Unittests were added to cover the new implemented behaviors (both at
BKE level, and the RNA/Py API).
This commit implements #119139 design.
Pull Request: https://projects.blender.org/blender/blender/pulls/126996
Code executed in `BLO_read_do_version_after_setup` would not update in
any ways the info in link/append context data.
NOTE: this could potentially be extended to other code in this 'complex
do version' area. However, other versionning did not cause issues
apparently so far, so would rather until such changes are proven needed.
Previously, values for `ID.flag` and `ID.tag` used the prefixes `LIB_` and
`LIB_TAG` respectively. This was somewhat confusing because it's not really
related to libraries in general. This patch changes the prefix to `ID_FLAG_` and
`ID_TAG_`. This makes it more obvious what they correspond to, simplifying code.
Pull Request: https://projects.blender.org/blender/blender/pulls/125811
There was already code to handle active scene pointer for the window.
Simply replace it by a call to `wm_data_consistency_ensure`, which will
ensure that all potentially missing pointers in UI data get reset.
Match function and declaration names, picking names based on
consistency with related code & clarity.
Also changes for old conventions, missed in previous cleanups:
- name -> filepath
- tname -> newname
- maxlen -> maxncpy
Add an explicit mask in `IDAddOperations` for flags that are inherited
by default for dependencies of explicitely added data.
And refactor handling of per-id-usage flags returned by the
`dependencies_filter_cb` callback to also have a mask value defined in
`IDAddOperations`, as this is clearer and easier to maintain than a
constexpr hiddin in implementation code.
This is used by ID copy/paste code to detect which IDs from a copy/paste
buffer can be used as paste source.
Also slightly refactor implementation to handle both fake/extra ID user,
and clipboard mark in the same utils function.
`DUPLICATE_DEPENDENCIES` was wrongly used instead of `ADD_DEPENDENCIES`,
the former should be considered a non-modifiable option for a whole
'add' operation. But the per-ID-usage callback should be able to force a
dependency to be added or cleared.
This is the main merge commit of the brush assets project. The previous
commits did some preparing changes, more tweaks are in the following commits.
Also, a lot of the more general work was already merged into the main branch
over the last two years.
With the new design, quite some things can be removed/replaced:
- There's a unified "Brush" tool now, brush based tools and all special
handling is removed.
- Old tool and brush icons are unsed now, and their initialization code
removed here. That means they draw as blank now, and the icon files can be
removed in a follow up.
- Creation of default brushes is unnecessary since brushes are now bundled in
the Essentials asset library. Icons/previews are handled as standard asset
previews.
- Grease pencil eraser options are replaced by a general default eraser brush
that can be set by the user.
More changes are planned still, see task list issue below.
Main Authors: Bastien Montagne, Brecht Van Lommel, Hans Goudey, Julian Eisel
Additionally involved on the design: Dalai Felinto, Julien Kaspar
Blog Post: https://code.blender.org/2024/07/brush-assets-is-out/
Tasks:
https://projects.blender.org/blender/blender/issues/116337
Reviewed incrementally as part of the brush assets project, see:
https://projects.blender.org/blender/blender/pulls/106303
