You can subscribe to this list here.
2000 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(390) 
_{Aug}
(767) 
_{Sep}
(940) 
_{Oct}
(964) 
_{Nov}
(819) 
_{Dec}
(762) 

2001 
_{Jan}
(680) 
_{Feb}
(1075) 
_{Mar}
(954) 
_{Apr}
(595) 
_{May}
(725) 
_{Jun}
(868) 
_{Jul}
(678) 
_{Aug}
(785) 
_{Sep}
(410) 
_{Oct}
(395) 
_{Nov}
(374) 
_{Dec}
(419) 
2002 
_{Jan}
(699) 
_{Feb}
(501) 
_{Mar}
(311) 
_{Apr}
(334) 
_{May}
(501) 
_{Jun}
(507) 
_{Jul}
(441) 
_{Aug}
(395) 
_{Sep}
(540) 
_{Oct}
(416) 
_{Nov}
(369) 
_{Dec}
(373) 
2003 
_{Jan}
(514) 
_{Feb}
(488) 
_{Mar}
(396) 
_{Apr}
(624) 
_{May}
(590) 
_{Jun}
(562) 
_{Jul}
(546) 
_{Aug}
(463) 
_{Sep}
(389) 
_{Oct}
(399) 
_{Nov}
(333) 
_{Dec}
(449) 
2004 
_{Jan}
(317) 
_{Feb}
(395) 
_{Mar}
(136) 
_{Apr}
(338) 
_{May}
(488) 
_{Jun}
(306) 
_{Jul}
(266) 
_{Aug}
(424) 
_{Sep}
(502) 
_{Oct}
(170) 
_{Nov}
(170) 
_{Dec}
(134) 
2005 
_{Jan}
(249) 
_{Feb}
(109) 
_{Mar}
(119) 
_{Apr}
(282) 
_{May}
(82) 
_{Jun}
(113) 
_{Jul}
(56) 
_{Aug}
(160) 
_{Sep}
(89) 
_{Oct}
(98) 
_{Nov}
(237) 
_{Dec}
(297) 
2006 
_{Jan}
(151) 
_{Feb}
(250) 
_{Mar}
(222) 
_{Apr}
(147) 
_{May}
(266) 
_{Jun}
(313) 
_{Jul}
(367) 
_{Aug}
(135) 
_{Sep}
(108) 
_{Oct}
(110) 
_{Nov}
(220) 
_{Dec}
(47) 
2007 
_{Jan}
(133) 
_{Feb}
(144) 
_{Mar}
(247) 
_{Apr}
(191) 
_{May}
(191) 
_{Jun}
(171) 
_{Jul}
(160) 
_{Aug}
(51) 
_{Sep}
(125) 
_{Oct}
(115) 
_{Nov}
(78) 
_{Dec}
(67) 
2008 
_{Jan}
(165) 
_{Feb}
(37) 
_{Mar}
(130) 
_{Apr}
(111) 
_{May}
(91) 
_{Jun}
(142) 
_{Jul}
(54) 
_{Aug}
(104) 
_{Sep}
(89) 
_{Oct}
(87) 
_{Nov}
(44) 
_{Dec}
(54) 
2009 
_{Jan}
(283) 
_{Feb}
(113) 
_{Mar}
(154) 
_{Apr}
(395) 
_{May}
(62) 
_{Jun}
(48) 
_{Jul}
(52) 
_{Aug}
(54) 
_{Sep}
(131) 
_{Oct}
(29) 
_{Nov}
(32) 
_{Dec}
(37) 
2010 
_{Jan}
(34) 
_{Feb}
(36) 
_{Mar}
(40) 
_{Apr}
(23) 
_{May}
(38) 
_{Jun}
(34) 
_{Jul}
(36) 
_{Aug}
(27) 
_{Sep}
(9) 
_{Oct}
(18) 
_{Nov}
(25) 
_{Dec}

2011 
_{Jan}
(1) 
_{Feb}
(14) 
_{Mar}
(1) 
_{Apr}
(5) 
_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}
(37) 
_{Sep}
(6) 
_{Oct}
(2) 
_{Nov}

_{Dec}

2012 
_{Jan}

_{Feb}
(7) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}
(10) 
2013 
_{Jan}

_{Feb}
(1) 
_{Mar}
(7) 
_{Apr}
(2) 
_{May}

_{Jun}

_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2014 
_{Jan}
(14) 
_{Feb}

_{Mar}
(2) 
_{Apr}

_{May}
(10) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(3) 
_{Dec}

2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(12) 
_{Nov}

_{Dec}
(1) 
2016 
_{Jan}

_{Feb}
(1) 
_{Mar}
(1) 
_{Apr}
(1) 
_{May}

_{Jun}
(1) 
_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1

2
(2) 
3
(6) 
4
(30) 
5
(21) 
6
(24) 
7
(8) 
8

9
(17) 
10
(21) 
11
(8) 
12
(12) 
13
(5) 
14
(1) 
15

16
(34) 
17
(28) 
18
(37) 
19
(34) 
20
(41) 
21
(9) 
22
(10) 
23
(7) 
24
(2) 
25
(5) 
26
(3) 
27

28
(4) 
29

30
(4) 
31





From: Chris Hecker <checker@d6...>  20021210 19:30:24

>Jakobsen stuff doesn't gaurantee that you're taking the shortest >path to a stable point, so you can take two configurations that >are epsilon apart, relax them both and get two results that are >grossly different. I'm not a big fan of adhoc solvers like the Jakobsen thing (although I think it's a great paper & presentation and it gets more people doing physics, which is good no matter what technique they use), but your statement is true of any nonlinear system with multiple local extrema, no matter how fancy your solver/simulator. It's not just a problem with the Jakobsen technique. Chris 
From: Charles Bloom <cbloom@cb...>  20021210 18:34:37

The DOF problem obviously arises when the tetrahedron is not able to satisfy its constraints for whatever reason. In fact, in general the Jakobsen iterative constraint system falls apart when the system can't satisfy its constraints for whatever reason. This happens, for example, when a rigid body falls into a littler crack. I suppose you could just start "backing up time" to find a point where the constraints can be satisfied. Iterative constraint relaxation has other problems, though, when the constraint can be satisfied in multiple different ways. The Jakobsen stuff doesn't gaurantee that you're taking the shortest path to a stable point, so you can take two configurations that are epsilon apart, relax them both and get two results that are grossly different. This generally occurs when you have multiple fixedpoint constraints combined with hinges and such.  Charles Bloom cb@... http://www.cbloom.com 
From: Tyson Jensen <twjensen@sa...>  20021210 18:26:18

Update: You do want to use all 4 points if you are emulating a rigid tetrahedron, otherwise the point you don't use will end up "squishy" (ie, slight errors in its position will not translate properly into the position of the object as a whole.) You can either use all 4 points in creating your frame, or you can just calculate the frame first using any method, and then make sure that your various constraints update the coordinate frame along with the actual penetrating point. Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Tyson Jensen Sent: Tuesday, December 10, 2002 9:50 AM To: gdalgorithmslist@... Subject: RE: [Algorithms] Extracting a Matrix from a Tetrahedron (was: Preventing Verlet Rigid Bodies From Going InsideOut) I don't see how either method would "bite" you, but I would probably just for my own mental sanity and debugging convenience define one of the points as "up" and another as "forward". I'd put the origin of the frame at the base of the tetrahedron opposite "up."*. From there construction is trivial**. But I'm doing extra work to get there and only so that I have a nice convenient local space. OTOH, nice convenient coordinate frames have saved me hours of debugging that I can then use to speed up really slow parts of the game. * Average the three bottom points ** up  base = up_vector, forward  base = forward_vector, up_vector X forward_vector = right_vector Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Steve Ranck Sent: Tuesday, December 10, 2002 12:26 AM To: gdalgorithmslist@... Subject: [Algorithms] Extracting a Matrix from a Tetrahedron (was: Preventing Verlet Rigid Bodies From Going InsideOut) Hi Charles, This is another great question. I'm currently using only 3 of the points and completely ignoring the 4th. Though I'm getting pretty decent results, I wonder if it's going to bite me under certain circumstances. In fact, the method I use to extract the matrix is even worst. I implemented the most straightforward approach, where the line between the first two vertices is one of my axis, and the other two are derived via cross products. This seems like two of the points would have direct influence over the matrix generation, followed by the 3rd, and ignoring the 4th. The ideal solution would generate a matrix considering all four points. It seems there should be a way to determine the matrix by somehow "averaging" the 3 axis formed by the particles of a right tetrahedron. Or if we measured how far off two axis were (using dot product, for example) from each other and called that the error, maybe we could select a matrix whose 3 axis form a minimum error when summed together. I wonder what Jakobsen did. Steve > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On > Behalf Of Charles Bloom > Sent: Monday, December 09, 2002 10:28 AM > To: gdalgorithmslist@... > Subject: Re: [Algorithms] Preventing Verlet Rigid Bodies From > Going InsideOut > > > > At 12:43 AM 12/9/2002 0800, Steve Ranck wrote: > >The "Rigid Bodies" section speaks about using a tetrahedron > >configuration of 4 particles with distance constraints > between them to > >represent a rigid body. From the particle positions, a matrix can be > >extracted and the graphics geo (or whatever) can be oriented > by using > >that matrix. > > BTW how are people extracting a frame from a tetrahedron? > The problem is overconstrained, since you only need 3 points > to define a coordinate frame. > >  > Charles Bloom cb@... http://www.cbloom.com > > > >  > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithmslist mailing list GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > >  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Jeff Lander <jeffl@da...>  20021210 18:22:41

Yeah, I guess I should have said. One specific case was I wanted a = rigid nondeforming (and non simulated) model to be physically attached = to the deformable model. So I could pin the base of the rigid object to = a node on the deformable. But I needed some plausible frame beyond just = the surface normal. There was another case where I was doing a FFD = lattice and needed a frame from that but I forget exactly why. Jeff  Original Message =20 From: David Lam  Tokamak=20 To: gdalgorithmslist@...=20 Sent: Tuesday, December 10, 2002 9:49 AM Subject: Re: [Algorithms] Preventing Verlet Rigid Bodies From Going = InsideOut Jeff, I am a bit puzzle as to why you would need to extract a frame = out of a tetrahedron when you are doing deformable bodies. Wouldn't you = just set the vertices' world space position?=20 David Lam=20 http://www.tokamakphysics.com=20 
From: Tyson Jensen <twjensen@sa...>  20021210 18:20:39

Three points and three sticks = 3*33 = 6 degrees of freedom. Therefore, 4 points is more than strictly needed to just make a coordinate frame. But there aren't any 3space shapes that are defined by three points. So 3 points are too few to demonstrate the power of the techniques being illustrated. Most 3space objects will want more than 4 points in order to look good. (Spheres shouldn't bounce like 4sided dice). Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Jamie Fowlston Sent: Tuesday, December 10, 2002 3:56 AM To: gdalgorithmslist@... Subject: RE: [Algorithms] Preventing Verlet Rigid Bodies From Going InsideOut the problem isn't over constrained. each particle has 3 degrees of freedom, but each 'stick' constraint removes one of them. so we have 3 * 4  6 = 6 degrees of freedom, as required to determine the position and orientation. jakobsen covers this in the paper. jamie Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Charles Bloom Sent: 09 December 2002 18:28 To: gdalgorithmslist@... Subject: Re: [Algorithms] Preventing Verlet Rigid Bodies From Going InsideOut At 12:43 AM 12/9/2002 0800, Steve Ranck wrote: >The "Rigid Bodies" section speaks about using a tetrahedron >configuration of 4 particles with distance constraints between them to >represent a rigid body. From the particle positions, a matrix can be >extracted and the graphics geo (or whatever) can be oriented by using >that matrix. BTW how are people extracting a frame from a tetrahedron? The problem is overconstrained, since you only need 3 points to define a coordinate frame.  Charles Bloom cb@... http://www.cbloom.com  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Tyson Jensen <twjensen@sa...>  20021210 17:53:16

Um, in a military simulation, I doubt anyone would care about the spider feet going into the floor. They'd be more concerned as to where AlQaeda got the giant spider! :) IK is nice for IK problems. Interpenetration is more a collisionvolume notworking problem. Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Nick Pelling Sent: Tuesday, December 10, 2002 3:05 AM To: 'gdalgorithmslist@...' Subject: RE: [Algorithms] Skeletal animation blending artefacts I'm not knocking IK, it's just that I've only ever had anything approaching a problem with quat interpolation in about 0.001% of cases, and then only fleetingly. These are for computer games, right? That giant spider isn't being used for a military AlQaedagiantspiderinvasionofAmerica simulation, where the spider foot occasionally penetrating the floor would compromise everything? Sure, piledrivers are great too: but I prefer nutcrackers when trying to stay within budget etc. And for eating nuts, of course. :) Cheers, .....Nick Pelling..... Original Message From: Jon Watte [mailto:hplus@...] Sent: 09 December 2002 22:10 To: gdalgorithmslist@... Subject: RE: [Algorithms] Skeletal animation blending artefacts > To stop a stupid spider's stupid feet very occasionally > penetrating into the > floor, you could just clip the height of any transformed vertices > so that it > never goes below the level of the floor. That will look almost exactly like penetration. I think the easiest thing to do is to offset the spider upwards so it's not penetrating. The second easiest, and I believe by far the bestlooking, would be an IK solver on each leg to put the feet on the floor. Note that this is NOT a "genericcoffee_maker" IK solution, with all those problems; this is a specific, constrained IK solution which can be made to look good with finite effort. > Of course, if you've been looking for an flimsy excuse to do IK > for a while, > then go for it. :) If you can reuse that IK for all your animated characters, and finally get rid of that horrible foot sliding, then you have done all your players a great service. Or perhaps I'm just ultra sensitive to this problem.  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Tyson Jensen <twjensen@sa...>  20021210 17:49:33

I don't see how either method would "bite" you, but I would probably just for my own mental sanity and debugging convenience define one of the points as "up" and another as "forward". I'd put the origin of the frame at the base of the tetrahedron opposite "up."*. From there construction is trivial**. But I'm doing extra work to get there and only so that I have a nice convenient local space. OTOH, nice convenient coordinate frames have saved me hours of debugging that I can then use to speed up really slow parts of the game. * Average the three bottom points ** up  base = up_vector, forward  base = forward_vector, up_vector X forward_vector = right_vector Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Steve Ranck Sent: Tuesday, December 10, 2002 12:26 AM To: gdalgorithmslist@... Subject: [Algorithms] Extracting a Matrix from a Tetrahedron (was: Preventing Verlet Rigid Bodies From Going InsideOut) Hi Charles, This is another great question. I'm currently using only 3 of the points and completely ignoring the 4th. Though I'm getting pretty decent results, I wonder if it's going to bite me under certain circumstances. In fact, the method I use to extract the matrix is even worst. I implemented the most straightforward approach, where the line between the first two vertices is one of my axis, and the other two are derived via cross products. This seems like two of the points would have direct influence over the matrix generation, followed by the 3rd, and ignoring the 4th. The ideal solution would generate a matrix considering all four points. It seems there should be a way to determine the matrix by somehow "averaging" the 3 axis formed by the particles of a right tetrahedron. Or if we measured how far off two axis were (using dot product, for example) from each other and called that the error, maybe we could select a matrix whose 3 axis form a minimum error when summed together. I wonder what Jakobsen did. Steve > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On > Behalf Of Charles Bloom > Sent: Monday, December 09, 2002 10:28 AM > To: gdalgorithmslist@... > Subject: Re: [Algorithms] Preventing Verlet Rigid Bodies From > Going InsideOut > > > > At 12:43 AM 12/9/2002 0800, Steve Ranck wrote: > >The "Rigid Bodies" section speaks about using a tetrahedron > >configuration of 4 particles with distance constraints > between them to > >represent a rigid body. From the particle positions, a matrix can be > >extracted and the graphics geo (or whatever) can be oriented > by using > >that matrix. > > BTW how are people extracting a frame from a tetrahedron? > The problem is overconstrained, since you only need 3 points > to define a coordinate frame. > >  > Charles Bloom cb@... http://www.cbloom.com > > > >  > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithmslist mailing list GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > >  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: David Lam  Tokamak <dlam@to...>  20021210 17:49:01

SmVmZiwgSSBhbSBhIGJpdCBwdXp6bGUgYXMgdG8gd2h5IHlvdSB3b3VsZCBuZWVkIHRvIGV4dHJh Y3QgYSBmcmFtZSBvdXQgb2YgYSB0ZXRyYWhlZHJvbiB3aGVuIHlvdSBhcmUgZG9pbmcgZGVmb3Jt YWJsZSBib2RpZXMuIFdvdWxkbid0IHlvdSBqdXN0IHNldCB0aGUgdmVydGljZXMnIHdvcmxkIHNw YWNlIHBvc2l0aW9uPw0KDQpEYXZpZCBMYW0NCg0Kd3d3LnRva2FtYWtwaHlzaWNzLmNvbQ0KDQoN Cg0KICAgLS0tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLS0tDQogICA+IEZyb206IGplZmZsQGRh cndpbjNkLmNvbSANCiAgID4gU3ViamVjdDogUmU6IFtBbGdvcml0aG1zXSBQcmV2ZW50aW5nIFZl cmxldCBSaWdpZCBCb2RpZXMgRnJvbSBHb2luZyAgSW5zaWRlLU91dA0KICAgPiBTZW50OiAxMCBE ZWMgMjAwMiAgMTc6MTM6MTkNCiAgID4gIEkgZG9uJ3QgdGhpbmsgSSBoYXZlIGEgcGVyZmVjdCBt ZXRob2QgZm9yIHRoaXMgYnV0IEkgaGF2ZSB0cmllZCBhIGNvdXBsZSBvZiB0aGluZ3MuICBJIGlt YmVkIGEgZnJhbWUgd2l0aGluIHRoZSB0ZXRyYWhlZHJvbiB1c2luZyBiYXJ5Y2VudHJpYyBjb29y ZGluYXRlcyBhbG9uZyB0aGUgZGlyZWN0aW9ucyB0aGF0IG1ha2Ugc2Vuc2UgZm9yIHRoZSBtb2Rl bC4gIFVzdWFsbHkgdGhpcyBlbmRzIHVwIGJlaW5nIGFsb25nIGF0IGxlYXN0IG9uZSBvZiB0aGUg ZWRnZXMgZm9yIGNsYXJpdHkgc2FrZSB3aGVuIG1vZGVsaW5nLiAgVGhlbiBpdCBpcyBlYXN5IHRv IGV4dHJhY3QgaXQgZHVyaW5nIHNpbXVsYXRpb24uDQogICA+ICBUaGUgcHJvYmxlbSBpcyB0aGF0 IHdoZW4gSSB1c2UgdGhpcyBmb3IgZGVmb3JtYWJsZXMsIHlvdSBzdGlsbCBuZWVkIHRvIG5vcm1h bGl6ZSB0aGUgZnJhbWUgc28gSSBqdXN0IGZpeCBpdCB1cCBhc3N1bWluZyB0aGUgdXAgdmVjdG9y IGlzIHRoZSBtb3N0IGNvcnJlY3QuICBJbiBjZXJ0YWluIGRlZm9ybWF0aW9ucywgdGhpcyBwcm9i YWJseSBsb29rcyB3cm9uZyBidXQgc2luY2UgaXQgaXMgY29uc2lzdGVudCBmcmFtZSB0byBmcmFt ZSwgaXQgc2VlbXMgYWxyaWdodC4gIFdoZW4gSSB3YXMgd29ya2luZyB3aXRoIGRlZm9ybWFibGUg Y3ViZXMsIEkgdHJpZWQganVzdCBmaW5kaW5nIHRoZSBiZXN0IE9CQiBhbmQgdXNpbmcgdGhhdCBi dXQgaXQgd2Fzbid0IGFsd2F5cyBjb25zaXN0ZW50IGZyYW1lIHRvIGZyYW1lIHBhcnRpY3VsYXJs eSBkdXJpbmcgc2V2ZXJlIGRlZm9ybWF0aW9uLg0KICAgPiAgRm9yIHNvbWV0aGluZyBsaWtlIHRo ZSByYWdkb2xsIHN0dWZmLCB3aGVyZSBkZWZvcm1hdGlvbiBpcyBub3QgZGVzaXJlZCBvciBhbiBp c3N1ZSwgSSB0aGluayB5b3UgbmVlZCB0byB1c2UgdGhlIGhpZXJhcmNoeS4gIFRoZSByZWxhdGlv bnNoaXAgYmV0d2VlbiBlYWNoIGpvaW50IHByb3ZpZGVzIGEgc29saWQgYXhpcyBhbmQgdGhlIGNy b3NzIGJldHdlZW4gY29ubmVjdGVkIGpvaW50cyBwcm92aWRlcyBhbm90aGVyLiAgU28geW91IG9u bHkgcmVhbGx5IG5lZWQgb25lIG1vcmUgcG9pbnQgYXMgYSByZWZlcmVuY2UuICBTb21ldGhpbmcg bGlrZSB0aGUgZWxib3cgaXMgZWFzeSBzaW5jZSB5b3UgbWF5IGJlIHVzaW5nIGFuIGVkZ2Ugb2Yg dGhlIHRldHJhaGVkcm9uIHRvIG1ha2UgYSBoaW5nZSBqb2ludC4gIFNob3VsZGVyIGlzIG1vcmUg YW1iaWd1b3VzLg0KICAgPiAgLUplZmYNCiAgID4gIEF0IDEwOjI4IEFNIDEyLzkvMjAwMiAtMDgw MCwgeW91IHdyb3RlOg0KICAgPiAgPkF0IDEyOjQzIEFNIDEyLzkvMjAwMiAtMDgwMCwgU3RldmUg UmFuY2sgd3JvdGU6DQogICA+ICA+ID5UaGUgIlJpZ2lkIEJvZGllcyIgc2VjdGlvbiBzcGVha3Mg YWJvdXQgdXNpbmcgYSB0ZXRyYWhlZHJvbg0KICAgPiAgPiA+Y29uZmlndXJhdGlvbiBvZiA0IHBh cnRpY2xlcyB3aXRoIGRpc3RhbmNlIGNvbnN0cmFpbnRzIGJldHdlZW4gdGhlbSB0bw0KICAgPiAg PiA+cmVwcmVzZW50IGEgcmlnaWQgYm9keS4gRnJvbSB0aGUgcGFydGljbGUgcG9zaXRpb25zLCBh IG1hdHJpeCBjYW4gYmUNCiAgID4gID4gPmV4dHJhY3RlZCBhbmQgdGhlIGdyYXBoaWNzIGdlbyAo b3Igd2hhdGV2ZXIpIGNhbiBiZSBvcmllbnRlZCBieSB1c2luZw0KICAgPiAgPiA+dGhhdCBtYXRy aXguDQogICA+ICA+DQogICA+ICA+QlRXIGhvdyBhcmUgcGVvcGxlIGV4dHJhY3RpbmcgYSBmcmFt ZSBmcm9tIGEgdGV0cmFoZWRyb24/ICBUaGUNCiAgID4gID5wcm9ibGVtIGlzIG92ZXItY29uc3Ry YWluZWQsIHNpbmNlIHlvdSBvbmx5IG5lZWQgMyBwb2ludHMgdG8gZGVmaW5lDQogICA+ICA+YSBj b29yZGluYXRlIGZyYW1lLg0KICAgPiAgPg0KICAgPiAgPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgID4gID5DaGFybGVzIEJsb29tICAg IGNiQGNibG9vbS5jb20gICAgaHR0cDovL3d3dy5jYmxvb20uY29tDQogICA+ICA+DQogICA+ICA+ DQogICA+ICA+DQogICA+ICA+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KICAgPiAgPlRoaXMgc2YubmV0IGVtYWlsIGlzIHNwb25zb3JlZCBi eTpUaGlua0dlZWsNCiAgID4gID5XZWxjb21lIHRvIGdlZWsgaGVhdmVuLg0KICAgPiAgPmh0dHA6 Ly90aGlua2dlZWsuY29tL3NmDQogICA+ICA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCiAgID4gID5HREFsZ29yaXRobXMtbGlzdCBtYWlsaW5nIGxpc3QN CiAgID4gID5HREFsZ29yaXRobXMtbGlzdEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCiAgID4gID5o dHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9nZGFsZ29yaXRobXMt bGlzdA0KICAgPiAgPkFyY2hpdmVzOg0KICAgPiAgPmh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvbWFp bGFyY2hpdmUvZm9ydW0ucGhwP2ZvcnVtX2lkPTYxODgNCiAgID4gIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgID4gIFRoaXMgc2YubmV0 IGVtYWlsIGlzIHNwb25zb3JlZCBieTpUaGlua0dlZWsNCiAgID4gIFdlbGNvbWUgdG8gZ2VlayBo ZWF2ZW4uDQogICA+ICBodHRwOi8vdGhpbmtnZWVrLmNvbS9zZg0KICAgPiAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgID4gIEdEQWxnb3JpdGhtcy1s aXN0IG1haWxpbmcgbGlzdA0KICAgPiAgR0RBbGdvcml0aG1zLWxpc3RAbGlzdHMuc291cmNlZm9y Z2UubmV0DQogICA+ICBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5m by9nZGFsZ29yaXRobXMtbGlzdA0KICAgPiAgQXJjaGl2ZXM6DQogICA+ICBodHRwOi8vc291cmNl Zm9yZ2UubmV0L21haWxhcmNoaXZlL2ZvcnVtLnBocD9mb3J1bV9pZD02MTg4DQogICAtLS0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tLS0NCgo= 
From: Jeff Lander <jeffl@da...>  20021210 17:14:40

I don't think I have a perfect method for this but I have tried a couple of things. I imbed a frame within the tetrahedron using barycentric coordinates along the directions that make sense for the model. Usually this ends up being along at least one of the edges for clarity sake when modeling. Then it is easy to extract it during simulation. The problem is that when I use this for deformables, you still need to normalize the frame so I just fix it up assuming the up vector is the most correct. In certain deformations, this probably looks wrong but since it is consistent frame to frame, it seems alright. When I was working with deformable cubes, I tried just finding the best OBB and using that but it wasn't always consistent frame to frame particularly during severe deformation. For something like the ragdoll stuff, where deformation is not desired or an issue, I think you need to use the hierarchy. The relationship between each joint provides a solid axis and the cross between connected joints provides another. So you only really need one more point as a reference. Something like the elbow is easy since you may be using an edge of the tetrahedron to make a hinge joint. Shoulder is more ambiguous. Jeff At 10:28 AM 12/9/2002 0800, you wrote: >At 12:43 AM 12/9/2002 0800, Steve Ranck wrote: > >The "Rigid Bodies" section speaks about using a tetrahedron > >configuration of 4 particles with distance constraints between them to > >represent a rigid body. From the particle positions, a matrix can be > >extracted and the graphics geo (or whatever) can be oriented by using > >that matrix. > >BTW how are people extracting a frame from a tetrahedron? The >problem is overconstrained, since you only need 3 points to define >a coordinate frame. > > >Charles Bloom cb@... http://www.cbloom.com > > > > >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Chris Hecker <checker@d6...>  20021210 17:03:09

>the problem isn't over constrained. each particle has 3 degrees of freedom, >but each 'stick' constraint removes one of them. so we have 3 * 4  6 = 6 >degrees of freedom, as required to determine the position and orientation. You start with one 3dof point. You add another, and a length constraint. That gives you 6dof  1dof = 5dof. You can visualize those 5dof by taking the position of the first point, and the spherical coordinates of the other point around it, with r fixed because of the constraint. If you add another 3dof point and two length constraints, you get 6dof. You can visualize this by thinking about the third point, and its only dof is to rotate around the line between the first two. The 4th point is 3dof, but it needs 3 constraints, so it's adding 0dof (in our example, it can't move relative to the other 3 points at all). If you add a 5th point and you want the whole thing to be rigid, you have to add another 3dof, so no more points are going to add any more dof to the system if they're all rigid. Adding a 5th point and adding all possible constraints to it would still add 0dof and not subtract any, because the constraints are linearly dependent. You could do a different linear algebrabased analysis that shows the constraints are linearly dependent after the ones that get you to 6dof. The deeper truth here is that there aren't any other "directions" to move a rigid body in 3D. For 2D it's 3dof. If you want the system to be flexible, then all the tetrahedrons have additional dof related to their deformation. But anyway, Jeff's right, and you can just simulate the finite element system directly if you want volume preserving behavior with some flexibility. Or just do real rigid bodies if you don't. The Jakobsen technique is simply an iterative solver combined with a representation (the particles) that attempts to avoid some of the nonlinearity of 3d rotation (but trade it for nonrigidity). You can use the first half with normal 6dof rigid bodies if you want, or whatever. If you want to use all 4 tetrahedron vertices to compute an orientation, then write down equations for the 3 axis vectors that depend on the 4 points, and the orthogonality constraints, and do a least squares solve. Chris 
From: Jamie Fowlston <jamief@qu...>  20021210 17:00:53

yes, i know. when the penetration point on the stick, tetrahedron, or whatever, is the position of one of the particles, that particle and that particle alone is moved, i.e. if X1 is the penetration point, X1' != X1, but X2' = X2. jamie Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Steve Ranck Sent: 10 December 2002 16:38 To: gdalgorithmslist@... Subject: RE: [Algorithms] Preventing Verlet Rigid Bodies From Going InsideOut > untrue. Jakobsen moves the penetration point of a dynamic > object onto the penetration point of a static object. if the > penetration point on the tetrahedron is the position of one > of the particles, Jakobsen's method moves that particle and > only that particle, and relies on the constraints between the > particles to reestablish the shape of the tetrahedron. I'm referring to the section titled, "Rigid bodies." In this section, Jakobsen computes the new positions of all particles. The first case is a simple stick, where he computes X1' and X2'. Then he goes on to describe how the same technique can be applied to a tetrahedron, X1' through X4'. Steve  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Steve Ranck <sranck@sw...>  20021210 16:38:20

> untrue. Jakobsen moves the penetration point of a dynamic > object onto the penetration point of a static object. if the > penetration point on the tetrahedron is the position of one > of the particles, Jakobsen's method moves that particle and > only that particle, and relies on the constraints between the > particles to reestablish the shape of the tetrahedron. I'm referring to the section titled, "Rigid bodies." In this section, Jakobsen computes the new positions of all particles. The first case is a simple stick, where he computes X1' and X2'. Then he goes on to describe how the same technique can be applied to a tetrahedron, X1' through X4'. Steve 
From: Jamie Fowlston <jamief@qu...>  20021210 16:04:04

Jakobsen suggests you may want to arrange the particles in an axis like manner, thus making the matrix extraction trivial :) Although you get the feeling that's not what he did, at least first time round. jamie Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Steve Ranck Sent: 10 December 2002 08:26 To: gdalgorithmslist@... Subject: [Algorithms] Extracting a Matrix from a Tetrahedron (was: Preventing Verlet Rigid Bodies From Going InsideOut) Hi Charles, This is another great question. I'm currently using only 3 of the points and completely ignoring the 4th. Though I'm getting pretty decent results, I wonder if it's going to bite me under certain circumstances. In fact, the method I use to extract the matrix is even worst. I implemented the most straightforward approach, where the line between the first two vertices is one of my axis, and the other two are derived via cross products. This seems like two of the points would have direct influence over the matrix generation, followed by the 3rd, and ignoring the 4th. The ideal solution would generate a matrix considering all four points. It seems there should be a way to determine the matrix by somehow "averaging" the 3 axis formed by the particles of a right tetrahedron. Or if we measured how far off two axis were (using dot product, for example) from each other and called that the error, maybe we could select a matrix whose 3 axis form a minimum error when summed together. I wonder what Jakobsen did. Steve > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On > Behalf Of Charles Bloom > Sent: Monday, December 09, 2002 10:28 AM > To: gdalgorithmslist@... > Subject: Re: [Algorithms] Preventing Verlet Rigid Bodies From > Going InsideOut > > > > At 12:43 AM 12/9/2002 0800, Steve Ranck wrote: > >The "Rigid Bodies" section speaks about using a tetrahedron > >configuration of 4 particles with distance constraints > between them to > >represent a rigid body. From the particle positions, a matrix can be > >extracted and the graphics geo (or whatever) can be oriented > by using > >that matrix. > > BTW how are people extracting a frame from a tetrahedron? > The problem is overconstrained, since you only need 3 points > to define a coordinate frame. > >  > Charles Bloom cb@... http://www.cbloom.com > > > >  > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithmslist mailing list GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > >  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: David Lam  Tokamak <dlam@to...>  20021210 13:55:13

ICAgPiAgQlRXIGhvdyBhcmUgcGVvcGxlIGV4dHJhY3RpbmcgYSBmcmFtZSBmcm9tIGEgdGV0cmFo ZWRyb24/ICBUaGUNCiAgID4gIHByb2JsZW0gaXMgb3Zlci1jb25zdHJhaW5lZCwgc2luY2UgeW91 IG9ubHkgbmVlZCAzIHBvaW50cyB0byBkZWZpbmUNCiAgID4gIGEgY29vcmRpbmF0ZSBmcmFtZS4N Cg0KSXQncyBub3Qgb3Zlci1jb25zdHJhaW5lZCAoSSB0aGluaykgaW4gdGhlIHNlbnNlIHRoYXQg eW91IG5lZWQgdGhlIGZvdXJ0aCBwb2ludCB0byANCmRldGVybWluZSB3aGljaCBzaWRlIG9mIHRo ZSB0cmlhbmdsZSB0aGUgdGV0cmFoZWRyb24gbGllLiBJZiB5b3UgYWx3YXlzIGFzc3VtZQ0KdGhl IHNhbWUgd2luZGluZyBvcmRlciBvZiB0aGUgMyBwb2ludHMgKHNheSBjY3cgd2hlbiBsb29raW5n IGZyb20gb3V0c2lkZSB0aGUgDQp0ZXRyYWhlZHJvbiksIHRoZW4gdGhlIGZvdXJ0aCBwb2ludCBp cyByZWR1bmRhbnQuIEJ1dCBpbiBvdXIgY2FzZSB3ZSBkb250IHJlYWxseSANCmhhdmUgYSB0ZXRy YXRoZWRyb24sIGp1c3QgNCBwb2ludHMgaW4gc3BhY2UgY29uc3RyYWluIGJ1dCB0aGUgZGlzdGFu Y2UgYmV0d2VlbiANCmVhY2ggb3RoZXIuDQoNCldoZW4gdHJ5aW5nIHRvIGV4dHJhY3QgYSBtYXRy aXggb3V0IG9mIHRoZSA0IHBvaW50cywgSSBtdXN0IHNheSB0aGF0J3MgYSBiaXQgZGlmZmljdWx0 Lg0KVGhlIHByb2JsZW0gaXMgeW91ciB2b2x1bWUgaXMgbm90IGNvbXBsZXRlbHkgcmlnaWQgYmV0 d2VlbiB1cGRhdGVzLiBUaGUgb25seSB0aGluZw0KSSBjYW4gdGhpbmsgb2YgaXMgdG8gZmluZCB0 aGUgJ2F2ZXJhZ2UnIG9yaWVudGF0aW9uIG9mIGRlcml2ZSBmcm9tIDMgZGlmZmVyZW50IHNldHMg b2YgMyANCnBvaW50cy4NCg0KQnV0IHdoZW4geW91IGFyZSBkb2luZyB0aGlzIHRvIG1ha2UgdGhl IFZlcmxldCBzY2hlbWUgd29yaywgYWxvbmcgd2l0aCBhbGwgb3RoZXINCnR3ZWFrcywgSSBtdXN0 IGFzayB0aGF0IChhdCB0aGUgcmlzayBvZiBiZWluZyBidXJuIGF0IHRoZSBzdGFrZSksIGFyZSB5 b3UgZG9pbmcgDQptb3JlIHdvcmsgKGxhYm91ciB3aXNlLCBhcyB3ZWxsIGFzIENQVSB3aXNlKSB0 aGFuIHlvdSBvdGhlcndpc2Ugd291bGQgaGF2ZSBpZiANCnlvdSBkbyB0cmFkaXRpb25hbCBtdWx0 aS1yaWdpZGJvZHkgc2ltdWxhdGlvbi4NCg0KRGF2aWQgTGFtDQoNCnd3dy50b2thbWFrcGh5c2lj cy5jb20NCg0KDQoNCiAgIC0tLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0tLQ0KICAgPiBGcm9t OiBjYmxvb21AY2Jsb29tLmNvbSANCiAgID4gU3ViamVjdDogUmU6IFtBbGdvcml0aG1zXSBQcmV2 ZW50aW5nIFZlcmxldCBSaWdpZCBCb2RpZXMgRnJvbSBHb2luZyAgSW5zaWRlLU91dA0KICAgPiBT ZW50OiAwOSBEZWMgMjAwMiAgMTg6Mjg6MTUNCiAgID4gIEF0IDEyOjQzIEFNIDEyLzkvMjAwMiAt MDgwMCwgU3RldmUgUmFuY2sgd3JvdGU6DQogICA+ICA+VGhlICJSaWdpZCBCb2RpZXMiIHNlY3Rp b24gc3BlYWtzIGFib3V0IHVzaW5nIGEgdGV0cmFoZWRyb24NCiAgID4gID5jb25maWd1cmF0aW9u IG9mIDQgcGFydGljbGVzIHdpdGggZGlzdGFuY2UgY29uc3RyYWludHMgYmV0d2VlbiB0aGVtIHRv DQogICA+ICA+cmVwcmVzZW50IGEgcmlnaWQgYm9keS4gRnJvbSB0aGUgcGFydGljbGUgcG9zaXRp b25zLCBhIG1hdHJpeCBjYW4gYmUNCiAgID4gID5leHRyYWN0ZWQgYW5kIHRoZSBncmFwaGljcyBn ZW8gKG9yIHdoYXRldmVyKSBjYW4gYmUgb3JpZW50ZWQgYnkgdXNpbmcNCiAgID4gID50aGF0IG1h dHJpeC4NCiAgID4gIEJUVyBob3cgYXJlIHBlb3BsZSBleHRyYWN0aW5nIGEgZnJhbWUgZnJvbSBh IHRldHJhaGVkcm9uPyAgVGhlDQogICA+ICBwcm9ibGVtIGlzIG92ZXItY29uc3RyYWluZWQsIHNp bmNlIHlvdSBvbmx5IG5lZWQgMyBwb2ludHMgdG8gZGVmaW5lDQogICA+ICBhIGNvb3JkaW5hdGUg ZnJhbWUuDQogICA+ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQogICA+ICBDaGFybGVzIEJsb29tICAgIGNiQGNibG9vbS5jb20gICAgaHR0 cDovL3d3dy5jYmxvb20uY29tDQogICA+ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICA+ICBUaGlzIHNmLm5ldCBlbWFpbCBpcyBzcG9u c29yZWQgYnk6VGhpbmtHZWVrDQogICA+ICBXZWxjb21lIHRvIGdlZWsgaGVhdmVuLg0KICAgPiAg aHR0cDovL3RoaW5rZ2Vlay5jb20vc2YNCiAgID4gIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQogICA+ICBHREFsZ29yaXRobXMtbGlzdCBtYWlsaW5nIGxp c3QNCiAgID4gIEdEQWxnb3JpdGhtcy1saXN0QGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KICAgPiAg aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vZ2RhbGdvcml0aG1z LWxpc3QNCiAgID4gIEFyY2hpdmVzOg0KICAgPiAgaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9tYWls YXJjaGl2ZS9mb3J1bS5waHA/Zm9ydW1faWQ9NjE4OA0KICAgLS0tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLS0tDQoK 
From: Martin Piper <MartinP@ar...>  20021210 13:26:41

Virtua Fighter 3 (did you mean VF3?) is an example where this type of = code is right 99% of the time but the last little bit is not. While playing, = for countless hours, I've noticed feet slide around, legs popping in to = very unusual poses, feet intersecting geometry and the worst of all where = the feet rapidly cycle between two different states. But you only really notice this when you stand still trying to make it happen and if you did this while playing properly you would get beaten rather quickly. ;) Original Message From: Awen Limbourg [mailto:alimbourg@...] Sent: 10 December 2002 13:05 To: gdalgorithmslist@... Subject: RE: [Algorithms] Skeletal animation blending artefacts >where the spider foot occasionally penetrating the floor would = compromise everything? It may be an absolute game (design) constraint: look at virtua fighter = and notice the legs of your fighter standing on stairs. With realistic = gigantic characters (not a 16 pixels wide screen coverage) player is going to = notice (and not forgive) the scenery hollowness :) We are just writing that some 'IK' are possible. Not telling that's required. But it could be if your spiders are 10 feet tall, and your game camera misplaced. Awen PS: We are just, at the studio, at the beginning of a new project, and speaking a lot about technicalbearings: i noticed a strange behaviour = that is to renounce to some technical POSSIBILITIES supposing there were previously badly misused and implemented (so when a technic is = presumingly good (because of MY experience and because i read YOU day after day), i = have to fight first the radical objectors to have the right to expose a single/simple feasibility to resolve our problem... Message d'origine De : gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]De la part de = Nick Pelling Envoy=E9 : mardi 10 d=E9cembre 2002 12:05 =C0 : 'gdalgorithmslist@...' Objet : RE: [Algorithms] Skeletal animation blending artefacts I'm not knocking IK, it's just that I've only ever had anything = approaching a problem with quat interpolation in about 0.001% of cases, and then = only fleetingly. These are for computer games, right? That giant spider isn't being used = for a military AlQaedagiantspiderinvasionofAmerica simulation, where = the spider foot occasionally penetrating the floor would compromise = everything? Sure, piledrivers are great too: but I prefer nutcrackers when trying = to stay within budget etc. And for eating nuts, of course. :) Cheers, .....Nick Pelling..... Original Message From: Jon Watte [mailto:hplus@...] Sent: 09 December 2002 22:10 To: gdalgorithmslist@... Subject: RE: [Algorithms] Skeletal animation blending artefacts > To stop a stupid spider's stupid feet very occasionally > penetrating into the > floor, you could just clip the height of any transformed vertices > so that it > never goes below the level of the floor. That will look almost exactly like penetration. I think the easiest thing to do is to offset the spider upwards so it's not penetrating. The second easiest, and I believe by far the bestlooking, would be an IK solver on each leg to put the feet on the floor. Note that this is NOT a "genericcoffee_maker" IK solution, with all those problems; this is a specific, constrained IK solution which can be made to look good with finite effort. > Of course, if you've been looking for an flimsy excuse to do IK > for a while, > then go for it. :) If you can reuse that IK for all your animated characters, and finally get rid of that horrible foot sliding, then you have done all your players a great service. Or perhaps I'm just ultra sensitive to this problem.  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Awen Limbourg <alimbourg@ed...>  20021210 13:06:26

>where the spider foot occasionally penetrating the floor would compromise everything? It may be an absolute game (design) constraint: look at virtua fighter and notice the legs of your fighter standing on stairs. With realistic gigantic characters (not a 16 pixels wide screen coverage) player is going to notice (and not forgive) the scenery hollowness :) We are just writing that some 'IK' are possible. Not telling that's required. But it could be if your spiders are 10 feet tall, and your game camera misplaced. Awen PS: We are just, at the studio, at the beginning of a new project, and speaking a lot about technicalbearings: i noticed a strange behaviour that is to renounce to some technical POSSIBILITIES supposing there were previously badly misused and implemented (so when a technic is presumingly good (because of MY experience and because i read YOU day after day), i have to fight first the radical objectors to have the right to expose a single/simple feasibility to resolve our problem... Message d'origine De : gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]De la part de Nick Pelling Envoyé : mardi 10 décembre 2002 12:05 À : 'gdalgorithmslist@...' Objet : RE: [Algorithms] Skeletal animation blending artefacts I'm not knocking IK, it's just that I've only ever had anything approaching a problem with quat interpolation in about 0.001% of cases, and then only fleetingly. These are for computer games, right? That giant spider isn't being used for a military AlQaedagiantspiderinvasionofAmerica simulation, where the spider foot occasionally penetrating the floor would compromise everything? Sure, piledrivers are great too: but I prefer nutcrackers when trying to stay within budget etc. And for eating nuts, of course. :) Cheers, .....Nick Pelling..... Original Message From: Jon Watte [mailto:hplus@...] Sent: 09 December 2002 22:10 To: gdalgorithmslist@... Subject: RE: [Algorithms] Skeletal animation blending artefacts > To stop a stupid spider's stupid feet very occasionally > penetrating into the > floor, you could just clip the height of any transformed vertices > so that it > never goes below the level of the floor. That will look almost exactly like penetration. I think the easiest thing to do is to offset the spider upwards so it's not penetrating. The second easiest, and I believe by far the bestlooking, would be an IK solver on each leg to put the feet on the floor. Note that this is NOT a "genericcoffee_maker" IK solution, with all those problems; this is a specific, constrained IK solution which can be made to look good with finite effort. > Of course, if you've been looking for an flimsy excuse to do IK > for a while, > then go for it. :) If you can reuse that IK for all your animated characters, and finally get rid of that horrible foot sliding, then you have done all your players a great service. Or perhaps I'm just ultra sensitive to this problem.  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Jamie Fowlston <jamief@qu...>  20021210 11:55:09

the problem isn't over constrained. each particle has 3 degrees of freedom, but each 'stick' constraint removes one of them. so we have 3 * 4  6 = 6 degrees of freedom, as required to determine the position and orientation. jakobsen covers this in the paper. jamie Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Charles Bloom Sent: 09 December 2002 18:28 To: gdalgorithmslist@... Subject: Re: [Algorithms] Preventing Verlet Rigid Bodies From Going InsideOut At 12:43 AM 12/9/2002 0800, Steve Ranck wrote: >The "Rigid Bodies" section speaks about using a tetrahedron >configuration of 4 particles with distance constraints between them to >represent a rigid body. From the particle positions, a matrix can be >extracted and the graphics geo (or whatever) can be oriented by using >that matrix. BTW how are people extracting a frame from a tetrahedron? The problem is overconstrained, since you only need 3 points to define a coordinate frame.  Charles Bloom cb@... http://www.cbloom.com  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Jamie Fowlston <jamief@qu...>  20021210 11:51:06

<snip> his method determines how much to move each of the 4 vertices such that one of the points ends up equal to the other. I believe this retains the shape of the tetrahedron. </snip> untrue. Jakobsen moves the penetration point of a dynamic object onto the penetration point of a static object. if the penetration point on the tetrahedron is the position of one of the particles, Jakobsen's method moves that particle and only that particle, and relies on the constraints between the particles to reestablish the shape of the tetrahedron. <snip> The idea of a single calculation that combines both the shape and volume </snip> note that Jakobsen's paper shows how to implement a 'stick' constraint which returns the stick to its original shape. there's no reason i can see that the method couldn't be extended to handle triangle and tetrahedron constraints which would handle multiple particles simultaneously (Jakobsen's paper relies on iterating over multiple stick constraints to return a triangle or tetrahedron to its original shape). the calculations wouldn't be quite as simple as those for a stick constraint, of course :) jamie Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Steve Ranck Sent: 10 December 2002 08:06 To: gdalgorithmslist@... Subject: RE: [Algorithms] Preventing Verlet Rigid Bodies From Going InsideOut Hi Jeff, > In the case of doing something like the > Jakobsenstyle integration, you use this > calculation to determine where the nodes > should be moved to directly instead of > applying forces. But it works the same. Is this similar to how Jakobsen applies collision response to the tetrahedron? Given the two points of contact (one on each body), his method determines how much to move each of the 4 vertices such that one of the points ends up equal to the other. I believe this retains the shape of the tetrahedron. Couldn't a force be modeled similarly by substituting the two points with the point of impact and the force vector? > The amount of calculations are Are what? Don't leave us hanging! :) > The two pieces are then a shape function > to maintain the "shape" of the tetrahedron > and a volume preservation term. These can > be combined into a single calculation that > determines the force on each node. The idea of a single calculation that combines both the shape and volume preservations sounds like it would be very robust. Is there something I can read online? Thanks, Steve  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Nick Pelling <NPelling@cl...>  20021210 11:04:21

I'm not knocking IK, it's just that I've only ever had anything approaching a problem with quat interpolation in about 0.001% of cases, and then only fleetingly. These are for computer games, right? That giant spider isn't being used for a military AlQaedagiantspiderinvasionofAmerica simulation, where the spider foot occasionally penetrating the floor would compromise everything? Sure, piledrivers are great too: but I prefer nutcrackers when trying to stay within budget etc. And for eating nuts, of course. :) Cheers, .....Nick Pelling..... Original Message From: Jon Watte [mailto:hplus@...] Sent: 09 December 2002 22:10 To: gdalgorithmslist@... Subject: RE: [Algorithms] Skeletal animation blending artefacts > To stop a stupid spider's stupid feet very occasionally > penetrating into the > floor, you could just clip the height of any transformed vertices > so that it > never goes below the level of the floor. That will look almost exactly like penetration. I think the easiest thing to do is to offset the spider upwards so it's not penetrating. The second easiest, and I believe by far the bestlooking, would be an IK solver on each leg to put the feet on the floor. Note that this is NOT a "genericcoffee_maker" IK solution, with all those problems; this is a specific, constrained IK solution which can be made to look good with finite effort. > Of course, if you've been looking for an flimsy excuse to do IK > for a while, > then go for it. :) If you can reuse that IK for all your animated characters, and finally get rid of that horrible foot sliding, then you have done all your players a great service. Or perhaps I'm just ultra sensitive to this problem. 
From: Steve Ranck <sranck@sw...>  20021210 08:25:55

Hi Charles, This is another great question. I'm currently using only 3 of the points and completely ignoring the 4th. Though I'm getting pretty decent results, I wonder if it's going to bite me under certain circumstances. In fact, the method I use to extract the matrix is even worst. I implemented the most straightforward approach, where the line between the first two vertices is one of my axis, and the other two are derived via cross products. This seems like two of the points would have direct influence over the matrix generation, followed by the 3rd, and ignoring the 4th. The ideal solution would generate a matrix considering all four points. It seems there should be a way to determine the matrix by somehow "averaging" the 3 axis formed by the particles of a right tetrahedron. Or if we measured how far off two axis were (using dot product, for example) from each other and called that the error, maybe we could select a matrix whose 3 axis form a minimum error when summed together. I wonder what Jakobsen did. Steve > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On > Behalf Of Charles Bloom > Sent: Monday, December 09, 2002 10:28 AM > To: gdalgorithmslist@... > Subject: Re: [Algorithms] Preventing Verlet Rigid Bodies From > Going InsideOut > > > > At 12:43 AM 12/9/2002 0800, Steve Ranck wrote: > >The "Rigid Bodies" section speaks about using a tetrahedron > >configuration of 4 particles with distance constraints > between them to > >represent a rigid body. From the particle positions, a matrix can be > >extracted and the graphics geo (or whatever) can be oriented > by using > >that matrix. > > BTW how are people extracting a frame from a tetrahedron? > The problem is overconstrained, since you only need 3 points > to define a coordinate frame. > >  > Charles Bloom cb@... http://www.cbloom.com > > > >  > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithmslist mailing list GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > 
From: Steve Ranck <sranck@sw...>  20021210 08:06:11

Hi Jeff, > In the case of doing something like the > Jakobsenstyle integration, you use this > calculation to determine where the nodes > should be moved to directly instead of > applying forces. But it works the same. Is this similar to how Jakobsen applies collision response to the tetrahedron? Given the two points of contact (one on each body), his method determines how much to move each of the 4 vertices such that one of the points ends up equal to the other. I believe this retains the shape of the tetrahedron. Couldn't a force be modeled similarly by substituting the two points with the point of impact and the force vector? > The amount of calculations are Are what? Don't leave us hanging! :) > The two pieces are then a shape function > to maintain the "shape" of the tetrahedron > and a volume preservation term. These can > be combined into a single calculation that > determines the force on each node. The idea of a single calculation that combines both the shape and volume preservations sounds like it would be very robust. Is there something I can read online? Thanks, Steve 