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}

2017 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1
(6) 
2
(19) 
3
(38) 
4
(42) 
5
(13) 
6
(6) 
7
(21) 
8
(59) 
9
(47) 
10
(21) 
11
(22) 
12
(33) 
13
(4) 
14
(14) 
15
(13) 
16
(41) 
17
(27) 
18
(14) 
19
(30) 
20
(6) 
21
(3) 
22
(22) 
23
(2) 
24
(56) 
25
(48) 
26
(31) 
27
(11) 
28

29
(14) 
30
(6) 
31
(11) 



From: Jim Offerman <j.offerman@in...>  20010110 23:10:28

I've always wondered, would my high school physics equations suffice to implement some simple dynamics simulation. I.e.: linear acceleration: a = F / m (from F = m * a) linear velocity: v = v(0) + a * t position: x = x(0) + v(0) * t + 0.5 * a * t ^ 2 angular acceleration: alpha = T / I angular velocity: omega = omega(0) + alpha * t rotation: sigma = sigma(0) + omega(0) * t + 0.5 * alpha * t ^ 2 Where m = mass; F = total force acting on the body; T = total torque acting on the body; I = Moment of Inertia; t = time. All quantities, except for m and t are vectors having components <x,y,z>. * = component wise product (and _not_ the dot product). I'm fairly sure the linear case produces quite satisfying behaviour, from some tests I've run with those. Never tested the angular stuff though, since I never took the time to find a good way to calculate (or at least approximate) I. Jim Offerman Innovade.  Original Message  From: "Tom Forsyth" <tomf@...> To: <gdalgorithmslist@...> Sent: Wednesday, January 10, 2001 2:11 PM Subject: RE: [Algorithms] Forces causing rotations on rigid bodies > You need the concept of rotations as vectors  the vector defines the axis > of rotation, and the length is the amount of rotation. Sort of like > quaternions without a "w" value. > > Once you have vector rotations, then differentiate once to get angular > velocities (multiply by moment of inertia round that axis to get angular > momentum), and again to get angular accelleration (multiply by MOI to get > torques). > > So find the centre of mass of your object, find the MOI around each of the > main axis (X,Y,Z). Then you can find the MOI around any arbitrary axis > (er... I think  might be wrong here  I might have approximated the MOI > calculation here  long time since I actually coded this gubbins). > > >From there, you can find the torque that a particular force exerts  the > direction is perpedicular to the plane through the line the force acts along > and the center of mass of the object. And the magnitude is the force times > the perpendicular distance to the center of mass. > > You can sum torques and anugular momenta just like forces and velocities, > and it all just works. Hoorah! > > Sadly, no dynamics books ever seem to deal with this stuff  they stick to > 2D cases of rotational dynamics only, even though the 3D cases is (a) useful > and (b) easy, once the principles are laid down. So I had to derive most of > it from scratch. > > Sombody please tell me if I'm barking up the wrong tree, but in the tests > I've done it all looks physically plausable and suchlike :) > > > Tom Forsyth  purely hypothetical Muckyfoot bloke. > > This email is the product of your deranged imagination, > and does not in any way imply existence of the author. > > > > > Original Message > > From: Doug Chism [mailto:dchism@...] > > Sent: 10 January 2001 02:05 > > To: gdalgorithmslist@... > > Subject: [Algorithms] Forces causing rotations on rigid bodies > > > > > > I need some help summing rotational force components on rigid > > bodies. I > > guess the problem is how do I find a common axis or method to > > add effects > > from multiple forces. Decomposing dosent seem to be a correct > > solution by > > itself because it needs some sort of sign  i.e. a downward > > force on one > > side of the rigid body should cancel out one on the opposite > > side if its the > > same distance from the center of mass. That wont happen if > > you decompose the > > rotational forces by itself  they will add. > > Ive been experimenting using a dot and cross product to > > make a unique > > axis of rotation and rotation matrix for each force and then > > multiplying the > > rotation matricies to form a cumulative rotation matrix > > representing the sum > > of all the individual rotations but that made the object in > > question spin > > like a top. The problem with that seems to be how do I get > > from a rotational > > force to a rotational amout. The motion of the object just > > acccumulates the > > velocity and position vectors but thats not valid for the > > rotational forces > > since they could change location with respect to the center > > of mass. If I > > could somehow decompose the rotational forces I think I could > > accumulate the > > rotational velocity and positions but like I said before  > > that ends up > > losing the effect of the lever arms orientation. I was > > thinking I could sum > > them by comparing their orientation to some known vector ( > > like a forward > > vector ) and then decompose  havent tried that one yet. Am I > > on the right > > path or what? Wish I kept my Dynamics book from college, but > > dont know if it > > would help really since I never turned dynamics into code. > > Can anyone give > > me a brief gameplan to follow for this? > > > > Doug Chism > > > > > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > 
From: Brian Sharon <bsharon@sa...>  20010110 22:11:16

It's a fairly substantial leap from the freshman level to Goldstein. I had a couple of undergraduate mechanics courses that also used the following books, someone might find other resources helpful: An Introduction To Mechanics, Kleppner/Kolenkow. used in the 2nd year of college. Could fill in some gaps for a newbie. Mechanics, Symon. used in the 4th year of college. I seem to have lost this book along the way but I remember liking it quite well when I took the course. Not on the level of Goldstein, but not far off. In addition, the Feynman Lectures volume 1 has some material on rigid body dynamics (chapter 20). brian Original Message From: Ron Levine [mailto:ron@...] Sent: Wednesday, January 10, 2001 12:33 PM To: gdalgorithmslist@... Subject: Re: [Algorithms] Forces causing rotations on rigid bodies Nonsense, you just have to look in a sufficiently advanced dynamics book, anything beyond the freshman level (which may not mean anything to you Brits). Goldstein's "Classical Mechanics" is a good one, actually a graduate level dynamics book. 
From: PeterPike Sloan <ppsloan@mi...>  20010110 20:45:22

Hi, I have to second Charles recommendation  I'm one of the authors in the interactive technical illustration paper (in particular I implemented the silhouette stuff in that paper) and pedros method is *much* better for the perspective case. He's actually improved it, there will be a paper at I3D this year that talks about it  you don't need all of the edges in the data structure, only the ones that could be silhouettes... PeterPike Sloan (Of course for nonstatic geometry things change  it's not clear if any of the preproccesing that's neccesary would be better then brute force...) Original Message From: Charles Bloom [mailto:cbloom@...] Sent: Wednesday, January 10, 2001 9:12 AM To: gdalgorithmslist@... Subject: Re: [Algorithms] Silhouettes in dual space Hye Pierre, have you read Hoppe et al's paper on Silhouette clipping? Their algorithm is as good as it gets, except for implementation details. In particular, they address the option of using the "backfacing" technique that you propose, and find that it's competetive with their technique, but requires about 2x as many edge tests in the end. Their algorithm is O(m log(n)) in the number of edges (m) in the Silhouette, where (n) is the total number of edges, so log(n) is the expected depth of the tree. Note that m is O(sqrt(n)) in the total number of edges n. At 11:28 AM 1/10/2001 +0100, you wrote: >>Could you explain this statement please? If you have found the Silhouette, >>surely finding the shadow volume is trivial? > >This has to do with screen perspective. > >To find the edges of a shadow volume you compute something like: > > Normal  Source >= 0 > >(Normal = face normal, Source = light pos,  = dot product) > >To find the edges of a silhouette you perform standard backface culling and >take the perspective into account: > > Normal  (Source  Base)) >= 0 > >(Source = camera pos, Base = any vertex on the face) > >Hoppe reports computing the second one is harder (cf silhouette clipping), >but that's exactly what the paper I mentioned does (and in O(log n), further >improved by temporal coherence). > >This is highly related to backface culling, and it's not surprising to find >traces of the dual space in other papers such as Kumar & Manocha's >"Hierarchical Backface Culling". Unfortunately the way to get rid of the >"point at infinity problem" is unclear to me. > >By the way, I also found a cool method using Hoff's normal masks: >1) Compute your standard normal masks >2) Group your polygons according to the normal cluster ID >3) Perform your conservative backface culling in O(1). This gives >potentially visible clusters. >4) Invert the viewing direction and perform it again. This gives potentially >visible clusters from the back of the object, still in O(1). >5) Since the culling is conservative, you can expect the silhouette edges to >be in the clusters common to 3) and 4). Those are what I would call the >"silhouette clusters". >6) Now you can search for silhouette edges in a standard way, but only >taking the silhouette clusters into account. > >Alternatively, the silhouette clusters may be used in VDPM to quickly locate >regions of interest. > > >Disclaimer: all of this is theoretical and completely untested.... what do >you think ? > > > >Pierre Terdiman * Home: p.terdiman@... >Coder in the dark * Zappy's Lair: http://www.codercorner.com > > > > > > > > > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > >  Charles Bloom cb@... http://www.cbloom.com _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist 
From: Pierre Terdiman <p.terdiman@wa...>  20010110 20:29:49

> In particular, they address the option of using the "backfacing" > technique that you propose, and find that it's competetive > with their technique, but requires about 2x as many edge tests > in the end. Actually you're right, the method already exists! Damn! But I had to follow their references and search for "Interactive Technical Illustration" in order to find it. > Their algorithm is O(m log(n)) in the number of edges (m) in the Silhouette, > where (n) is the total number of edges, so log(n) is the expected depth > of the tree. Note that m is O(sqrt(n)) in the total number of edges n. All in all, their way seems complex (I'm not sure to fully understand it), whereas the dual space approach is trivial. Moreover, and to tell the truth, the interesting thing here (as far as I am concerned) is more to learn about the dual space and how one could handle it, than to find some silhouette edges we already have anyway. A book sure may help (e.g. Preparata & Samos) but a practical and simple application is way better, of course. Now, to get back on topic, there's something I don't get. Using the dual space, finding silhouette edges seems to be O(log(n)) only, with n = total number of edges. So why would they use something apparently slower ? (unless I'm missing something) (which is probable :) Quid ? P. 
From: Tom Forsyth <tomf@mu...>  20010110 19:35:27

> From: Ron Levine [mailto:ron@...] > > > So find the centre of mass of your object, find the MOI > around each of the > > main axis (X,Y,Z). Then you can find the MOI around any > arbitrary axis > > (er... I think  might be wrong here  I might have > approximated the MOI > > calculation here  long time since I actually coded this gubbins). > > > > It's a little more complicated in that the total MOI is > actually what is > called a 2nd rank tensor, which has a representation as a matrix. After posting I saw someone else's mail mention using a tensor for this, and my brain went DOH! Of course it's a tensor  that makes far more sense than the approximation I used. > > >From there, you can find the torque that a particular > force exerts  the > > direction is perpedicular to the plane through the line the > force acts > along > > and the center of mass of the object. > > But this does not define a plane. More precisely, it is the > plane through > the point of application of the force and spanned by the > force vector and > the vector from the center of mass to the point of application of the > forceTHAT defines a plane. Sorry, that's what I meant. English bad  need diagrams. :) > >And the magnitude is the force times > > the perpendicular distance to the center of mass. > > Specifically, the torque = r cross F, where r is the vector > from the center > of mass to the point of application of the force, and F is > the force vector. > Neat, huh? Er... ah! Yes, it does all work out, excellent. > > You can sum torques and anugular momenta just like forces > and velocities, > > and it all just works. Hoorah! > > Hear, hear. > > > Sadly, no dynamics books ever seem to deal with this stuff >  they stick to > > 2D cases of rotational dynamics only, ... > > Nonsense, you just have to look in a sufficiently advanced > dynamics book, > anything beyond the freshman level (which may not mean anything to you > Brits). Years of American sitcoms have tutored us in the terminology. :) The problem being that for us lowly hackers, freshman physics books are filled to the brim of incomprehensible symbols(*) that actually convey very simple and powerful ideas. And I speak as one who did freshman physics (but had an excellent lecturer). The language is completely different. For example, how many coders know what a "tensor" is? Answer  lots, and they use them every day  they just don't know what the word "tensor" means. > Goldstein's "Classical Mechanics" is a good one, actually a > graduate level > dynamics book. Thanks  I might look it up. Tom Forsyth  purely hypothetical Muckyfoot bloke. This email is the product of your deranged imagination, and does not in any way imply existence of the author. (*) By "incomprehensible" I mean "defined in freshman maths books". Which is no good for the coder who hasn't quite got the time to do a degree in maths _and_ physics _and_ finish a game this decade. 
From: Angel Popov <jumpo@bi...>  20010110 18:57:44

>One thing that crossed my mind was to use the standard BSP technique to >generate convex sectors, and then to do a second pass through the map that >merges these sectors into larger ones. Sort of like triangle stripping, >except here it stops after it reaches a certain length :) >Could this approach work, or am I missing some important obstacles? Does >anyone have any other ideas about how this could be achieved? I've done that and the results are very satisfying: The merge algho that I use is this: Take all polygons from the two candiate cells, then form a convex hull from their planes by displacing plane.D ( find the distance of the farthest vertex from the plane and subtract it from Plane.D ), then contract that hull ( by adding some constant value to Plane.D ) and compute the area of the polygons inside the contracted hull. If that area is below some threshold value  the cells can be merged. I seperate my brushes into construction and detail and build the BSP only from the construction ones. When building the BSP I first pick planes that have the highest summed area of the polys that lie on them and generate the least number of splits. You have to avoid merges that break a potentialy good portal. This is a bit hard to explain, but I'll try  I group all adjacent portals that lie on the same plane, find the contour of these portals and give each contour a score  depending on whether that contour is convex, how many edges from the contour lie on a wall and how many are "in the air" and whether there are any polygons adjacent to the contour that have the same plane (as the contour). You can break such contour by merging two cells located at the both sides. So merges that affect highscore contours are performed last. You can download my level editor to see how well it works: http://thegeleto.tripod.com/editor.zip (2.6MB) Here's a screenshot: http://thegeleto.tripod.com/editor.jpg 
From: Ron Levine <ron@do...>  20010110 18:34:50

> > So find the centre of mass of your object, find the MOI around each of the > main axis (X,Y,Z). Then you can find the MOI around any arbitrary axis > (er... I think  might be wrong here  I might have approximated the MOI > calculation here  long time since I actually coded this gubbins). > It's a little more complicated in that the total MOI is actually what is called a 2nd rank tensor, which has a representation as a matrix. > >From there, you can find the torque that a particular force exerts  the > direction is perpedicular to the plane through the line the force acts along > and the center of mass of the object. But this does not define a plane. More precisely, it is the plane through the point of application of the force and spanned by the force vector and the vector from the center of mass to the point of application of the forceTHAT defines a plane. >And the magnitude is the force times > the perpendicular distance to the center of mass. > Specifically, the torque = r cross F, where r is the vector from the center of mass to the point of application of the force, and F is the force vector. Neat, huh? > You can sum torques and anugular momenta just like forces and velocities, > and it all just works. Hoorah! > Hear, hear. > Sadly, no dynamics books ever seem to deal with this stuff  they stick to > 2D cases of rotational dynamics only, ... Nonsense, you just have to look in a sufficiently advanced dynamics book, anything beyond the freshman level (which may not mean anything to you Brits). Goldstein's "Classical Mechanics" is a good one, actually a graduate level dynamics book. 
From: Charles Bloom <cbloom@cb...>  20010110 17:11:45

Hye Pierre, have you read Hoppe et al's paper on Silhouette clipping? Their algorithm is as good as it gets, except for implementation details. In particular, they address the option of using the "backfacing" technique that you propose, and find that it's competetive with their technique, but requires about 2x as many edge tests in the end. Their algorithm is O(m log(n)) in the number of edges (m) in the Silhouette, where (n) is the total number of edges, so log(n) is the expected depth of the tree. Note that m is O(sqrt(n)) in the total number of edges n. At 11:28 AM 1/10/2001 +0100, you wrote: >>Could you explain this statement please? If you have found the Silhouette, >>surely finding the shadow volume is trivial? > >This has to do with screen perspective. > >To find the edges of a shadow volume you compute something like: > > Normal  Source >= 0 > >(Normal = face normal, Source = light pos,  = dot product) > >To find the edges of a silhouette you perform standard backface culling and >take the perspective into account: > > Normal  (Source  Base)) >= 0 > >(Source = camera pos, Base = any vertex on the face) > >Hoppe reports computing the second one is harder (cf silhouette clipping), >but that's exactly what the paper I mentioned does (and in O(log n), further >improved by temporal coherence). > >This is highly related to backface culling, and it's not surprising to find >traces of the dual space in other papers such as Kumar & Manocha's >"Hierarchical Backface Culling". Unfortunately the way to get rid of the >"point at infinity problem" is unclear to me. > >By the way, I also found a cool method using Hoff's normal masks: >1) Compute your standard normal masks >2) Group your polygons according to the normal cluster ID >3) Perform your conservative backface culling in O(1). This gives >potentially visible clusters. >4) Invert the viewing direction and perform it again. This gives potentially >visible clusters from the back of the object, still in O(1). >5) Since the culling is conservative, you can expect the silhouette edges to >be in the clusters common to 3) and 4). Those are what I would call the >"silhouette clusters". >6) Now you can search for silhouette edges in a standard way, but only >taking the silhouette clusters into account. > >Alternatively, the silhouette clusters may be used in VDPM to quickly locate >regions of interest. > > >Disclaimer: all of this is theoretical and completely untested.... what do >you think ? > > > >Pierre Terdiman * Home: p.terdiman@... >Coder in the dark * Zappy's Lair: http://www.codercorner.com > > > > > > > > > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > >  Charles Bloom cb@... http://www.cbloom.com 
From: Tom Forsyth <tomf@mu...>  20010110 13:11:53

You need the concept of rotations as vectors  the vector defines the axis of rotation, and the length is the amount of rotation. Sort of like quaternions without a "w" value. Once you have vector rotations, then differentiate once to get angular velocities (multiply by moment of inertia round that axis to get angular momentum), and again to get angular accelleration (multiply by MOI to get torques). So find the centre of mass of your object, find the MOI around each of the main axis (X,Y,Z). Then you can find the MOI around any arbitrary axis (er... I think  might be wrong here  I might have approximated the MOI calculation here  long time since I actually coded this gubbins). From there, you can find the torque that a particular force exerts  the direction is perpedicular to the plane through the line the force acts along and the center of mass of the object. And the magnitude is the force times the perpendicular distance to the center of mass. You can sum torques and anugular momenta just like forces and velocities, and it all just works. Hoorah! Sadly, no dynamics books ever seem to deal with this stuff  they stick to 2D cases of rotational dynamics only, even though the 3D cases is (a) useful and (b) easy, once the principles are laid down. So I had to derive most of it from scratch. Sombody please tell me if I'm barking up the wrong tree, but in the tests I've done it all looks physically plausable and suchlike :) Tom Forsyth  purely hypothetical Muckyfoot bloke. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > Original Message > From: Doug Chism [mailto:dchism@...] > Sent: 10 January 2001 02:05 > To: gdalgorithmslist@... > Subject: [Algorithms] Forces causing rotations on rigid bodies > > > I need some help summing rotational force components on rigid > bodies. I > guess the problem is how do I find a common axis or method to > add effects > from multiple forces. Decomposing dosent seem to be a correct > solution by > itself because it needs some sort of sign  i.e. a downward > force on one > side of the rigid body should cancel out one on the opposite > side if its the > same distance from the center of mass. That wont happen if > you decompose the > rotational forces by itself  they will add. > Ive been experimenting using a dot and cross product to > make a unique > axis of rotation and rotation matrix for each force and then > multiplying the > rotation matricies to form a cumulative rotation matrix > representing the sum > of all the individual rotations but that made the object in > question spin > like a top. The problem with that seems to be how do I get > from a rotational > force to a rotational amout. The motion of the object just > acccumulates the > velocity and position vectors but thats not valid for the > rotational forces > since they could change location with respect to the center > of mass. If I > could somehow decompose the rotational forces I think I could > accumulate the > rotational velocity and positions but like I said before  > that ends up > losing the effect of the lever arms orientation. I was > thinking I could sum > them by comparing their orientation to some known vector ( > like a forward > vector ) and then decompose  havent tried that one yet. Am I > on the right > path or what? Wish I kept my Dynamics book from college, but > dont know if it > would help really since I never turned dynamics into code. > Can anyone give > me a brief gameplan to follow for this? > > Doug Chism > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > 
From: Pierre Terdiman <p.terdiman@wa...>  20010110 10:33:08

>Could you explain this statement please? If you have found the Silhouette, >surely finding the shadow volume is trivial? This has to do with screen perspective. To find the edges of a shadow volume you compute something like: Normal  Source >= 0 (Normal = face normal, Source = light pos,  = dot product) To find the edges of a silhouette you perform standard backface culling and take the perspective into account: Normal  (Source  Base)) >= 0 (Source = camera pos, Base = any vertex on the face) Hoppe reports computing the second one is harder (cf silhouette clipping), but that's exactly what the paper I mentioned does (and in O(log n), further improved by temporal coherence). This is highly related to backface culling, and it's not surprising to find traces of the dual space in other papers such as Kumar & Manocha's "Hierarchical Backface Culling". Unfortunately the way to get rid of the "point at infinity problem" is unclear to me. By the way, I also found a cool method using Hoff's normal masks: 1) Compute your standard normal masks 2) Group your polygons according to the normal cluster ID 3) Perform your conservative backface culling in O(1). This gives potentially visible clusters. 4) Invert the viewing direction and perform it again. This gives potentially visible clusters from the back of the object, still in O(1). 5) Since the culling is conservative, you can expect the silhouette edges to be in the clusters common to 3) and 4). Those are what I would call the "silhouette clusters". 6) Now you can search for silhouette edges in a standard way, but only taking the silhouette clusters into account. Alternatively, the silhouette clusters may be used in VDPM to quickly locate regions of interest. Disclaimer: all of this is theoretical and completely untested.... what do you think ? Pierre Terdiman * Home: p.terdiman@... Coder in the dark * Zappy's Lair: http://www.codercorner.com 
From: Pierre Terdiman <p.terdiman@wa...>  20010110 09:41:49

Hmmm, Is it possible to do something like a 3Dto1D mapping from a point to a position on the Hilbert curve ? If so, how do I do this ? Would it be related to the way textures are swizzled ? If we can do that for textures, can we extend the process to 3D ? (which would give a good hash key for spatial clustering I suppose) Pierre 
From: Alex Clarke <alexc@ar...>  20010110 09:30:08

That's a very interesting paper... Silhouette finding in O(log n) would be very nice! >6) This is a perspectivecorrect method, i.e. it works well for toon >rendering, silhouette clipping and occlusion culling (=E0 la Umbra). = But it >does not work to compute shadow volumes for ex. Is there a fast method = like >this to compute shadow volumes? Could you explain this statement please? If you have found the = Silhouette, surely finding the shadow volume is trivial? Alex Clarke, Programmer Argonaut Games PLC 
From: Alex Clarke <alexc@ar...>  20010110 09:09:58

The intel compiler produces some interesting code for: void foobar(int z, int *restrict zBuf, int len) { for (int i = 0; i < len; i++) zBuf[i] = z < zBuf[i] ? z : zBuf[i]; } 1284: void foobar(int z, int *restrict zBuf, int len) 1285: { 004CED10 push esi 004CED11 push ebx 004CED12 sub esp,10h 004CED15 mov esi,dword ptr [esp+1Ch] 1286: for (int i = 0; i < len; i++) 004CED19 xor ebx,ebx 004CED1B test esi,esi 004CED1D jle foobar+80h (004ced90) 004CED23 cmp esi,6 004CED26 jl foobar+70h (004ced80) 004CED28 lea eax,[esi6] 004CED2B mov dword ptr [esp+0Ch],ebp 004CED2F nop 1287: zBuf[i] = z < zBuf[i] ? z : zBuf[i]; 004CED30 mov ebp,dword ptr [edx+ebx*4] 004CED33 cmp ecx,ebp 004CED35 cmovl ebp,ecx 004CED38 mov dword ptr [edx+ebx*4],ebp 004CED3B mov ebp,dword ptr [edx+ebx*4+4] 004CED3F cmp ecx,ebp 004CED41 cmovl ebp,ecx 004CED44 mov dword ptr [edx+ebx*4+4],ebp 004CED48 mov ebp,dword ptr [edx+ebx*4+8] 004CED4C cmp ecx,ebp 004CED4E cmovl ebp,ecx 004CED51 mov dword ptr [edx+ebx*4+8],ebp 004CED55 mov ebp,dword ptr [edx+ebx*4+0Ch] 004CED59 cmp ecx,ebp 004CED5B cmovl ebp,ecx 004CED5E mov dword ptr [edx+ebx*4+0Ch],ebp 004CED62 mov ebp,dword ptr [edx+ebx*4+10h] 004CED66 cmp ecx,ebp 004CED68 cmovl ebp,ecx 004CED6B mov dword ptr [edx+ebx*4+10h],ebp 1286: for (int i = 0; i < len; i++) 004CED6F add ebx,5 004CED72 cmp ebx,eax 004CED74 jle foobar+20h (004ced30) 004CED76 mov ebp,dword ptr [esp+0Ch] 004CED7A lea esi,[esi] 1287: zBuf[i] = z < zBuf[i] ? z : zBuf[i]; 004CED80 mov eax,dword ptr [edx+ebx*4] 004CED83 cmp ecx,eax 004CED85 cmovl eax,ecx 004CED88 mov dword ptr [edx+ebx*4],eax 1286: for (int i = 0; i < len; i++) 004CED8B inc ebx 004CED8C cmp ebx,esi 004CED8E jl foobar+70h (004ced80) 1288: } 004CED90 add esp,10h 004CED93 pop ebx 004CED94 pop esi 004CED95 ret 4 If you have the time, I'd reccomend evaluating the Intel compiler. I tend to find it produces good code and it often has better error messages than VC++, it also integrates into the VC IDE which is great. Alex Clarke, Programmer Argonaut Games PLC 
From: Jim Offerman <j.offerman@in...>  20010110 06:26:43

> target you tell it (486, Pentium, PPro or Blend), but it will never use > instructions that the 486 doesnt have (that is, the code has to run on a > 486). That's why you dont see this code on VC generated code. That's a bit silly... while applications like Word 2000 *might* still run on a 486, but most of the applications we're working on will completely choke a 486 and perhaps run at some impressive 3 fps. I surely wouldn't mind my app not running on a 486. Jim Offerman Innovade. 
From: Doug Chism <dchism@d...>  20010110 03:54:21

Thanks Mark, Jeff and Chris, I will read up on the web resources tomorrow and if I need to get some books. I took a statics and dynamics class in collage but that was 10 years ago and the memory faded. I may be able to get by with the web refresher. The other problem is that since I got an EE degree I never implemented those ideas in code so I am missing the overall gameplan on how to code the rotational component, however I am confident I will get it eventually. We dont currently have a real physics guy here and I usually work exclusively in rendering, but the physics is pretty entertaining as well ( even humerous if you could see some of my attempts ;). I will take the advice and spend some good time researching and stop trying to code through my lack of understanding. Doug Chism  Original Message  From: "Mark Harris" <harrism@...> To: <gdalgorithmslist@...> Sent: Tuesday, January 09, 2001 10:34 PM Subject: Re: [Algorithms] Forces causing rotations on rigid bodies > Doug, > > This calls for another reference to Baraff and Witkin's excellent > coursenotes from the SIGGRAPH course on Physically Based Modeling. When I > implemented a rigid body dynamics simulator, I went almost straight from > these notes. Its a great teacher and reference  good and concise enough > that you probably won't need that dynamics textbook. ;) > > http://www.cs.cmu.edu/~baraff/sigcourse/index.html > > (Note: below is a really stripped down overview to get you thinking. The > math and a much better explanation are in the link above. I highly > recommend reading all of it, but especially the first chapter on Rigid > Body Dynamics) > > I believe the mistake you are making is in assuming that the concept of > "force" is enough to simulate changes in angular velocity, and thus > orientation. In the case of particles, or anything else where only linear > velocity is needed, sure, that's enough. If you are trying to simulate > rotation, though, you are simulating change in orientation over time: > angular velocity. If you apply a force anywhere but the center of mass of > a body, you'll induce both linear and angular acceleration. Over time, > these result in translation and rotation, respectively. The amount of > linear acceleration depends on force and mass. The amount of angular > acceleration depends on the distribution of mass in the body (the Inertia > Tensor), and the torque imparted to the body by the force. > > Now, in linear (particle) simulations, you just need to accumulate forces, > apply them to _particles_, and integrate over time. The state of each > particle is simply its position and velocity. To simulate angular motion, > things are more complicated. You accumulate both forces _and_ torques, > apply them to _bodies_, and integrate over time. The state in this case > is its position and orientation, as well as its linear and angular > momentum (you could say linear and angular velocity instead, but if you > read the notes, you'll see why it makes much more computational sense to > use momentum and compute the velocities when needed) > > Thinking about things as Baraff and Witkin describe them might cause you > to have to back up and reimplement some things, but I think its worth it > for the nice clean, straightforward code that results. > > Good luck, > > Mark > >  Original Message  > From: "Doug Chism" <dchism@...> > Date: Tuesday, January 9, 2001 9:04 pm > Subject: [Algorithms] Forces causing rotations on rigid bodies > > > I need some help summing rotational force components on rigid > > bodies. I > > guess the problem is how do I find a common axis or method to add > > effectsfrom multiple forces. Decomposing dosent seem to be a > > correct solution by > > itself because it needs some sort of sign  i.e. a downward force > > on one > > side of the rigid body should cancel out one on the opposite side > > if its the > > same distance from the center of mass. That wont happen if you > > decompose the > > rotational forces by itself  they will add. > > Ive been experimenting using a dot and cross product to make a > > uniqueaxis of rotation and rotation matrix for each force and then > > multiplying the > > rotation matricies to form a cumulative rotation matrix > > representing the sum > > of all the individual rotations but that made the object in > > question spin > > like a top. The problem with that seems to be how do I get from a > > rotationalforce to a rotational amout. The motion of the object > > just acccumulates the > > velocity and position vectors but thats not valid for the > > rotational forces > > since they could change location with respect to the center of > > mass. If I > > could somehow decompose the rotational forces I think I could > > accumulate the > > rotational velocity and positions but like I said before  that > > ends up > > losing the effect of the lever arms orientation. I was thinking I > > could sum > > them by comparing their orientation to some known vector ( like a > > forwardvector ) and then decompose  havent tried that one yet. Am > > I on the right > > path or what? Wish I kept my Dynamics book from college, but dont > > know if it > > would help really since I never turned dynamics into code. Can > > anyone give > > me a brief gameplan to follow for this? > > > > Doug Chism > > > > > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > > > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > 
From: Mark Harris <harrism@cs...>  20010110 03:34:06

Doug, This calls for another reference to Baraff and Witkin's excellent coursenotes from the SIGGRAPH course on Physically Based Modeling. When I implemented a rigid body dynamics simulator, I went almost straight from these notes. Its a great teacher and reference  good and concise enough that you probably won't need that dynamics textbook. ;) http://www.cs.cmu.edu/~baraff/sigcourse/index.html (Note: below is a really stripped down overview to get you thinking. The math and a much better explanation are in the link above. I highly recommend reading all of it, but especially the first chapter on Rigid Body Dynamics) I believe the mistake you are making is in assuming that the concept of "force" is enough to simulate changes in angular velocity, and thus orientation. In the case of particles, or anything else where only linear velocity is needed, sure, that's enough. If you are trying to simulate rotation, though, you are simulating change in orientation over time: angular velocity. If you apply a force anywhere but the center of mass of a body, you'll induce both linear and angular acceleration. Over time, these result in translation and rotation, respectively. The amount of linear acceleration depends on force and mass. The amount of angular acceleration depends on the distribution of mass in the body (the Inertia Tensor), and the torque imparted to the body by the force. Now, in linear (particle) simulations, you just need to accumulate forces, apply them to _particles_, and integrate over time. The state of each particle is simply its position and velocity. To simulate angular motion, things are more complicated. You accumulate both forces _and_ torques, apply them to _bodies_, and integrate over time. The state in this case is its position and orientation, as well as its linear and angular momentum (you could say linear and angular velocity instead, but if you read the notes, you'll see why it makes much more computational sense to use momentum and compute the velocities when needed) Thinking about things as Baraff and Witkin describe them might cause you to have to back up and reimplement some things, but I think its worth it for the nice clean, straightforward code that results. Good luck, Mark  Original Message  From: "Doug Chism" <dchism@...> Date: Tuesday, January 9, 2001 9:04 pm Subject: [Algorithms] Forces causing rotations on rigid bodies > I need some help summing rotational force components on rigid > bodies. I > guess the problem is how do I find a common axis or method to add > effectsfrom multiple forces. Decomposing dosent seem to be a > correct solution by > itself because it needs some sort of sign  i.e. a downward force > on one > side of the rigid body should cancel out one on the opposite side > if its the > same distance from the center of mass. That wont happen if you > decompose the > rotational forces by itself  they will add. > Ive been experimenting using a dot and cross product to make a > uniqueaxis of rotation and rotation matrix for each force and then > multiplying the > rotation matricies to form a cumulative rotation matrix > representing the sum > of all the individual rotations but that made the object in > question spin > like a top. The problem with that seems to be how do I get from a > rotationalforce to a rotational amout. The motion of the object > just acccumulates the > velocity and position vectors but thats not valid for the > rotational forces > since they could change location with respect to the center of > mass. If I > could somehow decompose the rotational forces I think I could > accumulate the > rotational velocity and positions but like I said before  that > ends up > losing the effect of the lever arms orientation. I was thinking I > could sum > them by comparing their orientation to some known vector ( like a > forwardvector ) and then decompose  havent tried that one yet. Am > I on the right > path or what? Wish I kept my Dynamics book from college, but dont > know if it > would help really since I never turned dynamics into code. Can > anyone give > me a brief gameplan to follow for this? > > Doug Chism > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > 
From: Mark Harris <harrism@cs...>  20010110 03:32:55

Doug, This calls for another reference to Baraff and Witkin's excellent coursenotes from the SIGGRAPH course on Physically Based Modeling. When I implemented a rigid body dynamics simulator, I went almost straight from these notes. Its a great teacher and reference  good and concise enough that you probably won't need that dynamics textbook. ;) http://www.cs.cmu.edu/~baraff/sigcourse/index.html (Note: below is a really stripped down overview to get you thinking. The math and a much better explanation are in the link above. I highly recommend reading all of it, but especially the first chapter on Rigid Body Dynamics) I believe the mistake you are making is in assuming that the concept of "force" is enough to simulate changes in angular velocity, and thus orientation. In the case of particles, or anything else where only linear velocity is needed, sure, that's enough. If you are trying to simulate rotation, though, you are simulating change in orientation over time: angular velocity. If you apply a force anywhere but the center of mass of a body, you'll induce both linear and angular acceleration. Over time, these result in translation and rotation, respectively. The amount of linear acceleration depends on force and mass. The amount of angular acceleration depends on the distribution of mass in the body (the Inertia Tensor), and the torque imparted to the body by the force. Now, in linear (particle) simulations, you just need to accumulate forces, apply them to _particles_, and integrate over time. The state of each particle is simply its position and velocity. To simulate angular motion, things are more complicated. You accumulate both forces _and_ torques, apply them to _bodies_, and integrate over time. The state in this case is its position and orientation, as well as its linear and angular momentum (you could say linear and angular velocity instead, but if you read the notes, you'll see why it makes much more computational sense to use momentum and compute the velocities when needed) Thinking about things as Baraff and Witkin describe them might cause you to have to back up and reimplement some things, but I think its worth it for the nice clean, straightforward code that results. Good luck, Mark  Original Message  From: "Doug Chism" <dchism@...> Date: Tuesday, January 9, 2001 9:04 pm Subject: [Algorithms] Forces causing rotations on rigid bodies > I need some help summing rotational force components on rigid > bodies. I > guess the problem is how do I find a common axis or method to add > effectsfrom multiple forces. Decomposing dosent seem to be a > correct solution by > itself because it needs some sort of sign  i.e. a downward force > on one > side of the rigid body should cancel out one on the opposite side > if its the > same distance from the center of mass. That wont happen if you > decompose the > rotational forces by itself  they will add. > Ive been experimenting using a dot and cross product to make a > uniqueaxis of rotation and rotation matrix for each force and then > multiplying the > rotation matricies to form a cumulative rotation matrix > representing the sum > of all the individual rotations but that made the object in > question spin > like a top. The problem with that seems to be how do I get from a > rotationalforce to a rotational amout. The motion of the object > just acccumulates the > velocity and position vectors but thats not valid for the > rotational forces > since they could change location with respect to the center of > mass. If I > could somehow decompose the rotational forces I think I could > accumulate the > rotational velocity and positions but like I said before  that > ends up > losing the effect of the lever arms orientation. I was thinking I > could sum > them by comparing their orientation to some known vector ( like a > forwardvector ) and then decompose  havent tried that one yet. Am > I on the right > path or what? Wish I kept my Dynamics book from college, but dont > know if it > would help really since I never turned dynamics into code. Can > anyone give > me a brief gameplan to follow for this? > > Doug Chism > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > 
From: Jeff Lander <jeffl@te...>  20010110 03:24:39

You need to read up a bit on rigid body dynamics. A force that is not applied at the center of mass of an object cause a change in the angular momentum of the object. For your example, you need to apply the principles of conservation of linear and angular momentum. Apply each force and calculate both the linear and angular components. Those can then be accumulated and you can step your simulation forward. I think you should pick up a good dynamics book and works some of the examples. I recommend Bedford and Fowler's Dynamics/Statics set (or Beer and Johnston or really any college level Mechanics books that cover Dynamics and Statics). That will give you the terms you need to frame the problem. Chris Hecker's introduction to rigid body dynamics in Game Developer is very good as well. http://www.d6.com for the articles and code samples. But you may still need a good dynamics book to follow the concepts and terms. He also has a good bibliography on his page. I also gave an overview lecture on rigid bodies at last year's Hardcore Technical seminars. However, I only have the Powerpoint slides and since it is a review, it assumes more then you know at this point I think. I really suggest learning what is going on by working the math on paper. Many people just use these demos without understanding why things are happening and that is when they get into trouble. By tackling something as sophisticated as a dynamic simulator, you have trend into one of those zones where you really need to understand the math. Otherwise making things work and debugging is a nightmare. Luckily this stuff has been done since Newton so there is plenty of info out there. Jeff At 09:04 PM 1/9/2001 0500, you wrote: >I need some help summing rotational force components on rigid bodies. I >guess the problem is how do I find a common axis or method to add effects >from multiple forces. Decomposing dosent seem to be a correct solution by >itself because it needs some sort of sign  i.e. a downward force on one >side of the rigid body should cancel out one on the opposite side if its the >same distance from the center of mass. That wont happen if you decompose the >rotational forces by itself  they will add. > Ive been experimenting using a dot and cross product to make a unique >axis of rotation and rotation matrix for each force and then multiplying the >rotation matricies to form a cumulative rotation matrix representing the sum >of all the individual rotations but that made the object in question spin >like a top. The problem with that seems to be how do I get from a rotational >force to a rotational amout. The motion of the object just acccumulates the >velocity and position vectors but thats not valid for the rotational forces >since they could change location with respect to the center of mass. If I >could somehow decompose the rotational forces I think I could accumulate the >rotational velocity and positions but like I said before  that ends up >losing the effect of the lever arms orientation. I was thinking I could sum >them by comparing their orientation to some known vector ( like a forward >vector ) and then decompose  havent tried that one yet. Am I on the right >path or what? Wish I kept my Dynamics book from college, but dont know if it >would help really since I never turned dynamics into code. Can anyone give >me a brief gameplan to follow for this? > >Doug Chism > > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist  Jeff Lander Game Technology Seminars Darwin 3D Jan 30  Feb 2, 2001 http://www.darwin3d.com http://www.techsem.com 
From: Chris Lee <chris@ch...>  20010110 03:23:39

Doug, I found these notes from siggraph '97 very useful in rigid body simulation: http://www.cs.cmu.edu/~baraff/sigcourse/notesd1.pdf Chris  Original Message  From: "Doug Chism" <dchism@...> To: <gdalgorithmslist@...> Sent: Tuesday, January 09, 2001 7:04 PM Subject: [Algorithms] Forces causing rotations on rigid bodies > I need some help summing rotational force components on rigid bodies. I > guess the problem is how do I find a common axis or method to add effects > from multiple forces. Decomposing dosent seem to be a correct solution by > itself because it needs some sort of sign  i.e. a downward force on one > side of the rigid body should cancel out one on the opposite side if its the > same distance from the center of mass. That wont happen if you decompose the > rotational forces by itself  they will add. > Ive been experimenting using a dot and cross product to make a unique > axis of rotation and rotation matrix for each force and then multiplying the > rotation matricies to form a cumulative rotation matrix representing the sum > of all the individual rotations but that made the object in question spin > like a top. The problem with that seems to be how do I get from a rotational > force to a rotational amout. The motion of the object just acccumulates the > velocity and position vectors but thats not valid for the rotational forces > since they could change location with respect to the center of mass. If I > could somehow decompose the rotational forces I think I could accumulate the > rotational velocity and positions but like I said before  that ends up > losing the effect of the lever arms orientation. I was thinking I could sum > them by comparing their orientation to some known vector ( like a forward > vector ) and then decompose  havent tried that one yet. Am I on the right > path or what? Wish I kept my Dynamics book from college, but dont know if it > would help really since I never turned dynamics into code. Can anyone give > me a brief gameplan to follow for this? > > Doug Chism > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist 
From: Toong See Wan <seewan@su...>  20010110 03:13:10

Do you know site that explain in detail how a skeletal animation engine work and how to program one? seewan  Original Message  From: "Vek" <vektuz@...> To: <gdalgorithmslist@...> Sent: Wednesday, January 10, 2001 4:22 AM Subject: Re: Re[2]: [Algorithms] Sketal Animation > The HalfLife SDK itself has a good description of the SMD file format, as > well as a SMD file exporter for 3ds Max  and at places like > http://www.planethalflife.com/wavelength > there are a couple more specs that might be useful. Basically, a SMD file > is just a text file containing the bones of a model, and the vertices of the > reference frame, and which bones they belong to (and U,V's)... then > additional > SMD files contain just the skeletal animation information, without the > vertices. > > Vek > >  Original Message  > From: "Toong See Wan" <seewan@...> > To: <gdalgorithmslist@...> > Sent: Tuesday, January 09, 2001 3:31 AM > Subject: Re: Re[2]: [Algorithms] Sketal Animation > > > > Is there any site that have a detail explaination on the animation system > > and file format for halflife? > > > > seewan > >  Original Message  > > From: "Cruise" <Cruise@...> > > To: "Jose Marin" <gdalgorithmslist@...> > > Sent: Tuesday, January 09, 2001 1:08 AM > > Subject: Re[2]: [Algorithms] Sketal Animation > > > > > > > try http://www.fileplanet.com > > > > > > > Hi > > > > > > > Where can I find the HalfLife SDK? > > > > > > > Thanks > > > > > > > > > >>The HalfLife SDK comes with a model viewer. You can look at the > header > > > >>file to see the file format. > > > > > > > > > _________________________________________________________________________ > > > > Get Your Private, Free Email from MSN Hotmail at > > http://www.hotmail.com. > > > > > > > > > > _______________________________________________ > > > > GDAlgorithmslist mailing list > > > > GDAlgorithmslist@... > > > > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > > > > > > > > > > > > _______________________________________________ > > > GDAlgorithmslist mailing list > > > GDAlgorithmslist@... > > > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > > > > > > > > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > 
From: Doug Chism <dchism@d...>  20010110 02:04:36

I need some help summing rotational force components on rigid bodies. I guess the problem is how do I find a common axis or method to add effects from multiple forces. Decomposing dosent seem to be a correct solution by itself because it needs some sort of sign  i.e. a downward force on one side of the rigid body should cancel out one on the opposite side if its the same distance from the center of mass. That wont happen if you decompose the rotational forces by itself  they will add. Ive been experimenting using a dot and cross product to make a unique axis of rotation and rotation matrix for each force and then multiplying the rotation matricies to form a cumulative rotation matrix representing the sum of all the individual rotations but that made the object in question spin like a top. The problem with that seems to be how do I get from a rotational force to a rotational amout. The motion of the object just acccumulates the velocity and position vectors but thats not valid for the rotational forces since they could change location with respect to the center of mass. If I could somehow decompose the rotational forces I think I could accumulate the rotational velocity and positions but like I said before  that ends up losing the effect of the lever arms orientation. I was thinking I could sum them by comparing their orientation to some known vector ( like a forward vector ) and then decompose  havent tried that one yet. Am I on the right path or what? Wish I kept my Dynamics book from college, but dont know if it would help really since I never turned dynamics into code. Can anyone give me a brief gameplan to follow for this? Doug Chism 