IK implementation
Author
Hello there;
I got my skinned mesh system working (MD5 based), and now i want do some simple IK to things like looking to a target or aiming something...i´ve searched a lot and all i got was link to buy books and a library called IKAN (not free for comercial projects)....does anybody knows a good starting place to learn about that, or has some paper, article, pdf or so on about that?
Thanks!!
Doing simple IK isn't all that hard to do yourself, this gives a quick rundown of the simplest approach and is fairly easy to implement. You do need to be fairly fluent in matrix maths, so if your not that would be a good place to start [smile]
In my oppinion CCD (Cyclic Coordinate Descent) is easier to implement and is more flexible.
It is similar (or the same) as the technique described at the bottom of the above paper linked by joanusdmentia.
CCD is particularly well suited to the axis-angle representation of rotations (which is directly supported by opengl to make life easier) if not then converting to a matrix is probably necessary for DirectX but its not that difficult.
Using CCD it is easy to impose joint constraints (to prevent daft things happening) which is is generally harder with other techniques.
Knowning your matrix math isn't really necessary for CCD (apart from the conversion from axis-angle format - but that doesn't mean matrix stuff isn't useful to know anyway) all you really need to know for this is dot-product and cross-product operations (which are easy)
CCD is definately a mathematically simple approach so I suppose it depends on how much your comfortable with :)
Edit: Here's an interesting looking paper.
Edit2: thanx to stroma for pointing out the link didn't work. Linky works here now too
[Edited by - dmatter on July 24, 2005 9:35:20 AM]
It is similar (or the same) as the technique described at the bottom of the above paper linked by joanusdmentia.
CCD is particularly well suited to the axis-angle representation of rotations (which is directly supported by opengl to make life easier) if not then converting to a matrix is probably necessary for DirectX but its not that difficult.
Using CCD it is easy to impose joint constraints (to prevent daft things happening) which is is generally harder with other techniques.
Knowning your matrix math isn't really necessary for CCD (apart from the conversion from axis-angle format - but that doesn't mean matrix stuff isn't useful to know anyway) all you really need to know for this is dot-product and cross-product operations (which are easy)
CCD is definately a mathematically simple approach so I suppose it depends on how much your comfortable with :)
Edit: Here's an interesting looking paper.
Edit2: thanx to stroma for pointing out the link didn't work. Linky works here now too
[Edited by - dmatter on July 24, 2005 9:35:20 AM]
Quote:Original post by dmatterthe link :
Edit: Here's an interesting looking paper.
http://www.darwin3d.com/gamedev/articles/col1198.pdf
The problem however with these numerical methods is that they can all the sudden give a completely different solution than the last frame, giving you nasty popping effects. You can try to work around those with some hacks, but none of them work perfectly.
An analytic solver would be best, depending on the requirements of course.
We implemented CCD, Jacobian and an analytic 2 bone solver. For lookat constraints we use a specialized analytic method, so not really using any of the IK solvers for this.
An analytic solver would be best, depending on the requirements of course.
We implemented CCD, Jacobian and an analytic 2 bone solver. For lookat constraints we use a specialized analytic method, so not really using any of the IK solvers for this.
You can avoid the popping effect by maintaining the matrix (or whatever) from the previous frame and begin the IK solver from this position rather than from the initial bind pose.
Its not a hack and prevents popping but its important to remember that for any given situation there is usually more than one solution so you won't get the same result if you move the end effector to the same point in space from a different initial position.
One last point: For a real-time application allowing CCD to run until it accurately solves the bone positions isn't reasonable so be prepared to allow the program to finish when it reaches a good approximation.
Its not a hack and prevents popping but its important to remember that for any given situation there is usually more than one solution so you won't get the same result if you move the end effector to the same point in space from a different initial position.
One last point: For a real-time application allowing CCD to run until it accurately solves the bone positions isn't reasonable so be prepared to allow the program to finish when it reaches a good approximation.
Yeah, that's one way, but unfortunately that also doesn't completely solve it and can result in some other issues again. Especially when adding joint limits things can still go wrong.
Try to do IK with CCD on a full character skeleton. It can be quite nice, but the different solutions that it sometimes picks (even with using the last pose as starting point) doesn't always make it look good.
The same however goes for the Jacobian solvers. But these are a bit smoother though.
Try to do IK with CCD on a full character skeleton. It can be quite nice, but the different solutions that it sometimes picks (even with using the last pose as starting point) doesn't always make it look good.
The same however goes for the Jacobian solvers. But these are a bit smoother though.
Ok, point taken :)
I don't suffer that problem because I never use IK for full character animation anyway.
I suppose if you want to avoid the 'popping' then you would have to accept circumstances where the solution is left un-solved rather than let the solver choose a wildly differnt pose. (like trying to scratch your back with your arm stretched across your front - either give up or take your arm into a completely different pose, it depends on how bad the itch is)
I don't suffer that problem because I never use IK for full character animation anyway.
I suppose if you want to avoid the 'popping' then you would have to accept circumstances where the solution is left un-solved rather than let the solver choose a wildly differnt pose. (like trying to scratch your back with your arm stretched across your front - either give up or take your arm into a completely different pose, it depends on how bad the itch is)
Author
To anonymous poster: can u describe your method for lookat constraints? I think i dont need a full IK solver to do only that and an aim-system...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
