* Bugfix #8599d:
When using the ChildOf constraint on bones without parents, with cyclic-offset in action the effect of the cyclic-offset was applied twice. Added a bone option to make the effect of cyclic-offset not be applied to rootbones which have the option 'enabled'.
In the UI, this is presented in the opposite way. It is represented by the 'Offs' button beside the parent-bone selector in the Armature Bones panel when in EditMode.
* Head/Tail setting and Constraint Channels:
Added back in checks to see if the head/tail IPO-curves for Constraint Channels can get applied for the target constraint. I had removed these when applying the patch, but I'd overlooked the fact that users could add an IPO-curve for this from the IPO-editor, potentially mucking up the behaviour of some constraints.
Finishing off some unfinished business (from the multi-target constraints work), it is now possible to get/set target-space for constraints where this is relevant.
For this to be possible, target-space setting(s) are now always presented as a list of ints, with each int representing the target-space setting for the relevant target.
Constraints C-API note:
get_targets function now needs to return the number of targets the constraint can have
This time is was due to different accuracy of floating point computation,
now it uses does a comparison a bit different to avoid this.
Also changed the vectoquat function to be threadsafe.
This bug-report brought to light some problems with the transform constraint's handling of degrees+radians. Now, the input-range scaling is done in degrees (as the clamping factors ranges are in degrees) instead of having that done after this stage. The problems should now be fixed (and gears now seem to work ok), but I hope no other rigs have been broken.
* Optimised transform constraint a bit
* PyConstraints now show the script-selection menu correctly when a new constraint is added (i.e. it now displays the correct initial value).
Added a new constraint, "Limit Distance". This constraint defines a 'virtual sphere' around the target which the owner can be made to stay inside, outside, or on the surface of it.
This constraint is best used when applied using the Ctrl-Alt-C hotkey, as the radius is set correctly that way.
One usage, is to prevent the target of an IK-chain from straying away from the chain. Care should be taken to not use a member of the IK-chain as the target though.
Description of Variables:
* 'Dist' - Radius of virtual sphere
* 'R' - Click on this to recalculate the 'Dist' value (note: like the 'R' button in the StretchTo constraint, this is currently buggy)
' Mode' - This menu gives different options for how the limiting sphere should act. The mode names are self explanatory.
* 'Soft' and 'SoftDistance' - currently not functional (so settings are hidden). These are used to define a smaller radius around the sphere of influence where a non-linear relationship between input and resulting locations occurs to prevent the owner 'crashing' into the sphere.
Basically, this is based on the behaviour of the unique_constraint_name (or equivilant) functions, which have traditionally been duplicated everytime a new datatype needed this.
Currently, this is in use for the following things:
* Constraints
* Action/Bone Groups
* Local Action Markers / PoseLib poses
Usage Notes:
* The file in which this is to be used should include the standard header file <stddef.h>. This defines the offsetof() macro, which should be used to find the relative location of the "name" member of the structs
* This function is only designed for names of up to 128 chars in length (Most names are at most 32. TimeMarkers are 64). If a longer string needs to be handled, the function will need to be modified accordingly.
* defname is the default name that should be used in case one hasn't been specified already
I'm committing some work-in-progress code for "bone groups" now, as I there have been are some major bugs caused by the timeoffset stuff (some of my test files were not loading, and other files were showing all sorts of weird problems).
Anyway, in this commit, the following things for "bone groups" have been done:
* Bone groups are stored per armature (internally, this is per bPose block)
* Added controls for editing bone-groups per armature - "add", "remove", "rename". These can be found in the "Links and Materials" panel in PoseMode, beside the settings for PoseLib.
* Reorganised buttons for editing selected bones in PoseMode. I've replaced the "dist" and "weight" buttons (they existed in EditMode anyway) with a menu to choose the bone-group and the custom-shape-ob field. In the place of the old custom-shape-ob field, I've restored the "Hide" button. This might break muscle-memory a bit, but there isn't a lot of space to play with there.
Some stuff I'd been originally planning to do before committing:
* When adding keyframes for bones, an action-group with the same name as the bone's group will be added to the action, and the action-channel will be made a member of that.
* New action/bone groups have unique names (renaming/adding new should check if name exists before assigning it)
* There's a setting under Bone-Groups stuff which sets which custom-colour set is used to colour that group's bones. Currently, this is non-functional, as the necessary drawing code for armatures is not in place yet.
Proxy protected bones can now get local (per-file) constraints added to them, which will be preserved after a file load. This is necessary for adding constraints to proxy-protected bones for special purposes while animating (i.e. adding CopyLocs to IK-hand controls to pick up an object).
These must be added after any constraints from the proxy, as proxy constraints may come and go without warning. As such, the UI forbids this from happening by removing the relevant button.
I've also made UI-changes to show which constraints come from the proxy (the buttons to move the constraint up/down and delete it, are replace with two icons - a the proxy 'ghost' icon and a lock). Also, trying to change any settings of proxy-protected constraint will show an error.
Notes:
* Object constraints are still not playing nice with proxies yet. They didn't before this commit either...
IK-constraint "flush_targets" function was causing segfaults on debug builds from certain MSVC compilers.
The cause of this, is that ct is freed in the SINGLETARGET_FLUSH_TARS macro already, but ct is accessed in the following line to get the next target (ct= ct->next). Caused by brecht's commit for the pole-target stuff for IK-constraint.
Now the SINGLETARGET_FLUSH_TARS macro, and the SINGLETARGETNS_FLUSH_TARS macro will correctly advance the location that ct points to.
-> Constraint Influence Ipo now can be local, linked to constraint itself
You enable this in the IpoWindow header, with the Action icon to the left
of the Ipo Type menu. The button tooltips give the clue as well.
Tech note: the Ipo now can get directly linked to a constraint, and is
being called during regular pose constraint solving.
Actions (and drivers in actions) are being calculated *before* pose
constraint solving. Result of actions then is written in bones, which
then solves the entire pose.
This means you can have a driver on both the constraint, as on the action
channel for the constraint! Not that I'm going to debug that easily :)
Additional fix: Joshua added a copy/paste IpoCurve feature, but he broke
the functionality to be able to paste in an empty ipo channel. That now
works again
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.
Now the Copy Scale Constraint also has the Offset functionality that Copy Loc/Rot have.
== Copy Rotation Constraint ==
Also, fixed the tooltip for the CopyRot Offset button.
Note: when working with pose-bones, and using offset, setting both owner+target spaces to pose-space should cancel any unwanted rotations visible.
Copy Rotation constraint now has ability for the owner's rotation to be added on top of the copied rotation (i.e. an 'offset' like for the Copy Location constraint).
I've finally traced down the causes of several of the bugs which caused PyConstraints to work incorrectly (or not at all).
* Freeing is now done using BLI_freelistN inside the pycon_free function, instead of looping through the targets ourselves. This fixes all of those Memblock free: pointer not in list errors.
* BPY_pyconstraint_update now correctly creates/frees the constraint's targets as needed. Previously, it was creating/removing the wrong number of targets. Also, pyconstraints no longer get disabled when using armatures (not bones)
* The panel drawing was also not working right, as there were still some offset issues.
Once again, I've recoded the constraints system. This time, the goals were:
* To make it more future-proof by 'modernising' the coding style. The long functions filled with switch statements, have given way to function-pointers with smaller functions for specific purposes.
* To make it support constraints which use multiple targets more readily that it did. In the past, it was assumed that constraints could only have at most one target.
As a result, a lot of code has been shuffled around, and modified. Also, the subversion number has been bumped up.
Known issues:
* PyConstraints, which were the main motivation for supporting multiple-targets, are currently broken. There are some bimport() error that keeps causing problems. I've also temporarily removed the doDriver support, although it may return in another form soon.
* Constraints BPy-API is currently has a few features which currently don't work yet
* Outliner currently only displays the names of the constraints instead of the fancy subtarget/target/constraint-name display it used to do. What gets displayed here needs further investigation, as the old way was certainly not that great (and is not compatible with the new system too)
Object constraints with a driven influence ipo were not being evaluated
properly. The code for adding the depsgraph relation and updating without
time changes was simply missing.
Now there's an option for the owner to follow the path of the target cyclically. Previously, if the owner moved past the extents of the side of the bounding-box used for the calculations, the object was placed on the curve at the nearest extent.
This option is only really useful if the curve itself is cyclic, although you can still use it otherwise. To enable, just turn on the cyclic option.
* Grouped Up/Down buttons in constraint panel headers, and fixed their tooltips
* Removed unused variable from action editor code
* Minor formatting in constraint.c
I've added the ability for PyConstraints to define a function (doDriver) that is able to directly modify values of the owner/target, so that certain setups can be created reliably. Users should take note that this is against the basic concept of what a constraint does, and that under no circumstances may they set the values of any variables controlling the transforms. For more details, check out the information in the PyConstraint template script.
I've also updated PyConstraints to be aware of geometry targets. The script template has been updated with this information.
This commit features fixes/improvements for problems I didn't manage to fix in time for the commit yesterday.
* Now for Meshes, the normals of the vertices in the VertexGroup are averaged and used to find the 'rotation' that needs to be applied. Unfortunately, this does not work with Lattices as they do not have normals.
* Depsgraph should now play nicely with geometry targets. Before, the constrained object's location wasn't being updated after the target's geometry was modified.
It is now possible to use the geometry of Meshes and/or Lattices as the target of a constraint. All you need to do, is to create a new Vertex-Group and assign all the points that you wish to use as the target, then type that name into the VG: field for the relevant constraints.
One of the cases where this is beneficial is when you need to copy the location of a vertex. Now you don't need to make extra vertex-parents for that.
Additional Notes:
* The code takes the average of the locations of the nominated vertices, and puts that in world-space for constraint solving (and regular space-conversion stuff).
* Currently, rotation and scaling of points is not taken into account. The rotation/scaling used is from the object's matrix. Hopefully, this will only be a temporary problem (will be fixed soon)
bsystem_time was being called with an extra variable, which was useless. Most of the places that called it, were passing NULL for that variable anyway.
I've also cleaned up that function a bit, but the underlying problems with that part of the code still exist (EVIL GLOBALS that are exported for frame_to_float), for mblur and fields rendering features. That remains for another time.
* Transform Constraint should now work in more cases. Somehow the old code (for location case) wasn't working correctly.
* ChildOf Constraint applied on objects, should now get the right 'inverse'/'offset' matrix set. It now uses the same code that is used by Blender's parenting method to do so.
At last, the 'Local' option for Armatures works properly!
Tonight I went through carefully and cross-checked the code once again, and found several bad mistakes I had made. These were:
* the value of one variable from the armatures code was not what I expected it to be, based off the name).
* Mat4MulSerie swaps the first two args! Grrr...
Note:
There's only one rig that I've tested that was broken. That was slikdigit's "mancandy", and the part in question was the jaw. It is likely that a few more rigs out there (in particular, their 'local' action constraints) relied on the wacky rotation values that used to be used, so are now broken.
I've finally fixed the bug with the Constraint Space Conversion. It was a single matrix multiplication in the wrong order (for local->pose).
Also, there is more code added for the space conversion process when bones have 'hinge' on. (NOTE: this stuff for hinge bones may still not work really nice yet)
Here are some attempts at fixing bugs being encountered with the constraint system after the recode. I've just fixed a few typos (where relevant), and added some extra checks for things.
This commit adds a new constraint to Blender: the Transformation Constraint. This constraint gives you more freedom to choose how transforms are copied from one object/bone to another object/bone.
You can assign the Loc/Rot/Scale channels of a source to the Loc/Rot/Scale channels of a destination, specifying the range of motion (per axis) from the source to consider, and the range of motion (per axis) that will be applied to the destination. Also, for each destination axis, you can choose which of the source axes to copy from.
A similar constraint was coded by Jason Blary (snark), as Patch #4991. This constraint is basically rewritten from scratch, although there are some elements of the original patch which may be borrowed in future.
Various notes:
* PyAPI access has been coded.
* Space conversion is also enabled for this constraint.
* Also the useless get_constraint_col function has been removed
* Doing a rotation copy with a ratio that is not 1:1 doesn't always work correctly yet (like for the Copy Rotation constraint).
* Removed obsolete comments from constraints code
* ChildOf constraint buttons: Set/Clear Inverse are now Set/Clear Offset. Hopefully that makes it a bit clearer for users.
After just over a week of coding, I've finished doing a major refactor/cleanup of the constraints code. In the process, quite a few old kludges and ugly hacks have been removed. Also, some new features which will greatly benefit riggers have been implemented.
=== What's New ===
* The long-awaited ``ChildOf Constraint'':
This allows you to animate parent influences, and choose which transformation channels the parent affects the child on (i.e. no translation/rotation/scaling). It should be noted that disabling some combinations may not totally work as expected. Also, the 'Set Inverse' and 'Clear Inverse' buttons at the bottom of this constraint's panel set/clear the inverse correction for the parent's effects. Use these to make the owner not stick/be glued to the parent.
* Constraint/Target Evaluation Spaces:
In some constraints, there are now 1-2 combo boxes at the bottom of their panel, which allows you to pick which `co-ordinate space' they are evaluated in. This is much more flexible than the old 'local' options for bones only were.
* Action Constraint - Loc/Rot/Size Inputs
The Action Constraint can finally use the target's location/rotation/scaling transforms as input, to control the owner of the constraint. This should work much more reliably than it used to. The target evaluation should now also be more accurate due to the new space conversion stuff.
* Transform - No longer in Crazy Space (TM)
Transforming objects/bones with constraints applied should no longer occur in Crazy Space. They are now correctly inverse-corrected. This also applies to old-style object tracking.
=== General Code Changes ===
* solve_constraints is now in constraints.c. I've removed the old `blend consecutive constraints of same type' junk, which made the code more complex than it needed to be.
* evaluate_constraint is now only passed the constraint, and two matrices. A few unused variables have been removed from here.
* A tempolary struct, bConstraintOb, is now passed to solve_constraints instead of relying on an ugly, static workobject in some cases. This works much better.
* Made the formatting of constraint code consistent
* There's a version patch for older files so that constraint settings are correctly converted to the new system. This is currently done for MajorVersion <= 244, and SubVersion < 3. I've bumped up the subversion to 3 for this purpose. However, with the imminent 2.45 release, this may need to be adjusted accordingly.
* LocEulSizeToMat4 and LocQuatSizeToMat4 now work in the order Size, Rot, Location. I've also added a few other math functions.
* Mat4BlendMat4 is now in arithb. I've modified it's method slightly, to use other arithb functions, instead of its crazy blending scheme.
* Moved some of the RigidBodyJoint constraint's code out of blenkernel, and into src. It shouldn't be setting its target in its data initialisation function based + accessing scene stuff where it was doing so.
=== Future Work ===
* Geometry to act as targets for constraints. A space has been reserved for this already.
* Tidy up UI buttons of constraints
ID Properties weren't being duplicated (by shift-D or any of the other
duplication functions). So now ID properties are duplicated in the
main copy_libblock function, which (as far as I can check) covers all
ID-contained ID properties.
I also updated the constraint system to copy pyconstraint ID properties
on shift-D.
This would probably be a good thing to add to the stable branch, btw.
Simplified the code in two functions where checking for targets/subtargets could really have been done using Constraint API methods (constraint_has_target, get_constraint_target).
At last! The ability to code constraints in Python. This opens up many interesting rigging possibilities, as well as making prototyping constraints easier.
* A PyConstraint script must begin with the line
#BPYCONSTRAINT
* It must also define a doConstraint function, which performs the core actions of the constraint.
* PyConstraints use IDProperties to store custom properties for each PyConstraint instance. The scripter can choose which of these ID-Properties to expose to a user to control the behaviour of the constraint. This must be done using the Draw.PupBlock method.
Credits to Joe Eager (joeedh) for coding the original patch on which this is based. I've made heavy revisions to large parts of the patch.
For more detailed information, and some demo scripts, see the following page:
http://aligorith.googlepages.com/pyconstraints2
