#114401 added forward compatibility code to remove unsupported socket
types and avoid crashing with unknown default_value data. However, this
did not update link pointers (which haven't been read at that point),
so the tree can end up with dangling pointers.
To fix this, removal of unsupported sockets is moved further back to a
point where links have been read and can be fixed accordingly.
Ported to main from #119630
Pull Request: https://projects.blender.org/blender/blender/pulls/119650
This adds two functions to the `Drawing` class: `fill_colors()`
and `fill_colors_for_write()`.
In places where the attribute API was used directly, these
functions are now used instead.
This is part of #119080. The point is that developers
shouldn't need to remember the name, type, default value,
and domain of built-in attributes (e.g. used by the renderer).
Pull Request: https://projects.blender.org/blender/blender/pulls/120296
The root of the issue, as identified by Jake-Faulkner in his PR
(!120099), was that after changes in commit 195bb4f8f5,
`BKE_libblock_ensure_unique_name` would not always correctly set
`bmain->is_memfile_undo_written` to false when an ID name was actually
modified.
However, after analyzing a bit more the code in ID renaming, it appeared
that `BKE_libblock_ensure_unique_name` was not needed and only made
things more confusing. Some ID renaming code (from RNA, the Outliner,
and some do_version areas) would then do some manual ID renaming
operations and then call it, instead of simply using the existing 'all
in one' `BKE_libblock_rename` function.
This commit removes `BKE_libblock_ensure_unique_name` and all of its
usages, and simplify all code previously using it by calling
`BKE_libblock_rename` instead.
NOTE: The only non-trivial (not-so-nice) aspect of this commit is the
changes needed in the Outliner renaming code, since here the name of the
ID is directly edited, before calling the rename function, so this edit
needs to be undone to allow calling the generic ID rename API.
Pull Request: https://projects.blender.org/blender/blender/pulls/120196
Because normals are calcualted lazily for all cases "depends_on_normals"
except for BMesh original normals, this is mostly unnecessary. It's actually
probably not necessary at all, because in practice there is always a separate
positions array stored in `EditMeshData` during mesh edit mode modifier
evaluation, bringing us back to the lazy calculation. But anyway, removing
the usage for topology-changing modifiers and modifiers which don't
accept BMesh as input anyway simplifies things.
Pull Request: https://projects.blender.org/blender/blender/pulls/120274
This resolves#120220.
The `parent_group()` and `parent_node()` functions would be
callable on `const` instances but return a non-`const` pointer/reference.
This introduces `const` and non-`const` variants of these
methods.
Pull Request: https://projects.blender.org/blender/blender/pulls/120261
When an object uses linked mesh data and the object and the modifier
node group are made local after versioning runs for the first time,
a new modifier is added every time the file is opened. An obvious
fix is to check whether there is already a modifier with the versioning
node group. In that case we can skip the object.
This doesn't fully fix the scenario from #120030; it requires that
the node group is made local so it doesn't leave a reference to
a non-existent library data-block.
The issue from the bug report mentions that the `Limit Rotation` constraint snaps
back to 0 when reaching 180 degrees with a min and max of 0 / 180.
The root cause of this goes a bit deeper though. Because the following also snaps back to 0.
* min max of 0 / 360
* angle of 185
The reason for this is that the clamping logic in the constraint was very simple.
It just took the matrix, decomposed it to euler and clamped the values directly.
However in that process, the euler angles are bound to a range of -180 / 180,
which means that any angle >= 180 would snap back to the min.
Pull Request: https://projects.blender.org/blender/blender/pulls/118502
The GPv3 tint modifier will give incorrect result in fill tint due to
two reasons: 1) The material index being wrong; 2) The default value
for `fill_color` attribute needs to be explicitly assigned as
`ColorGeometry4f(float4(0.0f))` to ensure correct color mixing and
switching between fill/material color in the tint modifier.
Pull Request: https://projects.blender.org/blender/blender/pulls/120249
Blend files with compositor node trees saves in 4.2 do not work in older
version. This is because 4.2 removed the chunk size property of the node
tree, so it is set to zero, which is invalid in older versions. To fix
this, we add it again as a deprecated DNA member, and set it to default
value upon write.
Pull Request: https://projects.blender.org/blender/blender/pulls/120246
This was caused by ab84f9eaf0.
The issue is that setting the flag in the `TreeNode`
constructor means that the root group will always
hide masks when its created. This effectively disables
masks in the entire object.
Instead, leave the default flag to be `0` (masks enabled)
and explicitly set the `HIDE_MASKS` flag when
creating a new layer/layer group.
Pull Request: https://projects.blender.org/blender/blender/pulls/120218
Implements the GPv2 onion skinning functionality.
There are no functional changes exept for the `use_ghosts_always`
option, which has been removed. This was used to show onion
skinning in the final render.
Pull Request: https://projects.blender.org/blender/blender/pulls/119792
After some discussions and investigation over the last couple months,
it's not clear what the "wrapper type finalize" logic is necessary for.
For edit meshes and regular meshes, normals are calculated lazily when
building the draw cache.
Apart from the unnecessary complication for mesh GPU draw data
extraction, this code also causes normals to always be calculated
when turning an edit mesh wrapper into a regular mesh. However, those
normals are immediately discarded since the edit deform cache is deleted
in the next line.
Beyond the obvious simplification, the motivation for this change is to
avoid requesting write access on the evaluated mesh and cage mesh. This
works better with implicit sharing, allowing other improvements.
Pull Request: https://projects.blender.org/blender/blender/pulls/120066
Avoid copying the positions array into the evaluated edit hints array
that's used to support editing with deformed positions when there is
a topology-changing procedural operation. In a simple test in sculpt
mode with 706k curve points, memory usage went from 78 to 70 MB.
This adds more duplication would be ideal, mainly because retrieving
the data with write access and making implicit sharing info for arbitrary
arrays aren't abstracted by implicit sharing utilities. It may be possible
to improve both of those aspects, either now or in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/120146
`xxHash` is a fast non-cryptographic hashing library. It significantly outperforms
md5 which we use in some places currently while also having great collision
resistance if not attacked explicitly.
The library is added to `extern` because that was the easiest way to do it and has
the least impact on others. I expect this library to become a required dependency
instead of an optional one. It's licence is `BSD 2-Clause` which seems to be the
first of its kind in Blender (there is `BSD 3-Clause` a couple of times).
For now, I used the library only for data deduplication when baking geometry nodes
where the same geometry is generated for each frame. The bake time in my test
goes down from >6s to <1s (note that this includes more than just the hashing time).
Pull Request: https://projects.blender.org/blender/blender/pulls/120139
after alignment, the rgb_frame's linesize is not equal to the actual
data length, so when copying the data generated from render to the
rgb_frame, they should use different linesize, one after alignment
and one before alignment.
Pull Request: https://projects.blender.org/blender/blender/pulls/120184
The root of the issue seems to be calling `BLI_snprintf` with the
wrong number of arguments in the `MorePointsForBezierRequired`
case. The fix arguably makes things simpler anyway: just use a
separate call in each case of the switch.
ffmpeg AVFrame objects should use correct alignment between image
rows, or otherwise bad things might happen. In this particular
case, multi-threaded libswscale RGB->YUV conversion was trampling
over 4 bytes of V plane, for each thread boundary.
Pull Request: https://projects.blender.org/blender/blender/pulls/120168
For some reason, the custom data type was set as `float[4][4]`
for tangents, but they are written as `float[4]`. The overallocation
might not have been a problem, since it looks like the extra memory
was never written to. But it's still confusing and potentially bad for
performance.
Since the code was added, it used the active indices of the input and
output custom data layers incorrectly. 82b88f130a exposed that
by actually modifying the active indices of the ouput custom data
correctly, but it didn't update a couple other places to take that into
account.
Large int64_t values were calculated and assigned int however the
calculation was performed on integer types which would truncate the
result before casting to an in64_t.
