Interactive blending of poses can now use negative factors (i.e. drag to
the left) to blend in the flipped pose.
This reverts rB6eb1c98b15bb7ea6cf184b08617f24c7afb91b6c where the F key
was used to flip the pose. That was already described as stop-gap
measure, and the new behaviour is more intuitive & direct.
Functionality over-the-shoulder reviewed by @hjalti.
Add a field `is_bidirectional` to sliders (`tSlider`). By defafult this
is `false`; when set to `true` the slider allows negative values.
The allowed ranges are now:
- No overshoot, no bidirectional: `[0, 1]`
- No overshoot, bidirectional: `[-1, 1]`
- Overshoot, no bidirectional: `[0, infinity)`
- Overshoot, bidirectional: `(-infinity, infinity)`
This will be used for the pose library blending operator, where sliding
to the right (postitive) blends as normal, and sliding to the left
(negative) flips the pose before blending.
This is part of D16858. Iterating over all field inputs allows us to extract
all anonymous attributes used by a field relatively easily which is necessary
for D16858.
This could potentially be used for better field tooltips for nested fields,
but that needs further investigation.
This is part of D16858 but is also useful for other purposes.
The changes to the node declaration in this commit allow us to figure
out which fields might be evaluated on which geometries statically (without
executing the node tree). This allows for deterministic anonymous attribute
handling, which will be committed separately. Furthermore, this is necessary
for usability features that help the user to avoid creating links that don't
make sense (e.g. because a field can't be evaluated on a certain geometry).
This also allows us to better separate fields which depend or don't depend
on anonymous attributes.
The main idea is that each node defines some relations between its sockets.
There are four relations:
* Propagate relation: Indicates that attributes on a geometry input can be
propagated to a geometry output.
* Reference relation: Indicates that an output field references an inputs field.
So if the input field depends on an anonymous attribute, the output field
does as well.
* Eval relation: Indicates that an input field is evaluated on an input geometry.
* Available relation: Indicates that an output field has anonymous attributes
that are available on an output geometry.
These relations can also be computed for node groups automatically, but that
is not part of this commit.
This was the case when done via the py-API.
Now also set active_color_attribute / default_color_attribute on newly
created attributes (in case none exist yet).
Maniphest Tasks: T103564
Differential Revision: https://developer.blender.org/D16898
Python API for moving strips to and from meta strips did not invalidate
strip lookup cache. Because of that, `SEQ_get_seqbase_by_seq()` failed
to lookup origin of strip, which resulted in crash on NULL dereference.
Invalidateion was added to functions `SEQ_edit_move_strip_to_meta()` and
`SEQ_add_meta_strip()`.
Partly a cleanup, but also iterating over spans can be faster than
linked lists. Also rewrite the multi-input socket link counting
to avoid the need for a temporary map. Overall, on my setup the changes
save about 5% (3ms) when drawing a large node tree (the mouse house file).
Small memory allocations are a bottleneck when drawing large node trees.
Avoid them by passing the socket index in the whole tree and getting the
tree from the context rather than allocating structs for the tree, node,
and socket. The performance improvement will be a few percent at most.
This was an oversight in rBdba2d828462ae22de5.
The evaluator uses multiple threads to initialize node states
but it is still in single threaded mode.
`get_main_or_local_allocator` did not return the right allocator
in this case.
During pose blending, when flipping the pose with {key F}, the pose
backup needs to be recreated. Without this, the blending wouldn't be
done properly.
F-for-flipping was introduced in rB6eb1c98b15bb7ea6cf184b08617f24
While blending poses from the pose library, press {key F} to flip the
pose.
Since rBc164c5d86655 removed the "Flip Pose" checkbox, there was no more
way to blend poses flipped.
Note that this is a bit of a stop-gap measure. The goal is to have a
bidirectional blend slider, where dragging to the left flips the pose,
and dragging to the right blends it normally.
As an optimization, dependency graph evaluation skips through
no-op nodes at the scheduling stage. However, that leaves update
flags enabled on the node, and the most problematic one is the
USER_MODIFIED flag, which get flushed to children every time
the no-op node is tagged.
This in turn can cause simulation caches downstream to be
permanently stuck in an outdated state until the depsgraph
is rebuilt and the stuck flag cleared out.
Differential Revision: https://developer.blender.org/D16868
The BONE_SEGMENTS operation node is only created if the bone is
actually a B-Bone. One location in the code wasn't checking that
before trying to create a relation.
Move some functions for transforming a span of vectors to a header
and call them from these functions, just like was done for curves
objects recently.
Resolves T102027, T102026
Differential Revision: https://developer.blender.org/D16883
Expose `BKE_pose_apply_action_blend` and a simplified pose backup system
to RNA. This will make it possible to easily create some interactive
tools in Python for pose blending.
When creating a backup via this API, it is stored on the
`Object::runtime` struct. Any backup that was there before is freed
first. This way the Python code doesn't need access to the actual
`PoseBackup *`, simplifying memory management.
The limitation of having only a single backup shouldn't be too
problematic, as it is meant for things like interactive manipulation of
the current pose. Typical use looks like:
- Interactive operator starts, and creates a backup of the current pose.
- While the operator is running:
- The pose backup is restored, so that the next steps always use the
same reference pose.
- Depending on user input, determine a blend factor.
- Blend some pose from the pose library into the current pose.
- On confirmation, leave the pose as-is.
- On cancellation, restore the backup.
- Free the backup.
`BKE_pose_apply_action_blend` is exposed to RNA to make the above
possible.
An alternative approach would be to rely on the operator redo system.
However, since for poses this would use the global undo, it can get
prohibitively slow. This change is to make it easier to prototype
things; further into the future the undo system for poses should be
improved, but that's an entire project on its own.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D16900
While the cost of creating AttributeAccessor and finding the "material_index"
attribute is not large, there's really no need to do that for each
polygon. Move the access outside of the per-polygon loop.
Move `pose_backup.cc` from `editors/armature` to `blenkernel`. This is
in preparation of an upcoming change where the pose backup is going to be
owned by the `Object`. This will need to be automatically cleared when the
object is freed, which means that `blenkernel` needs the corresponding
logic.
Technically only the freeing code could be moved, but I felt it made more
sense to keep the related code together.
No functional changes.
There are two underlying issues which got uncovered by the report:
First, is that the poll() function for the operator was using legacy
API which is on its way of removal in the next major version release.
This part is fixed in this patch based on a patch provided by Philipp
Oeser (P3389) with the modification that the `clip` is not accessed
prior to None check. Ended up in a bit annoying one-liner, the entire
function could be refactored to use early returns.
The second issue is that the Python access to the legacy property
was wrong: need to access camera reconstruction instead of accessing
deprecated DNA field.
Some files out there (e.g. in T103441) contain face definitions with
four indices, which the importer code was not expecting. The OBJ
standard spells out up to three indices per face corner; the file in
there must be using some sort of non-standard OBJ syntax extension.
Now the code simply ignores any trailing per-face-corner data.
Similar to T98782 that was about normal indices: some files out there
are technically "wrong" since they refer to UV indices, without ever
defining any UVs. If the file does not have any UVs, simply ignore UV
indices in the OBJ face definitions. Fixes T103212.
- Move from blenkernel to the node editor, the only place it was used
- Use two vectors instead of ListBase
- Remove define for validating the clipboard, which shouldn't be skipped
- Comment formatting, other small cleanups to whitespace
Differential Revision: https://developer.blender.org/D16880
The geometry nodes evaluator supports "lazy threading", i.e. it starts out
single-threaded. But when it determines that multi-threading can be
benefitial, it switches to multi-threaded mode.
Now it only creates an enumerable-thread-specific if it is actually using
multiple threads. This results in a 6% speedup in my test file with many
node groups and math nodes.
When these declarations are built without the help of the special
builder class, it's much more convenient to set them directly rather
than with a constructor, etc. In most other situations the declarations
should be const anyway, so theoretically this doesn't affect safety too
much. Most construction of declarations should still use the builder.
Whenever a node group is entered during evaluation, a new compute
context is entered which has a corresponding hash. When node groups
are entered and exited a lot, this can have some overhead. In my test
file with ~100.000 node group invocations, this patch improves performance
by about 7%.
The speedup is achieved in two ways:
* Avoid computing the same hash twice by caching it.
* Invoke the hashing algorithm (md5 currently) only once instead of twice.
Geometry nodes used to log all socket values during evaluation.
This allowed the user to hover over any socket (that was evaluated)
to see its last value. The problem is that in large (nested) node trees,
the number of sockets becomes huge, causing a lot of performance
and memory overhead (in extreme cases, more than 70% of the
total execution time).
This patch changes it so, that only socket values are logged that the
user is likely to investigate. The simple heuristic is that socket values
of the currently visible node tree are logged.
The downside is that when the user changes the visible node tree, it
won't have any logged values until it is reevaluated. I updated the
tooltip message for that case to be a bit more precise.
If user feedback suggests that this new behavior is too annoying, we
can always add a UI option to log all socket values again. That shouldn't
be done without an actual need though because it takes up UI space.
Differential Revision: https://developer.blender.org/D16884
