This allows deleting a bunch of duplicate code, since there doesn't
need to be a special single-threaded case anymore. It also just
reduces the necessary boilerplate.
Also change naming a bit and use signed integers instead of unsigned.
I didn't notice any performance difference.
Pull Request: https://projects.blender.org/blender/blender/pulls/119069
Split `BKE_fcurve_blend_write(writer, listbase)` into two functions:
- `BKE_fcurve_blend_write_data(writer, fcurve)` for the data of a single
F-Curve, and
- `BKE_fcurve_blend_write_listbase(writer, listbase)` for writing a list
of F-Curves.
And the same for `BKE_fcurve_blend_read_data()`.
This is necessary for the upcoming Animation data-block, which will
store F-Curves as arrays instead of `ListBase`s.
No functional changes.
- Pass null instead of an empty string to BKE_tempdir_init
because the string isn't meant to be used.
- Never pass null to BLI_temp_directory_path_copy_if_valid
(the caller must check).
- Additional comments for which checks are performed & why
from discussion about #95411.
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
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.
No functional changes.
This PR replaces the uses of the C-style `BLI_BITMAP`
with `blender::BitVector` in `keyframing.cc`.
Note that in `BKE_animsys_nla_remap_keyframe_values` I had to
add code that maps from one to the other because I don't feel
comfortable ripping out the `BLI_BITMAP` from
`NlaEvalChannelSnapshot->remap_domain`
Pull Request: https://projects.blender.org/blender/blender/pulls/118957
This adds implicit sharing support for the `MemFile` undo-step. This decreases memory
usage and increases performance.
Implicit sharing allows the undo system to take (shared) ownership of some data.
Previously, the data would always be serialized and compared to the previous undo-step.
So this turns an O(n) operation into O(1) (in terms of memory usage and time).
Read/write code that wants to make use of this has to use the new `BLO_read_shared`
and `BLO_write_shared` functions respectively. Those either make use of implicit-sharing
internally or do the "full" read/write based on a passed-in function. It seems possible to
use the same API in the future to store shared data to .blend files.
Improvements:
* Much faster undo step creation in many cases by avoiding the majority data copies
and equality checks. This fixes#98574. I found undo step creation and undo step
decoding to be 2-5 times faster in some demo files from the blender website and in
some production files from the Heist project.
* Reduced memory usage when there is large data in `bmain`. For example, when
loading the same highly subdivided mesh that I used in #106228 the memory usage
is 1.03 GB now (compared to 1.62 GB in `main` currently). The main remaining copy
of the data now is done by rendering code.
* Some significant performance improvements were also measured for the new grease
pencil type (#105540).
There is one main downside of using implicit-sharing as implemented here: `MemFile`
undo steps can't be written as .blend files anymore. This has a few consequences:
* Auto-save becomes slower (up to 3x), because it can't just save the previous undo step
anymore and does a normal save instead. This has been discussed in more detail here:
https://devtalk.blender.org/t/remove-support-for-saving-memfile-undo-steps-as-blend-files-proposal/33544
It would be nice to work towards asynchronous auto-save to alleviate this problem.
Some previous work has been done to reduce the impact of this change in 41b10424c7
and f0f304e240. This has been committed separately in efb511a76d.
* Writing `quit.blend` has to do a normal file save now. So it's a bit slower too, but it's
less of a problem in practice.
* The `USE_WRITE_CRASH_BLEND` functionality does not work anymore. It doesn't seem
to be used by anyone (removed in e90f5d03c4)
There are also benefits to not writing `MemFile` from undo steps to disk. It allows us to
more safely do undo-specific optimizations without risking corrupted .blend files. This
is especially useful when we want to preserve forward compatibility in some cases.
This requires converting data before writing the .blend files, but this conversion is not
necessary for undo steps. Trying to implement this kind of optimization in the past has
often lead to bugs (e.g. 43b37fbc93).
Another new problem is that it is harder to know the size of each undo step. Currently, a
heuristic is used to approximate the memory usage, but better solutions could be found
if necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/106903
- Skip leading forward slashes when setting the temp directory.
- Add a utility function to set the temporary directory
which is used for the user preferences & environment variables.
This issue was raised by #95411 where "//" resolves to "/",
then asserts when passed to Blender's file-system functions.
However the crash referenced in this report looks to be caused
by Collada failing to write to the temporary directory which
can be handled separately.
Ref !118872
Adds two nodes as "grid" equivalents to the existing volume nodes:
- **Grid to Mesh**
- **Distribute Points in Grid**
The code for the latter is just duplicated for now. In a later step
old node can be replaced by versioning with two new nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/118830
Any access to this after calling what_does_obaction would reference
invalid stack memory with undefined behavior.
Set to null to ensure this never happens.
There probably are more cases where crash will happen as it is
rooting into the issue with BKE_object_workob_calc_parent() which
is used in multiple places.
The issue is caused by the access to a runtime field of workob
outside of the BKE_object_workob_calc_parent(): the runtime field
is stack-allocated in the function, and can not be accessed outside
of the function.
The easiest way to reproduce is to use ASAN, and parent mesh to an
armature with automatic weights. Although, on macOS ASAN did not
report issues, so setting workob->runtime to nullptr at the end of
of the BKE_object_workob_calc_parent() was the easiest.
The solution is simple: make the function to return the matrix,
and take care of the working object inside of it, so all tricky
parts are hidden from the API.
The patch is targeting the main branch, as in 4.1 it is not
required to do such change because all uses of the function only
access object_to_world, which is stored in the object in 4.1.
A double-check in the what_does_obaction() might be needed as it
follows the similar pattern, but it does not seem that runtime
field of the workob is accessed in usages of the what_does_obaction().
Pull Request: https://projects.blender.org/blender/blender/pulls/118847
The time offset modifier was working differently than in GPv2. This is because in the new implementation, the time offset modifier actually modifies the keyframe mappings. And thus the order of the modifiers, and where the time offset modifier is placed in the stack, matters.
The problem is that this can lead to unexpected results like seeing unmodified drawings.
Technically, the issue here is that other modifiers only modify the current frame as supposed to all drawings in the timeline.
This is done as an optimization, but doesn't work when drawings can be shifted around on the timeline using the time offset modifier.
The fix changes the way the modifiers are executed. Because the time offset modifier can only modify **when** the drawings
are show, and not the drawing data themselves, we execute all the time offset modifiers first (in the order they appear in the stack) and then execute all the other modifiers after.
This means that the user can no longer run into the issue of "moving" drawings away from the current frame where they can't be seen.
It also makes time offset modifier behave the same as they did in GPv2.
Pull Request: https://projects.blender.org/blender/blender/pulls/118842
This rewrites the Alembic and USD data importers to work with and
output GeometrySets instead of Meshes.
The main motivation for this change is to be able to import properly
point clouds, which are currently imported as Meshes, and curves
data, which suffer from a lot of issues due to limitations of
legacy curves structures (fixed by the new curves data-block) and are
also converted to Meshes. Further, for Curves, it will allow importing
arbitrary attributes.
This patch was primarily meant for Alembic, but changes to USD import
were necessary as they share the same modifier.
For Alembic:
There should be no behavioral changes for Meshes
Curves are imported as the new Curves object type
Points are imported as PointClouds
For USD:
There should be no behavioral changes for Meshes
Curves are imported as the new Curves object type
Note that the current USD importer does not support loading PointClouds,
so this patch does not add support for it.
For both Alembic and USD, knots arrays are not read anymore, as the new
Curves object does not expose the ability to set them. Improvements can
be made in the future if and when example assets are provided.
This fixes at least the following:
#58704: Animated Alembic curves don't update on render
#112308: Curves have offset animations (alembic / USD)
#118261: wrong motion blur from usd in cycles and reverting to the first
frame when disabeling motion blur
Co-authored-by: Jesse Yurkovich <jesse.y@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/115623
String attributes are not handled correctly (or at all) by geometry nodes
currently because their storage is very inefficient and will likely have to
change in the future anyway. Elsewhere processing string attributes was
explicitly disabled. That was missing in these cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/118802
This PR adds a new method to BMLog to explicitly make the intent of
searching for an entry clear and adjusts the calling code in `pbvh_bmesh`
to utilize it.
Pull Request: https://projects.blender.org/blender/blender/pulls/118543
When an asset is heavily modified, all production files having
liboverrides of it will still try to link all their known linked
reference IDs, leading to potentially thousands of not-really-useful
warnings about missing IDs in the console.
Now that liboverrides resync cleans up better these left-over data, it's
better to report missing linked data _after_ the liboverride resync
process.
Note that the original place can still report all effectively missing
linked data if needed, but this is now a logging info, so it won't be
displayed anywhere unless explicitely requested.
Pull Request: https://projects.blender.org/blender/blender/pulls/118577
Often when the reference linked data is significantly modified, a lot of
'ghost' linked data remain referenced by liboverrides, even after
resync. This is due to the fact that missing data is ignored (skipped)
during resync process, to avoid potential destruction of data in case
the linked data is actually missing.
However, after all resync has been done, we can consider that missing
linked references and their liboverrides can be safely deleted, if the
later are not user-edited or hierarchy roots.
Internal link is not created for a node when it has rotation output
socket. This is because the missing case for `sock_rotation` in
`get_internal_link_type_priority()` which fails to find input_socket
priority in this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/118735
Armature deformation modifier for Grease Pencil v3.
Changes compared to GPv2:
- `multi` DNA field was unused and was removed.
- `vert_coords_prev` array is unused and was removed (gets passed to
armature functions but never gets allocated).
- GPv3 modifier uses the common `influence` struct to store the vertex
group name, for consistency. The
`GREASE_PENCIL_INFLUENCE_INVERT_VERTEX_GROUP` flag is copied to
`deformflag` as `ARM_DEF_INVERT_VGROUP` before evaluation, which is
used internally by armature functions.
- `BKE_armature_deform_coords_with_curves` is added as another variant
of the deform function, but uses C++ parameter types (spans instead
of raw pointers). It gets a `Span<MDeformVert>` directly instead of
deducing it internally from the object type. This is because we want
to do this curve-by-curve and already use arbitrary vector spans for
positions.
Pull Request: https://projects.blender.org/blender/blender/pulls/118752
Crash happens in `action_group_colors_set_from_posebone` /
`ANIM_bonecolor_posebone_get` on a `bPoseChannel` without a `bone`.
If I am not mistaken a new `bPoseChannel` (e.g. after duplication) will
only get its `bone` after leaving editmode.
So in a way the situation is similar to 2a8ce1f121
Behavior of `animchan_sync_group` is not reliable in a way that getting
a `bPoseChannel` from an `bActionGroup` will guarantee these are really
corresponding. So usually, if you dulplicate/symmetrize a bone, there
would be no corresponding `bActionGroup` and nothing would happen
really. But you could for example group fcurves from `Bone` under a
group called `Bone.001` and vice versa. This is totally allowed to do.
In this case, `animchan_sync_group` is doing nothing totally helpful, so
it could find the "wrong" `bPoseChannel`. And it could try
`action_group_colors_set_from_posebone` with that `bPoseChannel` which
still does not have a `bone` and then crash.
So now only do this if we have a valid `bone`.
Pull Request: https://projects.blender.org/blender/blender/pulls/118676
This is a migration of the current Line Art modifier to GPv3.
Note:
- The modifier is using the exact same DNA structure as the old one, it's re-defined in a different name. At the moment all the variable names and placement after the `ModifierData` part should stay exactly the same until we do proper versioning of the modifier data and completely remove the GPv2 support.
- Vertex weight transfer feature no longer supports name initial matching ("group" used to match "group1","group2" etc). Now it will only transfer vertex weight from source vertex groups that has the exact same name as specified.
Pull Request: https://projects.blender.org/blender/blender/pulls/117028
