driver radian confused

I was under the impression that any variable multiplied by a formula would equal to 1 unit in the dependency graph.

i.e var*(pi/4) would mean that 1 unit is equal to 45 degrees.

Recently what happens is that the degree of rotation on the object doing the driving is multiplied by the equation.

so if it’s 45 degrees what happens is that 0.785*(pi/4) which is news to me.

Is there something I’m missing?

Its fairly straight forward from a mathematical point of view, you should remember that:

  1. A full circle of 360 degrees is 2 * pi radians.
  2. 1 radian = 57.29199821758228 degrees (approximately, you can never be accurate, thanks to the work of Isaac Newton in his work Principia Mathematica, which is nothing to do with apples falling on your head!)
  3. To express a rotation in a Driver you should always use radians, not degrees.
  4. To convert a rotation in degrees to radians you should use a formula of the order R(radians) = (R(degrees) * pi) / 180.

So 45 degrees = (45 / 180) * pi = pi / 4 as you have stated, so if you want something to revolve by blocks of 45 degrees, driven by a variable, your expression would be var * (pi / 4) as you have stated. This however, will not resolved to a single unit in the dependency graph, or ay other graph for that matter. If you want a straight line movement of the target variable of 1 unit to result in a rotation of 45 degrees of the driven object then your equation would hold true, however, what is often confused is that if you take a rotation from another object as your variable, you then are dealing with radians driving radians, so there is no need to insert the pi converter. If you want one object to rotate 45 degrees, for every rotation of 90 degrees by the target object, your scripted expression becomes simply var / 2.

The number 0.785 rings a bell with me in that it is 45 degrees expressed as a 3 sig. fig. Radian. Beyond what I have said it would be difficult to comment further unless I see a blend file with your driver in it - you may be missing/messing something somewhere, otherwise I hope this helps.

Cheers, Clock.

I’ve hacked the thing to work. It’s not mathematically accurate but visually/functionally yes.

If you’d be willing to take a look.

http://www.pasteall.org/blend/35393

The bone in question is MCH_mechanicalAnchor.

What’s happened is that Frame numbers have been replaced by Driver values at desired increments.

The goal of the problem was to have
(dependency graph)
1st Frame = 27 degree rotation
2nd Frame = 35 degrees
3rd Frame = 27 again
4rth Frame = 0
then same in the negatives

Didn’t check out though.

thanks

At first, I said …

You should have been able to do this simply with curves … setting keypoints at the necesary frame-numbers and then manually editing the Y-values of each point by calculating and then typing-in the appropriate floating point number.

You would have had to enter “27.0” and “35.0” manually anyway, of course. But, instead, you’d just grab your handy calculator or, in a slightly-obscure Blender feature, tell Blender to calculate the formula itself.

However, “if it worked, then Mission Accomplished.™ Move on to the next shot.” :slight_smile:

But then, on second thought, I said …

And-d-d-d, come to think of it, a driver can be “just what the doctor ordered.” If what you want to do is to move in an inclusive range between (say …) 27.0 and 35.0 degrees, then “a driver is,” in effect, “a mathematical function.” You can easily define the driver to be a function f(a)=b that maps an input (a) in the range [0.0 … 1.0] to an output (b) in the range [27.0 degrees = radians … 35.0 degrees = radians]. That might be much cleaner and easier to manage, if, say, the driver-function mimics the mechanical range-of-motion of some driven machine-part.