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.
Generally sculpt uses a combination of data from the original,
deformed, and final evaluated meshes. Keeping track of all that
is confusing and using a more specific variable name helps a bit.
The issue was introduced by b35831ad6c.
Since that commit `tree->boundary` will always be non-nullptr, even
when the target mesh had no boundaries. Some code was still relying
on the fact that `tree->boundary != nullptr` means the mesh has
boundary.
Update shrinkwrap code for this fact, avoiding access past array
boundaries.
Pull Request: https://projects.blender.org/blender/blender/pulls/120054
Also access the evaluated deform mesh with a function rather than
directly from object runtime data. The goal is to make it easier to use
implicit sharing for these meshes and to improve overall const
correctness.
Hans Goudey
YimingWu
Christoph Lendenfeld
Omar Emara
Campbell Barton
Falk David
Jacques Lucke
alxdsptr
Sean Kim
Iliya Katueshenock
Aras Pranckevicius
Lukas Tönne
Sergey Sharybin