Bake Joint Animation?
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 26/11/2008 at 23:32, xxxxxxxx wrote:
User Information:
Cinema 4D Version: R10+
Platform: Windows ;
Language(s) : C++ ;---------
First off, bear in mind that I'm not terribly versed with animations in general, or Joints, in particular, so any help will be appreciated...
Ok, I'm working on exporting rigging and keyframed animations related to that rigging. The problem (or advantage, depending on your perspective) with Cinema 4D is that there are so many different methods available to rig/animate a figure. I might be looking at a 'Bone' system, or a 'Joint' system or some other setup. Even within those options, they are fairly open-ended as far as adding controllers, constraints and expressions, etc. to further limit or control the rigging.
Anyway, my current question is in regards to "Joint" Object rigs. My understanding is that I can look for and grab a pointer to a CAWeightTag object and use that to get a list of joints, as well as weights/weight-maps for each joint. So far, so good - that pretty much covers what I need to export the rig itself.
Next thing I also need to do is export animations. Again, this is a new area for me, but I'll figure out how to get the tracks and keyframe info I need... but my concern is this:
Most of the example riggings/animation I've looked at doesn't actually animate the "Joint" objects themselves (no keyframes for joints) - instead, controllers are set up and the controllers are animated. Therein lies my question... without just exporting every frame, is there some way to resolve the controller keyframes into joint keyframes (ie. without having to basically parse the entire scene to determine what expressions, constraints and controllers may be affecting some particular joint) ?
Is there some sort of BakeJointKeyFrames() routine that I'm missing? Or... any ideas?
Thanks,
Keith -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 27/11/2008 at 00:13, xxxxxxxx wrote:
I am afraid you have to "bake" the animation of the joints for each frame. You have to use AnimateDocument() because AnimateObject() does not evaluate expressions.
cheers,
Matthias -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 27/11/2008 at 04:55, xxxxxxxx wrote:
Thanks... Ouch. Do exchange formats like Collada and FBX preserve good keyframe info? I guess a mechanism for transfering the IK chain info would go a long way to solving the issue - I'll look into that, but I don't recall seeing anything on that yet (for Ogre3D XML-based mesh/skeleton formats).
BTW, do we have programatic access (and docs) for IK chain info (IK Tag not found in R10 SDK docs)? -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 27/11/2008 at 05:13, xxxxxxxx wrote:
...also, would doc->AutoKey() help me here? I've never used that, but it sounds like maybe I could AnimateDocument() to each frame and call AutoKey() with (a copy of ?) the previous frame to help determine which joints actually moved/rotated (presumably, keys would be created only for the ones that changed).
That would still be inefficient (from a 'key' frame perspective), but might be cleaner than just exporting a keyframe for every joint on every frame. Then again, it might be easier for me to just track a matrix for each joint and do the comparions myself as I animate the document and write out keyframes. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 27/11/2008 at 05:28, xxxxxxxx wrote:
I can't speak directly to C4D, but I've done something similar at work lately in Maya.
I wouldn't bother with transferring IK chains. Chains tend to behave very differently between programs. I don't know how OGRE handles IK (if at al) but I bet you'd spend more time fixing the IK than anything else.
As far as the chains go, don't worry about exporting the data per frame. Gather all the information, then check the slopes between frames. If the slopes are even, you can then go in and remove redundant keys.
FBX is great at maintaining keyframe data, as well as constraints (in some situations) and even IK. I know that Collada can hold animation clip info, but I don't know if it's as all-encompassing as FBX.
The other thing you could consider is writing your own IK solver in Ogre3D. It sounds scarier than it actually is -- the math is here, with Flash demos:
http://www.gotoandplay.it/_articles/2004/12/inverseKinematics.php
A word of advice if you go that route: keep your solver 2D, and rotate at the hip or the shoulder if you want to spin the whole chain.
As far as the IK tag goes, I did a bit of testing on this a few months ago and found that you can get the tag's type through COFFEE. I can't recall the function but it returns an integer that IIRC wasn't listed anywhere. The different fields in the Tag's window (goal, start, end, etc) can be dragged into the COFFEE window, too, so you can figure out what their actual names are. A lot of stuff that's missing in the SDK can be discovered this way.
Hope that helps.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 27/11/2008 at 06:11, xxxxxxxx wrote:
Hi katt,
Thanks for all the tips. What I'm working on is a generalized Ogre3D file Export plugin - I don't actually use Ogre3D myself, so I'm just trying to determine what the total pool of gatherable data is and how I might go about accessing it. I've got all the 'mesh' part of it working fine and am now looking into the 'skeleton' side of things (which includes keyframed skeletal animations).
I just did another quick scan of the .dtd file (the XML template for the Ogre3D file formats) and didn't see anything related to IK at all, so I'm pretty much going to have to resolve animations to the joint/bone keyframe level. Your comment on checking the 'slopes' sounds like what I was thinking about looking for next... can you (or anyone else) elaborate on where I can find that info in C4D?
And yes, I actually found that the IK Tag is a'Tkinematic'type and figured that I'll probably need to parse it's BaseContainer to find the data it tracks, but thanks for those tips as well. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 27/11/2008 at 06:35, xxxxxxxx wrote:
BTW... my thinking on the IK (tag) thing is/was that... If I can figure out the structure of the IK chain(s), I can generate/fill-in keyframes for the joints that are affected by keyframed goal objects.
For example, given the following IK chain:ankle |_toe |_toe_tip...with an IK Tag on the 'ankle' Joint (the start of the chain), with the 'End' set to the 'toe_tip' Joint and 'Goal' set to some Null object in the scene named 'toe_tip.Goal'.
In this case, there would likely not be any keyframes set up for the Joint Objects (ankle, toe, toe_tip), but there would be keyframes for the ' toe_tip.Goal ' object. Since the goal will be affecting all the joints in that chain, I'm thinking that I could just generate a keyframe for those joints for every keyframe where the goal had one.
This may be more trouble than it's worth though, since it may not account for every other thing that might cause those joints to be altered (expressions or something?). It might be safer to just animate the document and see what's changed and then try to clean up those results based on the slopes as you mentioned (which might aso be a more generalized solution for working with Joints vs Bones, etc). -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 27/11/2008 at 07:15, xxxxxxxx wrote:
I think you will run into problems as soon as there are not only IK expressions involved. You simply can't track all expression links. The approach to compare the joints' matrices from frame to frame seems to be the best way I think.
cheers,
Matthias -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 27/11/2008 at 07:31, xxxxxxxx wrote:
Yeah, I think even 'constraints' on the joints could cause intermediate (erm, sub-keyframe) changes. Thanks.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 27/11/2008 at 07:41, xxxxxxxx wrote:
I agree with Matthias here. The matrix is the thing of most importance for export as it has the final transform information for each bone/joint. And you can forego the insanity of trying to combine all of many influences (including third-party plugins like Cactus Dan's or mine for instance).
