THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 20/06/2005 at 00:22, xxxxxxxx wrote:
Cinema 4D Version: 8.503
Platform: Windows ; Mac ; Mac OSX ;
Language(s) : C++ ;
This is sort of complex and a solution doesn't seem apparent.
I have a set of XYZ-ordered (meaning that rotation order is important) rotation keys, but the rotation axes are split (can be animated or not individually). These correspond to fixed-bone rotations. When setting static poses, the rotations are concatenated into a Matrix in the specified order, post-multiplied by the fixed-bone rotation HPB matrix, and set to the bone's Global Matrix. This has been the only way to go from XYZ-ordered to HPB rotations in the fixed-bone hierarchy.
The same procedure appears to be needed for setting up the animation keys, but this proves to be difficult since Cinema 4D's Rotation keys are Local Matrix based. If you can see where this is going, then you see the problem. Easy enough to set the Global Matrix as usual (even for an individually rotated axis), but the resulting Local Rotation Vector will contain a set of corresponding rotations to accomplish the single-axis XYZ-ordered rotation. Ain't no way to set AnimValue->value = obj->GetRot(), now is there?!
Any clever suggestions???
On 20/06/2005 at 17:10, xxxxxxxx wrote:
If there is no way to solve the actual math, I guess two workarounds would be a) implementing your own XYZ rotation track or b) animating a three levels deep structure of null objects, representing XYZ rotation.
On 20/06/2005 at 19:35, xxxxxxxx wrote:
Late last night, I did arrive at one possible approach, but it is tricky. For each rotation axis, fill in all three. If there is more than one axis rotation simultaneously (on any given object), then each rotation will need to be summed into the H, P, and B key values.
So, for an X rotation, I do my Global Matrix work and extract the Local Rotation vector. HPB are set from this vector. If there is a simultaneous Y rotation, then its HPB are added to this (signed values). And the same for the Z rotation. This has't been implemented and tested yet.
I did try a Local only approach, but with identical results to a simpler, more naive method. When the figure is rigged and bones fixed, I store the Local Matrix of each bone into a tag as a 'default pose' matrix - this allows me to reset the pose and thereafter apply new ones. I tried extracting that and adding the rotations (which are converted from Degrees into Radians). But Cinema 4D has the nasty habit of juxtaposing the axial rotation function on fixed bones - this I have more than sufficient evidence for such as when you go to rotate a bone axis and it doesn't rotate on the perpendicular plane but another. So, there is no means to guarantee that the axes that I think (after careful, logical consideration) are the correct one to which to apply the XYZ rotations are the ones they will affect. So, I think that it would be possible to apply the local rotations if and only if there were a way to know what bone axis is assigned to H, P, and B rigorously.
On 20/06/2005 at 23:38, xxxxxxxx wrote:
One problem with my possible approach is the matter of keyframe interpolations. That could get messy since each rotation axis can have different interpolations. Hmmm...
As for nested Null objects, never! Null objects within a fixed bone hierarchy are bad. They destroy the hierachical chain. For such necessities, I use Null bones. Ah, but they suffer just as greatly from this odd rotation behavior.
It is one thing to have all of this done for you when doing user manipulations in the editor/AM, but quite another when trying to set things programmatically. Without knowledge or information on how Cinema 4D does its little HPB dance (like juxtaposition at certain values (90d or 180d)), it makes things very difficult. Great to avoid gimbal lock, bad for me since this style of rotation is not documented anywhere. If you can provide or coax the Maxon developers to divulge sources (I have an ACM membership), that may help.
On 21/06/2005 at 08:13, xxxxxxxx wrote:
After some observation and experimentation, it appears that the local rotation problem may be all a problem of 'gimbal lock'. The individual rotation keys appear to be correctly setup and, in this particular case, the right arm animation of the figure is working correctly. But the left arm is not responding since as the bones go from pointing +X to -Y in some cases, the heading becomes coincident with the banking rotation and its rotatability becomes lost. This is classical gimbal lock.
Now, if this were a normal rotation set to the object, I'd use a XYZ-ordered Matrices to avoid this (as I do for posing). But this is animation keyframes.
Any information on how to work with this situation - remembering the individual interpolations and individuality of rotatability?