| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* These operators were still clearing the pchan->bone (i.e. restpose values) instead
of the pchan values, which may have messed things up quite a bit.
* I've also now included the curve x/y stuff in rotation. While the transform being
applied to the handles is more like translation, the effect is actually closer
to rotation of the bone segments. So, on balance, let's try it this way.
|
|
|
|
locations as relative
This is an experimental option for use with the previous commit. It's an attempt
at making these bone references more useful when there's a big gap between the
reference bone being used, and the bone it's controlling.
|
|
controlling handles
This is an experimental option which makes it possible to specify which bone
to use as the reference handle for the previous/next bones, instead of only
using those that are directly connected on either end.
To use:
* Enable the "Use Custom Handle References" option in the Bendy Bones panel
* Set Start and/or End bones accordingly. If both are left blank, then the BBone
will only respond to whatever offsets have been set by the animator
* Be careful when positioning the start/end bones! It will use the bone position
as the point at which the handle currently sits - best results seem be when these
bones are in line with the bbone to start with.
Why (according to @jpbouza):
When you have a very long chain of bbones, as they are all parented, when you rotate
the first bone in the chain (Y rotation, like twisting the chain), all the child
bones rotate. So the only way to avoid this is to add a copy rotation constraint to
each bone in the chain in order to override their parent rotation, thus achieving
control over twisting of each segment of the chain.
This commit makes it possible to have a bone (that is not a parent or child of the bone
being affected) to influence the bbone curvature as if they were.
|
|
* Improved naming of BBone properties to be less clunky
* Rewrote all the tooltips to be more descriptive about what they do
(and hopefully, to give an idea of how they can be used)
* Improved the ranges on all the properties
- Curve X/Y now has a range of +/- 5 (vs +/- 2 before)
- Scale In/Out now has a range of 0-5 (vs 0-2 before)
The extra flexibility doesn't seem to lead to any ill effects; instead,
at least in my tests so far, they instead give more leeway for creative
posing.
* Set defaults for the scale properties (1.0)
|
|
The fix here is to apply a scaling correction to the offsets we're applying
if the do_scale flag gets set. For whatever reason (I'm guessing floating point
precision errors), when the scale factor gets to around 8.15/8.16, there's a bit
more of a difference between x/y or y/z scale factors, leading to everything
needing to get scaled up 8 times (i.e. the bone length for the calculations is
8.16 not 1.0 as per usual). If we don't scale the offsets being applied to
compensate for this, the effect of the offsets will be less (i.e. the handles move
less), hence the bbone flattening out.
|
|
|
|
set in editmode
The restpose/editmode values should still be applied during "rest",
so that their effects will not be factored into the final "deform"
that gets applied via the bones. However, we still need to have
these restpose values applied at some point to the bones, so that
in the viewport we get the offset values on top of the base.
|
|
The Breakdowner and Pose Sliding tools (Push/Relax) now have support for the
bbone properties too, making it possible to use these tools for playing with
them like another other part of the pose.
Implementation Note:
I've ended up reusing a bunch of flags which we don't use, and haven't used
for at least a decade (and which were if 0'd out). When they were in use,
they would have been for runtime purposes anyway. Just to be safe, the version
patch in modern Blender will clear out all those flags so that we can use them.
|
|
* Changed num_segments from n - 1 to just n. Previously, it ended up just looking
odd, as everything would change, up till but not including the last one, when
playing with the "scale in" setting.
* Removed the before calculating scaleFactorIn/Out - these were always true!
|
|
|
|
follow
|
|
|
|
Copying poses now copies the bendy bone settings (posebone not bone ones).
By and large this should work fine now, though the behaviour for "paste flipped"
might need further checking.
|
|
Looks like we shouldn't be applying the inverse matrix here...
|
|
To preserve backwards compat with old rigs, the behaviour to use the BBone
shape when interpolating Head/Tail values will now only be performed when
the "curve" toggle beside the head/tail slider is enabled.
TODO: Make this toggle only show up when the target is actually a bbone
|
|
Last segment needs special handling, as the values there are a little wonky...
|
|
straight-line interpolation
This can be used to reduce the complexity of rigs, by reducing the number of extra bones
that may have otherwise been needed to accomplish a similar effect.
|
|
|
|
|
|
The bendy bone settings (curve in/out, etc.) now exist on both Bone and PoseBone
levels. What this means is that the "Bone" level settings (i.e. what we had before)
are used for defining the rest pose curve for the bone (i.e. to fit things like
curved eyebrows, and so forth), while the "PoseBone" level settings (i.e. new stuff)
will be what animators play with to animate their characters.
Implementation Notes:
* All the BBone settings are now found in a new "Curved Bones" panel. This is located
just below the Transform properties panels (instead of by "Deform"), so that it's
easier to reach for animating.
The segments and ease in+out settings are still also located in the "Deform" panel.
I'm still unsure whether to remove them for good from there. For now, I've duplicated
them, to be more convenient for animation tweaking (though it might also be a bit
confusing)
* Ease In/Out is still a bone-level setting only (i.e. no posemode offsets/override).
This may be subject to change still, but more investigation will be needed first.
* Scale In/Out is handled multiplicatively. That is,
scaleIn_final = bone->scaleIn * pbone->scaleIn
* I've added a hacky "stripped down" copy of b_bone_spline_setup() for drawing
the editmode previews of these bbone settings. Whether this is the final approach
used is still open to debate. Better suggestions welcome, though this seems to be
the simplest (least overhead) solution currently.
|
|
|
|
It turns out that this wasn't changed in the patch after all...
|
|
|
|
leftover
|
|
I've gone through making a bunch of changes (mostly, just reverting quite a few
things back to their pre-patch state, and adding in a few other bits), and it
finally looks like it actually works for both BlenRig and the test files. Yay!
(Things are still quite messy, with a lot of commented out leftovers and stuff
to deal with, which I'll clean up in a moment after verifying that it all actually
works for real)
|
|
final step
If we use the old formula (currently enabled), old rigs work, but new options don't.
However, if we use the new one (without tmat == inverse mats[0]), old rigs
(blenrig) breaks, while the new options don't really work that great.
|
|
|
|
|
|
|
|
previous experiments
|
|
|
|
* Roll angles should be stored in radians, and displayed using the appropriate
RNA type instead
* Some general code cleanup work (style, avoid type conversions, etc.)
|
|
Author: Jose Molina
Idea: Daniel M Lara (pepeland)
|
|
|
|
|
|
|
|
|
|
Together with the extended loop callback and userdata_chunk, this allows to perform
cumulative tasks (like aggregation) in a lockfree way using local userdata_chunk to store temp data,
and once all workers have finished, to merge those userdata_chunks in the finalize callback
(from calling thread, so no need to lock here either).
Note that this changes how userdata_chunk is handled (now fully from 'main' thread,
which means a given worker thread will always get the same userdata_chunk, without
being re-initialized anymore to init value at start of each iter chunk).
|
|
BLI_task_parallel_range() & co.
|
|
|
|
New code is actually much, much better than first version, using 'fetch_and_add' atomic op
here allows us to get rid of the loop etc.
The broken CAS issue remains on windows, to be investigated...
|
|
Some variants of gcc compilation were reporting 'control reaching end of non-void function' error
in this switch/case maze. Either use break everywhere or not at all (which is simpler, since we
only always return anyway...).
|
|
This reverts commit b13bc48932761dd813597507b1a1dc86d951ebff.
Wasn't only typo fixes, broke compiling
|
|
patch by @Blendify
|
|
feature."
There are some serious issues under windows, causing deadlocks somehow (not reproducible under linux so far).
Until further investigation over why this happens, better to revert to previous
spin-locked behavior.
This reverts commits a83bc4f59707ab and 98123ae9168.
|
|
In case not all bones are selected, not all possible mirrors are set in editbone->temp.ebone,
so we need to search them...
|
|
Reading the shared state->iter value after storing it in the 'reference' var could in theory
lead to a race condition setting state->iter value above state->stop, which would be 'deadly'.
This **may** be the cause of T48422, though I was not able to reproduce that issue so far.
|
|
|
