Blender Git Commits

Blender Git commits from all branches.

Page: 579 / 2888

December 31, 2020, 17:36 (GMT)
Tweak draw sharp preset to include size-pressure
December 31, 2020, 17:30 (GMT)
Merge branch 'master' into sculpt-dev
December 31, 2020, 17:03 (GMT)
LibOverrides: First stage of detection of 'need resync'.

We can fairly easily detect some resync-needed cases when applying the
overrides operations on a Pointer RNA property.

This should cover all cases where an existing override's ID pointer is
changed in its linked data.

We still have to add code to detect when a not-yet-overridden linked ID
needs to become overridden (because its relations to other data-blocks
changed in a way that requires it).
December 31, 2020, 14:24 (GMT)
Merge branch 'master' into override-refactor-tmp
December 31, 2020, 13:26 (GMT)
Merge branch 'master' into override-refactor-tmp
December 31, 2020, 10:04 (GMT)
Merge branch 'master' into override-refactor-tmp
December 30, 2020, 19:30 (GMT)
NLA: Remove Hold resetting between Hold_Forward Behavior

Before, moving (or Push-Down Action-ing) a Replace strip with extrap=`Hold or Hold_Forward` will auto reset to the other based on whichever first occurs among all the tracks. Now, that auto reset behavior has been completely removed and //only// that behavior.

This patch does not change strip evaluation. Between two strips, the first with `None` extrapolation and the next with `Hold`, neither strip will evaluate, which matches previous behavior. A future patch can change the evaluation behavior.

Part of {T82230}

Differential Revision: https://developer.blender.org/D9942
December 30, 2020, 19:30 (GMT)
NLA: Strip Evaluate Held Strips Even When Not First Strip

Changes NLA strip evaluation.

A visual example of the change (with current frame between both strips):

**Before**:
| First strip extrapolation | Next strip extrapolation | Evaluated Strip
| None | Hold | Neither
| Hold or Hold_Forward| Hold | First

**Now**:
| First strip extrapolation | Next strip extrapolation | Evaluated Strip
| None | Hold | Next
| Hold or Hold_Forward | Hold | First

There isn't a concrete use-case for this new behavior. It's more to avoid the case of [None | Hold | Neither] which appears buggy.

UI-wise, the case of `Hold`/`Hold_Forward` leading to a `Hold` will draw with a slightly darker extrapolation area overlay. Pre-extrapolation and post-extrapolation alpha is changed to the same value now too.

Part of {T82230}
This patch functionally depends on {D9942} to sanely test this patch.

Differential Revision: https://developer.blender.org/D9943
December 30, 2020, 17:17 (GMT)
Merge branch 'master' into sculpt-dev
December 30, 2020, 13:37 (GMT)
Merge branch 'master' into override-refactor-tmp
December 30, 2020, 10:55 (GMT)
Merge branch 'master' into override-refactor-tmp
December 29, 2020, 22:01 (GMT)
Directly select animation curves in the graph editor

Hi!

In Blender, in the graph editor, it is for now impossible to select a curve directly without selecting a keyframe of that curve.
This can sometimes be a bit frustrating, especially for people coming from softwares where this is possible. Being able to select curves directly allows to hide or lock them a bit faster, for instance.

This patch enables the user to **directly select animation curves with the usual selection operators**. When doing a selection, the usual keyframe selection is first performed, and if no keyframe could be found, then it tries selecting the curve. This is done on a per-curve basis (per-channel), which means that the user may select both a keyframe for a curve A, and a curve B with no keyframe. I found it to be more intuitive, but maybe this is something that should change.

The selection of the curves is done by sampling them in the interval defined by the xmin and the xmax of the selection area, and checking if those points are inside of this area.

Selecting curve is available in the **box selection** operator, the **lasso**, and the **circle selection** operators.

{F8892684}

Reviewed By: sybren, zeddb, looch

Differential Revision: https://developer.blender.org/D8687
December 29, 2020, 20:39 (GMT)
USD Importer: dependency graph update crash.

Fixed occasional random crash due to simultaneous update
to the dependency graph from multiple threads. A typical
collision might happen when the USD import job thread
is creating a material while the window manager in the
main thread is processing event notifiers. Specifically,
invoking BKE_object_material_slot_add() in the import
thread would crash in the call Depsgraph::find_id_node(),
presumably because the call to BKE_scene_graph_update_for_newframe()
from the main thread is invalidating Depsgraph::id_hash.
The current fix is to remove the ND_FRAME flag from the call
to WM_jobs_timer(), which prevents ED_update_for_newframe()
from being called in wm_event_system.c, line 506.
We should look into whether we can skip invoking WM_jobs_timer()
from the import thread altogether.
December 29, 2020, 17:02 (GMT)
Armature: fix bad B-Bone deformation blending with Preserve Volume.

The double quaternion blending method in addition to the deformation
matrix of each bone requires their rest matrices. For ordinary bones
this literally should use the bone rest matrix without any ambiguity.

However, it was also using the bone rest matrix for all of its
B-Bone segments, which is incorrect and causes strange deformation
in some cases involving extreme non-uniform scale, especially
at boundaries between different B-Bones.

This changes both the Armature modifier and the Armature constraint
to use the actual segment rest matrices. Unlike bones, these can have
scale even in rest pose, so normalization is required.
December 29, 2020, 17:01 (GMT)
Weight Paint: avoid creating very small values with locked weights.

When painting using Auto-Normalize or Lock Relative with some
groups locked, the locked weights may not add up precisely to
1 because of precision limitations, which results in creating
nonzero weights close to FLT_EPSILON. With Lock Relative display
mode this is very obvious and annoying (random red points amid
black or blue), so add an epsilon check to consider less than
1e-6 unlocked weight to be the same as 0.

In addition, in cases when no weight can be painted due to locks,
don't create vertex group entries at all if they don't exist yet.
December 29, 2020, 16:58 (GMT)
Armature: add B-Bone lengthwise scaling and custom handle scaling options.

In addition to the base bone transformation itself, B-Bones have
controls that affect transformation of its segments. For rotation
the features are quite complete, allowing to both reorient the
Bezier handles via properties, and to control them using custom
handle bones. However for scaling there are two deficiencies.

First, there are only X and Y scale factors (actually X and Z,
but this is the legacy naming), while lengthwise all segments
have the same scaling. The ease option merely affects the shape
of the curve, and does not cause actual scaling.

Second, scaling can only be controlled via properties, thus
requiring up to 6 drivers per joint between B-Bones to transfer
scaling factors from the handle bone. This is very inefficient.

This patch addresses these deficiencies by adding Length scale
inputs, and providing toggles to apply custom handle local scale
channels to the now four scale-related properties. The 'Length'
name is used to avoid confusion due to the X/Y vs X/Z naming.

The two Length scale inputs control the ratio between the lengths
of the start and end segments of the bone: although for convenience
two inputs are provided, the whole chain is still uniformly scaled
to fit the curve.

A Scale Easing option is provided to multiply the easing value
by the Length scale factors to synchronize them - this produces
a natural scaling effect where both the shape of the curve and
the scale is affected.

The second issue is addressed by providing toggles for each handle
that multiply each of the X, Z, Length and Ease values by the matching
Local Scale channel of the handle bone, thus replacing trivial drivers.
The Scale Easing option has no effect on this process since it's easy
to just enable both Length and Ease buttons.

Finally, this fixes a strange behavior where the segments were not
actually scaled in the Y direction to match their actual length, thus
producing gaps or overlap depending on the shape of the curve. For
transformation the change should be very small if enough segments
are used, but this will affect the results of the Copy Transforms
and Armature constraints, so a backwards compatibility option is
provided. Newly created bones default to the new behavior.

Differential Revision: https://developer.blender.org/D9870
December 29, 2020, 16:56 (GMT)
Limit Rotation: add an Euler Order option and orthogonalize the matrix.

Since Limit Rotation is based on Euler decomposition, it should allow
specifying the order to use for the same reasons as Copy Rotation does,
namely, if the bone uses Quaternion rotation for its animation channels,
there is no way to choose the order for the constraint.

In addition, add a call to orthogonalize the matrix before processing
for the same reasons as D8915, and an early exit in case no limits are
enabled for a bit of extra efficiency.

Since the constraint goes through Euler decomposition, it would remove
shear even before the change, but the rotation won't make much sense.

Differential Revision: https://developer.blender.org/D9626
December 29, 2020, 16:56 (GMT)
Copy Transforms: implement Invert, Fix Shear and more Mix options.

This constraint can be naturally viewed as a prototype for a future
4x4 matrix math node (or subset thereof), since its basic semantics
already is matrix assignment. Thus it makes sense to add math options
to this constraint to increase flexibility in the meantime.

This patch adds support for several operations that would be useful:

- An option to fix shear in the incoming target matrix.
- An option to invert the target matrix.
- More ways to combine target and owner matrix.

Shear is known to cause issues for various mathematical operations,
so an option to remove it at key points is useful. In the future node
system this would be a separate operation, but due to the limits of
the constraint stack it has to be built in for now.

Inverting a matrix is also an operation that can be useful to have.
For some uses it may be useful to invert components separately, so
implement this by checking the Mix mode setting to avoid UI options.

Finally, add two more ways to combine the matrices (multiplied by
two due to the necessity for the Before/After choice). Now there
are three combine modes:

Full implements regular matrix multiplication as the most basic option.

Split Channels combines location, rotation and scale separately.
Looking at D7547 there is demand for such a mode in some cases,
and even with nodes it's cumbersome to rig manually every time.

Finally, Aligned emulates the 'anti-shear' Aligned Inherit Scale mode,
and basically uses Full for location, and Split for rotation/scale.

Differential Revision: https://developer.blender.org/D9469
December 29, 2020, 16:56 (GMT)
Constraints: add support for a new Owner Local Space for targets.

Add a new transformation space choice for bone constraints, which
represent the local transformation of the bone in the constraint
owner's local space.

The use case for this is transferring the local (i.e. excluding the
effect of parents) transformation of one bone to another one, while
ignoring the difference between their rest pose orientations.

Owner Local Space replaces the following setup:

* A `child` bone of the `target`, rotated the same as `owner` in rest pose.
* A `sibling` bone of the `target`, positioned same as `child` in rest
pose and using Copy Transforms in World Space from `child`.
* The `owner` bone constraint uses Local Space of `sibling`.

(This analogy applies provided both bones use Local Location)

Since the space list is getting long, this adds a couple of separators.

Differential Revision: https://developer.blender.org/D9493
December 29, 2020, 16:56 (GMT)
Constraints: refactor the D7437 patch adding Custom Space for constraints.

As mentioned in the comments to that patch, I had an idea for
a different way to do some technical aspects, but it was too
complicated to force changes in the original patch. Thus I submit
this follow up patch.

First, instead of modifying all the get_constraint_targets and
flush_constraint_targets callbacks, introduce wrapper functions
for accessing constraint targets, convert all code to use them,
and handle the new reference there uniformly for all constraints.

This incidentally revealed a place in the Collada exporter that
didn't clean up after retrieving the targets.

Also, tag the special target with a flag so other code can
handle it appropriately where necessary. This for instance
allows dependency graph to know that the Use B-Bone Shape
option doesn't affect this specific target.

Finally, rename and simplify the function for initializing the
custom space, and make sure it is called everywhere necessary.

Differential Revision: https://developer.blender.org/D9732
By: Miika HämäläinenLast update: Nov-07-2014 14:18MiikaHweb | 2003-2021