Which Constraints are not Ready for "Prime Time?"

Hi All,

I’m run across a few constraints that just aren’t working properly and I’ve been told there are others, but I’m looking to find out which ones.

So far, I know about these:

Track to: Doesn’t always know which way is ‘up’

Clamp to: just doesn’t do anything; the Target field doesn’t even show a list of possible targets

Can anyone add to this list?

PS: I’m not trying to dis anyone’s efforts or complain about broken bits of Blender. I just want to know which constraints to avoid for now until they’re fixed.

Clamp To does work. You can only clamp to curves (and maybe more, but it definitely works for curves). Unfortunately it isn’t hugely useful because you have very little control of where on the curve your object will be clamped to. You can only have blender’s “best guess”.

Thanks, Timmmm (is that the right number of m’s… [whispering to self] one, two, three… four). It never occurred to me that I was seeing nothing in the list because I had no curves in the scene.

Still, as you said, it doesn’t seem very useful if there’s no control.

To answer your questions:

  1. Track To - broken by design, and isn’t going to be “fixed” per se as it is kindof beyond that. Instead, use the Damped Track constraint only.
  2. Clamp To - it works, for the specific purpose for which it was designed (i.e. moving along a curve only). Use Shrinkwrap only instead for what you want to do.
  3. The only constraint to avoid outright is Pivot.

For other info, see:

Thanks. I knew about the substitution; someone else told me (might even have been you).

But… What do you mean, “broken by design?” What’s the reasoning behind it?

Thanks again. I didn’t know about that one.

Excellent! Thanks once again. This is the kind of thing I’ve been looking for.

As with any Community Driven Software … like Linux… and Blender… and others… different people at different times… (History of the Software) get Rewriten by different people… it’s sometimes easier for an new guy to just stick with writing his new and improved version than trying to go back and change what someone else has done… (the new programmer not knowing 100 % for sure what all was done… ) so it becomes dangerous (as in crashing the Programm) to just strip out an old piece of code. Risking software failure in the process… So what happens is you put in the new improved Code and leave in the old Code in for awhile until your sure everyone has feild tested the new one… plus you continue to study the old code and it’s connections unitl you are confident about taking it out… Plus… there may be some users to object to the way the new one works and still like the old one … for what ever reason… so it may get left in just to please peoples wishes…

That is the case I’m sure with Track to and Damped Track… Dampted Track is the new version… (at least this is what I have heard through the grapevine…) I had not heard that Shrinkwrap was the replacement for Clamp to… but that makes since…

@norvman:
Yeah, I was thinking about the constraint system this morning and came to the conclusion that whoever wrote the original system has likely moved on. Getting coders to document their code can sometimes be challenging (personal experience) but it sure helps increase understanding for later maintainers.

I can only imagine how mind-bending a constraint system is to write. :spin:

Yah I haven’t writen any C++ for decades… but I remember some of that stuff… I think I still have a head ache from one piece of code I tried to write for a graphics driver… (didn’t work in the end)… I think that’s why I gave up on trying to be a coder…

The ChildOf constraint does not seem to work correctly when recording keyframes in the BGE. The keyframes are recorded correctly, but the viewport is not updated correctly.

I know what you mean. :slight_smile:

Is this behaviour the same in Blender itself?

Is this behaviour the same in Blender itself?

Seems to be the same in Blender Render as well as Blender Game.

NOTE: It is only while the physics system is running that I experience the problem.

Thanks, Atom.