Do I have to copy the frames over if I do IK?

Started by
8 comments, last by L. Spiro 9 years, 8 months ago

Let me first describe my situation. I have an IK solver, which updates the upper arm of the agent. But it finishes updating, the character goes back to the original pose (T-pose). I don't like that to happen, I want the character to stay in that pose after the IK finishes, now I am trying to resolve it, I think the problem lies in that the frame root belongs to the master copy of the mesh, I clone the animation controller for each instance but just making a shallow copy of the skinned mesh. If I also clone the frames over, I don't think it will happen any more. But my question is if I have thousands of such characters, will it consume a lot of computer resources? Could anyone please help me find out the solution?

Update:

Could anyone explain how to work this out?

If the animation set has a tick of 500 per second?

And the keyframes lie at 0, 625, 1250, 1875, 2500

And the m_pAnimSet->GetPeriod() returns 5.0f, why does it work out like that?

Thanks

Jack

Advertisement


the character goes back to the original pose

You haven't provided enough information to help you out with that. And it's not clear what "original pose (T-pose)" is. The bind pose? The pose it was in what the IK started? Just a guess - after the IK has completed you update the animation controller and the animation controller uses identity matrices for both the offset and animation matrices.


If the animation set has a tick of 500 per second?

And the keyframes lie at 0, 625, 1250, 1875, 2500

And the m_pAnimSet->GetPeriod() returns 5.0f, why does it work out like that?

The period is the length of time a particular animation takes from beginning to end. The keyframe with a tick count of 2500 is the last frame.

2500 ticks / 500 ticks/sec = 5 seconds.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

Hi Buckeye,

The original pose is the T-pose (Bind pose).

However, I run into this problem now, this is quite a priority.

These two code snippets return different positions.

D3DXVECTOR3 pos = D3DXVECTOR3(m_pHandBone->CombinedTransformationMatrix._41,m_pHandBone->CombinedTransformationMatrix._42,
            m_pHandBone->CombinedTransformationMatrix._43) + D3DXVECTOR3(0.0f, 3.0f, 3.0f);
D3DXVECTOR3 target(pos.x, pos.y, pos.z);
ApplyArmIK(D3DXVECTOR3(0,0,-1), target);

This returns
-3.594435 15.447500 32.920174 which is right

if (m_time <= m_pAnimSet->GetPeriod()) {    
   D3DXVECTOR3 sca, pos;
   D3DXQUATERNION rot;
   m_pAnimSet->GetSRT(m_time, 0, &sca, &rot, &pos);
   D3DXVECTOR3 target(pos.x, pos.y, pos.z);
   ApplyArmIK(D3DXVECTOR3(0, 0, -1), target);

returns 64.055664 124.475006 -0.798272

for the first frame, which is wrong.

I have created an animation set (m_pAnimSet) with keys

Time: 0

Value: _41, _42, _43 of the Combined Transformation of the hand bone

Time: 2000

Value: The value at 0 with addition of D3DXVECTOR3(0,3,3) to it.

BTW, I have tested 2 sets of keyframes with seemingly no difference to the results of GetSRT();

Hope you can shed some lights on this.

Thanks

Jack

First, you're highjacking your own post. Bad form. If you have a question not related to the current topic, create a new thread. Just to be clear, this isn't "your" thread - it's for everyone's benefit. The process of keeping discussion within a thread consistent has several advantages:

- primarily, it's consistent with forum rules. Review the FAQ.

- for those searching the forums for questions and answers, it keeps information in one place and provides better search results. Your posts aren't just for your own benefit.

- for you, people will see a new topic that they may be able to help you with. They may have looked at your current topic before, and skip it the next day. You'll get better responses by keeping to the topic.

With regard to GetSRT: are you, in fact, interested in animation index 0 only? Is that the correct index for what you're trying to do?

Commonly, animation sets have an animation for most bones/nodes/frames. If you're targeting a particular bone, do you get an index of 0 when you call GetAnimationIndexByName?

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

[del]....................

Short answer: if you only store the model in bind pose, every time you want to render it in any other pose, IK-ed or not, you have to re-pose it as you render (e.g. vertex skinning shader).

If you want to render a model in a particular pose without doing this then, yes, you need to make a copy of the model.

This is just simple logic, not related to anything specific about what you are doing.

Example: shadow mapping requires rendering a model multiple times so (notwithstanding any recent cleverness with API stuff I don't know about) there is a tradeoff between doing the skinning on a bind pose model multiple times to keep the skinning in hardware or doing the skinning CPU side (and paying the memory cost to store it) so you can just render the model multiple times in its current pose without having to repeat the skinning calculations.

I've personally found that doing multiple skinning is cheap compared to creating a dynamic vertex buffer, filling it and uploading it to the GPU just to save a few matrix operations per vertex in a shader but YMMV.

IK is a fully solvable instruction over very CPU. You need to supplly those. But in my experience, one cannot separate those data from visible phenomena, as much as it gets. Thisis one unlucky stuff of visulaization.....

I have an IK solver, which updates the upper arm of the agent.

how many elbows?

how many planes of an elbow violation in structure?

an elbow caries a single plane, look at your own.

do you need a procedural behaviour?

ragdoll?

not realy

I am lately trying to implemetn morphing, let talk about this. We cannot do stuff without that

In regards to inverse kinematics, which is the only thing I will address in this topic, you have a high-level processing error.

There is no reason the model should go back to bind-pose for any reason unless you specifically tell it to do so. Each joint in the skeleton has a matrix for its current orientation. This matrix changes when the joint moves as a result of IK, FK (forward kinematics; standard animation), or user-supplied matrix-modifiers (to make a head look at a target for example).

The only reason your system would go back to bind-pose after running an animation or performing IK is if you put it into bind-pose each frame and then update from there.
This is not how it works.

The proper flow is:
  • Load Model
  • Apply Bind-Pose as Default
  • Update Joint Matrices Based on FK, IK, or Custom Routines
  • Repeat #3 Until Model Unload


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

This topic is closed to new replies.

Advertisement