hellborg@Posted: Sun Oct 15, 2006 3:04 am :
Hi!

I followed the BSoD/Introduction_to_Character_Animation guidelines to setup my IK, so that the character's feet are locked in place (in the game: to the floor). This was very useful for example to animate a jump animation - with the feet on the floor, the torso can simply be dragged and the legs stretch and react very naturally. As soon as the character lifts of, I can then explicitly move the feet to finish the animation.

To achieve this, controler bones are added to the feet, which are the child of "none" to keep them from moving when I animate other parts of the rig. It works great in Blender and it helps a lot to generate more complex animations and I can also export the animation, but doom3 does not like to have multiple root bones and does not load the model. So, instead of making the controler bones the child of none, I made them child of origin. Works fine in blender, but after I import it into Doom3, the legs don't react correctly anymore. It seems as if the feet stay on the ground as I wished, but the bones inbetween the feet and the body appear to be loose and the skin of the leg stretches instead of the natural way how the leg would stretch by rotations of the joints. I tried to bake the animation, but that did not help either.

So, I wonder, if there is a way to properly bake all rotation/location positions, so that they import correctly into Doom3. Or, alternatively, if there is a different way how I can setup my character, so that I have a nice IK setup, which keeps the feet on the ground while I shift the torso etc.

Thanks alot!



kat@Posted: Sun Oct 15, 2006 5:05 am :
How have you actually rigged the model? Are you using Blender auto IK system or have you set up a different system? What version of Blender are you using?

Post a screenshot if you can as that's help to figure out what you've done and what you need to do. I could suggest something now but I'd rather see what you've done so you can work around the problem rather than causing you more problems than necessary.



hellborg@Posted: Sun Oct 15, 2006 7:35 am :
Thanks kat for offering your help.

I am using Blender 2.42 and I do not use the autoIK.

This is what I want to achieve:

http://www.gravity-music.net/temp/ikgoal.jpg

At the same time I want to have the benefits of controling each individual foot using an IK solver:

http://www.gravity-music.net/temp/ikgoal2.jpg

As I said earlier, this all works fine in Blender, but after export to doom3, the legs are not reacting in the way how they react in Blender.

This is what I have done:

http://www.gravity-music.net/temp/iksetup.jpg

I think all the important info is in the picture. The foot has a total of three bones: llegbfoot, backleg_l and backfoot_l (sorry for the senseless names...) basically, backleg_l is the control bone and does not have any weights assigned to it. llegbfoot and backfoot_l control the mesh. Additionally, llegbfoot has a ik solver that extends to all bones of the whole leg.



kat@Posted: Sun Oct 15, 2006 8:37 am :
hmm; fill in the gaps for me.. your leg chain of bones goes something like this?
Code:
hips > upper leg > lower leg > ankle > foot


With the 'helpers' connected to the 'foot' bone like this?
Code:
foot > helper 1
foot > helper 2

Of all of that which one one the 'master' IK? The 'foot'?

Try simply 'moving' the IK master to the two helper bones and see what that does. IOW you'll have two master IK controllers then, backfoot and backleg (I'm assuming those are the IK controllers from the info you've posted). It might be that not having an IK controller at the very end of the chain is was messing things up slightly.

One of the other things you want to try and do is keep the bones 'upright' so the fat end is at the base of the bone becasue doing it the way you've done it looks like the chain reads from the top down rather than bottom up (hips > foot instead of foot > hips) which *may* also be effecting what happening. Take that with a pinch of salt though as I don't know if it 'technically' makes any difference. IOW it should go;
Code:
foot > ankle > lower leg > upper leg > hips
That's as much as I can think without looking at the mesh itself.



kat@Posted: Sun Oct 15, 2006 8:40 am :
Oh wait... bleh I just remembered, there *might* be issues with the exporter and 2.42 so check that as well as a source of the problems by trying to export the model from 2.41 (you *should* be ok to open the 2.42 file in 2.41).

That's an interested idea to lock the feet like that btw, I hadn't thought to try that with my own characters :wink:



6th Venom@Posted: Sun Oct 15, 2006 9:36 am :
Hehe! So hellborg, you redid all bones and skin? Maybe it was the best solution for the wing problem, plus you use blender who is very different that max for Ik system.

What i can say to you, is that in max you don't include helpers (IK) into the skin for export, IK in max is just used for YOU make your animations and export them.
D3 create its own IK system with your def declarations.
Code:
model your_monster {
   anim ik_pose            models/md5/monsters/your_monster.md5anim
...

and
Code:
entityDef your_monster {
...
   "ik_numLegs"         "2"  //here it's for a standard 2 legs monster.
   "ik_footSize"           "20"
   "ik_minWaistAnkleDist"       "50"
   "ik_footUpTrace"      "32"
   "ik_footDownTrace"        "128"
   "ik_waist"            "Body"
   "ik_hip1"            "Lupleg"
   "ik_hip2"            "Rupleg"
   "ik_knee1"           "Lloleg"
   "ik_knee2"          "Rloleg"
   "ik_ankle1"                  "Lankle_r"
   "ik_ankle2"                  "Rankle_r"
   "ik_dir1"                  "Lknee"
   "ik_dir2"                  "Rknee"
   "ik_foot1"                  "cyber_lfoot_dust"
   "ik_foot2"                  "cyber_rfoot_dust"
...

So i think you don't got to export your IK system, cause you redefine it in your entity definition.
But maybe i missunderstood the blender problem here! :wink:



kat@Posted: Sun Oct 15, 2006 10:00 am :
This is about the IK system used in Blender to animate a model *not* a problem with trying to *export the IK*, which you correctly point out you can't do (D3 doesn't understand external 'IK' systems).

It's possibly not a def file issue either, but I reserve judgement on that, as it sounds like a problem associated with the way the data is being exported (generally speaking bones that don't have any vert groups asigned to them are supposed to be ignored anyway regardless as to whether they get exported - they simply don't do anything)



hellborg@Posted: Sun Oct 15, 2006 10:30 am :
6th Venom:

I actually did not need to redo the rig/skin - it all imported into blender from your md5mesh file. I also imported the testanimation you did and that worked fine as well. But as you point out, the md5mesh file does not contain a IK setup, so I need to redo it. The IK in the rig is not intended for in game IK functionality, but for helping to animate nice smooth animations. I also do not want to export this IK setup - I just want to use it to easily set the bone angles/positions for exporting nice animations.

Kat:

to make this easier, I will give the bones better names:

foot for llegbfoot
toe for backfoot_l
legcontrol for backleg_l

child-parent relationships:

hip>legup>legmid>leglow>foot

origin>legcontrol>toe

both chains are 'somehow' glued together by the IK solver, as the 'target' (but not the parent?) of the foot is the legcontrol. See the picture for details on how the IK solver constraint was setup. Don't ask me why, this is just copying the way how it was suggested in the BSoC tutorial.

the only bone in this setup that has an ik solver is the 'foot' bone, not the legcontrol. I guess, that the IK solver is controlled by the legcontrol bone, as legcontrol is a target of the IK solver.

I will see if switching to 2.41 helps.



hellborg@Posted: Sun Oct 15, 2006 10:48 am :
hmm, I tried 2.41 and I also removed the af setup to avoid any potential problems with the altered bone rig, but neither of these solved or altered the problem....



kat@Posted: Sun Oct 15, 2006 11:09 am :
You know you're right... based on what you've posted there that shouldn't even be working at all because the control bones have no parent>child relationship with any of the leg bones by the looks it.

Those control bones *should* be parented to the legs because those are the bones they control UNLESS.....

... What you did when you set the system up was extrude those control bones from the foot so they're part of the bone chain - this is hard to describe but essentially if you extrude a bone from another it remains 'connected' even if it's not set to influence the parent bone.

The opposite to that is if you create the control bones independantly as seperate armature objects and then 'join' them all together the bones will move independantly of each other so will need a parent > child relationship.

I don't know if you've seen this video I did a while back that ran thru the basics (no audio) of using Blender 'manual' IK chain setup, it might prove helpful here.

Basically there is something wrong with the relationship between your bones and at a guess based on what you've said the legs are breaking because those control bones are parented to the origin bone and not the 'foot' as they should be (according to the animation data on export).



hellborg@Posted: Sun Oct 15, 2006 12:33 pm :
Thanks for the info Kat,

I think that I understand the basic manual IK setup. What I wanted to do and what I suceeded at within blender, was to lock the feet - by whatever means, so that animating the rig gets easier. I looked through various tutorials for IK setup and the technique I used here is the only one I came accross to do this. I do not really understand why it needs to be so difficult. The IK solver apparently can only be set up to influence bones in the hirarchy towards the parent bones. I.e., I can tell the IK to influence up to 5 parent bones. That works fine, if I set a IK constraint on the tip of the extremity. However, if I setup an IK solver in a central bone, such as the torso, and set a chain length of 3 bones, it will correctly influence only 3 bones up the hirachy, but then it will influence all the child bones (including the feet...). I tried to solve this problem with the above setup, which worked in blender, but then failed to export. I would be very happy, if there is another setup that would yield similar functionality. It just seems to be a very basic task to me...



kat@Posted: Sun Oct 15, 2006 12:56 pm :
hmmm I know what you're trying to do but I've never actually needed to try and use it so I can't confirm any technique to use.

The way the rig needs to be set up so that D3's ragdoll stuff works properly does tend to make rigging rather tricky when you want to do something like you're attempting at the moment. however, I do know there is supposed to be some 'walk helper' in 2.42 somewhere but I've yet to properly look at 2.42 myself so you may need to root around the elysiun forums and see what you can dig up.



kat@Posted: Sun Oct 15, 2006 4:04 pm :
OK, I just had a look at this on my Bob character. Basically this 'trick' won't work becasue it changes the parent > child relationship between the anchor bone set and the origin.

Becuase of the way the bones tend to reparent themselves to the origin bone (because of the way the constraint works) it means that in effect, and as D3 sees it, it's creating another 'limb' from where lowerLeg parents to origin.

In other words, the *complete* leg chain has been broken (toe all the way up to hip - it's now in effect Toe > lowerLeg, and then lowerLeg > Hip).

So although it animates and works fine in Blender (which it would do) it won't in D3 - technically it *is* working properly but because in effect there is now an extra 'limb' it means the skeleton is then behaving as if it should have one there, so relative to what you did in Blender, D3 will play that anim back 'incorrectly'.

Basically this is an 'internal' trick used for animation *rendering* rather than character animation for *exporting*, at least to D3.



hellborg@Posted: Sun Oct 15, 2006 8:37 pm :
Alright, let me try to look at this from another point of view. After I bake the animation, I would expect, that all the rotations and translations of the individual bones are 'baked' according to the IK solver. However, if I look at the ipo curves, I can see only the translations and rotations, which I explicitly applied while making the animation. And looking at the final result in Doom3, it appears, that these bone movements are the only ones, which are exported. Am I doing something wrong while I bake the animation?



kat@Posted: Sun Oct 15, 2006 10:03 pm :
You shouldn't need to use bake to be that explicit with the IPO data. Basically strategic keyframing will work as the anim gets baked on export anyway as part of the process.

Baking *should* be fixing the pose for all bones at each frame of the anim and I think by default it bakes rotation/translation (not scaling or anything else), so I'd expect to see that sort of data in the MD5 anyway; if you're getting that then it at least means the animation is getting out of Blender OK. So based on what we're seeing it looks like the data *is* correct but D3 doesn't know how to work with the wierd parenting relationship it finds.

Incedently have you tried running this mesh and anim through der_toms model viewer? If you get the same wierd behaviour in that as you do in D3 then yeah, there's something wrong with the exported data.

I still think that what I mentioned above about the 'broken' leg is what's happening based on what I saw happen when I followed the BSoC docs myself.

Have you tried (contraint) 'targeting' the legs at an empty or something like that? I seem to recall there was a way to target a bone at an object and have it not move unless the target was moved and using a constraint means that the parent > child relationship shouldn't be adversly effected.



hellborg@Posted: Mon Oct 16, 2006 12:16 am :
THat was a good suggestion. I checked the modelviewer and the animation looks perfect. So, yes, it is soemthing about the animation within Doom3 that messes things up. One other thing about the animation in DOom3 is that the origin does not move along with the animation. Maybe that has something to do with it. I will try to experiment with this a bit more to figure out what is going on.



kat@FIXME failed to extract: Doom3world • View topic - problems with IK setup to 'lock feet on the ground'

Doom3world

The world is yours! Doom 3 - Quake 4 - ET:QW - Prey - Rage
It is currently Thu Dec 27, 2007 5:02 pm

All times are UTC




Post new topic Reply to topic  [ 26 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: problems with IK setup to 'lock feet on the ground'
PostPosted: Sun Oct 15, 2006 3:04 am 
Offline
picked up 200 ammo

Joined: Sun Jan 30, 2005 9:59 am
Posts: 277
Hi!

I followed the BSoD/Introduction_to_Character_Animation guidelines to setup my IK, so that the character's feet are locked in place (in the game: to the floor). This was very useful for example to animate a jump animation - with the feet on the floor, the torso can simply be dragged and the legs stretch and react very naturally. As soon as the character lifts of, I can then explicitly move the feet to finish the animation.

To achieve this, controler bones are added to the feet, which are the child of "none" to keep them from moving when I animate other parts of the rig. It works great in Blender and it helps a lot to generate more complex animations and I can also export the animation, but doom3 does not like to have multiple root bones and does not load the model. So, instead of making the controler bones the child of none, I made them child of origin. Works fine in blender, but after I import it into Doom3, the legs don't react correctly anymore. It seems as if the feet stay on the ground as I wished, but the bones inbetween the feet and the body appear to be loose and the skin of the leg stretches instead of the natural way how the leg would stretch by rotations of the joints. I tried to bake the animation, but that did not help either.

So, I wonder, if there is a way to properly bake all rotation/location positions, so that they import correctly into Doom3. Or, alternatively, if there is a different way how I can setup my character, so that I have a nice IK setup, which keeps the feet on the ground while I shift the torso etc.

Thanks alot!


Top
 Profile  
 
 Post subject:
PostPosted: Sun Oct 15, 2006 5:05 am 
Offline
"...mostly harmless?!"
User avatar

Joined: Thu Nov 08, 2001 11:00 pm
Posts: 4940
Location: UK, York
How have you actually rigged the model? Are you using Blender auto IK system or have you set up a different system? What version of Blender are you using?

Post a screenshot if you can as that's help to figure out what you've done and what you need to do. I could suggest something now but I'd rather see what you've done so you can work around the problem rather than causing you more problems than necessary.

_________________
ImageCo-Admin - Modelling and modding tutorials and tips


Top
 Profile  
 
 Post subject:
PostPosted: Sun Oct 15, 2006 7:35 am 
Offline
picked up 200 ammo

Joined: Sun Jan 30, 2005 9:59 am
Posts: 277
Thanks kat for offering your help.

I am using Blender 2.42 and I do not use the autoIK.

This is what I want to achieve:

http://www.gravity-music.net/temp/ikgoal.jpg

At the same time I want to have the benefits of controling each individual foot using an IK solver:

http://www.gravity-music.net/temp/ikgoal2.jpg

As I said earlier, this all works fine in Blender, but after export to doom3, the legs are not reacting in the way how they react in Blender.

This is what I have done:

http://www.gravity-music.net/temp/iksetup.jpg

I think all the important info is in the picture. The foot has a total of three bones: llegbfoot, backleg_l and backfoot_l (sorry for the senseless names...) basically, backleg_l is the control bone and does not have any weights assigned to it. llegbfoot and backfoot_l control the mesh. Additionally, llegbfoot has a ik solver that extends to all bones of the whole leg.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Oct 15, 2006 8:37 am 
Offline
"...mostly harmless?!"
User avatar

Joined: Thu Nov 08, 2001 11:00 pm
Posts: 4940
Location: UK, York
hmm; fill in the gaps for me.. your leg chain of bones goes something like this?
Code:
hips > upper leg > lower leg > ankle > foot


With the 'helpers' connected to the 'foot' bone like this?
Code:
foot > helper 1
foot > helper 2

Of all of that which one one the 'master' IK? The 'foot'?

Try simply 'moving' the IK master to the two helper bones and see what that does. IOW you'll have two master IK controllers then, backfoot and backleg (I'm assuming those are the IK controllers from the info you've posted). It might be that not having an IK controller at the very end of the chain is was messing things up slightly.

One of the other things you want to try and do is keep the bones 'upright' so the fat end is at the base of the bone becasue doing it the way you've done it looks like the chain reads from the top down rather than bottom up (hips > foot instead of foot > hips) which *may* also be effecting what happening. Take that with a pinch of salt though as I don't know if it 'technically' makes any difference. IOW it should go;
Code:
foot > ankle > lower leg > upper leg > hips
That's as much as I can think without looking at the mesh itself.

_________________
ImageCo-Admin - Modelling and modding tutorials and tips


Top
 Profile  
 
 Post subject:
PostPosted: Sun Oct 15, 2006 8:40 am 
Offline
"...mostly harmless?!"
User avatar

Joined: Thu Nov 08, 2001 11:00 pm
Posts: 4940
Location: UK, York
Oh wait... bleh I just remembered, there *might* be issues with the exporter and 2.42 so check that as well as a source of the problems by trying to export the model from 2.41 (you *should* be ok to open the 2.42 file in 2.41).

That's an interested idea to lock the feet like that btw, I hadn't thought to try that with my own characters :wink:

_________________
ImageCo-Admin - Modelling and modding tutorials and tips


Top
 Profile  
 
 Post subject:
PostPosted: Sun Oct 15, 2006 9:36 am 
Offline
Last man standing
User avatar

Joined: Tue Nov 22, 2005 12:42 am
Posts: 1172
Location: somewhere over the rainbow...
Hehe! So hellborg, you redid all bones and skin? Maybe it was the best solution for the wing problem, plus you use blender who is very different that max for Ik system.

What i can say to you, is that in max you don't include helpers (IK) into the skin for export, IK in max is just used for YOU make your animations and export them.
D3 create its own IK system with your def declarations.
Code:
model your_monster {
   anim ik_pose            models/md5/monsters/your_monster.md5anim
...

and
Code:
entityDef your_monster {
...
   "ik_numLegs"         "2"  //here it's for a standard 2 legs monster.
   "ik_footSize"           "20"
   "ik_minWaistAnkleDist"       "50"
   "ik_footUpTrace"      "32"
   "ik_footDownTrace"        "128"
   "ik_waist"            "Body"
   "ik_hip1"            "Lupleg"
   "ik_hip2"            "Rupleg"
   "ik_knee1"           "Lloleg"
   "ik_knee2"          "Rloleg"
   "ik_ankle1"                  "Lankle_r"
   "ik_ankle2"                  "Rankle_r"
   "ik_dir1"                  "Lknee"
   "ik_dir2"                  "Rknee"
   "ik_foot1"                  "cyber_lfoot_dust"
   "ik_foot2"                  "cyber_rfoot_dust"
...

So i think you don't got to export your IK system, cause you redefine it in your entity definition.
But maybe i missunderstood the blender problem here! :wink:

_________________
If that smell like a shit & look like a shit... it's a shit. ;)


Top
 Profile  
 
 Post subject:
PostPosted: Sun Oct 15, 2006 10:00 am 
Offline
"...mostly harmless?!"
User avatar

Joined: Thu Nov 08, 2001 11:00 pm
Posts: 4940
Location: UK, York
This is about the IK system used in Blender to animate a model *not* a problem with trying to *export the IK*, which you correctly point out you can't do (D3 doesn't understand external 'IK' systems).

It's possibly not a def file issue either, but I reserve judgement on that, as it sounds like a problem associated with the way the data is being exported (generally speaking bones that don't have any vert groups asigned to them are supposed to be ignored anyway regardless as to whether they get exported - they simply don't do anything)

_________________
ImageCo-Admin - Modelling and modding tutorials and tips


Top
 Profile  
 
 Post subject:
PostPosted: Sun Oct 15, 2006 10:30 am 
Offline
picked up 200 ammo

Joined: Sun Jan 30, 2005 9:59 am
Posts: 277
6th Venom:

I actually did not need to redo the rig/skin - it all imported into blender from your md5mesh file. I also imported the testanimation you did and that worked fine as well. But as you point out, the md5mesh file does not contain a IK setup, so I need to redo it. The IK in the rig is not intended for in game IK functionality, but for helping to animate nice smooth animations. I also do not want to export this IK setup - I just want to use it to easily set the bone angles/positions for exporting nice animations.

Kat:

to make this easier, I will give the bones better names:

foot for llegbfoot
toe for backfoot_l
legcontrol for backleg_l

child-parent relationships:

hip>legup>legmid>leglow>foot

origin>legcontrol>toe

both chains are 'somehow' glued together by the IK solver, as the 'target' (but not the parent?) of the foot is the legcontrol. See the picture for details on how the IK solver constraint was setup. Don't ask me why, this is just copying the way how it was suggested in the BSoC tutorial.

the only bone in this setup that has an ik solver is the 'foot' bone, not the legcontrol. I guess, that the IK solver is controlled by the legcontrol bone, as legcontrol is a target of the IK solver.

I will see if switching to 2.41 helps.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Oct 15, 2006 10:48 am 
Offline
picked up 200 ammo

Joined: Sun Jan 30, 2005 9:59 am
Posts: 277
hmm, I tried 2.41 and I also removed the af setup to avoid any potential problems with the altered bone rig, but neither of these solved or altered the problem....


Top
 Profile  
 
 Post subject:
PostPosted: Sun Oct 15, 2006 11:09 am 
Offline
"...mostly harmless?!"
User avatar

Joined: Thu Nov 08, 2001 11:00 pm
Posts: 4940
Location: UK, York
You know you're right... based on what you've posted there that shouldn't even be working at all because the control bones have no parent>child relationship with any of the leg bones by the looks it.

Those control bones *should* be parented to the legs because those are the bones they control UNLESS.....

... What you did when you set the system up was extrude those control bones from the foot so they're part of the bone chain - this is hard to describe but essentially if you extrude a bone from another it remains 'connected' even if it's not set to influence the parent bone.

The opposite to that is if you create the control bones independantly as seperate armature objects and then 'join' them all together the bones will move independantly of each other so will need a parent > child relationship.

I don't know if you've seen this video I did a while back that ran thru the basics (no audio) of using Blender 'manual' IK chain setup, it might prove helpful here.

Basically there is something wrong with the relationship between your bones and at a guess based on what you've said the legs are breaking because those control bones are parented to the origin bone and not the 'foot' as they should be (according to the animation data on export).

_________________
ImageCo-Admin - Modelling and modding tutorials and tips


Top
 Profile  
 
 Post subject:
PostPosted: Sun Oct 15, 2006 12:33 pm 
Offline
picked up 200 ammo

Joined: Sun Jan 30, 2005 9:59 am
Posts: 277
Thanks for the info Kat,

I think that I understand the basic manual IK setup. What I wanted to do and what I suceeded at within blender, was to lock the feet - by whatever means, so that animating the rig gets easier. I looked through various tutorials for IK setup and the technique I used here is the only one I came accross to do this. I do not really understand why it needs to be so difficult. The IK solver apparently can only be set up to influence bones in the hirarchy towards the parent bones. I.e., I can tell the IK to influence up to 5 parent bones. That works fine, if I set a IK constraint on the tip of the extremity. However, if I setup an IK solver in a central bone, such as the torso, and set a chain length of 3 bones, it will correctly influence only 3 bones up the hirachy, but then it will influence all the child bones (including the feet...). I tried to solve this problem with the above setup, which worked in blender, but then failed to export. I would be very happy, if there is another setup that would yield similar functionality. It just seems to be a very basic task to me...


Top
 Profile  
 
 Post subject:
PostPosted: Sun Oct 15, 2006 12:56 pm 
Offline
"...mostly harmless?!"
User avatar

Joined: Thu Nov 08, 2001 11:00 pm
Posts: 4940
Location: UK, York
hmmm I know what you're trying to do but I've never actually needed to try and use it so I can't confirm any technique to use.

The way the rig needs to be set up so that D3's ragdoll stuff works properly does tend to make rigging rather tricky when you want to do something like you're attempting at the moment. however, I do know there is supposed to be some 'walk helper' in 2.42 somewhere but I've yet to properly look at 2.42 myself so you may need to root around the elysiun forums and see what you can dig up.

_________________
ImageCo-Admin - Modelling and modding tutorials and tips


Top
 Profile  
 
 Post subject:
PostPosted: Sun Oct 15, 2006 4:04 pm 
Offline
"...mostly harmless?!"
User avatar

Joined: Thu Nov 08, 2001 11:00 pm
Posts: 4940
Location: UK, York
OK, I just had a look at this on my Bob character. Basically this 'trick' won't work becasue it changes the parent > child relationship between the anchor bone set and the origin.

Becuase of the way the bones tend to reparent themselves to the origin bone (because of the way the constraint works) it means that in effect, and as D3 sees it, it's creating another 'limb' from where lowerLeg parents to origin.

In other words, the *complete* leg chain has been broken (toe all the way up to hip - it's now in effect Toe > lowerLeg, and then lowerLeg > Hip).

So although it animates and works fine in Blender (which it would do) it won't in D3 - technically it *is* working properly but because in effect there is now an extra 'limb' it means the skeleton is then behaving as if it should have one there, so relative to what you did in Blender, D3 will play that anim back 'incorrectly'.

Basically this is an 'internal' trick used for animation *rendering* rather than character animation for *exporting*, at least to D3.

_________________
ImageCo-Admin - Modelling and modding tutorials and tips


Top
 Profile  
 
 Post subject:
PostPosted: Sun Oct 15, 2006 8:37 pm 
Offline
picked up 200 ammo

Joined: Sun Jan 30, 2005 9:59 am
Posts: 277
Alright, let me try to look at this from another point of view. After I bake the animation, I would expect, that all the rotations and translations of the individual bones are 'baked' according to the IK solver. However, if I look at the ipo curves, I can see only the translations and rotations, which I explicitly applied while making the animation. And looking at the final result in Doom3, it appears, that these bone movements are the only ones, which are exported. Am I doing something wrong while I bake the animation?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Oct 15, 2006 10:03 pm 
Offline
"...mostly harmless?!"
User avatar

Joined: Thu Nov 08, 2001 11:00 pm
Posts: 4940
Location: UK, York
You shouldn't need to use bake to be that explicit with the IPO data. Basically strategic keyframing will work as the anim gets baked on export anyway as part of the process.

Baking *should* be fixing the pose for all bones at each frame of the anim and I think by default it bakes rotation/translation (not scaling or anything else), so I'd expect to see that sort of data in the MD5 anyway; if you're getting that then it at least means the animation is getting out of Blender OK. So based on what we're seeing it looks like the data *is* correct but D3 doesn't know how to work with the wierd parenting relationship it finds.

Incedently have you tried running this mesh and anim through der_toms model viewer? If you get the same wierd behaviour in that as you do in D3 then yeah, there's something wrong with the exported data.

I still think that what I mentioned above about the 'broken' leg is what's happening based on what I saw happen when I followed the BSoC docs myself.

Have you tried (contraint) 'targeting' the legs at an empty or something like that? I seem to recall there was a way to target a bone at an object and have it not move unless the target was moved and using a constraint means that the parent > child relationship shouldn't be adversly effected.

_________________
ImageCo-Admin - Modelling and modding tutorials and tips


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 16, 2006 12:16 am 
Offline
picked up 200 ammo

Joined: Sun Jan 30, 2005 9:59 am
Posts: 277
THat was a good suggestion. I checked the modelviewer and the animation looks perfect. So, yes, it is soemthing about the animation within Doom3 that messes things up. One other thing about the animation in DOom3 is that the origin does not move along with the animation. Maybe that has something to do with it. I will try to experiment with this a bit more to figure out what is going on.


Top
 Profile  
 
 Post subject:>