## RE: [Algorithms] calculating weights for blending arbitrary number of animations

 RE: [Algorithms] calculating weights for blending arbitrary number of animations From: Ryan Greene - 2004-11-30 19:34:36 ```I tried doing this exact system for a project I worked on in the past, but found the results to be pretty poor -- it was rare that a character was aiming his weapon juuuust right. Furthermore, the cost of having an animator build _proper_ animations was just too much, so I wrote an IK solver to do the work. It took a little time to get it right, but the results are a whole lot better and easier to generate. I had my animators build a few base aiming poses from different positions -- standing, crouching, and prone, then wrote special IK for each (although standing and crouching were nearly identical). I'm willing to bet the IK approach is slightly more expensive than blending together a few animations, but it is just so much easier (once you get over the fact that you're doing near full-body IK), especially from an asset production standpoint. Another benefit we got from it was that it was easy to tie into weapon firing to simply adjust the IK to simulate weapon recoil w/o having to have another layer of animations to deal with. I'm sure other people have had good results from the animation blending technique, but from a project that had way too few animators doing way too many animations -- IK is the way to go. -----Original Message----- From: gdalgorithms-list-admin@... [mailto:gdalgorithms-list-admin@...] On Behalf Of Yordan Gyurchev Sent: Tuesday, November 30, 2004 11:23 AM To: gdalgorithms-list@... Subject: [Algorithms] calculating weights for blending arbitrary number of animations Hello, Imagine a soldier (or character with a weapon of some kind). We are tying to get its weapon (two weapons, two handed weapon) to point into the direction of aiming. We have 9 animations. Each represents a pose into a certain direction. Each "pose" animation has a vector associated with it. For a given character aiming direction vector we compute weight for each animation to contribute into the final anim. Question is: Given N (in this paricular case 9) vectors and the aiming one how to compute good weights that max to 1.0 when the aming coincides with them? (Did I mention that weights need to add up to 1.0? but of course you know that...) We have tried few methods and we have a couple of working but far from ideal bodged solutions. I'm sure someone has solved this problem elegantly with some clever maths. A lot of games seem to do that kind of thing although in some cases IK can be applied. One solution that gives smooth results is just a dot product. Wi =3D Vi dot Va where Wi are normalized afterwards with Wi =3D = Wi/sum(Wi) (Wi weight for each bone, Vi - Direction vectors for anims, Va - aim vector) Unfortunately, this only works perfectly if all direction vectors (Vi) are perpendicular to each other so when they max out no other anim contributes to the final. It still works in other cases but the results are not accurate enough for us. We have also explored few solutions where assumptions have been made that some vectors lie in a certain plane but I'm looking for a generic solution that will work in all cases. Thanks, Yordan ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.=20 http://productguide.itmanagersjournal.com/ _______________________________________________ GDAlgorithms-list mailing list GDAlgorithms-list@... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 ```

 RE: [Algorithms] calculating weights for blending arbitrary number of animations From: Ryan Greene - 2004-11-30 19:34:36 ```I tried doing this exact system for a project I worked on in the past, but found the results to be pretty poor -- it was rare that a character was aiming his weapon juuuust right. Furthermore, the cost of having an animator build _proper_ animations was just too much, so I wrote an IK solver to do the work. It took a little time to get it right, but the results are a whole lot better and easier to generate. I had my animators build a few base aiming poses from different positions -- standing, crouching, and prone, then wrote special IK for each (although standing and crouching were nearly identical). I'm willing to bet the IK approach is slightly more expensive than blending together a few animations, but it is just so much easier (once you get over the fact that you're doing near full-body IK), especially from an asset production standpoint. Another benefit we got from it was that it was easy to tie into weapon firing to simply adjust the IK to simulate weapon recoil w/o having to have another layer of animations to deal with. I'm sure other people have had good results from the animation blending technique, but from a project that had way too few animators doing way too many animations -- IK is the way to go. -----Original Message----- From: gdalgorithms-list-admin@... [mailto:gdalgorithms-list-admin@...] On Behalf Of Yordan Gyurchev Sent: Tuesday, November 30, 2004 11:23 AM To: gdalgorithms-list@... Subject: [Algorithms] calculating weights for blending arbitrary number of animations Hello, Imagine a soldier (or character with a weapon of some kind). We are tying to get its weapon (two weapons, two handed weapon) to point into the direction of aiming. We have 9 animations. Each represents a pose into a certain direction. Each "pose" animation has a vector associated with it. For a given character aiming direction vector we compute weight for each animation to contribute into the final anim. Question is: Given N (in this paricular case 9) vectors and the aiming one how to compute good weights that max to 1.0 when the aming coincides with them? (Did I mention that weights need to add up to 1.0? but of course you know that...) We have tried few methods and we have a couple of working but far from ideal bodged solutions. I'm sure someone has solved this problem elegantly with some clever maths. A lot of games seem to do that kind of thing although in some cases IK can be applied. One solution that gives smooth results is just a dot product. Wi =3D Vi dot Va where Wi are normalized afterwards with Wi =3D = Wi/sum(Wi) (Wi weight for each bone, Vi - Direction vectors for anims, Va - aim vector) Unfortunately, this only works perfectly if all direction vectors (Vi) are perpendicular to each other so when they max out no other anim contributes to the final. It still works in other cases but the results are not accurate enough for us. We have also explored few solutions where assumptions have been made that some vectors lie in a certain plane but I'm looking for a generic solution that will work in all cases. Thanks, Yordan ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.=20 http://productguide.itmanagersjournal.com/ _______________________________________________ GDAlgorithms-list mailing list GDAlgorithms-list@... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 ```
 RE: [Algorithms] calculating weights for blending arbitrary number of animations From: Peter-Pike Sloan - 2004-11-30 23:36:40 ```It's on my web page. There is also a paper on using this type of stuff for IK explicitly: "Artist-Directed Inverse Kinematic Using Radial Basis Function Interpolation", Rose et al Eurographics 2001. http://research.microsoft.com/~ppsloan/ The above paper does a couple of things, one is to use "pseudo-examples" (warping the basis functions associated with each animation effectively, but not introducing a new animation) to satisfy the IK constraints explicitly in the parameterization of the abstract space - ie: in your pointing example the abstract space could be a 2D plane (where the gun should point to), given a small number of examples, it would create basis functions for each example that when evaluated sum to 1 and at any location the gun should be pointing in the given direction (ie: just evaluating these basis functions makes everything work.) The idea of pseudo examples was developed more in the I3D paper - but it focused on shape and efficiency related issues more than animation. -Peter-Pike Sloan (The k-nearest neighbor interpolants can sometimes be better behaved compared to the RBF stuff that we used, but I think there are scenarios where RBF's work quite well.) -----Original Message----- From: gdalgorithms-list-admin@... [mailto:gdalgorithms-list-admin@...] On Behalf Of Alex Mohr Sent: Tuesday, November 30, 2004 3:01 PM To: gdalgorithms-list@... Subject: Re: [Algorithms] calculating weights for blending arbitrary number of animations >I also saw a reference to another method called cardinal radial basis=20 >functions and a reference to a paper that I'm not able to find/download >on the web. SLOAN, P.-P., ROSE, C., AND COHEN, M. F. 2001. Shape by example. >In Proceedings >of 2001 Symposium on Interactive 3D Graphics. > >Does anyone have a link? If I type 'shape by example' into google and hit "I'm feeling lucky", I get the pdf. Does this not work for you? Alex ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.=20 http://productguide.itmanagersjournal.com/ _______________________________________________ GDAlgorithms-list mailing list GDAlgorithms-list@... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 ```
 RE: [Algorithms] calculating weights for blending arbitrary number of animations From: Ryan Greene - 2004-12-06 19:49:25 ```It actually wasn't that bad. We only had a few base rotations to make the character look right: we rotated 2 bones in the spine to get some lateral and vertical body rotation, the right shoulder where the weapon was attached (rotate the entire arm and weapon all at once), and then a solver for the head (actually a separate IK solution so that characters could look around while having their weapons aimed). The last part (and the expensive bit) was reattaching the other hand to the weapon -- this was done with a CCD, but since it only had to manage two bones (the upper arm and lower arm) it wasn't that expensive. I didn't bother making the hand re-grip the weapon properly since the camera wasn't ever close enough to really see that. For the skeleton that we had, I don't think this was much more expensive than taking a set of 4 animations and blending them together -- and it was a whole lot easier once the system was up and running (again, only 1 animator). -----Original Message----- From: gdalgorithms-list-admin@... [mailto:gdalgorithms-list-admin@...] On Behalf Of Tom Forsyth Sent: Saturday, December 04, 2004 9:45 PM To: gdalgorithms-list@... Subject: RE: [Algorithms] calculating weights for blending arbitrary number of animations > animator build _proper_ animations was just too much, so I wrote an IK > solver to do the work. That's pretty heavyweight! I suspect an easier solution is to do the blending as best you can, and then correct for the (hopefully small errors) by rotating the joints of the spine to get the aim right, but keeping the whole upper body completely rigid. Sounds a lot easier than trying to IK a shoulder, both arms and the head & eye (which is the case for something complex like a chap looking through a rifle's telescopic sight). There is the separate issue that blending the animations of the separate hierarchies of each arm and the head produce different results _with respect to each other_ - yeah, you need some IK solvers to stick the hands to the weapon. If that's all you meant by IK, then it's worth investing in those - they're fairly simple 2-bone solvers, and not that gnarly to get right (and you can use them all over the place - picking up things, climbing ladders, opening doors, etc). TomF. > -----Original Message----- > From: gdalgorithms-list-admin@...=20 > [mailto:gdalgorithms-list-admin@...] On=20 > Behalf Of Ryan Greene > Sent: 30 November 2004 11:34 > To: gdalgorithms-list@... > Subject: RE: [Algorithms] calculating weights for blending=20 > arbitrary number of animations >=20 >=20 > I tried doing this exact system for a project I worked on in the past, > but found the results to be pretty poor -- it was rare that a=20 > character > was aiming his weapon juuuust right. Furthermore, the cost of=20 > having an > animator build _proper_ animations was just too much, so I wrote an IK > solver to do the work. It took a little time to get it right, but the > results are a whole lot better and easier to generate. I had my > animators build a few base aiming poses from different positions -- > standing, crouching, and prone, then wrote special IK for=20 > each (although > standing and crouching were nearly identical). I'm willing to=20 > bet the IK > approach is slightly more expensive than blending together a few > animations, but it is just so much easier (once you get over the fact > that you're doing near full-body IK), especially from an asset > production standpoint. Another benefit we got from it was that it was > easy to tie into weapon firing to simply adjust the IK to simulate > weapon recoil w/o having to have another layer of animations to deal > with. >=20 > I'm sure other people have had good results from the=20 > animation blending > technique, but from a project that had way too few animators doing way > too many animations -- IK is the way to go. >=20 >=20 > -----Original Message----- > From: gdalgorithms-list-admin@... > [mailto:gdalgorithms-list-admin@...] On Behalf Of > Yordan Gyurchev > Sent: Tuesday, November 30, 2004 11:23 AM > To: gdalgorithms-list@... > Subject: [Algorithms] calculating weights for blending=20 > arbitrary number > of animations >=20 > Hello, >=20 > Imagine a soldier (or character with a weapon of some kind). We are > tying > to get its weapon (two weapons, two handed weapon) to point into the > direction of aiming. >=20 > We have 9 animations. Each represents a pose into a certain direction. > Each > "pose" animation has a vector associated with it. > For a given character aiming direction vector we compute=20 > weight for each > animation to contribute into the final anim. >=20 > Question is: Given N (in this paricular case 9) vectors and the aiming > one > how to compute good weights that max to 1.0 when the aming coincides > with > them? (Did I mention that weights need to add up to 1.0? but of course > you > know that...) >=20 > We have tried few methods and we have a couple of working but far from > ideal > bodged solutions. I'm sure someone has solved this problem elegantly > with > some clever maths. A lot of games seem to do that kind of=20 > thing although > in > some cases IK can be applied. >=20 > One solution that gives smooth results is just a dot product. > Wi =3D Vi dot Va where Wi are normalized afterwards with Wi =3D=20 > Wi/sum(Wi) > (Wi > weight for each bone, Vi - Direction vectors for anims, Va -=20 > aim vector) > Unfortunately, this only works perfectly if all direction vectors (Vi) > are > perpendicular to each other so when they max out no other anim > contributes > to the final. It still works in other cases but the results are not > accurate > enough for us. >=20 > We have also explored few solutions where assumptions have been made > that > some vectors lie in a certain plane but I'm looking for a generic > solution > that will work in all cases. >=20 > Thanks, > Yordan >=20 >=20 >=20 >=20 > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from=20 > real users. > Discover which products truly live up to the hype. Start reading now.=20 > http://productguide.itmanagersjournal.com/ > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from=20 > real users. > Discover which products truly live up to the hype. Start reading now.=20 > http://productguide.itmanagersjournal.com/ > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.=20 http://productguide.itmanagersjournal.com/ _______________________________________________ GDAlgorithms-list mailing list GDAlgorithms-list@... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 ```
 RE: [Algorithms] calculating weights for blending arbitrary number of animations From: Tom Forsyth - 2004-12-05 05:44:54 ```> animator build _proper_ animations was just too much, so I wrote an IK > solver to do the work. That's pretty heavyweight! I suspect an easier solution is to do the blending as best you can, and then correct for the (hopefully small = errors) by rotating the joints of the spine to get the aim right, but keeping = the whole upper body completely rigid. Sounds a lot easier than trying to IK = a shoulder, both arms and the head & eye (which is the case for something complex like a chap looking through a rifle's telescopic sight). There is the separate issue that blending the animations of the separate hierarchies of each arm and the head produce different results _with = respect to each other_ - yeah, you need some IK solvers to stick the hands to = the weapon. If that's all you meant by IK, then it's worth investing in = those - they're fairly simple 2-bone solvers, and not that gnarly to get right = (and you can use them all over the place - picking up things, climbing = ladders, opening doors, etc). TomF. > -----Original Message----- > From: gdalgorithms-list-admin@...=20 > [mailto:gdalgorithms-list-admin@...] On=20 > Behalf Of Ryan Greene > Sent: 30 November 2004 11:34 > To: gdalgorithms-list@... > Subject: RE: [Algorithms] calculating weights for blending=20 > arbitrary number of animations >=20 >=20 > I tried doing this exact system for a project I worked on in the past, > but found the results to be pretty poor -- it was rare that a=20 > character > was aiming his weapon juuuust right. Furthermore, the cost of=20 > having an > animator build _proper_ animations was just too much, so I wrote an IK > solver to do the work. It took a little time to get it right, but the > results are a whole lot better and easier to generate. I had my > animators build a few base aiming poses from different positions -- > standing, crouching, and prone, then wrote special IK for=20 > each (although > standing and crouching were nearly identical). I'm willing to=20 > bet the IK > approach is slightly more expensive than blending together a few > animations, but it is just so much easier (once you get over the fact > that you're doing near full-body IK), especially from an asset > production standpoint. Another benefit we got from it was that it was > easy to tie into weapon firing to simply adjust the IK to simulate > weapon recoil w/o having to have another layer of animations to deal > with. >=20 > I'm sure other people have had good results from the=20 > animation blending > technique, but from a project that had way too few animators doing way > too many animations -- IK is the way to go. >=20 >=20 > -----Original Message----- > From: gdalgorithms-list-admin@... > [mailto:gdalgorithms-list-admin@...] On Behalf Of > Yordan Gyurchev > Sent: Tuesday, November 30, 2004 11:23 AM > To: gdalgorithms-list@... > Subject: [Algorithms] calculating weights for blending=20 > arbitrary number > of animations >=20 > Hello, >=20 > Imagine a soldier (or character with a weapon of some kind). We are > tying > to get its weapon (two weapons, two handed weapon) to point into the > direction of aiming. >=20 > We have 9 animations. Each represents a pose into a certain direction. > Each > "pose" animation has a vector associated with it. > For a given character aiming direction vector we compute=20 > weight for each > animation to contribute into the final anim. >=20 > Question is: Given N (in this paricular case 9) vectors and the aiming > one > how to compute good weights that max to 1.0 when the aming coincides > with > them? (Did I mention that weights need to add up to 1.0? but of course > you > know that...) >=20 > We have tried few methods and we have a couple of working but far from > ideal > bodged solutions. I'm sure someone has solved this problem elegantly > with > some clever maths. A lot of games seem to do that kind of=20 > thing although > in > some cases IK can be applied. >=20 > One solution that gives smooth results is just a dot product. > Wi =3D Vi dot Va where Wi are normalized afterwards with Wi =3D=20 > Wi/sum(Wi) > (Wi > weight for each bone, Vi - Direction vectors for anims, Va -=20 > aim vector) > Unfortunately, this only works perfectly if all direction vectors (Vi) > are > perpendicular to each other so when they max out no other anim > contributes > to the final. It still works in other cases but the results are not > accurate > enough for us. >=20 > We have also explored few solutions where assumptions have been made > that > some vectors lie in a certain plane but I'm looking for a generic > solution > that will work in all cases. >=20 > Thanks, > Yordan >=20 >=20 >=20 >=20 > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from=20 > real users. > Discover which products truly live up to the hype. Start reading now.=20 > http://productguide.itmanagersjournal.com/ > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from=20 > real users. > Discover which products truly live up to the hype. Start reading now.=20 > http://productguide.itmanagersjournal.com/ > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 ```