Just a quick question about constraints in general:
If I wanted to have a constraint at 0.25 influence, say, a transformation constraint, how would I get it to use the entire range of target motion?
For instance, if I rotate the target around two full revolutions, the constraint owner should rotate half of one revolution. But it doesn’t. At half a revolution of target movement, the constraint owner suddenly flips as though I’m rotating from the other side!
This is very annoying. I need the constraint owner to recognize multiple revolutions. How would I go about doing that?
This may be a bug in how the constraints calculate rotations – your problem has been reported before here, and I submitted a bug report based on using the Transform Constraint, but haven’t yet seen any response.
i would suggest you dont use a constraint-transform from the
rotation of the source-object to the rotation of the target-object.
You should setup a source-object with a translation (example only in y-axis)
and use this translation in a constraint-transform to the rotation of the
2 other objects (example use rot around x-axis and there use the y-axis-movement
of the source-object). If you move the source-object along the y-axis,
both target-objects will rotate and you can setup different influence or
you can setup differnt ranges to be calculated for rotations.
In 2.49 blender you have to enable “extrapolate” in the constraint, because
you can only enter up to 360degrees for rotation. In 2.5alpha one can enter
bigger values like 3600degrees for 10 full-rotations.
@ test-dr: I tested the Transform Constraint by mapping rotation of one object to translation of another, both with and without Extrapolate enabled. In all cases, there was an anomalous “resetting” of the driven object’s position at specific points in its source’s rotation cycle. With Extrapolate enabled, the error was cyclic and predictable by a specific formula.
More info and an exemplar .blend can be found at this link
cant read the bug-entry … no enabled cookies –
but, did you read my tip? I suggested to go the other way and
use a transform from translation to rotation, not rotation to rotation.
As long one do not use a procedural(scriptet, function) rotation generation,
the setup of a rotation by hand needs special treatment to have a turn
in cycles and not suddenly a turn backward.
And last, i did test the 2.5alpha version only with some simple cubes
and the constraint transform.
Rotation IPOs can be easily edited for continuous rotation, or set to extrapolate, but constraints aren’t editable in that regard. Note that I mapped rotation to translation using the Transform Constraint, not rotation to rotation. The glitch occurs at 180deg + n * 360deg, where n is the period for continuous or cyclic rotation of the source object, so at 540, 900, 1260deg … the positional value of the driven object resets instead of increasing continuously as expected. This is not the same as reaching 360 deg and returning to zero.
The glitch would apply to mapping source rotation to (fractional) rotation as well. An earlier thread reported the same prob with fractional influence and rotations using the Copy Rotation Constraint, and a later thread about mapping rotation to translation led me to investigate the Transform Constraint’s operation. The test .blend is attached if you want to see it in action.
I tested in 2.46, 2.48 & 2.49 with the same results. It would be interesting to see if it acts the same way in 2.5 alpha, which I don’t have on board.
@chipmasque,
here is your blend-file with an example cube
rotating and moving down (like your screw)
but i cannot see any “glitch” -
compressed-2.49-blender-file 5000Bytes
and move the empty along the z-axis to see the
rotating and moving down cube
or run animation …
The point is not that mapping translation to rotation does not work (your file shows it does), but that mapping rotation to translation (or any other transform) has a periodic error that should not be there (which my setup shows). Your example is a workaround for the “screwdriver”-type effect, but for something like a gear train, where a master gear rotation should be able to drive differential rotation of satellite gears via fractional influence of the constraint, the bug I describe screws things up (pun intended ).
Both our examples should work – yours does because there’s no error in reading translation and mapping it to rotation. Mine doesn’t because there is an error in reading rotation and mapping it to translation.
The OP mentioned using rotation to drive rotation using fractional influence, thus my response was based on that configuration, as an explanation of what he was seeing.
If you can produce a file in 2.5 that maps rotation to translation without the periodic error, then it would show that the problem has been addressed and fixed in 2.5. But it’s still present and problematic in 2.49 & below.
i dont see a problem,
why running with the head against the wall instead using a door a few steps aside?
I asume you cannot realize the basic difference between rotation and translation,
… there is no problem to check the direction in translation, it is always straight.
Rotation will always have problems …
… using smaller steps to solve the problem is only possible for some time until the space
between those steps is hit.
You know it is easy to check that the number 7 is below 8 and above 6,
but where is the positon in an rotation of 80 degrees? … you know the difference
between left and right? … or are you hanging upside-down …
thats why i suggested to use a source-translation to drive an constant rotation and
not to use a rotation to drive another rotation …
).