>From Ken (who wrote the IK for the combine in hl2):
It's currently only enabled for HL2, and only for npcs. We've not done it for multiplayer. As it's currently written, the server doesn't do IK, only the clients. The main issue is that the client can't do the drop all on its own, the server needs to do the adjustment so that it can do accurate collision detection for bullets. In order for the model to drop enough below the AABB for the feet to touch the ground, there's backchannel in the client->server networking for when the IK fails. All it really is is if the npc is too high, it tells the server how much it needs to drop so that the feet will hit the ground. See CBaseAnimating::SetIKGroundContactInfo() and related code. The funky cycling you're seeing is the IK enabling and disabling itself on the client after failure. For players, you can probably go ahead and do it all on the server, just be prepared to eat the extra per-frame animation cost. Normally animations are only calculated if a traceline intersects the AABB, or on the client if they're in the FOV, which is usally only a tiny fraction of the possible set. For NPC's, on the server their animation is only calculated to about 10hz, way too slow to catch them running up stairs. In any case, to get it to always work you'll need to calculate every player every frame to see how much they'll need to drop. On top of that, you'll need to synchronize the feet on the client and server, something we've never done. All of that might not be a issue for your game, but we couldn't afford it during HL2. -----Original Message----- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Christopher Harris Sent: Thursday, July 16, 2009 4:55 PM To: 'Discussion of Half-Life Programming' Subject: [hlcoders] Multiplayer Inverse Kinematics? Hey, I've been trying to implement IK onto our models in a multiplayer OB mod and have been running into numerous issues. 1)The legs have a tendency, when near the max of the chain, to spaz out. (Basically it looks as though it is trying to find the ground to put the feet on, but fails and then tries again. It causes the offending limb to pop up and down. 2)Unlike in Lost Coast for example or models are not fitting to the terrain in a similar manner to that of combine soldiers for instance. Their idle anim has the knees with literally no bend which means they are the length of the ikchain at rest and even though this is true they can still walk up a stairs with a proper feet to stair alignment. When our model tries to rest idle on a set of stairs the leg on the highest stair is looking good, but the other foot just floats in the air as if IK was not on. Here are my QC commands that I have been toying with: The ikchains: $ikchain rfoot "valvebiped.Bip01_R_Foot" Z 0 knee 0.707 0.707 0 center 4 0 0 pad 2 $ikchain lfoot "valvebiped.Bip01_L_Foot" Z 0 knee 0.707 0.707 0 center 4 0 0 pad 2 $ikautoplaylock rfoot 1.0 0.1 $ikautoplaylock lfoot 1.0 0.1 And then examples from our idle animation: $animation a_idle "idle1" { loop weightlist HipsLowerbodyReplace ikrule lfoot footstep 3 ikrule rfoot footstep 3 } I have 3 there because I assumed it would map to IK_GROUND in code, but it does not. I've also tried in my ikrules contact 0 and height 24 with no noticeable difference resulting. With these settings currently the legs only seem to have very little range in the idle because it sets the model height to be based off the highest leg instead of the lowest leg and so when model is at a little ledge with ground not very far below the leg can't reach because the idle has the legs almost full extended. Thanks Chris _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
