From BlenderWiki
Goals
- Constraints to become a generalised relationship model for Objects and Bones
- Inverse correction of constraints for Transform - for offsets and no more crazyspace?
- 'Nice', standardised way of handling the various spaces that constraints may wish to work in
- (Possibility of complex node setups for picky riggers?)
- Blending of constraints?
What is a Constraint
A constraint describes a relationship between one Object/Bone (target) and another Object/Bone (owner). Some constraints may not need to use a target though.
Relative-Transform
- Copy Loc/Rot/Scale
- Child Of (parent-child relationship)
Directional
- TrackTo/LockTrack
- StretchTo
- IK?
Surface/Tracking/Restriction
- Clamp To -> curve path, curve surface/NURBS surface, mesh
- Floor
- Limit Loc/Rot/Scale
Freeform
- Python/Script (i.e. expressions, drivers)
New Style Constraints
UI
- Presentation of constraints:
- Maintain current vertical stacking panels?
- Show array of available constraints on owner, but only one active?
- Standards for constraints GUI's:
- Currently very haphazard. Buttons are often placed in the 'first empty space' available, and are very cramped most of the time.
- Spaces to work in should be presented in some uniform manner in the UI:
- Some combo-box with pictures around the top of each constraint ?
Target Types
In the code, there are defines for the following types of targets already:
- Object (in use)
- Bone (in use)
- Vertex (not used)
- Face (not used)
- Control Point (not used)
The types that are not currently in use could become quite potentially useful, reducing the need for complex hook+constraint combos to get things done.
Evaluation
- Solve_Constraints:
- The current hack of copying PoseChannel data into a tempolary object should be abandoned. An alternative is to use a special struct that contains only the necessary data that will be used. Ideally, direct access to data will be enabled.
- The 'inverse' of constraint stack is inverse(post_constraint_matrix * inverse(pre_constraint_matrix))
- Evaluation should simply apply each constraint, in turn, to the final matrix. Fancy normalisation of influences may be considered, but is not really critical.
- Constraint evaluation function should simply be given:
- It's own data - for special handling/behaviour
- Source matrix to work on (already in correct space). The 'result' is to be directly written to this when done. There really isn't any any constraint that needs direct access to the owner's data.
- Target matrix (also in right space). It contains the appropriate information from the target.
- Space Handling:
- Constraints can be evaluated in multiple combinations of spaces (for both owner and target)
- Before a constraint is evaluated, all the matrices it is supplied with must be in the appropriate space. After it has been evaluated, the inverse operation must take place.
- No constraint should need to perform its own calculations for spaces
- Spaces will include the effects of previous constraints
- Spaces for Objects: World-Space, Parent-Space, Local-Space
- Spaces for Bones: World-Space, Pose-Space, Local-Space
IK and Constraint Stack
- Current method of solving IK for whole pose after all constraints doesn't work well in all cases. There are situations where it is really needed by riggers, and lack of tools causes frustration.
- Possible Solution: calculate pose twice. 1 = constraints not reliant on IK results + IK; 2 = constraint reliant on IK results. Will need depsgraph changes most likely.
Blending of Constraints
- Old method was to blend the effect of consecutive constraints of same type (normalising).
- This lead to the need for Null constraints in order to stop certain combinations blending into each other
- For example, it made it easy to have the owner sit in the middle of two or more targets, via several Copy Location constraints with the same influence, sitting one after the other
- Current method is to just blend constraints as their weight value dictates with any previous constraints.
- No need for NULL constraints as they're just ignored anyway
- Using the previous example, it will be more difficult to do so, as the user needs to calculate the appropriate blending values for each so that they blend in the right way
- Possible new methods:
- Node trees to help mix complex mixes
- Make new constraint(s) or reuse Null constraint to signal that a bunch of constraints need to be blended in a particular fashion
Changes for Specific Constraints
Copy Rotation
This really needs to work in Quaternions. However, in some cases this currently works worse due to a few nasty flipping artifacts in places. That needs to be resolved.
Action
Location and Size input support are critical.
ChildOf
Code me! Needs to be ported from existing parenting code.
TrackTo
Has a few issues on certain angles (i.e. when target is directly in line with owner) causing weird turning - related to quat math again?
Limit Location
Remove space handling stuff.
ClampTo
Support meshes as surface to clamp to?
Stretch To
Cessen reports that there is the following bug with this constraint since 2.44: Depending on relative position the sphere behaves how it should vs becoming a line. (http://www.cessen.com/storage/temp/stretch_to.blend)
Progress Reports
Stages
- Stage 1 - Clean up existing code (formatting, comments, unneeded variables, move stuff around)
- Stage 2 - Recode the way constraints are evaluated (solve_constraints function is a mess). Set up the space conversion tools, and constraint inverse systems. Allow geometry to be the target of a constraint.
- Stage 3 - Fix up existing constraints to work with the new system, and resolve any issues they have. Also, code any constraints that are needed (i.e. ChildOf).
15 July 2007
- This has now been committed to svn.
12 July 2007
- Constraints are no longer transformed in crazy space. Old hacks in the transform system have been removed to do this. Hopefully this doesn't break any other transform features.
- Patch
http://aligorith.googlepages.com/constraints_recode_06.patch
11 July 2007
- Fixed bug with order of matrix creation for ChildOf constraint. It may also improve behaviour of Copy Rotation constraint.
- A few more PyAPI tweaks
- Latest patch again:
http://aligorith.googlepages.com/constraints_recode_05.patch
10 July 2007
- ChildOf constraint now has a 'rough' form of a inverse matrix functionality
- The basis foundations for a constraints inverse correction is now in place.
- Transform code still doesn't work well with constraints, but I did a few experiments to see what could enable this to happen. Awaiting clarification from theeth about these matters before proceeding.
- PyAPI has now been updated to remove old things that don't work anymore, and add support for ChildOf constraint.
- Patch:
http://aligorith.googlepages.com/constraints_recode_04.patch
09 July 2007
- A few more little bugfixes/code cleanups here and there
- At last! The mighty, long anticipated, ChildOf constraint!
- Although I've implemented a possibility for an inverse matrix, this doesn't seem to be necessary (according to preliminary tests).
- For this to totally duplicate behaviour of old parenting, constraints will need to be able to use geometry data as a target. How this will be exposed in the interface still needs to be thought out, before this support is coded for all constraints.
- The patch with these changes is here:
http://aligorith.googlepages.com/constraints_recode_03.patch
- After publishing the patch, I realised I had a few mistakes in the code (yet again).
- ChildOf constraint did not actually work right yet, but that has now been rectified.
- Added a sortof hack for certain situations. Unfortunately, it still doesn't solve the problems with the FollowPath constraint (it requires a local matrix, AND also the world-space scaling).
- The updated patch is here:
http://aligorith.googlepages.com/constraints_recode_03a.patch
- Tomorrow, I aim to complete this project
- Inverse correction of constraints needs to be done
- Related to that is the inverse for ChildOf constraint
- Also, PyAPI needs to be fixed up to cope with changes
08 July 2007
- Fixed a version-patching bug with Action Constraints
- Removed some mucky code from new_constraint_data -> RigidBodyJoint constraint should not have been setting its target on initialisation from there. That should not have been in blenkernel at all, but rather in src (it's more of interface stuff)
- ChildOf Constraint nearly functional (just supporting functions done)
- Local Space for both Objects and Bones should now be working properly in all but one very minor case
- When using the Copy Location constraint: if a parentless bone is copying the location of a bone with a parent, rotating the parent of the bone with a parent will cause the parentless bone to move in circles.
- New patch with today's fixes:
http://aligorith.googlepages.com/constraints_recode_02.patch
07 July 2007
- Recoded Action Constraint so that now it has been code, supports using location or scaling of the target as well, and works through the spaces api. It might cause a few minor compatability woes, but hopefully nothing too major.
- Removed any obsolete code from other constraints that had not yet been removed
- Started coding the ChildOf constraint (porting it from a PyConstraint prototype I did the other day). Data structure and flag defines done.
- A clever 'inverse' function needs to be created for this, but I'll probably do that after I've got this stuff in svn, as a separate refactor of the parenting code.
- Properly set up interface to access space stuff
- After doing so, I've found that 'local' is currently not working for rotation/scaling of bones. However, 'local with parent' works better for those two cases
- Link to first patch:
http://aligorith.googlepages.com/constraints_recode_01.patch
06 July 2007
- Quickly hacked Limit/Copy Location Constraints to work with the spaces api to see how well it was working.
- Spent a whole day tracking down two simple bugs (typos)
- Objects work perfectly well with this api now
- Bones now also work perfectly well with this api
- Bumped up subversion number for version patches, so that old files will get corrected accordingly.
05 July 2007
`Stage 2' nearly complete
- The crufty old 'blend consecutive constraints' code has been removed. Constraint evaluation can be done much more simply without it, and nobody really missed it anyways.
- Removed the stupid 'size' hacks that each constraint performed. It basically set the value of an array named size to {1,1,1}, just so that the consecutive cruft could work ok.
- Added a semi-experimental way of transferring data to and from the solve_constraints function. A temporary struct (bConstraintOb) is dynamically allocated for each operation of solving a set of constraints.
- This really gets rid of the static workob, and also provides a uniform base for objects and bones, which can later be extended.
- There are 2 api calls to set this up, so that it works nice
- My only concern is whether this constant memory (de)allocation may slow down transforms a bit...
- Work on space conversion 'api' is almost done. There's just one case that's left to code (local to pose), and then it can be tested.
04 July 2007
`Stage 1' pretty much complete.
- This involved moving some code around (notably solve_constraints from object.c to constraint.c)
- Removal of unnecessary stuff - unused variables passed to functions, variables that were initialised but not used
- evaluate_constraints is no longer passed an object (or workob for pose-bones) and a two other variables for any funky stuff that needs those.
- most constraints didn't need those things anyway
- FollowPath and Limit Location are the only two constraints affected by this change, as they needed access to other variables of the object structs. However, that was done as they needed matrices in different spaces, which will be looked into later anyways.
Now on to Stage 2: main evaluation loop.
