As mentioned in new code comments, the auto smooth behavior in 4.0 was
to skip sharp angle tagging when the evaluated mesh had custom normals.
There was already a check for custom normals on the original mesh (we
can't access the evaluated mesh from versioning code). But that didn't
handle cases where custom normals were created by modifiers (the normal
edit and weighted normal modifiers). Now skip adding the new modifier
when those modifiers come last in the stack. Alternatively we could
check if they existed in the stack at all, but that seems a bit more
risky.
The `cache.curves_cache.proc_attributes_buf[i]` is independent of the subdivision level.
Therefore it's not freed when the subdivision level changes currently. However, the
check assumed that when no attribute was changed, the final subdivided buffer is
non-zero, which is not true when the subdivision level changed.
Now directly check whether the attribute is cached already.
Pull Request: https://projects.blender.org/blender/blender/pulls/119216
When linking a collection from library, it can be linked inside another
linked/overrided collection if it is selected in outliner. This can be
prevented by linking with editable parent collection.
Pull Request: https://projects.blender.org/blender/blender/pulls/119144
The depth pass of the Viewport Compositor has low precision if the
precision of the node tree is set to Auto. To fix this, we always
expose the depth pass in full precision.
The new operator "View in Graph Editor" (#114407) only looked at the selection
when generating the FCurve bounds.
This failed in certain cases if things are not selected, or not selectable.
The simplest example is to key the emission strength of the world settings and
try to view that.
This was mentioned by Jonathan Lampel on the PR #114407
The fix is to also resolve the bounds of the animation data on the button.
This means for a few FCurves the bounds might be calculated twice but it
doesn't change the overall result.
This has another side effect though:
The Graph Editor might zoom into an area where there is no FCurve
visible because the thing is not selected so it isn't shown.
This issue existed before if filters were applied, but is now more pronounced
since by default the Graph Editor doesn't show unselected objects.
A warning is raised when at least one of the FCurves that are viewed is not
visible with the current filter settings. The view will still zoom into that area.
Pull Request: https://projects.blender.org/blender/blender/pulls/118658
Caused by 9c1da81a4c.
This happened in the case where objects shared the same data and slots
are assigned to object and receiving object did not have a material slot
yet.
Then, `ob->matbits` may be NULL, now just check for this, too.
Pull Request: https://projects.blender.org/blender/blender/pulls/119161
The property is actually there, but was marked PROP_SKIP_SAVE |
PROP_HIDDEN in 4234cddda9
This PR removes this again (with the consequence that shortcuts/menu
entries will now remember the select setting from the last time).
This is now in line to how editmode does this (the "Reveal Hidden"
operator).
Pull Request: https://projects.blender.org/blender/blender/pulls/119153
When in mesh editmode, skin_vertices point to bmesh customdata, the
skin_vertices data is empty since custom data is stored per element
instead of a single array there (same es UVs etc.).
Fix similar to 3e2619b3e7, 5179b8236b (basically disallowing the
access in editmode).
Pull Request: https://projects.blender.org/blender/blender/pulls/119149
In future files from 4.2, `object_to_world` is moved to a runtime struct
and therefore isn't saved in files. It was always considered runtime information
though, since it's built by depsgraph evaluation and copied back to the original
object. Therefore to have the proper data in `object_to_world` we need to
evaluate the depsgraph.
This partially solves #118694, but there is still an issue with the snap cursor
system never running before using the `plane_omat` value.
For example, creating the "position" attribute with the wrong name or type
could crash Blender when exiting edit mode. This is because some data isn't
stored as attributes in Blender, and the attribute API doesn't work very well
with BMesh.
Two parts to the solution:
- Remove builtin attributes with incorrect domains or names when
converting from BMesh to Mesh.
- Add error messages when creating builtin attributes in edit mode. It's still
possible to create name-convention attributes, because Blender should be
able to handle different types and domains for them.
Pull Request: https://projects.blender.org/blender/blender/pulls/119110
Regression in 427eed292d.
Root of the issue was that animation system was using a single same
check to decide if an F-Curve/driver was valid to use to animate some
data, and whether user can create/edit animation for that data.
Both cases are actually different, since e.g. linked data is not
user-editable, but it can still be animated (either by related linked
Actions, drivers defined in the linked data, or some more hackish
changes like py API/RNA scripting).
This commit now defines two checks:
* `RNA_property_animateable`: whether a RNA pointer & propoerty is
animateable, based on their types and definition.
* `RNA_property_anim_editable`: whether a specific data referenced by
the RNA pointer and property is effectively user-editable.
The new `driveable` check added by 427eed292d is also renamed to
`RNA_property_driver_editable` (since the basic type-based
`RNA_property_animateable` is also valid for drivers currently).
Pull Request: https://projects.blender.org/blender/blender/pulls/119089
The Realtime Compositor crashes with intricate node setups. That's
due to hardware limitations where shaders can't have as many output
images as needed by the compositor shader operations. To fix this, we
recursively split shader operations until their output count fits the
hardware limitation.
Pull Request: https://projects.blender.org/blender/blender/pulls/119075
Typically nodes that edit instances only change the top level of
instances. As an oversight, that wasn't done in the sort elements node.
This causes problems as the top level of instances are reordered and
nested instances are edited. As the top-level is replaced, its
contained geometry sets (the nested instances) are deleted.
To fix, only reoder the top-level instances in this node.
The "capture field on geometry" utility is used in many places to store
the result of field evaluation as an attribute. There is a special case
for when an attribute already exists with the same name, data type, and
domain. But when exactly the same attribute was stored, it would assert
because it ended up copying an array to itself. Arguments for those copy
functions aren't supposed to alias each other.
As a fix, clarify the logic a bit to return earlier in this case.
Also remove a redundant case handling the same thing later on
in the function.
Pull Request: https://projects.blender.org/blender/blender/pulls/119063
This PR adds an extra check to exit from sculpt gesture code early to
avoid attempting to allocate a 3 * (UINT_MAX - 1) amount of elements
inside the trim gesture code.
Pull Request: https://projects.blender.org/blender/blender/pulls/119073
The armature reported had two bones with a `bMotionPath` but its lengths
are zero (which causes trouble in `motion_path_cache` drawing code due
to 0 allocations).
Not exactly sure how we got there, something like
`animviz_verify_motionpaths` should take care of this already in current
code, but this might be from a time where there were not enough sanity
checks.
So now early out in `motion_path_cache` if we encounter such a
"corrupted" motion path.
Pull Request: https://projects.blender.org/blender/blender/pulls/119081
This can happen e.g. when relative "//" is in Preferences > File Paths >
Temporary Files is used.
Now catch the corresponding COLLADASW::StreamWriterException
and cancel export then.
NOTE: 51126fab33 might have prevented the most common case
to run into this crash (but there might be other cases still so being safe
here does not hurt)
Pull Request: https://projects.blender.org/blender/blender/pulls/118958
Regression from 427eed292d, in IDProperty case the 'ensured' PropertyRNA
pointer is some sort of empty template, and cannot be used for many
things.
Instead of calling `rna_ensure_property` twice for each call to
`RNA_property_animateable`, rather add an optional parameter to static
helper `rna_property_editable_do`, and call it directly from
`RNA_property_animateable`.
Although rare (and not recommended!), it can happen that a same exact
RNA path points to a different type of data.
This can come from an update of the code itself, but this is very
unlikely and discouraged.
However, geometry nodes and their 'modifiers' interface have made it way
more easy to create such conflicting situation, since users are free to
re-arrange and edit the nodes and their 'public' interface as they
want...
Found out while investigating some unrelated issues in some studio Gold
production files (namely,
`pro/shots/090_joining_whale/090_0130/090_0130-anim.blend` r2110
exhibits such issue for `OBGEO-mika-body`
`modifiers["RIG-GN-mask-clothing"]["Socket_3"]`, where the RNA type
changes from integer to bool).
Other minor changes:
- Remove reference to `TMP` environment variable in the `--help` text
as this isn't a posix standard and is noted as something that may be
removed in the future.
- Show WIN32 `TEMP` when showing all help text so it will be included
in the user manual.
Fix for Sculpt: Color Filter crash #117824
This change fixes the crash due to invalid active color layer
in the Undo/Redo stack when redoing from the original state.
Previously when performing a redo to a filter color state from the
original state, it cased a crash because
&((SculptUndoStep *)us_iter)->active_color_start did not contain valid
color data in the original state.
In this PR we check if is the original state and use the
&((SculptUndoStep *)us_iter)->active_color_end instead which is
de correct data to use.
- [x] Fix color update when redo from initial state
Pull Request: https://projects.blender.org/blender/blender/pulls/118885
`sock_rotation` has higher priority (6) than the vector socket (4).
Hence inserting node between vector-vector link joins thorugh "rotation"
socket (`get_main_socket()` / `get_main_socket_priority()`).
This can be fixed by making "vector" input socket as default for link.
But this will break the link creation when node is inserted between
rotation-rotation link. It seems rotation is converted to vectors so
perhaps make sense to make "vector" as default socket for link.
Pull Request: https://projects.blender.org/blender/blender/pulls/116550
The clipping was introduced because it looked a bit like the dots are
above the scrollbar. However, the clipping looks worse and the dots
are actually below the scrollbar. If we don't want stuff to be visible
through the scrollbar, it should be more opaque.
It's possible that multiple custom data layers share the same underlying data.
This data is only written once (per data-block) currently. However, when reading
the data again, two separate `ImplicitSharingInfo` were constructed which
referenced the same underlying memory. The fix is to reuse previously created
`ImplicitSharingInfo` that manage the same data.
Pull Request: https://projects.blender.org/blender/blender/pulls/118991
When adding strips that generate image on their own, while 3 or more
strips are selected, it emits error. This was caused by incorrect
handling of this case in `seq_effect_find_selected()`. If effect has no
inputs, function should return early.
Pull Request: https://projects.blender.org/blender/blender/pulls/118866
Second issue reported in the comment was caused by some shapekeys
flagged as embedded liboverride data, when their owner ID (Mesh e.g.)
is not a liboverride at all.
The `BKE_lib_override_library_validate` called on file read was only
covering real liboverride IDs, which where then supposed to take care of
their own embedded data. But since the owner ID is already a full
non-override ID, its embedded data ended up never being properly
sanitized.
Most likely more corruption data from quite old files and/or deprecated
experimental features.
For various reasons, node tools don't support some data. Shape keys aren't
supported because their format is entirely different for evaluated and
original data-blocks, and node tools currently work in the "evaluated"
world. Though that would be nice to change, in the meantime users
should at least be warned when this happens.
This PR adds a simple "Mesh shape key data removed" operator warning.
See #113662
Pull Request: https://projects.blender.org/blender/blender/pulls/118986
This fixes#116096 and is based on #115249 with some changes.
This patch contains three changes:
* `NodeSocket.links` in the Python API gives the links in the correct order.
* `NodeLink.multi_input_sort_id` gives read-only access to an id that's used
for sorting. Note that for historical reasons the highest id is the first link.
* `NodeLink.swap_multi_input_sort_id(other_link)` provides a safe way to
change the order of links connected to a multi-input socket.
Co-authored-by: Adrian Bibby Walther <adrianbibbywalther@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/118987
Building the depsgraph from a worker thread is unsafe currently, as it
may trigger some deferred processing on the Main data itself.
Mimic what was already done for USD (from `5cf3654d9d`) and build the
graph before launching `export_startjob`.
Pull Request: https://projects.blender.org/blender/blender/pulls/118974
This PR initializes all brushes with the default automasking cavity
curve when a `startup.blend` file is loaded. Because there exists a
series of brushes that are added if they are not found in the
`startup.blend` file (e.g. "Paint") **after** the file is already
loaded, the existing fallback code to handle `nullptr` in the loader
code does not run.
Pull Request: https://projects.blender.org/blender/blender/pulls/118943
Recurse selection was not restricted to "mouse over icon" during range
selection (i.e. if we shift- double click on any area of tree element,
resurse select is still executed, which is wrong)
Also did a bit cleanup to use existing `is_over_icon` instead of calling
`outliner_item_is_co_over_icon` multiple times
Pull Request: https://projects.blender.org/blender/blender/pulls/118556
The `RNA_property_animateable` would check for some conditions, where it
is not valid to add or edit animations (e.g. if using a linked Action
ID...).
Add a new `RNA_property_drivable`, which is essentially a call to
`RNA_property_animateable` with extra checks in liboverride cases, as
drivers are stored directly in the AnimData struct, instead of their own
dedicated ID.
Pull Request: https://projects.blender.org/blender/blender/pulls/118809
There seems to not be a strict rule to only have armatures as parents to
single bones, apparently collada files can also be set up to have mesh
parents for bones. As a consequence, the collada importer
`joint_parent_map` is not safe to fetch objects from and assume their
data can be cast to `bArmature`.
Ultimately, the `joint_parent_map` needs to be looked at again, this
patch just avoids a crash in this scenario (so no such joints will be
iported). Still better than crashing I guess.
Pull Request: https://projects.blender.org/blender/blender/pulls/118751
One of the consequences of the mistake in 3fcf535d2e (fixed in previous
commit), was that the more recent `LIB_EMBEDDED_DATA_LIB_OVERRIDE` ID
flag could be wrongly set in some nodetrees from pre-2.76 blendfiles.
This commit adds a check that embedded IDs flagged with
`LIB_EMBEDDED_DATA_LIB_OVERRIDE` are actually embedded IDs of a
liboverride.
Pull Request: https://projects.blender.org/blender/blender/pulls/118921
