Hi,
I’ve recently coded three new constraints for blender. Limit Location, Limit Rotation, and Limit Scale. You can download a build (for windows) at graphicall.org. For users on other systems, if you’ve got a build environment set up, you can grab the patch from the patch tracker (#4662).
EDIT: get it here http://www.graphicall.org/builds/builds/showbuild.php?action=show&id=167
Have fun testing 
Aligorith
Downloading… Can’t wait to test! 
Update:
OK nevermind… ignore the below I found the “Local” button for bones. But we seem to be lacking the button for things that are not bones.
Update:
It works! But is there a way to make the transform inputs stop changing when it hits the limit?
calvin:
The only cases where you get a Local button are
a) for bones - difference between doing it with bone restpose as original value(s) of bone, and world as origin
b) for parented objects (location only) - difference between using parent as origin, and world-origin as origin
I’m not sure what other situations you would need it for…
Unfortunately, if you want the transform inputs to stop changing, I would also have to alter/duplicate the code into the transform code, which could get messy. I’ll rethink whether the code should also change those values…
I also wonder if anybody wants me to add the necessary info to the python api for constraints. I was working on a python script that worked with modifiers the other day, and I was annoyed by how clumsy it was (constants have names in capitals, and can only be accessed by accessing the right dictionary). Constraints api as I gather, is the same as that for modifiers. If there is no interest in this, I won’t add it, as it will be an area of many bugs.
Aligorith
I definitely want the python API. I’ve been working on and off on an auto rig generation script for a while now, and the more constraint stuff is open in the Python API, the more stuff I don’t have to tell the user to fix afterwards.
On limiting the values: I think that should be coded in. By my reckoning blender calculates coordinates, etc., in the following order:
Local -> Constraint -> Parent (n) -> Constraint -> Global / World
Thus, the constraint is more than allowed to forcefully set the values, in my mind, since it only gets applied after the fact.
I don’t think I made a lot of sense there, but I hope you understand. I’ll attempt the patch a little later.
Unfortunately, if you want the transform inputs to stop changing
When you do enable the “local” button for bones. The Transform input (key n) “does” stop changing when you hit the limit. (and when you try to enter values into the transform input window, it won’t let you go passed the limit) So I’m happy… 
But for moveable objects that are not bones… it doesn’t effect the transform inputs.
I’m guessing there is a different transform input system for objects then?
Ok, I guess I might have to explain how the animation system seems to work according to my rummaging through the source and blender experience:
Objects:
object final transfrom = parent transform + user-defined transforms + constraint transforms
I’m not sure whether the parent transform is it’s final transform, or just the user-defined transform.
User-defined transforms are things like transforms in 3d-space that appear in n-key panel, ipo/action/nla value for object at given frame. IPO-drivers sort of come under here as well.
Constraints transforms. All the previous transforms are rolled into one lump and given to the constraints. Each constraint in turn, gets given this data with whatever changes the constraint(s) before it added, then it does its thing, and its changes are scaled back by the influence factor, and then its changes are integrated back into the final transform. Work is done on the matrices of the object.
If we look at the situation like this, we notice that the n-key panel only displays the USER-DEFINED transforms, not that of constraints OR parents.
User defined transforms are relative to the parent (if any), or to the world/origin. I’m not sure how inverse-parents work, as I have rarely/never used them.
Bones:
Refer to blender.org documentation on how these work…
For your knowledge, constraints on bones which have local turned on (except Action for some reason), is evaluated differently from the normal constraint evaluation code. This means that: Copy Location, Copy Rotation, and my constraints Limit Location, Limit Rotation are in a seperate function. Here, instead of working on matrices of the bone(s), the location constraints directly access the location variable of the bone(s) that the n-key panel uses. Hence why that works that way.
… but, wait…
While writing these constraints, I started pondering the possibility of adding a new mode to the nodes. In this mode, users would be able to set up chains of transforms however they liked. Imagine it… Node Based Rigging!
IPO drivers and Action constraints could be superseeded by an exciting new alternative; the ability to link either one transform to another, or a whole set of transforms to others.
Shape keys could have their values strung together so that they influenced each other…
You could define what the constraints worked on, and even what they don’t work on…
With parenting, you could selectively choose what elements of an object’s transform was affected by the parent…
This sort of thing could make blender even more powerful than maya (I think ;)), but it would come at a cost. Firstly, users would need to be acutely aware of how all of these things interact, which means that there needs to be good documentation available that makes sure how the whole thing works is clear. Secondly, speed is a major consideration - customability usually means reduced speed, as instead of going along a single black+white path, the each step needs to be looked up (like reading a map). Thirdly, the amount of changes required to the inner workings of blender would be so much that whoever implements this (ton, me, any other daring soul, or nobody at all) would probably have a hard time doing so.
Aligorith
Aligorith,
This is a fantastic addition to Blender that really “should” have been there when the Armature system was implemented or re-written.
I just tested it with this Great Horse Model/Rig, and it solves the ‘wandering head’ problem with this rig very nicely.
Great stuff !
I’m going to try applying your patch to my MingW build environment, will let you know how it goes.
Mike
mstram: thanks. I actually develop this on a MingW + Scons build environment, so it should work ok…
I’ve also heard from the Plumiferos team, who from what I hear, are really enjoying this patch. Although I wanted this functionality myself, it was the wiki Plumiferos had set up with a wishlist, that really inspired me to get it coded…
Now, I’m getting the python api for these done (compared with the rest of python api, this part is horrid IMO).
I was also wondering if, for the Limit Rotation constraint, you guys would prefer the buttons to have limits going from -180 to 180 for both min and max; -360 to 360 for both min and max; or -180 to 0 for min, and 0 to 180 for max (current. based on DoF for bones/joints in IK chains).
After this I’ll either code the other constraint I wanted (sdna already has a number allocated for it) which is a constraint that acts like parenting, or another one of the Plumiferos wishes…
Aligorith
Great stuff,Aligorith!
Blender need more constraint and rigging tools,you are going into the right direction.
A parent constraint could also be very useful.
Thank you very much.
Actually maya already has this built in, but from what I can tell it’s generally hidden. To do the really fun node-based stuff, you have to use the createNode function in the console thingy.
Now, if someone were brave enough to do this in Blender, it’d be amazing, especially if it were all visual like the current node system. One of the problems with the Maya version is that editing those nodes is a pain – just finding them requires you to select an object and then check its connections to get the constraint visible, because it doesn’t have a default clickable object or view. If Blender were able to have something similar but still have the ability to edit them visually I’d let out a girlish squeal and possibly buy the author a round of beer. ^_^;
Personally I think you should put in as much freedom as possible and let people decide, as long as it doesn’t make your job too hard. That is, -360 to 360 for each would be best in my book, as it covers the whole range. If you implement arbitrary limits at the constraint level (and don’t allow the user to pick whatever dastardly limits they want), you’ll find the results people get from the constraint to be less than if they’re given enough rope to hang themselves.
These limits aren’t really a novice thing. If the Plumiferos guys are into it, that means you’ve come across a feature that power users are going to want to use to the fullest of its ability. Thus, let the users decide how limiting things should be. Does that make sense?
Still need to try the patch. =/ Been busy, but it’s on my list!
Aligorith,
Do I need to apply all of the patches, in order (v01 - 03), or just the v03 patch?
Mike
mstram: just apply the latest version.
In response to anyone who wants to know how to apply this patch, here is what to do:
Blender Source Code Tree:
online
/cvsroot
/bf-blender (1)
/blender
/source (2)
/lib
locally
/blenderdev (1)
/blender
/source (2)
/lib
Ok, all file paths in the patch are relative to source (indicated in bold, and with the number 2 beside it).
Today, I’ve just updated the patch to include access for to the constraints from python. The one caveat at the moment is that the local buttons are a bit of a mess/overloaded to work in certain situations. The main problem for python scripters to be aware of for this current state is that THERE IS NO WAY TO ACCESS/CHANGE THE LOCAL VALUES. On top of that, the implementation of one of the local settings may have to change a bit, as currently, that setting will show up where we don’t want it.
I’ve decided to set the rotation limits at -360 to 360 for now.
I’ll provide a new build once I’ve got the python issues sorted…
Aligorith
Ok, now I’ve finally got the python api completely sorted. I’ve decided not to code any safety-nets in the api for accessing/setting values for the local settings. Instead, it is the responsibility of the SCRIPT AUTHOR to ensure that the right things are set at the right time.
To anybody who saved any files with a previous version of this patch, please be careful when opening the files with this and future (if any) version(s) of this patch, as I’ve juggled some settings around. You will need to re-set any ‘local’ settings you applied to parented objects.
Aligorith
Build updated…
Aligorith
wow this is great…
why hasnt blendernation done a story on this?
great work Aligorith, its people like you that have made blender great
Good grief! What is with you people?
You couldn’t even wait until 2.42 was out before you have to start messing around, adding new features? :eek:
Looks like it will solve some problems rather handily! Thanks, you nut.
I’m not familiar with the versions you mention - is the Windows patch based on the actual 2.42 release code or another version?
FYI, it’s the final transform.
A refresh cycle goes through the dependancy graph, to assure that all objects are finalized before the objects that depend on them.
Martin
This thing is really helpfull, but i think I found a bug:
After copying those “.dll” libraries and “.exe”, there’s something wrong with “set codec” button in render settings for animations.
It just disappear… (what I really mean is that, it doesn’t appear in its normal position).
Is this button moving to some other place??
Amrid: That might be related to the way this build was compiled (mingw+scons). It might be just one of the optional libs that I disabled (most likely quicktime).
Theeth: thanks. I shall go back and read through the depsgraph documentation again and try to understand it.
Aligorith
Theeth or anybody else with cvs write acces: If you’re reading this, just a friendly reminder that cvs is unfrozen now…
Aligorith