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.
SubdvigCCG is null for the evaluated mesh in the render depsgraph
because of the `!for_render` check in `MOD_multires.cc`. But the PBVH
type is still `PBVH_GRIDS`. That's a weird inconsistency that ideally
wouldn't happen, but probably isn't simple to change. The simplest and
most obviously harmless fix is to just check whether the list of PBVH
nodes to update is empty.
The issue was that the `PointerRNA` passed to `BKE_animsys_get_nla_keyframing_context`
needs to point to an `ID` which wasn't the case when keying bones.
That is because internally the `FCurve` path is used to resolve the property.
This can only work from the `ID` because the `FCurve` path is always stored relative to that.
While the function doesn't fail when the property can't resolve the path, it won't actually do
the remapping when passing it to `BKE_animsys_nla_remap_keyframe_values` later.
Pull Request: https://projects.blender.org/blender/blender/pulls/120008
Handling animation of GPv3 in itself is relatively straightforward, it's
mainly a matter of duplicating animdata into the new GreasePencil ID.
In case some propoerties need to be remapped, this will be done in a
similar way as e.g. GP object's modifiers animation for Object-level
animation.
The complex and ugly part of this PR is in the need to move animation
from GPdata to Object level for some properties. This PR tackles the
'layer adjustments to modifiers' aspect (i.e. adjustments on tint and
thickness).
Known limitations currently with these GPData to Object animation:
* NLA is not supported (i.e. if an NLA in legacy GP data controls these
adjustments animations, it won't be converted to Object-level NLA to
control matching modifiers settings).
* Drivers targets are not handled either, i.e. in case a driver is using
data from legacy GPdata as input, these will be left as-is (this is
true for all anim handling currently).
* There is no adjustments of values for animation (e.g. the thickness
adjustment values would need to be devided by 2000).
Most of these limitations can be addressed at some point, depending on
how critical they are to support. This would have a cost (in time and
code complexity) though.
Pull Request: https://projects.blender.org/blender/blender/pulls/119214
Caused by 6a79a6a24a
`Mask` `AnimData` is read by `BKE_animdata_blend_read_data` since above
commit, so `BLO_read_data_address` on `AnimData` is already done there.
However, `mask_blend_read_data` does it again
Similar calls to `BLO_read_data_address` in `blend_read_data` callbacks
were usually removed in 6a79a6a24a, Masks being an exception.
Accoding to @mont29 the reason while a double remapping will fail is
because there can only be one remapping from old addresses to new ones.
Once the new address has been read, this new address cannot be used as
'key' again (it will likely map to nothing, or worse, remap to something
completely unrelated!)
Pull Request: https://projects.blender.org/blender/blender/pulls/119961
Remove all BLF "_ex" versions of functions by using default arguments.
These functions only differ by having an optional argument that can
return extra details about the result of the operation. This PR just
make these part of the main function as optional arguments with default
values - all nullptr.
Pull Request: https://projects.blender.org/blender/blender/pulls/119994