Jump to content

  • Log In with Google      Sign In   
  • Create Account

Kest

Member Since 17 Aug 2005
Offline Last Active May 12 2012 06:32 PM

Posts I've Made

In Topic: Extracting an input matrix from a final matrix

12 May 2012 - 06:35 PM

Thanks for your help. I really appreciate it!

In Topic: Convert Ragdoll matrices back to Animation matrices

11 May 2012 - 02:29 PM

After two days of working at it, I finally figured it out. For anyone trying to do the same thing, this is essentially what I did:

1. Remove the primitive bind pose from all ragdoll shapes (ie: inverse(ragdoll_bind_pose)*ragdoll_transform for every ragdoll bone).
2. Treat the resulting ragdoll transforms (after #1) like rendering matrices, and convert them back to raw unrelative animation states.
3. In order to convert to animation states, I had to do the opposite procedure I did to convert normal animation states to rendering states.

For instance, if you compute a character render matrix like this: RenderMatrix = ToOrigin * state * ToJoint * parent;.
Then you would reverse that as something like this: state = inverse(ToOrigin) * RenderMatrix * inverse(parent) * inverse(ToJoint);

And this worked for me. Now I just need to figure out how to turn the top level bone into character motion.
Thanks for your help Ashman!

In Topic: Extracting an input matrix from a final matrix

11 May 2012 - 02:12 PM

Yes, that is correct. And thank you very much for the correct answer.

Just out of curiousity, and not really related to my original question, is there any way to turn this computation:
output = JointToOrigin * State * OriginToJoint

Into a single (matrix * matrix) multiply? For instance, can I pre-calculate a matrix using JointToOrigin that will allow me to perform this step with one multiply instead of two?

Thank you again for your help.

In Topic: Direct Input DIK_* defines are in incorrect order for keyboard

18 February 2012 - 12:43 PM

Well, I searched and found a keyboard testing program which reports which scan codes a keyboard uses for each key, and it seems that the keyboard is working fine. Within the program, the ] key reports scan code 27, which is after [, and all other keys seem correct. So it appears that I am some-how getting the wrong dwOfs value in my enumerating callback function. I check the value ASAP within the actual enumeration function, and it is wrong from the get-go.

Any ideas on how I can even begin trying to fix this? Anyone have their own direct input program laying around that shows the scan code for keys being pressed? That way, I could determine if my code is causing this somewhere,or if my keyboard just doesn't play nice with DirectInput. Unfortunately, the direct input samples do not include such a program.

In Topic: Dot product limitation

23 July 2009 - 03:54 AM

There are some really detailed answers here. I really appreciate the time you guys put into it. I'm still looking over it all.

Quote:
Original post by SiCrane
I'm assuming you want all of the vector inputs and outputs to be normalized vectors. In that case you could use:

Vector proj = projection of childvec onto stillvec
Vector perp1 = childvec - proj
Vector perp2 = perp1 normalized
float scalar_perp = sqrt(1 - dot_limit * dot_limit)
return dot_limit * stillvec + scalar_perp * perp2

Dude, you're awesome for laying the math out in code syntax for me (not sure if you remembered that I absorb it better that way or not). But I'm not sure I understand the first line. What would be the projection of childvec onto stillvec? Do you mean to smash it onto its normal? Something else?

PARTNERS