Patch by: Roland Hess (harkyman)
For example, a constraint can be sub-targeted at the 50% (or 31.2% or 85% etc.) point of its target bone, giving you enormous rigging flexibility and removing the need for complex contraptions to do such things as:
- A bone whose base slides only between to points on a rig (CopyLoc with a variable, animated subtarget point)
- Bones that attach to multiple points along another bone (CopyLocs, each with a different head/tail percentage)
- Bones that need to stretch to a point midway between specific spots on two other bones (old way: too crazy to mention; new way: stretch bone between points on end bones, then another stretch to the midpoint of the first stretch)
It is only used for the constraint types for which it is relevant: CopyLoc, TrackTo, StretchTo and MinMax, TrackTo, and Floor.
Notes:
- This is accessed by the Head/Tail number-slider.
- This value can be animated per constraint
- The old "Copy Bone Tail" option for the CopyLoc constraint has been automatically converted to 1.0 Head/Bone values for the affected constraints
- In the code, this value is in the bConstraint struct, so it is available for all constraints, even though only a few implement it.
====================
Dynamic binding support. This means that the mesh can move _within_
the cage and still deform correct. If the mesh goes out of the cage,
don't expect correct result. Must be enabled with the 'Dynamic'
option, because it is slower and consumes more memory.
This is useful to use e.g. the cage mesh for main deformations and
still have shape keys for facial deformation working.
Old log Message:
-----------
bug fix, when opening blender with a file (by double clicking or from the
command line) - the initial undo state would be set to the default scene.
So holding Ctrl+Z would go back to the default .B.blend rather then the
file that the user opened.
Tree From Curve,
- report error when nurbs or poly curves are used.
- don't throw errors when >4 branch's per segment are used. also try deal with this better. though no nice solution exists.
- default speed is 10x slower then before.
- brought back the check for a valid relative base when selecting.
- kept the check for when file is saved too and warning message is printed to console instead of popping up.
Also fixed BLI_split_filedir overwriting parameter passed as const char*
* bugfix: calling imagebrowser with relative path results in non-existing dir
* cleanup: removed unneeded BIF_filelist_appenddir function
* added check for valid relative base when activating imagebrowser (like in filebrowser)
Now, when rotating along local axes of an object/bone with a copy-rot constraint that has offset on, the results are more predicatable. However, doing so with global axes is still in CrazySpace (TM).
This commit fixes the issue by disabling access to screens via the path input field.
Note that appending screens might actually be a useful feature to implement at some point.
* made stamp filename optional
* renamed weightpaint "Filter" to "Blur"
* made the defailt weightpaint opacity 1.0 rather then 0.2 so when you select 1.0 weight you can paint it with without multiple clicks.
'Auto IK' is a great feature, however when solitary unconnected bone (without connected child bones) is grabbed it can't be moved because of IK. This can be really annoying. Preventing 'Auto IK' for solitary bones would improve user-experience by making mixing of FK and IK more convenient while using 'Auto IK'.
Patch by Teppo Kansala (teppoka).
This patch by Teppo Känsälä (teppoka) makes parenting bones with Ctrl-P support the X-Axis-Mirror option for Armatures. It will cause the mirror-bone of the selected bone to also get parented. i.e. if "bone.R" was selected and being parented, "bone.L" would also get parented.
I've made an addition to this patch, which means that if the bone that acts as the parent also has a mirror-bone (i.e. when parenting "lowerArm.L" to "upperArm.L", "lowerArm.R" gets parented to "upperArm.R"). Otherwise, they both get parented to the same parent bone (i.e. a parent bone that doesn't belong on either side such as "upperSpine")
with many points (think treetrunk), it would be nice to take into account distance on the path when doing the curve interpolation.
Also moved added undo call's that were missing for 2 of the other curve specials.
Scene.update(full=1) was pretty useless as it didn't actually evaluate the
depsgraph DAG. This meant, for example, that re-evaluating the parenting
tree for an armature pose could only be done by redrawing the view (which
evaluates the depsgraph). scene_update_for_newframe() is now called when Scene.update is in "full" mode; to prevent firing off newframe scriptlink events, scriptlinks are
temporarily disabled while scene_update_for_newframe() is being called.
Peach Request:
Now the Action and NLA editors have the "Extend" transform mode first seen in the Sequence Editor. Just use the EKEY to start transforming.
It works like Grab, except it only moves the keyframes/side of NLA-strip that was on the same side of the current-frame marker as the mouse was when transform started.
B-bones didn't work well with non-uniform scaling applied to them.
The code to solve this is not too pretty, but don't know how to do
it simpler, and at least it makes that stretchy spine work.
====================
The MeshDeform modifier can deform a mesh with another 'cage' mesh.
It is similar to a lattice modifier, but instead of being restricted
to the regular grid layout of a lattice, the cage mesh can be modeled
to fit the mesh better.
http://www.blender.org/development/current-projects/changes-since-244/modifiers/
Implementation Notes:
- OpenNL has been refactored a bit to allow least squares matrices to
be built without passing the matrix row by row, but instead with
random access. MDef doesn't need this actually, but it's using this
version of OpenNL so I'm just committing it now.
- Mean value weights for polygons have been added to arithb.c, a type
of barycentric coordinates for polygons with >= 3 vertices. This
might be useful for other parts of blender too.
"Rotation Difference"
This option, for Bones, allows the angle between two Bones to be
the driver for another Ipo channel. This angle now is hardcoded
based on the Bone-space orientation (without parenting rotation).
Thanks to nathan for poking and test!
New listbase functions:
void BLI_insertlinkafter(struct ListBase *listbase, void *vprevlink, void *vnewlink);
- corrolary to insertlinkbefore
BLI_sortlist(struct ListBase *listbase, int (*cmp)(void *, void *));
- simple in place sorting method. NOT optimized, so use for small lists only. Uses a variant of insertion sort (I was lazy, people should feel free to rewrite).
====================
This changes the way hinge bones are transformed when their parent bones
are also selected. Before it just disabled transform for these, now they
are rotated and scaled as well, but without influencing the transform
center, which gives behaviour as if they were regular bones.
==
Solving is now done independent of scale, by scaling the chain to have a
size of about 1.0. This solves some issues with small or big chains, and
also makes the IK stretch setting independent of scale. The latter breaks
backwards compatibility somewhat, but is an improvement over what it did
before.
When scaling all the control-points in the IPO Editor with negative scales, the control-points would end up "sticking together", and cancelling/undo would not help.
When using targetless-ik, the offset in rotation of the final transform from the rest-position was being incorrectly calculated.
Now, visual-rotation keyframing uses the space-switching code I wrote for constraints, to calculate the value to keyframe. So far, it seems to work quite well.
As the constraint space-switcher correctly handles hinged bones too (I think it should!), I've also removed the restriction of only allowing visual-rotation keying on bones that didn't have hinge set.
This changes the default behaviour in adding new objects, which has been
discussed for a long time, in person, on the funboard, and in the tracker,
and was agreed to be implemented during the 2.5 release cycle, so here it is.
They have been made default, with preferences to bring back old behaviour since
although people like myself still prefer the new default anyway, it will benefit
new users the most.
The preferences are in the 'Edit Methods' section, changing back to old behaviour
is as simple as a click of a button.
- Switch to edit mode preference
By default, now adding a new object doesn't automatically switch to edit mode.
Not only can this be annoying (most of the time when setting up scenes and models
I don't want to edit it straight away anyway), but it's a major hurdle in the learning
curve that new users have had to deal with at a very early stage.
Blender's different modes are an important part of understanding how the software works
and should have clear behaviour. The problem is that when a user selects something from
the add menu, he's not telling Blender to change modes, he wants to add an object.
But Blender then goes ahead and changes modes underneath him anyway, something that was
never explicitly asked for, something that's unrelated to the mental task at hand, and
fundamentally important to the operation of the software.
We observed plenty of people struggling with this during the training sessions that
we ran during Project Orange, and there's also no shortage of "why can't I select
other objects" questions on the forums.
- Aligned to View preference
Now by default, adding a new object doesn't rotate it so it's aligned facing the view,
but rather, it's remains unrotated in world space. This is something that's more of
a convenience issue (allowing people like me to stop the 'Add->Tab->Alt R dance),
but also makes things easier for new users, especially when doing things like rigging.
For a lot of tools in Blender, like curve deform, path cycling, constraints, it's necessary
for your objects' local axes to be aligned. This requirement isn't that obvious, and I've
had to debug rigs a few times from the animator in our studio, who has everything set up
correctly, but he just happened to be in a different vie at the time he added the object,
so they're misaligned and causing problems. Having all objects get created aligned to
worldspace, by default, makes a lot of these problems go away. It's much more understandable
when rotations are caused by something you've done explicitly, rather than as a side effect
of the software.
For convenience as well, most of the time, when I'm working in context and I decide I need a new object,
particularly working on production scenes that involve more than just one model, an Alt R
is almost always required after adding, since I don't want to have to disrupt the current
view of the scene by switching to top view, just to add an object. It's a bit arbitrary,
the view from which you want to look at your objects isn't usually the way you want them to
be looking at you.
