Thread: RE: [Algorithms] Animation and change of root
Brought to you by:
vexxed72
From: Gribb, G. <gg...@ra...> - 2004-11-09 18:49:28
|
Well if you have a heirarchy, something has to be at the root. And the = concept of a heirarchy is not at all artifical. If I bend my elbow, my = fingers move. But if I move my fingers, my elbow doesn't move. Quite a = natural relation. -Gil -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of Jonathan Blow Sent: Tuesday, November 09, 2004 12:39 PM To: gda...@li... Subject: Re: [Algorithms] Animation and change of root "The root" of a skeleton is a pretty artificial concept that has mostly=20 outlived its usefulness. Most people still do things that way, but it's = not a great idea. Dynamic re-rooting of a skeleton is pretty easy; the annoying part is=20 when you have all this animation data that's stored bone-relative and=20 you're like, hey, what do I do with all this stuff? The most=20 straightforward thing is to evaluate that animation on a spare skeleton=20 that has a fixed root, to get the object space transforms, then=20 re-compute bone space transforms for the new hierarchy based on that.=20 (If you like bone space, which a lot of people on this list seem to.) =20 Anyway, that's not "fast" if you are thinking=20 I-am-peephole-optimizing-my-algorithm fast, but it's O(n) with the=20 number of bones, so hey, whatever. But if you have time to actively experiment on this stuff, I would=20 explore doing things without a root. Chris Haarmeijer wrote: >Hi, > >For an animation system, I have to change the root of the system = frequently >from the left foot to the right foot. Are there any publications = available >on the subject of fast changing of the root of an animation hierarchy ? > >Kind regards, > >Chris Haarmeijer >--- >Keep IT Simple Software >Van Alphenstraat 12 >7514 DD Enschede > >W: http://www.keepitsimple.nl >E: mailto:in...@ke... >T: +31 53 4356687 > > > >------------------------------------------------------- >This SF.Net email is sponsored by: >Sybase ASE Linux Express Edition - download now for FREE >LinuxWorld Reader's Choice Award Winner for best database on Linux. >http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > =20 > ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 |
From: Sam M. <sam...@ho...> - 2004-11-11 14:27:19
|
Forgive me if this is really obvious, but it is just the concept of hierarchy and not necessarily a root that you're against? If you effectively have all your limbs hung off a root position with constraints between them you still have a root or sorts? I presume you aren't removing the concept of object-space? Sam >Message: 8 >Date: Tue, 09 Nov 2004 14:00:50 -0600 >From: Jonathan Blow <jo...@nu...> >To: gda...@li... >Subject: Re: [Algorithms] Animation and change of root >Reply-To: gda...@li... > > > >If you would do this without a root, how would you go about this ? > > > > =20 > > > >Generally speaking, you have systems where you treat the limbs as bodies=20 >stored in a non-hierarchical way, with constraints between the bodies. =20 >The constraints give you a system of (e.g. linear) equations which you=20 >can then solve. To fix one of the feet, you then just add a constraint=20 >between the foot and whatever it's pushing off of (which may just be a=20 >point and orientation fixed in worldspace). > > > > > > =20 > > > >>Right, by disparaging the root I am saying that the hierarchy is not a > >>good idea. > >> > >>I have found that once we start doing things that are more interesting > >>than playing back animations, the hierarchy becomes vestigial and a big > >>hinderance. Sure, if you bend your elbow, your fingers move. But if > >>your hand hits a wall, it stops your elbow. Influence travels both > >>ways, that's what being in a physical reality is all about. > >> > >> > >>Gribb, Gil wrote: > >> > >> =20 > >> > >>>Well if you have a heirarchy, something has to be at the root. And the > >>> =20 > >>> > >concept of a heirarchy is not at all artifical. If I bend my elbow, my > >fingers move. But if I move my fingers, my elbow doesn't move. Quite a > >natural relation. > > =20 > > > >>>-Gil > >>> > >>>-----Original Message----- > >>>From: gda...@li... > >>>[mailto:gda...@li...]On Behalf Of > >>>Jonathan Blow > >>>Sent: Tuesday, November 09, 2004 12:39 PM > >>>To: gda...@li... > >>>Subject: Re: [Algorithms] Animation and change of root > >>> > >>> > >>>"The root" of a skeleton is a pretty artificial concept that has mostl= >y > >>>outlived its usefulness. Most people still do things that way, but it= >'s > >>>not a great idea. > >>> > >>>Dynamic re-rooting of a skeleton is pretty easy; the annoying part is > >>>when you have all this animation data that's stored bone-relative and > >>>you're like, hey, what do I do with all this stuff? The most > >>>straightforward thing is to evaluate that animation on a spare skeleto= >n > >>>that has a fixed root, to get the object space transforms, then > >>>re-compute bone space transforms for the new hierarchy based on that. > >>>(If you like bone space, which a lot of people on this list seem to.) > >>>Anyway, that's not "fast" if you are thinking > >>>I-am-peephole-optimizing-my-algorithm fast, but it's O(n) with the > >>>number of bones, so hey, whatever. > >>> > >>>But if you have time to actively experiment on this stuff, I would > >>>explore doing things without a root. > >>> > >>> > >>> > >>>Chris Haarmeijer wrote: > >>> > >>> > >>> > >>> =20 > >>> > >>>>Hi, > >>>> > >>>>For an animation system, I have to change the root of the system > >>>> =20 > >>>> > >frequently > > =20 > > > >>>> =20 > >>>> > >>>>from the left foot to the right foot. Are there any publications > >>> =20 > >>> > >available > > =20 > > > >>> =20 > >>> > >>>>on the subject of fast changing of the root of an animation hierarchy= > ? > >>>> > >>>>Kind regards, > >>>> > >>>>Chris Haarmeijer > >>>>--- |
From: Brian O. <os...@vv...> - 2004-11-11 14:39:08
|
I think what he's saying is that concepts like "hierarchy" and "root" should emerge implicitly from the construction of the skeleton, not be forced in by design. Object space still makes perfect sense - that's the best way to ensure the correlation he's mentioned, which is in turn what enables compression. But all links in a real skeleton are inherently bi-directional. So we should think of the skeleton as a pile of bones (all in object space), with a set of constraints. That set of constraints may make certain bones have more influence over the position of the whole, but if you don't jump on that bandwagon and force that structure to dictate your implementation, then things like "re-rooting" the skeleton happen auto-magically by imposing a new "fixed position" constraint on some arbitrary bone (like the hand or foot that an Ogre grabs as he picks me up off the floor). Suddenly, the constraint solver has to propagate changes from hand to chest, not the other way around. And while you can special case all of this in a traditional system, having a general framework where arbitrary (unforseen) manipulations of the skeleton "just work" is a pretty cool idea. -Brian ----- Original Message ----- From: "Sam Martin" <sam...@ho...> To: <gda...@li...> Sent: Thursday, November 11, 2004 9:26 AM Subject: [Algorithms] Re: Animation and change of root > Forgive me if this is really obvious, but it is just the concept of > hierarchy and not necessarily a root that you're against? If you > effectively have all your limbs hung off a root position with constraints > between them you still have a root or sorts? I presume you aren't removing > the concept of object-space? > > Sam > >>Message: 8 >>Date: Tue, 09 Nov 2004 14:00:50 -0600 >>From: Jonathan Blow <jo...@nu...> >>To: gda...@li... >>Subject: Re: [Algorithms] Animation and change of root >>Reply-To: gda...@li... >> >> >> >If you would do this without a root, how would you go about this ? >> > >> > =20 >> > >> >>Generally speaking, you have systems where you treat the limbs as >>bodies=20 >>stored in a non-hierarchical way, with constraints between the bodies. =20 >>The constraints give you a system of (e.g. linear) equations which you=20 >>can then solve. To fix one of the feet, you then just add a constraint=20 >>between the foot and whatever it's pushing off of (which may just be a=20 >>point and orientation fixed in worldspace). >> >> >> > >> > =20 >> > >> >>Right, by disparaging the root I am saying that the hierarchy is not a >> >>good idea. >> >> >> >>I have found that once we start doing things that are more interesting >> >>than playing back animations, the hierarchy becomes vestigial and a big >> >>hinderance. Sure, if you bend your elbow, your fingers move. But if >> >>your hand hits a wall, it stops your elbow. Influence travels both >> >>ways, that's what being in a physical reality is all about. >> >> >> >> >> >>Gribb, Gil wrote: >> >> >> >> =20 >> >> >> >>>Well if you have a heirarchy, something has to be at the root. And the >> >>> =20 >> >>> >> >concept of a heirarchy is not at all artifical. If I bend my elbow, my >> >fingers move. But if I move my fingers, my elbow doesn't move. Quite a >> >natural relation. >> > =20 >> > >> >>>-Gil >> >>> >> >>>-----Original Message----- >> >>>From: gda...@li... >> >>>[mailto:gda...@li...]On Behalf Of >> >>>Jonathan Blow >> >>>Sent: Tuesday, November 09, 2004 12:39 PM >> >>>To: gda...@li... >> >>>Subject: Re: [Algorithms] Animation and change of root >> >>> >> >>> >> >>>"The root" of a skeleton is a pretty artificial concept that has >> >>>mostl= >>y >> >>>outlived its usefulness. Most people still do things that way, but >> >>>it= >>'s >> >>>not a great idea. >> >>> >> >>>Dynamic re-rooting of a skeleton is pretty easy; the annoying part is >> >>>when you have all this animation data that's stored bone-relative and >> >>>you're like, hey, what do I do with all this stuff? The most >> >>>straightforward thing is to evaluate that animation on a spare >> >>>skeleto= >>n >> >>>that has a fixed root, to get the object space transforms, then >> >>>re-compute bone space transforms for the new hierarchy based on that. >> >>>(If you like bone space, which a lot of people on this list seem to.) >> >>>Anyway, that's not "fast" if you are thinking >> >>>I-am-peephole-optimizing-my-algorithm fast, but it's O(n) with the >> >>>number of bones, so hey, whatever. >> >>> >> >>>But if you have time to actively experiment on this stuff, I would >> >>>explore doing things without a root. >> >>> >> >>> >> >>> >> >>>Chris Haarmeijer wrote: >> >>> >> >>> >> >>> >> >>> =20 >> >>> >> >>>>Hi, >> >>>> >> >>>>For an animation system, I have to change the root of the system >> >>>> =20 >> >>>> >> >frequently >> > =20 >> > >> >>>> =20 >> >>>> >> >>>>from the left foot to the right foot. Are there any publications >> >>> =20 >> >>> >> >available >> > =20 >> > >> >>> =20 >> >>> >> >>>>on the subject of fast changing of the root of an animation >> >>>>hierarchy= >> ? >> >>>> >> >>>>Kind regards, >> >>>> >> >>>>Chris Haarmeijer >> >>>>--- > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > Confidentiality Notice: This message, including any attachments, may contain confidential information. If you have received this message by mistake, please notify the sender immediately, delete all copies, and do not distribute or use this information. Thanks! |
From: <Pau...@sc...> - 2004-11-11 14:54:36
|
> And while you can special case all of this in a traditional system, having a > general framework where arbitrary (unforseen) manipulations of the skeleton > "just work" is a pretty cool idea. Much neater and more powerful concept, yes - however, much slower at runtime. Obviously a traditional skeleton's constraints are implicit in the hierarchy whereas having to run a constraint solver just to keep the limbs attached together is slightly more costly ;-) Actually, it can be done in linear time, but I'm sure its still gonna cost more than the traditional method. I'd love to be proven wrong, however! Cheers, Paul. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify pos...@sc... This footnote also confirms that this email message has been checked for all known viruses. ********************************************************************** Sony Computer Entertainment Europe |
From: Jon W. <hp...@mi...> - 2004-11-11 19:49:38
|
> > And while you can special case all of this in a traditional system, > > having a > > general framework where arbitrary (unforseen) manipulations of the > > skeleton > > "just work" is a pretty cool idea. > Actually, it can be done in linear time, but I'm sure its still gonna cost > more than the traditional method. I'd love to be proven wrong, however! I'm thinking connected point masses for the bones, a la cloth simulation. The differences are that bones stretch less, and the connectivity is not a regular grid (and, in fact, most bones just connect to two other bones). This gives you basic, un-limited rag dolling. Then joint limits and forces trying to get you into a desired pose need to be added, but that can be done cheaply per-joint, rather than in a global solver. Then you need to detect when the two ogres are pulling you in different directions, and decide wether to split you or apply counter-force ;-) Anyone done this yet? It feels like it ought to have been done already. Cheers, / h+ |
From: metanet s. <met...@ya...> - 2004-11-11 20:26:44
|
hi, i'm doing something like this, but in a much simpler case -- 2D -- which i'm not sure can be easily extended to 3D. in my case i'm modelling an entire limb as two point-masses: for instance an arm is made up of a shoulder and a hand. the position of the elbow can be inferred from the position of the shoulder/hand (given info on the length of the upper/lower arm); in 3D it seems like this might not be as easy to do (since the above doesn't provide any info about the rotation of the elbow around the shoulder->hand axis). but it makes the animation and simulation a LOT cheaper/simpler. one thing i'm still trying to figure out is how exactly to implement "root-less-ness". this might just be due to denseness on my part -- i'm not sure how you'd go about describing animations without some concept of a "root"/basis of the space in which the animation is described. but the method of describing the basis seems to create problems. if you tie the basis of the animation space to a particular bone/point-mass, you get problems (i.e if the root is the pelvis or foot and a force moves the pelvis or foot, the entire body moves with it). but if the basis _isn't_ rigidly locked to a particular joint/bone.. how exactly do you infer its current position/orientation?! right now my solution has been to simulate the movement of the basis seperately from the movement of the body/pose, and tie the two together with forces -- i.e keyboard input pushes the basis around, which drags the body/pose along with it. collision forces are applied to the body/pose, and then propagated to the basis.. this seems really poorly thought-out and frankly isn't working that well ;( but how else would you describe an animation system which was "rootless'? raigan Jon Watte <hp...@mi...> wrote: I'm thinking connected point masses for the bones, a la cloth simulation. The differences are that bones stretch less, and the connectivity is not a regular grid (and, in fact, most bones just connect to two other bones). This gives you basic, un-limited rag dolling. Then joint limits and forces trying to get you into a desired pose need to be added, but that can be done cheaply per-joint, rather than in a global solver. Then you need to detect when the two ogres are pulling you in different directions, and decide wether to split you or apply counter-force ;-) Anyone done this yet? It feels like it ought to have been done already. --------------------------------- Post your free ad now! Yahoo! Canada Personals |
From: Jon W. <hp...@mi...> - 2004-11-11 23:43:18
|
> but if the basis _isn't_ rigidly locked to a particular joint/bone.. > how exactly do you infer its current position/orientation?! There needs to be a "point of reference", such as the center of the capsule that's the collision proxy of your character, or the center of gravity of the main torso body, or the spot where your lollipop spring hits the ground, or whatever (depending on how you do your character). This point of reference defines "object space". All the bones can then be in "object space" off of this point of reference. That point does not need to be a bone at all. We just call this ephemereal point the Master Root, I'm sure others have other names for it. Now, if you model at the origin in your art tool, then "object space" is the same as "world space" for the modeler. However, we've found that it's useful to allow different objects to go at different physical locations, and then merge them on export -- LODs, morphs, and all that, so thinking about object space all the way through the pipeline works best for us. You might want to animate movement animations in actual world space (offset from origin as you walk), and then derive physics impulses based on this master root offset, and assume the offset is zero when you go to actually apply the animation. This way, your animation will avoid foot sliding (track movement perfectly) as long as you walk unimpeded, on flat terrain. Improvements can be had over that with more work :-) Cheers, / h+ |
From: metanet s. <met...@ya...> - 2004-11-12 15:57:10
|
hi, if i understand you, then this is what i've been doing -- using either a point on the proxy or a point on the skeleton (possibly not a point on a bone, it could be a point like the center-of-mass that's generated by blending the skeleton together to get a single point). my problem is that i haven't found a good way to allow forces to propagate in _both_ directions (from collision proxy/"character DOF" to pose/skeleton, and from skeleton to proxy). depending on how you define the basis, one of the directions of force propagation works a lot better than the other. for instance: locking basis to the collision proxy. it's easy to just move the proxy (based on user input or whatever) and have the pose move along with it. but, in a previous post someone mentioned the "orc picks you up by the arm" case. here you need some way to let skeletal movement/forces/etc. influence the proxy -- if the orc grabs your arm and swings you around, it's exerting forces on your skeleton that need to influence the movement/position of the proxy. so: you lock the basis to the skeleton. using the skeleton's current center of mass as the origin of the basis seems like a good idea (since the COM _should_ arbitrate between the skeleton and the proxy; both skeleton and proxy can influence the position of the COM, and the COM in turn influences the position of both the skeleton and proxy). but figuring out exactly how this "influence" should work has thus far been frustrating. in some ways it seems like it's not a solution at all -- it's just transformed the problem. if you do the easy thing and lock the basis to the proxy, then it's very easy to let the proxy influence the skeleton -- you move the proxy and the skeleton automatically moves with it. but how do you allow the skeleton to move the proxy around? you could lock part of the skeleton rigidly to the proxy (i.e forcing the pelvis to correspond to the origin of the capsule you're using as a proxy). then you have two-way influence, but unfair weighting as i mentioned in my previous post -- if something hits the pelvis it ends up moving the character/basis a LOT. ideally the pelvis would move around in objectspace -- instead of objectspace moving WITH the pelvis. if you use the COM as a basis, then it becomes really easy to let the skeleton move the basis around in a nice not-too-severe way; the pelvis can move without it dragging the basis around too much. so now it's easy to let the skeleton influence the basis. but now letting the proxy inflence the basis is a nightmare -- you want to try to exert forces on each part of the skeleton such that the COM moves towards a predetermined point on the proxy.. so far i've had no luck finding a simple solution to this. your other suggestions seem a bit more one-sided -- if you tie the basis to the collision proxy, you need to allow the skeleton to somehow influence the position/movement of the proxy. and at that point it sort of seems pretty much identical to using the COM (at least, the only way i've been able to link the skeleton and proxy is by munging all of the skelton's points together in some way to generate a single point, analogous to a center of mass). if anyone has any experience with something that works well.. ;) thus far the only thing that's worked "well" was to use the lock-proxy-to-pelvis, but use a spring/weak constraint that wasn't rigidly satisfied each frame. this was still far from great though. sorry if this doesn't make much sense; it's quite frustrating as it seems like there should be an obvious, simple, well-known solution, but i haven't been able to find one.. raigan Jon Watte <hp...@mi...> wrote: There needs to be a "point of reference", such as the center of the capsule that's the collision proxy of your character, or the center of gravity of the main torso body, or the spot where your lollipop spring hits the ground, or whatever (depending on how you do your character). This point of reference defines "object space". All the bones can then be in "object space" off of this point of reference. That point does not need to be a bone at all. We just call this ephemereal point the Master Root, I'm sure others have other names for it. --------------------------------- Post your free ad now! Yahoo! Canada Personals |
From: Bob D. <Bob...@bl...> - 2004-11-12 10:05:38
|
> But the hierarchy doesn't consider the two=20 arms to be related so it doesn't exploit this. But if you analyze the=20 joint angles of the two arms over the course of the animation you can=20 say "aha these guys are correlated, and typically there is this average=20 transform Q that takes me from arm1's rotation to arm2's rotation during = any given frame.=20 That's very interesting Jonathan, - this correlation scheme is adapting = over time (?) ie. if the arm1,2 motion cease to be correlated (arm1 = get's lopped off say) the correlation goes below some significance and = the "pairing" is dropped... is that the sort of thing?=20 > -----Original Message----- > From: Jonathan Blow [mailto:jo...@nu...] > Sent: 10 November 2004 03:51 > To: gda...@li... > Subject: Re: [Algorithms] Animation and change of root >=20 >=20 >=20 > > > >I'd like to hear more about this compression stuff though.=20 > when you have > >time... > > =20 > > >=20 > Well, "delta compression" is the very general compression=20 > idea that if=20 > you have some set of values, oftentimes the differences between them=20 > will be smaller and more orderly than the values themselves,=20 > so they are=20 > easier to represent. A simple example of delta compression=20 > for audio is=20 > the ADPCM format. >=20 > In animation, the hierarchy gives you delta compression because what=20 > you're saying is, "Factor off my parent's transform, and just=20 > store my=20 > local transform", in other words, just store the difference=20 > between my=20 > parent's rotation and my rotation. Often this difference will be=20 > constant (like if you have a finger on a hand and the finger doesn't=20 > move relative to the hand). >=20 > However, there are many things that the hierarchy *doesn't*=20 > give you. =20 > For example, say you have an animation of a guy swaying his arms back=20 > and forth in a parallel motion. Well, both of the arms have highly=20 > correlated rotations. Any time there is correlation, there is the=20 > capacity for compression. But the hierarchy doesn't consider the two=20 > arms to be related so it doesn't exploit this. But if you=20 > analyze the=20 > joint angles of the two arms over the course of the animation you can=20 > say "aha these guys are correlated, and typically there is=20 > this average=20 > transform Q that takes me from arm1's rotation to arm2's=20 > rotation during=20 > any given frame. It is not always exactly Q, but it's close.=20 > So what I=20 > will do is store arm1 in the animation, and store the constant Q, and=20 > then for every frame I will store the deltas from Q that get=20 > me all the=20 > way to arm2, which is smaller and easier than the original=20 > transforms." >=20 > A lot of human motion is highly correlated (think about walking,=20 > running, etc etc). So there is a lot of capacity for=20 > compression that=20 > the hierarchical bone-local storage scheme is oblivious to. >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 |
From: Tom F. <tom...@ee...> - 2004-11-12 10:14:54
|
You would probably do this correlation-finding as a preprocess on each animation individually, since it's going to be pretty slow - basically = an O(n^2) algorithm (or worse). This is essentially data-compression, = rather than the correlation meaning anything "real" (though of course it might, e.g. the person is carrying a large object and using both hands). So at runtime you would decompress each playing animation using their respective (and probably different) correlations, then blend them = together. TomF. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Bob Dowland > Sent: 12 November 2004 02:06 > To: gda...@li... > Subject: RE: [Algorithms] Animation and change of root >=20 >=20 > > But the hierarchy doesn't consider the two=20 > arms to be related so it doesn't exploit this. But if you=20 > analyze the=20 > joint angles of the two arms over the course of the animation you can=20 > say "aha these guys are correlated, and typically there is=20 > this average=20 > transform Q that takes me from arm1's rotation to arm2's=20 > rotation during=20 > any given frame.=20 >=20 > That's very interesting Jonathan, - this correlation scheme=20 > is adapting over time (?) ie. if the arm1,2 motion cease to=20 > be correlated (arm1 get's lopped off say) the correlation=20 > goes below some significance and the "pairing" is dropped...=20 > is that the sort of thing?=20 >=20 > > -----Original Message----- > > From: Jonathan Blow [mailto:jo...@nu...] > > Sent: 10 November 2004 03:51 > > To: gda...@li... > > Subject: Re: [Algorithms] Animation and change of root > >=20 > >=20 > >=20 > > > > > >I'd like to hear more about this compression stuff though.=20 > > when you have > > >time... > > > =20 > > > > >=20 > > Well, "delta compression" is the very general compression=20 > > idea that if=20 > > you have some set of values, oftentimes the differences=20 > between them=20 > > will be smaller and more orderly than the values themselves,=20 > > so they are=20 > > easier to represent. A simple example of delta compression=20 > > for audio is=20 > > the ADPCM format. > >=20 > > In animation, the hierarchy gives you delta compression=20 > because what=20 > > you're saying is, "Factor off my parent's transform, and just=20 > > store my=20 > > local transform", in other words, just store the difference=20 > > between my=20 > > parent's rotation and my rotation. Often this difference will be=20 > > constant (like if you have a finger on a hand and the=20 > finger doesn't=20 > > move relative to the hand). > >=20 > > However, there are many things that the hierarchy *doesn't*=20 > > give you. =20 > > For example, say you have an animation of a guy swaying his=20 > arms back=20 > > and forth in a parallel motion. Well, both of the arms have highly=20 > > correlated rotations. Any time there is correlation, there is the=20 > > capacity for compression. But the hierarchy doesn't=20 > consider the two=20 > > arms to be related so it doesn't exploit this. But if you=20 > > analyze the=20 > > joint angles of the two arms over the course of the=20 > animation you can=20 > > say "aha these guys are correlated, and typically there is=20 > > this average=20 > > transform Q that takes me from arm1's rotation to arm2's=20 > > rotation during=20 > > any given frame. It is not always exactly Q, but it's close.=20 > > So what I=20 > > will do is store arm1 in the animation, and store the=20 > constant Q, and=20 > > then for every frame I will store the deltas from Q that get=20 > > me all the=20 > > way to arm2, which is smaller and easier than the original=20 > > transforms." > >=20 > > A lot of human motion is highly correlated (think about walking,=20 > > running, etc etc). So there is a lot of capacity for=20 > > compression that=20 > > the hierarchical bone-local storage scheme is oblivious to. > >=20 > >=20 > >=20 > > ------------------------------------------------------- > > This SF.Net email is sponsored by: > > Sybase ASE Linux Express Edition - download now for FREE > > LinuxWorld Reader's Choice Award Winner for best database on Linux. > > http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 |
From: Bob D. <Bob...@bl...> - 2004-11-12 11:13:28
|
> You would probably do this correlation-finding as a preprocess Thanks Tom - yes.. I was thinking "animation-time" rather than frametime = but good to make that explicit. Would be interesting to hear more about = the correlation scheme.. For general interest (in changes of root ideas) "Nonconvex Rigid Bodies = with stacking." discusses a method which involves building a graph = (non-hierarchical) to represent contact between a set of bodies together = with a scheme for establishing a hierarchical structure in a second = pass. The hierarcy essentially reflects "relative-rootedness" eg. foot = becomes child of terrain etc... and the use of a hierarchy allows = collision resolution to be modelled basically as an energy pulse = propagated through the hierarchy. It seems to be one way to squeeze = juice out of both representation schemes. Not sure about real-time = performance but I believe someone implemented a decent rag-doll demo on = the basis of these ideas. :) > -----Original Message----- > From: Tom Forsyth [mailto:tom...@ee...] > Sent: 12 November 2004 10:15 > To: gda...@li... > Subject: RE: [Algorithms] Animation and change of root >=20 >=20 > You would probably do this correlation-finding as a preprocess on each > animation individually, since it's going to be pretty slow -=20 > basically an > O(n^2) algorithm (or worse). This is essentially=20 > data-compression, rather > than the correlation meaning anything "real" (though of=20 > course it might, > e.g. the person is carrying a large object and using both hands). >=20 > So at runtime you would decompress each playing animation using their > respective (and probably different) correlations, then blend=20 > them together. >=20 > TomF. >=20 >=20 > > -----Original Message----- > > From: gda...@li...=20 > > [mailto:gda...@li...] On=20 > > Behalf Of Bob Dowland > > Sent: 12 November 2004 02:06 > > To: gda...@li... > > Subject: RE: [Algorithms] Animation and change of root > >=20 > >=20 > > > But the hierarchy doesn't consider the two=20 > > arms to be related so it doesn't exploit this. But if you=20 > > analyze the=20 > > joint angles of the two arms over the course of the=20 > animation you can=20 > > say "aha these guys are correlated, and typically there is=20 > > this average=20 > > transform Q that takes me from arm1's rotation to arm2's=20 > > rotation during=20 > > any given frame.=20 > >=20 > > That's very interesting Jonathan, - this correlation scheme=20 > > is adapting over time (?) ie. if the arm1,2 motion cease to=20 > > be correlated (arm1 get's lopped off say) the correlation=20 > > goes below some significance and the "pairing" is dropped...=20 > > is that the sort of thing?=20 > >=20 > > > -----Original Message----- > > > From: Jonathan Blow [mailto:jo...@nu...] > > > Sent: 10 November 2004 03:51 > > > To: gda...@li... > > > Subject: Re: [Algorithms] Animation and change of root > > >=20 > > >=20 > > >=20 > > > > > > > >I'd like to hear more about this compression stuff though.=20 > > > when you have > > > >time... > > > > =20 > > > > > > >=20 > > > Well, "delta compression" is the very general compression=20 > > > idea that if=20 > > > you have some set of values, oftentimes the differences=20 > > between them=20 > > > will be smaller and more orderly than the values themselves,=20 > > > so they are=20 > > > easier to represent. A simple example of delta compression=20 > > > for audio is=20 > > > the ADPCM format. > > >=20 > > > In animation, the hierarchy gives you delta compression=20 > > because what=20 > > > you're saying is, "Factor off my parent's transform, and just=20 > > > store my=20 > > > local transform", in other words, just store the difference=20 > > > between my=20 > > > parent's rotation and my rotation. Often this difference will be=20 > > > constant (like if you have a finger on a hand and the=20 > > finger doesn't=20 > > > move relative to the hand). > > >=20 > > > However, there are many things that the hierarchy *doesn't*=20 > > > give you. =20 > > > For example, say you have an animation of a guy swaying his=20 > > arms back=20 > > > and forth in a parallel motion. Well, both of the arms=20 > have highly=20 > > > correlated rotations. Any time there is correlation,=20 > there is the=20 > > > capacity for compression. But the hierarchy doesn't=20 > > consider the two=20 > > > arms to be related so it doesn't exploit this. But if you=20 > > > analyze the=20 > > > joint angles of the two arms over the course of the=20 > > animation you can=20 > > > say "aha these guys are correlated, and typically there is=20 > > > this average=20 > > > transform Q that takes me from arm1's rotation to arm2's=20 > > > rotation during=20 > > > any given frame. It is not always exactly Q, but it's close.=20 > > > So what I=20 > > > will do is store arm1 in the animation, and store the=20 > > constant Q, and=20 > > > then for every frame I will store the deltas from Q that get=20 > > > me all the=20 > > > way to arm2, which is smaller and easier than the original=20 > > > transforms." > > >=20 > > > A lot of human motion is highly correlated (think about walking,=20 > > > running, etc etc). So there is a lot of capacity for=20 > > > compression that=20 > > > the hierarchical bone-local storage scheme is oblivious to. > > >=20 > > >=20 > > >=20 > > > ------------------------------------------------------- > > > This SF.Net email is sponsored by: > > > Sybase ASE Linux Express Edition - download now for FREE > > > LinuxWorld Reader's Choice Award Winner for best database=20 > on Linux. > > > http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick > > > _______________________________________________ > > > GDAlgorithms-list mailing list > > > GDA...@li... > > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > > Archives: > > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > >=20 > >=20 > >=20 > > ------------------------------------------------------- > > This SF.Net email is sponsored by: > > Sybase ASE Linux Express Edition - download now for FREE > > LinuxWorld Reader's Choice Award Winner for best database on Linux. > > http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dick > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 |
From: <Pau...@sc...> - 2004-11-12 12:21:06
|
gda...@li... wrote on 12/11/2004 11:13:23: > > You would probably do this correlation-finding as a preprocess > > Thanks Tom - yes.. I was thinking "animation-time" rather than > frametime but good to make that explicit. Would be interesting to > hear more about the correlation scheme.. > > For general interest (in changes of root ideas) "Nonconvex Rigid > Bodies with stacking." discusses a method which involves building a > graph (non-hierarchical) to represent contact between a set of > bodies together with a scheme for establishing a hierarchical > structure in a second pass. The hierarcy essentially reflects > "relative-rootedness" eg. foot becomes child of terrain etc... and > the use of a hierarchy allows collision resolution to be modelled > basically as an energy pulse propagated through the hierarchy. It > seems to be one way to squeeze juice out of both representation > schemes. Not sure about real-time performance but I believe someone > implemented a decent rag-doll demo on the basis of these ideas. Yeah, I've used it and can say it performs well (although I didn't implement the acyclic part). Basically, it allows faster propagation and resolution when using impulses to solve a system of constraints. It amounts about 16 lines of code in total. That paper doesn't give a very through explanation however. Google for Directed Acyclic Graph. Cheers, Paul. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify pos...@sc... This footnote also confirms that this email message has been checked for all known viruses. ********************************************************************** Sony Computer Entertainment Europe |
From: Jonathan B. <jo...@nu...> - 2004-11-09 18:56:52
|
Right, by disparaging the root I am saying that the hierarchy is not a=20 good idea. I have found that once we start doing things that are more interesting=20 than playing back animations, the hierarchy becomes vestigial and a big=20 hinderance. Sure, if you bend your elbow, your fingers move. But if=20 your hand hits a wall, it stops your elbow. Influence travels both=20 ways, that's what being in a physical reality is all about. Gribb, Gil wrote: >Well if you have a heirarchy, something has to be at the root. And the c= oncept of a heirarchy is not at all artifical. If I bend my elbow, my fin= gers move. But if I move my fingers, my elbow doesn't move. Quite a natur= al relation. > >-Gil > >-----Original Message----- >From: gda...@li... >[mailto:gda...@li...]On Behalf Of >Jonathan Blow >Sent: Tuesday, November 09, 2004 12:39 PM >To: gda...@li... >Subject: Re: [Algorithms] Animation and change of root > > >"The root" of a skeleton is a pretty artificial concept that has mostly=20 >outlived its usefulness. Most people still do things that way, but it's= =20 >not a great idea. > >Dynamic re-rooting of a skeleton is pretty easy; the annoying part is=20 >when you have all this animation data that's stored bone-relative and=20 >you're like, hey, what do I do with all this stuff? The most=20 >straightforward thing is to evaluate that animation on a spare skeleton=20 >that has a fixed root, to get the object space transforms, then=20 >re-compute bone space transforms for the new hierarchy based on that.=20 >(If you like bone space, which a lot of people on this list seem to.) =20 >Anyway, that's not "fast" if you are thinking=20 >I-am-peephole-optimizing-my-algorithm fast, but it's O(n) with the=20 >number of bones, so hey, whatever. > >But if you have time to actively experiment on this stuff, I would=20 >explore doing things without a root. > > > >Chris Haarmeijer wrote: > > =20 > >>Hi, >> >>For an animation system, I have to change the root of the system freque= ntly >> =20 >> >>from the left foot to the right foot. Are there any publications availa= ble > =20 > >>on the subject of fast changing of the root of an animation hierarchy ? >> >>Kind regards, >> >>Chris Haarmeijer >>--- >>Keep IT Simple Software >>Van Alphenstraat 12 >>7514 DD Enschede >> >>W: http://www.keepitsimple.nl >>E: mailto:in...@ke... >>T: +31 53 4356687 >> >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: >>Sybase ASE Linux Express Edition - download now for FREE >>LinuxWorld Reader's Choice Award Winner for best database on Linux. >>http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick >>_______________________________________________ >>GDAlgorithms-list mailing list >>GDA...@li... >>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>Archives: >>http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >> >>=20 >> >> =20 >> > > > >------------------------------------------------------- >This SF.Net email is sponsored by: >Sybase ASE Linux Express Edition - download now for FREE >LinuxWorld Reader's Choice Award Winner for best database on Linux. >http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > >------------------------------------------------------- >This SF.Net email is sponsored by: >Sybase ASE Linux Express Edition - download now for FREE >LinuxWorld Reader's Choice Award Winner for best database on Linux. >http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=CCk >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > =20 > |
From: Chris H. <c.h...@ke...> - 2004-11-09 19:42:08
|
Doing things with or without a root both has its pros and cons. It depend= s on the application. We're currently analyzing human motion using orientat= ion and pressure sensors. The pressure sensors are located beneath the feet a= nd the orientation sensors on each limb. We want to compute position based o= n the orientation sensors. To do this, we have to fix the foot with the mos= t pressure as the root of the system so the other one can move freely (gait cycle analysis). That's why I need to change the root of the system durin= g runtime. If you would do this without a root, how would you go about this= ? Chris ----- Original Message -----=20 From: "Jonathan Blow" <jo...@nu...> To: <gda...@li...> Sent: Tuesday, November 09, 2004 7:56 PM Subject: Re: [Algorithms] Animation and change of root > Right, by disparaging the root I am saying that the hierarchy is not a > good idea. > > I have found that once we start doing things that are more interesting > than playing back animations, the hierarchy becomes vestigial and a big > hinderance. Sure, if you bend your elbow, your fingers move. But if > your hand hits a wall, it stops your elbow. Influence travels both > ways, that's what being in a physical reality is all about. > > > Gribb, Gil wrote: > > >Well if you have a heirarchy, something has to be at the root. And the concept of a heirarchy is not at all artifical. If I bend my elbow, my fingers move. But if I move my fingers, my elbow doesn't move. Quite a natural relation. > > > >-Gil > > > >-----Original Message----- > >From: gda...@li... > >[mailto:gda...@li...]On Behalf Of > >Jonathan Blow > >Sent: Tuesday, November 09, 2004 12:39 PM > >To: gda...@li... > >Subject: Re: [Algorithms] Animation and change of root > > > > > >"The root" of a skeleton is a pretty artificial concept that has mostl= y > >outlived its usefulness. Most people still do things that way, but it= 's > >not a great idea. > > > >Dynamic re-rooting of a skeleton is pretty easy; the annoying part is > >when you have all this animation data that's stored bone-relative and > >you're like, hey, what do I do with all this stuff? The most > >straightforward thing is to evaluate that animation on a spare skeleto= n > >that has a fixed root, to get the object space transforms, then > >re-compute bone space transforms for the new hierarchy based on that. > >(If you like bone space, which a lot of people on this list seem to.) > >Anyway, that's not "fast" if you are thinking > >I-am-peephole-optimizing-my-algorithm fast, but it's O(n) with the > >number of bones, so hey, whatever. > > > >But if you have time to actively experiment on this stuff, I would > >explore doing things without a root. > > > > > > > >Chris Haarmeijer wrote: > > > > > > > >>Hi, > >> > >>For an animation system, I have to change the root of the system frequently > >> > >> > >>from the left foot to the right foot. Are there any publications available > > > > > >>on the subject of fast changing of the root of an animation hierarchy= ? > >> > >>Kind regards, > >> > >>Chris Haarmeijer > >>--- > >>Keep IT Simple Software > >>Van Alphenstraat 12 > >>7514 DD Enschede > >> > >>W: http://www.keepitsimple.nl > >>E: mailto:in...@ke... > >>T: +31 53 4356687 > >> > >> > >> > >>------------------------------------------------------- > >>This SF.Net email is sponsored by: > >>Sybase ASE Linux Express Edition - download now for FREE > >>LinuxWorld Reader's Choice Award Winner for best database on Linux. > >>http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick > >>_______________________________________________ > >>GDAlgorithms-list mailing list > >>GDA...@li... > >>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >>Archives: > >>http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > >> > >> > >> > >> > >> > > > > > > > >------------------------------------------------------- > >This SF.Net email is sponsored by: > >Sybase ASE Linux Express Edition - download now for FREE > >LinuxWorld Reader's Choice Award Winner for best database on Linux. > >http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick > >_______________________________________________ > >GDAlgorithms-list mailing list > >GDA...@li... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > > > > >------------------------------------------------------- > >This SF.Net email is sponsored by: > >Sybase ASE Linux Express Edition - download now for FREE > >LinuxWorld Reader's Choice Award Winner for best database on Linux. > >http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=CCk > >_______________________________________________ > >GDAlgorithms-list mailing list > >GDA...@li... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=CCk > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 |
From: Jonathan B. <jo...@nu...> - 2004-11-09 20:00:54
|
>If you would do this without a root, how would you go about this ? > > =20 > Generally speaking, you have systems where you treat the limbs as bodies=20 stored in a non-hierarchical way, with constraints between the bodies. =20 The constraints give you a system of (e.g. linear) equations which you=20 can then solve. To fix one of the feet, you then just add a constraint=20 between the foot and whatever it's pushing off of (which may just be a=20 point and orientation fixed in worldspace). > > =20 > >>Right, by disparaging the root I am saying that the hierarchy is not a >>good idea. >> >>I have found that once we start doing things that are more interesting >>than playing back animations, the hierarchy becomes vestigial and a big >>hinderance. Sure, if you bend your elbow, your fingers move. But if >>your hand hits a wall, it stops your elbow. Influence travels both >>ways, that's what being in a physical reality is all about. >> >> >>Gribb, Gil wrote: >> >> =20 >> >>>Well if you have a heirarchy, something has to be at the root. And the >>> =20 >>> >concept of a heirarchy is not at all artifical. If I bend my elbow, my >fingers move. But if I move my fingers, my elbow doesn't move. Quite a >natural relation. > =20 > >>>-Gil >>> >>>-----Original Message----- >>>From: gda...@li... >>>[mailto:gda...@li...]On Behalf Of >>>Jonathan Blow >>>Sent: Tuesday, November 09, 2004 12:39 PM >>>To: gda...@li... >>>Subject: Re: [Algorithms] Animation and change of root >>> >>> >>>"The root" of a skeleton is a pretty artificial concept that has mostl= y >>>outlived its usefulness. Most people still do things that way, but it= 's >>>not a great idea. >>> >>>Dynamic re-rooting of a skeleton is pretty easy; the annoying part is >>>when you have all this animation data that's stored bone-relative and >>>you're like, hey, what do I do with all this stuff? The most >>>straightforward thing is to evaluate that animation on a spare skeleto= n >>>that has a fixed root, to get the object space transforms, then >>>re-compute bone space transforms for the new hierarchy based on that. >>>(If you like bone space, which a lot of people on this list seem to.) >>>Anyway, that's not "fast" if you are thinking >>>I-am-peephole-optimizing-my-algorithm fast, but it's O(n) with the >>>number of bones, so hey, whatever. >>> >>>But if you have time to actively experiment on this stuff, I would >>>explore doing things without a root. >>> >>> >>> >>>Chris Haarmeijer wrote: >>> >>> >>> >>> =20 >>> >>>>Hi, >>>> >>>>For an animation system, I have to change the root of the system >>>> =20 >>>> >frequently > =20 > >>>> =20 >>>> >>>>from the left foot to the right foot. Are there any publications >>> =20 >>> >available > =20 > >>> =20 >>> >>>>on the subject of fast changing of the root of an animation hierarchy= ? >>>> >>>>Kind regards, >>>> >>>>Chris Haarmeijer >>>>--- >>>>Keep IT Simple Software >>>>Van Alphenstraat 12 >>>>7514 DD Enschede >>>> >>>>W: http://www.keepitsimple.nl >>>>E: mailto:in...@ke... >>>>T: +31 53 4356687 >>>> >>>> >>>> >>>>------------------------------------------------------- >>>>This SF.Net email is sponsored by: >>>>Sybase ASE Linux Express Edition - download now for FREE >>>>LinuxWorld Reader's Choice Award Winner for best database on Linux. >>>>http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick >>>>_______________________________________________ >>>>GDAlgorithms-list mailing list >>>>GDA...@li... >>>>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>>>Archives: >>>>http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >>>> >>>> >>>> >>>> >>>> >>>> =20 >>>> >>> >>>------------------------------------------------------- >>>This SF.Net email is sponsored by: >>>Sybase ASE Linux Express Edition - download now for FREE >>>LinuxWorld Reader's Choice Award Winner for best database on Linux. >>>http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick >>>_______________________________________________ >>>GDAlgorithms-list mailing list >>>GDA...@li... >>>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>>Archives: >>>http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >>> >>> >>>------------------------------------------------------- >>>This SF.Net email is sponsored by: >>>Sybase ASE Linux Express Edition - download now for FREE >>>LinuxWorld Reader's Choice Award Winner for best database on Linux. >>>http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=CCk >>>_______________________________________________ >>>GDAlgorithms-list mailing list >>>GDA...@li... >>>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>>Archives: >>>http://sourceforge.net/mailarchive/forum.php?forum_ida88 >>> >>> >>> >>> =20 >>> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: >>Sybase ASE Linux Express Edition - download now for FREE >>LinuxWorld Reader's Choice Award Winner for best database on Linux. >>http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=CCk >>_______________________________________________ >>GDAlgorithms-list mailing list >>GDA...@li... >>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>Archives: >>http://sourceforge.net/mailarchive/forum.php?forum_ida88 >> =20 >> > > > >------------------------------------------------------- >This SF.Net email is sponsored by: >Sybase ASE Linux Express Edition - download now for FREE >LinuxWorld Reader's Choice Award Winner for best database on Linux. >http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=CCk >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > =20 > |
From: Lars W. <la...@ch...> - 2004-11-17 20:20:06
|
I'm a bit late coming to this discussion, but what's wrong with maintaining two hierarchies, one rooted at the left foot, and one at the right. It should be relatively straightforward to transform your measured data into the local coordinates for the bones of each hierarchy (I'm assuming you are measuring joint angles). You can change which one is active dynamically based on when the weight change occurs (e.g. which hierarchy influences the vertices of your mesh). Lars Wilke Credo Interactive Inc. www.charactermotion.com > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On > Behalf Of Chris Haarmeijer > Sent: Tuesday, November 09, 2004 11:44 AM > To: gda...@li... > Subject: Re: [Algorithms] Animation and change of root > > > Doing things with or without a root both has its pros and > cons. It depends > on the application. We're currently analyzing human motion > using orientation > and pressure sensors. The pressure sensors are located > beneath the feet and > the orientation sensors on each limb. We want to compute > position based on > the orientation sensors. To do this, we have to fix the foot > with the most > pressure as the root of the system so the other one can move > freely (gait > cycle analysis). That's why I need to change the root of the > system during > runtime. If you would do this without a root, how would you > go about this ? > > Chris > > |
From: Yordan G. <yo...@gy...> - 2004-11-09 20:26:26
|
> Right, by disparaging the root I am saying that the hierarchy is not a > good idea. Although we use hierarchies and local bone animations... I think I'm with you on that. Everything to do with programmatically changing the current animation pose including IK, other physical interaction, mirroring etc requires it to be in world space... may be the only one that can be done in bone space without any additional trouble is noise... From a memory point of view (animation storage) a hierarchy is useful because in most skeletons positions stay fixed and most of (our) animations simply don't contain position data while with world space anim data positions will be changing all the time and have to be good quality to avoid strange artefacts. For example the anim data for the generic movement of the main characters and the NPCs on the game I work is around 4Mb... that is with a lot of error factored in to reduce the data. And 4Mb is about the maximum I can currently spare on PS2 for animation. Also, certain third party engines impose hierarchies... ... Btw John (concerning the other thread) I did a bit of maths and it looks horrendously different with bone space blends (as opposed to concatenated blends). I have no reasonable explanation to offer about why it works in my case but I can assure you we do/have done a lot blends including: - easein/out blends for anims - per bone weights for all blenders (upper body is just a configuration of bone weights) - blending of 3-4 movement animation for seamless transition between walk, jog, run... (with phase, time scaling matching, etc) - blending simple IK stuff in (must say this is big effort in local space and I wished I'd never gone there) - blending 9 anims (each representing key pose) to achieve a specific intermediate pose... And they do look convincingly right... but as I said I have no reasonable explanation why. You may as well be right in saying that it is going to look better with object space blends... I just remembered some few months ago when I was doing some of this (Casey's?) quaternion spline fitting... one of the guys at work swore it would never work (interpolating quaternions this way) - still it works like a charm. Is there any reasonable math ground behind it? because it seems to me local bone blends are quite similar to that... -Yordan ----- Original Message ----- From: "Jonathan Blow" <jo...@nu...> To: <gda...@li...> Sent: Tuesday, November 09, 2004 6:56 PM Subject: Re: [Algorithms] Animation and change of root Right, by disparaging the root I am saying that the hierarchy is not a good idea. I have found that once we start doing things that are more interesting than playing back animations, the hierarchy becomes vestigial and a big hinderance. Sure, if you bend your elbow, your fingers move. But if your hand hits a wall, it stops your elbow. Influence travels both ways, that's what being in a physical reality is all about. Gribb, Gil wrote: >Well if you have a heirarchy, something has to be at the root. And the concept of a heirarchy is not at all artifical. If I bend my elbow, my fingers move. But if I move my fingers, my elbow doesn't move. Quite a natural relation. > >-Gil > >-----Original Message----- >From: gda...@li... >[mailto:gda...@li...]On Behalf Of >Jonathan Blow >Sent: Tuesday, November 09, 2004 12:39 PM >To: gda...@li... >Subject: Re: [Algorithms] Animation and change of root > > >"The root" of a skeleton is a pretty artificial concept that has mostly >outlived its usefulness. Most people still do things that way, but it's >not a great idea. > >Dynamic re-rooting of a skeleton is pretty easy; the annoying part is >when you have all this animation data that's stored bone-relative and >you're like, hey, what do I do with all this stuff? The most >straightforward thing is to evaluate that animation on a spare skeleton >that has a fixed root, to get the object space transforms, then >re-compute bone space transforms for the new hierarchy based on that. >(If you like bone space, which a lot of people on this list seem to.) >Anyway, that's not "fast" if you are thinking >I-am-peephole-optimizing-my-algorithm fast, but it's O(n) with the >number of bones, so hey, whatever. > >But if you have time to actively experiment on this stuff, I would >explore doing things without a root. > > > >Chris Haarmeijer wrote: > > > >>Hi, >> >>For an animation system, I have to change the root of the system frequently >> >> >>from the left foot to the right foot. Are there any publications available > > >>on the subject of fast changing of the root of an animation hierarchy ? >> >>Kind regards, >> >>Chris Haarmeijer >>--- >>Keep IT Simple Software >>Van Alphenstraat 12 >>7514 DD Enschede >> >>W: http://www.keepitsimple.nl >>E: mailto:in...@ke... >>T: +31 53 4356687 >> >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: >>Sybase ASE Linux Express Edition - download now for FREE >>LinuxWorld Reader's Choice Award Winner for best database on Linux. >>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click >>_______________________________________________ >>GDAlgorithms-list mailing list >>GDA...@li... >>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>Archives: >>http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >> >> >> >> >> > > > >------------------------------------------------------- >This SF.Net email is sponsored by: >Sybase ASE Linux Express Edition - download now for FREE >LinuxWorld Reader's Choice Award Winner for best database on Linux. >http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > >------------------------------------------------------- >This SF.Net email is sponsored by: >Sybase ASE Linux Express Edition - download now for FREE >LinuxWorld Reader's Choice Award Winner for best database on Linux. >http://ads.osdn.com/?ad_idU88&alloc_id065&opÌk >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > > ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=ick _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 |
From: Jonathan B. <jo...@nu...> - 2004-11-09 20:59:53
|
>>From a memory point of view (animation storage) a hierarchy is useful >because in most skeletons positions stay fixed and most of (our) animations >simply don't contain position data while with world space anim data >positions will be changing all the time and have to be good quality to avoid >strange artefacts. For example the anim data for the generic movement of the >main characters and the NPCs on the game I work is around 4Mb... that is >with a lot of error factored in to reduce the data. And 4Mb is about the >maximum I can currently spare on PS2 for animation. > > Right, one thing the animation hierarchy gives you is an easy form of delta compression. One thing you can do is just treat this as compression, and expand to object space at the beginning of each frame or whatever. Another thing you can do is to go beyond this kind of low-hanging-fruit compression and do something more hardcore. Such an algorithm would involve automated clustering, etc, and would make the hierarchy unnecessary (since when the finger rotates with the hand, it would notice that and make a cluster). I have never done this but it's been on my to-do list for a few years now (just soooo busy....) >... > >Btw John (concerning the other thread) I did a bit of maths and it looks >horrendously different with bone space blends (as opposed to concatenated >blends). I have no reasonable explanation to offer about why it works in my >case but I can assure you we do/have done a lot blends including: >- easein/out blends for anims >- per bone weights for all blenders (upper body is just a configuration of >bone weights) >- blending of 3-4 movement animation for seamless transition between walk, >jog, run... (with phase, time scaling matching, etc) >- blending simple IK stuff in (must say this is big effort in local space >and I wished I'd never gone there) >- blending 9 anims (each representing key pose) to achieve a specific >intermediate pose... >And they do look convincingly right... but as I said I have no reasonable >explanation why. You may as well be right in saying that it is going to look >better with object space blends... > > One example that I had of extreme problems with bone-space blends was with a swordfighting game I did a few years ago. There was a "swing the broadsword" animation, but you could also control how much your character was bending with the mouse (it basically did some IK on the spine joints to make you bend the appropriate amount). Well, in most skeleton setups the spine is parent to the shoulders, arms, etc. Even small bends of the spine would cause the arms and head to arc in a very weird way when swinging the sword. I ended up putting an object-space fixup at the base of the neck. But everyone's case is different. If all your blends go all the way down to the root, for example, or your source data is not very different in terms of the orientations of nodes near the root, the problem would be a lot smaller. Generally though, all I want to highlight is the fact that if you visualize a blend in object space, it's pretty easy to see that that's something reasonable, whereas a blend in bone space, well, it's a lot less clear what's going on. And the two answers are different. And most people aren't aware that the two answers are different. In the end, though, I am a proponent of "if it's working for you, ship the game". >I just remembered some few months ago when I was doing some of this >(Casey's?) quaternion spline fitting... one of the guys at work swore it >would never work (interpolating quaternions this way) - still it works like >a charm. Is there any reasonable math ground behind it? because it seems to >me local bone blends are quite similar to that... > > The reason this works is, when you dig down far enough, that linear interpolation has a valid and reasonable meaning for quaternions. (And by that I mean actual linear interpolation, not slerp). When we first learning about quaternions, we see them as these weird entities that you have to do all kinds of special creepy stuff for. But that's not as true as it would seem, which becomes evident when we really dig deep with quaternions and gain a good understanding. So I would say that the reason the guy at work was so surprised is that he kind of understands quaternions, but not really. I have a couple of articles that explain this to some degree... http://number-none.com/product/Understanding%20Slerp,%20Then%20Not%20Using%20It/index.html http://number-none.com/product/Hacking%20Quaternions/index.html You're right that this is relevant to the local bone blend issue. I hadn't thought of it that way. The difference between the cases, though, is that when doing spline fitting, error is bounded. (Because hey, you make a new knot in the spline and there you go). For bone blends, you just sort of do the blend and what ever you end up with, you end up with. The linear interpolation *does* induce error and if you composite a few layers of it you can get something wacky. The spline fit keeps a lid on this, but the bone blend doesn't have any mechanism for that. |
From: Jonathan B. <jo...@nu...> - 2004-11-09 21:12:05
|
I wrote: > > You're right that this is relevant to the local bone blend issue. I > hadn't thought of it that way. The difference between the cases, > though, is that when doing spline fitting, error is bounded. (Because > hey, you make a new knot in the spline and there you go). For bone > blends, you just sort of do the blend and what ever you end up with, > you end up with. The linear interpolation *does* induce error and if > you composite a few layers of it you can get something wacky. The > spline fit keeps a lid on this, but the bone blend doesn't have any > mechanism for that. > One more thing to say here. Because the curve fitter's job is to control error, to some extent it does not matter *what* the lower-level interpolation function is, because its error will be controlled. Charles Bloom pointed this out very clearly in an email a while back, and it's up on his tech page right now: http://www.cbloom.com/3d/rambles.html , look for the 3-6-02 entry. The same cannot be said for local-space bone blends: obviously your interpolator matters a lot, small changes in the interpolator can cause large changes in what happens in the output! So to me this pretty clearly illustrates the differences between the two cases. |
From: Yordan G. <yo...@gy...> - 2004-11-10 00:08:33
|
I agree with your points. I have read you articles when it was printed in gdmag... by some bizarre coincidence I remember reading Mr. Bloom's stuff as well... might have been mentioned previously in this list. You are also right that most of my blends are full body (or are coming from a full body skeleton). Even when I did the IK stuff it uses full body reference pose or just copies the current pose of the root blender... anyway as I said if one doesn't what to go mad the only choice is to convert it into world (object) space and derive and IK there... then inverse transform it back into bone space - waste of time and CPU... One additional thing is that in my lerp during bone blends I do a check and flip one of the quaternions if needed. I'd like to hear more about this compression stuff though. when you have time... -Yordan ----- Original Message ----- From: "Jonathan Blow" <jo...@nu...> To: <gda...@li...> Sent: Tuesday, November 09, 2004 8:59 PM Subject: Re: [Algorithms] Animation and change of root > > >>From a memory point of view (animation storage) a hierarchy is useful > >because in most skeletons positions stay fixed and most of (our) animations > >simply don't contain position data while with world space anim data > >positions will be changing all the time and have to be good quality to avoid > >strange artefacts. For example the anim data for the generic movement of the > >main characters and the NPCs on the game I work is around 4Mb... that is > >with a lot of error factored in to reduce the data. And 4Mb is about the > >maximum I can currently spare on PS2 for animation. > > > > > > Right, one thing the animation hierarchy gives you is an easy form of > delta compression. One thing you can do is just treat this as > compression, and expand to object space at the beginning of each frame > or whatever. > > Another thing you can do is to go beyond this kind of low-hanging-fruit > compression and do something more hardcore. Such an algorithm would > involve automated clustering, etc, and would make the hierarchy > unnecessary (since when the finger rotates with the hand, it would > notice that and make a cluster). I have never done this but it's been > on my to-do list for a few years now (just soooo busy....) > > >... > > > >Btw John (concerning the other thread) I did a bit of maths and it looks > >horrendously different with bone space blends (as opposed to concatenated > >blends). I have no reasonable explanation to offer about why it works in my > >case but I can assure you we do/have done a lot blends including: > >- easein/out blends for anims > >- per bone weights for all blenders (upper body is just a configuration of > >bone weights) > >- blending of 3-4 movement animation for seamless transition between walk, > >jog, run... (with phase, time scaling matching, etc) > >- blending simple IK stuff in (must say this is big effort in local space > >and I wished I'd never gone there) > >- blending 9 anims (each representing key pose) to achieve a specific > >intermediate pose... > >And they do look convincingly right... but as I said I have no reasonable > >explanation why. You may as well be right in saying that it is going to look > >better with object space blends... > > > > > > One example that I had of extreme problems with bone-space blends was > with a swordfighting game I did a few years ago. There was a "swing the > broadsword" animation, but you could also control how much your > character was bending with the mouse (it basically did some IK on the > spine joints to make you bend the appropriate amount). Well, in most > skeleton setups the spine is parent to the shoulders, arms, etc. Even > small bends of the spine would cause the arms and head to arc in a very > weird way when swinging the sword. I ended up putting an object-space > fixup at the base of the neck. > > But everyone's case is different. If all your blends go all the way > down to the root, for example, or your source data is not very different > in terms of the orientations of nodes near the root, the problem would > be a lot smaller. > > Generally though, all I want to highlight is the fact that if you > visualize a blend in object space, it's pretty easy to see that that's > something reasonable, whereas a blend in bone space, well, it's a lot > less clear what's going on. And the two answers are different. And > most people aren't aware that the two answers are different. In the > end, though, I am a proponent of "if it's working for you, ship the game". > > >I just remembered some few months ago when I was doing some of this > >(Casey's?) quaternion spline fitting... one of the guys at work swore it > >would never work (interpolating quaternions this way) - still it works like > >a charm. Is there any reasonable math ground behind it? because it seems to > >me local bone blends are quite similar to that... > > > > > > The reason this works is, when you dig down far enough, that linear > interpolation has a valid and reasonable meaning for quaternions. (And > by that I mean actual linear interpolation, not slerp). When we first > learning about quaternions, we see them as these weird entities that you > have to do all kinds of special creepy stuff for. But that's not as > true as it would seem, which becomes evident when we really dig deep > with quaternions and gain a good understanding. > > So I would say that the reason the guy at work was so surprised is that > he kind of understands quaternions, but not really. > > I have a couple of articles that explain this to some degree... > > http://number-none.com/product/Understanding%20Slerp,%20Then%20Not%20Using%20It/index.html > http://number-none.com/product/Hacking%20Quaternions/index.html > > > You're right that this is relevant to the local bone blend issue. I > hadn't thought of it that way. The difference between the cases, > though, is that when doing spline fitting, error is bounded. (Because > hey, you make a new knot in the spline and there you go). For bone > blends, you just sort of do the blend and what ever you end up with, you > end up with. The linear interpolation *does* induce error and if you > composite a few layers of it you can get something wacky. The spline > fit keeps a lid on this, but the bone blend doesn't have any mechanism > for that. > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > |
From: Jonathan B. <jo...@nu...> - 2004-11-10 03:50:40
|
> >I'd like to hear more about this compression stuff though. when you have >time... > > Well, "delta compression" is the very general compression idea that if you have some set of values, oftentimes the differences between them will be smaller and more orderly than the values themselves, so they are easier to represent. A simple example of delta compression for audio is the ADPCM format. In animation, the hierarchy gives you delta compression because what you're saying is, "Factor off my parent's transform, and just store my local transform", in other words, just store the difference between my parent's rotation and my rotation. Often this difference will be constant (like if you have a finger on a hand and the finger doesn't move relative to the hand). However, there are many things that the hierarchy *doesn't* give you. For example, say you have an animation of a guy swaying his arms back and forth in a parallel motion. Well, both of the arms have highly correlated rotations. Any time there is correlation, there is the capacity for compression. But the hierarchy doesn't consider the two arms to be related so it doesn't exploit this. But if you analyze the joint angles of the two arms over the course of the animation you can say "aha these guys are correlated, and typically there is this average transform Q that takes me from arm1's rotation to arm2's rotation during any given frame. It is not always exactly Q, but it's close. So what I will do is store arm1 in the animation, and store the constant Q, and then for every frame I will store the deltas from Q that get me all the way to arm2, which is smaller and easier than the original transforms." A lot of human motion is highly correlated (think about walking, running, etc etc). So there is a lot of capacity for compression that the hierarchical bone-local storage scheme is oblivious to. |
From: Tom F. <tom...@ee...> - 2004-11-12 08:58:00
|
Sure it's artificial. The hierarchy should (*) just be chosen to = minimise the amount of data encoding you have to do. In all animations of organic creatures, as you flex one muscle, it tightens other areas of the body, = and other muscles have to actively move to counteract it - there is no such thing as a "pure" movement. Certainly when reaching for a cup of tea, there's a whole bunch of complex movements and corrections going on. In fact, in this specific case, it makes far more sense to have a dual hierarchy - one originaling from the middle of the spine, and the other originating from the hand - these are the two most fixed points - and = they meet in the middle in some complex dance. > But if I move my=20 > fingers, my elbow doesn't move. Ah, but if you wiggle your fingers, the skin just above your elbow = moves, because that's where those muscles live. If you rowed a lot of boats = when you were young, as I did, and developed an absurdly powerful grip, it = moves vertically by about an inch or so :-) TomF. (*) ideally, that is - it's moderately impractical to keep changing them around though, so you probably need to pick just a few. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Gribb, Gil > Sent: 09 November 2004 10:50 > To: gda...@li... > Subject: RE: [Algorithms] Animation and change of root >=20 >=20 > Well if you have a heirarchy, something has to be at the=20 > root. And the concept of a heirarchy is not at all artifical.=20 > If I bend my elbow, my fingers move. But if I move my=20 > fingers, my elbow doesn't move. Quite a natural relation. >=20 > -Gil >=20 > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...]On Behalf Of > Jonathan Blow > Sent: Tuesday, November 09, 2004 12:39 PM > To: gda...@li... > Subject: Re: [Algorithms] Animation and change of root >=20 >=20 > "The root" of a skeleton is a pretty artificial concept that=20 > has mostly=20 > outlived its usefulness. Most people still do things that=20 > way, but it's=20 > not a great idea. >=20 > Dynamic re-rooting of a skeleton is pretty easy; the annoying part is=20 > when you have all this animation data that's stored bone-relative and=20 > you're like, hey, what do I do with all this stuff? The most=20 > straightforward thing is to evaluate that animation on a=20 > spare skeleton=20 > that has a fixed root, to get the object space transforms, then=20 > re-compute bone space transforms for the new hierarchy based on that.=20 > (If you like bone space, which a lot of people on this list=20 > seem to.) =20 > Anyway, that's not "fast" if you are thinking=20 > I-am-peephole-optimizing-my-algorithm fast, but it's O(n) with the=20 > number of bones, so hey, whatever. >=20 > But if you have time to actively experiment on this stuff, I would=20 > explore doing things without a root. >=20 >=20 >=20 > Chris Haarmeijer wrote: >=20 > >Hi, > > > >For an animation system, I have to change the root of the=20 > system frequently > >from the left foot to the right foot. Are there any=20 > publications available > >on the subject of fast changing of the root of an animation=20 > hierarchy ? > > > >Kind regards, > > > >Chris Haarmeijer > >--- > >Keep IT Simple Software > >Van Alphenstraat 12 > >7514 DD Enschede > > > >W: http://www.keepitsimple.nl > >E: mailto:in...@ke... > >T: +31 53 4356687 > > > > > > > >------------------------------------------------------- > >This SF.Net email is sponsored by: > >Sybase ASE Linux Express Edition - download now for FREE > >LinuxWorld Reader's Choice Award Winner for best database on Linux. > >http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick > >_______________________________________________ > >GDAlgorithms-list mailing list > >GDA...@li... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > > > =20 > > >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 |