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
(13) 
2
(15) 
3
(54) 
4
(51) 
5
(10) 
6
(2) 
7
(25) 
8
(25) 
9
(19) 
10
(18) 
11
(25) 
12
(9) 
13
(7) 
14
(20) 
15
(55) 
16
(35) 
17
(34) 
18
(23) 
19
(8) 
20
(5) 
21
(19) 
22
(16) 
23
(5) 
24
(19) 
25
(39) 
26
(11) 
27
(4) 
28
(7) 
29
(16) 
30
(35) 



From: Andras Balogh <bnd@ma...>  20030430 21:36:30

Hi Jon, > Instead of normal maps, it's entirely possible to store just > the artistsupplied grayscale bump map, and derive a local > normal by sampling three points and do the cross product in > the fragment shader. The obvious win is using native 8 bit > grayscale formats (or even 16 bit formats) instead of spending > 32 bits per texel (or 64 ;) and thus getting a 4x increase in > bump map resolution for the same oncard memory cost. Yeah, and you did not even mention the IMHO most important feature of heightmaps: you can simply add them together, while you obviously cannot do this with normal maps... This is great for adding extra detail bumps! It is also straightforward to animate it, allowing for some really cool effects! > The question I have for those who have gone before is how to > determine how far from the sample center to place the three > samples? nVIDIA hardware seems to have some kind of magic > which can generate derivatives for "any quantity" in the > shaders, but this is of course vendor specific. I dunno about this NV magic (does this actually calculate the difference between some texels in a fragment program??), but you could store the gradients instead of height. This means that you loose height information (do you need that?), and it would take up twice the storage, but it is still less than a normal map, and can also be added together. Also, it can be used on old, non fp hardware. Actually, I'm a student, and don't have fp hardware to play with, so what I plan on doing is create a texture that contains the normals for every gradient combination and then do a dependent texture read with the offset_texture_2d shader to transform my gradients into unit length normals. This might be even faster than doing some swizzling to calculate the cross product, and normalizing the result in a fp (yeah, I know fp will be faster in the future, but so far, we are still in the present ;). Hmm.. If you've got texture units to spare, you could calculate the gradients on the fly by using two slightly offset textures and subtracting them... > I suppose you could just say "sample 1/512th to the side" and > it might look good enough. But I have a feeling this > discerning crowd would know of better ways of doing it, > ideally in a platform neutral way (i e exposed through DX9 > pixel shaders, or GL_ARB_fragment_program). > Another approach would be to store the "local texel density" > in the third (r) texture coordinate, and then multiply by > distance (and probably clamp to avoid shooting off the scale) > in the vertex program to generate an interpolated quantity. > This could possibly interact well with MIP mapping, come to > think of it, except it wouldn't improve the glancing angle > case much. Sorry, what is "local texel density"?? > So, if you've done this, what were your experiences? Or if > you're just waking up and smelling the shaders, what will > your fresh perspective say about this? Well, I'm felling asleep actually, but hey, I can smell the shaders! =) > Cheers, > / h+ bye, Bandi 
From: Andras Balogh <bnd@ma...>  20030430 21:36:30

Tuesday, April 29, 2003, 10:48:13 PM, Jon Watte wrote: > What complicates the matter for us is that we allow/encourage use in > windowed mode, which means that gamma adjustment would affect the > entire desktop. Most users are used to their uncorrected desktops, > and complain that things look washedout if you actually calibrate > their displays... It would be cool to have a default _linear_ window theme (or a tool that corrects a theme) and let the hardware apply gamma correction. Hmm... But I guess it would still ruin the family photo album. :( It's a PITA that gamma correction was ignored at the very beginning.. I've heard that the SGI machines had built in gamma correction, why did they throw it away on the PC?? b 
From: Gribb, Gil <ggribb@ra...>  20030430 18:54:32

The exact time and point of impact between a moving ellipsoid and a plane, point or line can be computed analytically. Really these are just sphere routines in a special space. Ellipsoids are nice because they give good "contact normals" for sliding around obstructions (or up stairs). In other words, the contact point gives you a half space of possible movement that is possible without interpenetration and a plane of movement of contact slides. I don't know about renderware, but my ellipsoid routines are very robust. Gil Did ellipsoid volume suddenly become a desirable collision volume? Last I checked, there was no analytical solution to finding the closest point or line to an ellipsoid, making an accurate collision check rather slow. (See ellipsoid discussion on GDAlg) RenderWare Studio uses an ellipsoid collision volume that is deeply flawed; if you don't believe me, make a tall skinny ellipsoid and run it up a ramp. You'll see it interpenetrate up to about the middle of the volume. ;) Is there something about ellipsoids that make them worth using; especially considering there are fairly clean analytical solutions for a capsule/hotdog/pill volume? Eric Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Glenn Fiedler Sent: Tuesday, April 29, 2003 6:18 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Physics and stairs i would recommend having an ellipsoid collision volume and properly handling grazing collisions  this is the approach we are taking for stairs, bumps etc. in tribes3 Original Message From: Charles Bloom [mailto:cbloom@...] Sent: Wednesday, 30 April 2003 11:51 AM To: gdalgorithmslist@... Subject: Re: [Algorithms] Physics and stairs These are the standard old tricks, but what do people do who are using a "real" physics engine? What would Dave Wu do? At 05:59 PM 4/29/2003 0700, phil_wilkins@... wrote: >What we did (and what I've seen other people do) was, upon colliding >with something that looks like it might be a step, to try another move >offset vertically by the maximum step height, and then, if successfull, >cast down again to see just how high the step actually was. > >Cheers, >Phil > >PS IIRC there's an instructive thread somewhere in the archives about >this. Doesn't Halo do it by having ramps over the actual stairs? Only >using the actual stair geometry to fix up the feet for rendering >purposes. > > > > > "Leonel A." > <caoss001@... > om.mx> To > Sent by: gdalgorithmslist@... > gdalgorithmslist .net > admin@... cc > ceforge.net > Subject > [Algorithms] Physics and stairs > 04/29/2003 05:34 > PM > > > Please respond to > gdalgorithmslist > @lists.sourceforg > e.net > > > > > > > >Hi all > I like to make a First Person Shooter, and for that, I have done a >physics simulator who work nicely for moving or resting objects. I made >the player to move according to physics, If he need to move forward, I >apply a force and in response, he moves. Till now, all work fine, he >clamp hills, jump, fall. But I need to clamp an stair right now, and >when the player bounding box collide the first stair step, the >collision system return an opositive collision normal, so, the box >bounce backward instead of jump or clamp as it does when a hill is found. > Is it a good idea to make the player a physic body? or is best >just simulate the physics on it? Any way, could some one explain how >that FPS clamp stairs with out cheating the collision system. > >Cheers > Leonel > > > >Do You Yahoo!? >Yahoo! Net: La mejor conexión a internet y 25MB extra a tu correo por >$100 al mes. > > > > > >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_ida88  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_ida88  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_ida88  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_ida88 
From: Eric Yiskis <erk@sa...>  20030430 18:12:02

Did ellipsoid volume suddenly become a desirable collision volume? Last I checked, there was no analytical solution to finding the closest point or line to an ellipsoid, making an accurate collision check rather slow. (See ellipsoid discussion on GDAlg) RenderWare Studio uses an ellipsoid collision volume that is deeply flawed; if you don't believe me, make a tall skinny ellipsoid and run it up a ramp. You'll see it interpenetrate up to about the middle of the volume. ;) Is there something about ellipsoids that make them worth using; especially considering there are fairly clean analytical solutions for a capsule/hotdog/pill volume? Eric Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Glenn Fiedler Sent: Tuesday, April 29, 2003 6:18 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Physics and stairs i would recommend having an ellipsoid collision volume and properly handling grazing collisions  this is the approach we are taking for stairs, bumps etc. in tribes3 Original Message From: Charles Bloom [mailto:cbloom@...] Sent: Wednesday, 30 April 2003 11:51 AM To: gdalgorithmslist@... Subject: Re: [Algorithms] Physics and stairs These are the standard old tricks, but what do people do who are using a "real" physics engine? What would Dave Wu do? At 05:59 PM 4/29/2003 0700, phil_wilkins@... wrote: >What we did (and what I've seen other people do) was, upon colliding=20 >with something that looks like it might be a step, to try another move=20 >offset vertically by the maximum step height, and then, if successfull, >cast down again to see just how high the step actually was. > >Cheers, >Phil > >PS IIRC there's an instructive thread somewhere in the archives about=20 >this. Doesn't Halo do it by having ramps over the actual stairs? Only=20 >using the actual stair geometry to fix up the feet for rendering=20 >purposes. > > > > > "Leonel A." > <caoss001@... > om.mx> To > Sent by: gdalgorithmslist@... > gdalgorithmslist .net > admin@... cc > ceforge.net > Subject > [Algorithms] Physics and stairs > 04/29/2003 05:34 > PM > > > Please respond to > gdalgorithmslist > @lists.sourceforg > e.net > > > > > > > >Hi all > I like to make a First Person Shooter, and for that, I have done a=20 >physics simulator who work nicely for moving or resting objects. I made >the player to move according to physics, If he need to move forward, I=20 >apply a force and in response, he moves. Till now, all work fine, he=20 >clamp hills, jump, fall. But I need to clamp an stair right now, and=20 >when the player bounding box collide the first stair step, the=20 >collision system return an opositive collision normal, so, the box=20 >bounce backward instead of jump or clamp as it does when a hill is found. > Is it a good idea to make the player a physic body? or is best=20 >just simulate the physics on it? Any way, could some one explain how=20 >that FPS clamp stairs with out cheating the collision system. > >Cheers > Leonel > > > >Do You Yahoo!? >Yahoo! Net: La mejor conexi=F3n a internet y 25MB extra a tu correo por = =20 >$100 al mes. > > > > > >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_ida88  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_ida88  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_ida88 
From: Guillaume Provost <Guillaume@ps...>  20030430 18:02:56

Diogo, You are not properly transforming the ray origin. You need to inverse the ray origin in the full matrix: ie: LRayOrigin = Inverse(MeshOrientation) * (GRayOrigin  MeshPosition) LRayDirection = Inverse(MeshOrientation) * GRayDirection and not: LRayOrigin = (GRayOrigin  MeshPosition) LRayDirection = Inverse(MeshOrientation) * GRayDirection Hope this helps. Guillaume. Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Diogo de Andrade Sent: Wednesday, April 30, 2003 1:09 PM To: gdalgorithmslist@... Subject: [Algorithms] Collision detection Hey all! I have a small problem that I hope some can give me some help... In my collision system, to check if an object is being intersected by a ray, I do a check between the object's bounding sphere and the ray and this works fine... Now, I want to go to the mesh level and see if the mesh triangles and the ray collide... The problem is, the mesh is stored in local mesh coordinates (LMC), adn the object contains the information on the mesh's position in world space (WC)... So, when I wanted to check if the mesh was being intersected by a ray, I just converted the LMCs to WCs and checked the ray/triangle intersection... This worked fine, but I think it's inneficient, so I came up with the idea of converting the ray (that is specified in WC) to LMC... This is where the brown stuff hits the fan... I can't seem to get the math working, specially because I'm using quaternions for rotations... This is the code that works: bool sbMesh::is_intersected(Vec3f *mesh_pos,Quaternion *mesh_ori,sbRay* ray) { Quaternion tmp_ori=(*mesh_ori); float tp; for (unsigned long i=0; i<get_triangle_count(); i++) { sbVertex *pos1,*pos2,*pos3; get_triangle(i,&pos1,&pos2,&pos3); // Apply transformations to point Vec3f pt1,pt2,pt3; tmp_ori.rotate_point(pt1,pos1>pos); pt1=pt1+(*mesh_pos); tmp_ori.rotate_point(pt2,pos2>pos); pt2=pt2+(*mesh_pos); tmp_ori.rotate_point(pt3,pos3>pos); pt3=pt3+(*mesh_pos); // Check collision sbTriangle tri(pt1,pt2,pt3); if (sbIntersection::is_intersecting(ray,&tri,&tp)) { return true; } } return false; } And this is the one that doesn't: bool sbMesh::is_intersected(Vec3f *mesh_pos,Quaternion *mesh_ori,sbRay* ray) { // Convert ray from WC to LMC sbRay tmp_ray; tmp_ray._origin=ray>_origin(*(mesh_pos)); Quaternion tmp_ori=(*mesh_ori); tmp_ori.invert(); tmp_ori.rotate_point(tmp_ray._dir,ray>_dir); float tp; for (unsigned long i=0; i<get_triangle_count(); i++) { sbVertex *pos1,*pos2,*pos3; get_triangle(i,&pos1,&pos2,&pos3); // Check collision sbTriangle tri(pos1>pos,pos2>pos,pos3>pos); if (sbIntersection::is_intersecting(ray,&tri,&tp)) { return true; } } return false; } Can someone tell me what am I doing wrong? Thanks in advance! Diogo de Andrade http://www.spellcasterstudios.com/~diogo.andrade diogo.andrade@... "Never trust something that bleeds for five days and doesn't die..." Robert A. Heinlein "People say I'm evil, but I have the heart of a little boy... in a jar... on my desk..."  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: Casey Muratori <gda@fu...>  20030430 17:47:31

> // Convert ray from WC to LMC > sbRay tmp_ray; > > tmp_ray._origin=ray>_origin(*(mesh_pos)); > > Quaternion tmp_ori=(*mesh_ori); tmp_ori.invert(); > tmp_ori.rotate_point(tmp_ray._dir,ray>_dir); Simply moving the ray origin isn't sufficient. You also need to rotate the ray origin into the mesh's frame of reference. Think of this the same way you would a camera transform. You want to view the ray from the mesh's perspective. Your handling of the ray direction is correct  since it is a vector, it does not move, so rotating it by the inverse orientation is correct. It is your handling of the ray origin that is wrong. Not only do you need to rotate it as well, but you need to rotate it in the correct order. I think I posted this equation not a few weeks back :) If R is the orientation of the object, t is the translation of the object, p' is the ray origin in world space (which we know), and p is what the ray origin is in object space (which we don't know), then p' = Rp + t p'  t = Rp R1(p'  t) = p right? So you want to first do the subtraction, which you're doing, and THEN inverse rotate, which you left out. So I'm imagining your code would work properly in this way: > // Convert ray from WC to LMC > sbRay tmp_ray; > > Quaternion tmp_ori=(*mesh_ori); tmp_ori.invert(); > tmp_ori.rotate_point(tmp_ray._dir,ray>_dir); > tmp_ori.rotate_point(tmp_ray._origin,ray>_origin(*(mesh_pos))); assuming your rotate_point routine handles passing the same vector for the source and the target. You can envision the action of this easily: you are moving the point so that it is "where it would be from the objects point of view", and then you are rotating it so that it is aligned with the way the object is facing. Does that make sense? Of course there might be other problems too, but the rest of the code looked fine at a cursory glance.  Casey 
From: Pierre Terdiman <p.terdiman@wa...>  20030430 17:32:14

> Can someone tell me what am I doing wrong? Difficult to say without seeing your "invert()" method. One easy way to debug it would be to make it work first using matrices, then convert correct matrices to quats afterwards, and see where the two ways differ. Or better, use matrices all the way, it's not going to make any speed difference. In any case you can check Opcode's raymesh intersection code (www.codercorner.com/Opcode.htm), it does what you're trying to do. I'm using matrices, but the 4x4 inversion is actually optimized for (Position, Rotation) matrices, so in the end it should be just as fast as the quaternion version  and probably easier to follow. My two bits...  Pierre http://www.codercorner.com 
From: Lippmann, Christopher <clippmann@ea...>  20030430 17:13:45

Based on the messages flying around it's pretty clear that Tony has a good grasp on this and it's also pretty clear that these emails aren't sufficient to educate someone in the subtleties of classical mechanics. Perhaps the entire issue can be put to rest with a reference to Goldstein's "Classical Mechanics". There are probably those who find this treatment "too mathematical" but I'd argue that the mathematics are required in order to properly understand... In the event that "realism" is not what is required then feel free to ignore classical mechanics of course, but realize that there is some peril in doing so. Arbitrary constructions, if not done with enough care, can cause problems if the appropriate physical quantities are not conserved. Chris. Original Message From: Tony Cox [mailto:tonycox@...]=20 Sent: Wednesday, April 30, 2003 9:55 AM To: gdalgorithmslist@... Subject: RE: [Algorithms] Re: Cumalative rotation >"And obviously we have to be talking about a fixed frame=20 >of reference  which object space isn't (since the object=20 >is rotating)." > >Argh, definition inferno. The above statement can be interpreted in two ways. Object space _is_ a fixed >frame of reference with reference to the object (provided it's a rigid body); it is rigidly attached to >the object. Ofcourse, the "fixed frame of reference" Tony is talking about, is then worldspace, the=20 >space that sees the object rotating. Yes, I was a little sloppy here. Actually, it occurred to me that one source of Richard's confusion may be that he is applying his intuition about linearly moving frames, and assuming it all carries over unchanged to rotating frames. This isn't quite true. Consider whether momentum is conserved in a frame. Clearly, if my frame of reference is moving with constant linear velocity, and I observe the linear momentum of an object which has no forces applied to it, then I will observe that momentum to be constant. However, if my frame is accelerating, this is no longer true, I will observe a changing momentum for the object, even though no forces are applied to it. Now consider a rotating frame. Track the motion of one particle in a rotating object  its velocity is always changing, i.e. it is *accelerating*. A rotating frame is an accelerating frame. And relative to an accelerating frame, you cannot say that momentum is unchanged if no force is applied. This is where Richard I think is falling down. He assumes that if you transform everything into object space, then you can apply your knowledge about how torques affect angular momenta in that frame. But you can't, because a rotating frame is accelerating. You have to do your computations in a nonaccelerating frame. A good choice would be world space. Tony Cox  Development Lead, Hockey Microsoft Games Studios  Sports  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_ida88 
From: Diogo de Andrade <Diogo.Andrade@sp...>  20030430 17:08:46

Hey all! I have a small problem that I hope some can give me some help... In my collision system, to check if an object is being intersected by a ray, I do a check between the object's bounding sphere and the ray and this works fine... Now, I want to go to the mesh level and see if the mesh triangles and the ray collide... The problem is, the mesh is stored in local mesh coordinates (LMC), adn the object contains the information on the mesh's position in world space (WC)... So, when I wanted to check if the mesh was being intersected by a ray, I just converted the LMCs to WCs and checked the ray/triangle intersection... This worked fine, but I think it's inneficient, so I came up with the idea of converting the ray (that is specified in WC) to LMC... This is where the brown stuff hits the fan... I can't seem to get the math working, specially because I'm using quaternions for rotations... This is the code that works: bool sbMesh::is_intersected(Vec3f *mesh_pos,Quaternion *mesh_ori,sbRay* ray) { Quaternion tmp_ori=(*mesh_ori); float tp; for (unsigned long i=0; i<get_triangle_count(); i++) { sbVertex *pos1,*pos2,*pos3; get_triangle(i,&pos1,&pos2,&pos3); // Apply transformations to point Vec3f pt1,pt2,pt3; tmp_ori.rotate_point(pt1,pos1>pos); pt1=pt1+(*mesh_pos); tmp_ori.rotate_point(pt2,pos2>pos); pt2=pt2+(*mesh_pos); tmp_ori.rotate_point(pt3,pos3>pos); pt3=pt3+(*mesh_pos); // Check collision sbTriangle tri(pt1,pt2,pt3); if (sbIntersection::is_intersecting(ray,&tri,&tp)) { return true; } } return false; } And this is the one that doesn't: bool sbMesh::is_intersected(Vec3f *mesh_pos,Quaternion *mesh_ori,sbRay* ray) { // Convert ray from WC to LMC sbRay tmp_ray; tmp_ray._origin=ray>_origin(*(mesh_pos)); Quaternion tmp_ori=(*mesh_ori); tmp_ori.invert(); tmp_ori.rotate_point(tmp_ray._dir,ray>_dir); float tp; for (unsigned long i=0; i<get_triangle_count(); i++) { sbVertex *pos1,*pos2,*pos3; get_triangle(i,&pos1,&pos2,&pos3); // Check collision sbTriangle tri(pos1>pos,pos2>pos,pos3>pos); if (sbIntersection::is_intersecting(ray,&tri,&tp)) { return true; } } return false; } Can someone tell me what am I doing wrong? Thanks in advance! Diogo de Andrade http://www.spellcasterstudios.com/~diogo.andrade diogo.andrade@... "Never trust something that bleeds for five days and doesn't die..." Robert A. Heinlein "People say I'm evil, but I have the heart of a little boy... in a jar... on my desk..." 
From: Charles Nicholson <cnicholson@sa...>  20030430 17:01:28

Check out "Texturing and Modeling: A Procedural Approach" by Ebert, Musgrave et al. Chapter 12, "Procedural Fractal Terrains", has a lot about the algorithms behind multifractal terrains, which have the features it sounds like you want (smoothing valleys, rough mountains). Also, check out World Machine: http://students.washington.edu/sschmitt/world/ it does some pretty cool terrain generation by letting you construct a DAG of terrain mutators. Again, it's perlin noise based. it's a lot of fun to just play around with anyway, even if it's not what you're looking for.... ;) HTH, charles nicholson sammy studios Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of David Clyde Sent: Wednesday, April 30, 2003 2:58 AM To: gdalgorithmslist@... Subject: [Algorithms] Fw: Terrain Generation Recently I have been working on some terrain generation. I have been doing some research on different methods of doing so and I am currently using a method that involves randomly adding semispheres heights around the map. Its very similar to http://www.robotfrog.com/3d/hills/hill.html where I was exposed to the idea. I have found that by tweaking the iterations, min/max random radii and the overall min/max heights after I normalize the heights and run some filters on them, that I can get some terrain that is close to what I want. The problem in this is that I cant seem to find a pattern between the tweaked settings to get an easily adjustable terrain. What I am striving for is something that generates a range of terrain from semi/nearly flat like an open field with some bumps to rolling hills. I have checked out a couple games and one I am using for reference is Medieval Total War's terrain. The problems I am commonly getting with the semisphere method is I will get portions of good terrain and then moguls. Another thing is that I cannot find a smoothing method that will leave the good steady hills alone, smooth out some of the lowmiddle/bumpy land for large groups of actor movement, and yet still leave some lower areas for possible lakes. A couple things I have thought of are:  Using perlin noise to generate height rings (well not circular rings but I cannot think of the name) and using those to generate the different heights of the terrain.  Randomly seeding the terrain with a small number (maybe 610) points which are assigned semi random heights designed to result in the wanted terrain type. I would then interpolate their influence on other areas of the terrain. Unfortunately I cannot think of a good way to do this without everything looking too roundish. Anyone have any suggestions? PS: I cant seem to find where to search the archives of this list for the life of me. Can someone toss me a link? 
From: Tony Cox <tonycox@mi...>  20030430 16:54:55

>"And obviously we have to be talking about a fixed frame=20 >of reference  which object space isn't (since the object=20 >is rotating)." > >Argh, definition inferno. The above statement can be interpreted in two ways. Object space _is_ a fixed >frame of reference with reference to the object (provided it's a rigid body); it is rigidly attached to >the object. Ofcourse, the "fixed frame of reference" Tony is talking about, is then worldspace, the=20 >space that sees the object rotating. Yes, I was a little sloppy here. Actually, it occurred to me that one source of Richard's confusion may be that he is applying his intuition about linearly moving frames, and assuming it all carries over unchanged to rotating frames. This isn't quite true. Consider whether momentum is conserved in a frame. Clearly, if my frame of reference is moving with constant linear velocity, and I observe the linear momentum of an object which has no forces applied to it, then I will observe that momentum to be constant. However, if my frame is accelerating, this is no longer true, I will observe a changing momentum for the object, even though no forces are applied to it. Now consider a rotating frame. Track the motion of one particle in a rotating object  its velocity is always changing, i.e. it is *accelerating*. A rotating frame is an accelerating frame. And relative to an accelerating frame, you cannot say that momentum is unchanged if no force is applied. This is where Richard I think is falling down. He assumes that if you transform everything into object space, then you can apply your knowledge about how torques affect angular momenta in that frame. But you can't, because a rotating frame is accelerating. You have to do your computations in a nonaccelerating frame. A good choice would be world space. Tony Cox  Development Lead, Hockey Microsoft Games Studios  Sports 
From: Guillaume Provost <Guillaume@ps...>  20030430 16:10:56

Charles, We do (for the moment atleast) the same thing as everybody else ;). We collide a (nonapproximated) convex decomposition of the stairs with a capsule like sensor around the biped, accumulating contacts to = gives us a smoothed ground normal. We then physically correct the individual feet position to hit the stairs using smaller 'ball' sensors around the feet. We then correct the pelvis/chest positions to stabilize the center of mass. All corrections are made at physics time, and layer on top of the animation data. We do not simulate bipeds by modelling the feet as a dual support mechanism. Guillaume Provost 3D Graphics Programmer, Pseudo Interactive. =09 Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Charles Bloom Sent: Tuesday, April 29, 2003 9:51 PM To: gdalgorithmslist@... Subject: Re: [Algorithms] Physics and stairs These are the standard old tricks, but what do people do who are using = a=20 "real" physics engine? What would Dave Wu do? At 05:59 PM 4/29/2003 0700, phil_wilkins@... wrote: >What we did (and what I've seen other people do) was, upon colliding = with >something that looks like it might be a step, to try another move = offset >vertically by the maximum step height, and then, if successfull, cast = down >again to see just how high the step actually was. > >Cheers, >Phil > >PS IIRC there's an instructive thread somewhere in the archives about = this. >Doesn't Halo do it by having ramps over the actual stairs? Only using = the >actual stair geometry to fix up the feet for rendering purposes. > > > > > "Leonel A." > <caoss001@... > om.mx> = To > Sent by: = gdalgorithmslist@... > gdalgorithmslist .net > admin@... = cc > ceforge.net > = Subject > [Algorithms] Physics and = stairs > 04/29/2003 05:34 > PM > > > Please respond to > gdalgorithmslist > @lists.sourceforg > e.net > > > > > > > >Hi all > I like to make a First Person Shooter, and for that, I have done a >physics simulator who work nicely for moving or resting objects. I = made the >player to move according to physics, If he need to move forward, I = apply a >force and in response, he moves. Till now, all work fine, he clamp = hills, >jump, fall. But I need to clamp an stair right now, and when the = player >bounding box collide the first stair step, the collision system return = an >opositive collision normal, so, the box bounce backward instead of = jump or >clamp as it does when a hill is found. > Is it a good idea to make the player a physic body? or is best = just >simulate the physics on it? Any way, could some one explain how that = FPS >clamp stairs with out cheating the collision system. > >Cheers > Leonel > > > >Do You Yahoo!? >Yahoo! Net: La mejor conexi=F3n a internet y 25MB extra a tu correo = por $100 >al mes. > > > > > >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_ida88  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_ida88 
From: Willem H. de Boer <Willem@mu...>  20030430 15:44:41

"And obviously we have to be talking about a fixed frame of reference  which object space isn't (since the object is rotating)." Argh, definition inferno. The above statement can be interpreted in two ways. Object space _is_ a fixed frame of reference with reference to the object (provided it's a rigid body); it is rigidly attached to the object. Ofcourse, the "fixed frame of reference" Tony is talking about, is then worldspace, the space that sees the object rotating. Willem 
From: Tony Cox <tonycox@mi...>  20030430 15:23:16

>but I am not diagonalising the matrix, I am just using the x,y,z >axes as my tensor. There is accuracy degradation, not much normally, >but under certain situations, it could cause big problems. So I >design the data to fit the engine. When you say 'accuracy degradation', most people think you're making = some minor approximation. But you're doing something which is just flat = out wrong. It may give 'spinny looking' results, and maybe that's good = enough for you, but it's not physically accurate. I think your posts = have been misleading to someone looking for advice on how to do it = right. >> So when you say you are using a 3element vector to represent >> the inertia tensor, what you are _really_ doing is storing the >> three diagonal entries of the diagonalised inertia tensor in >> object space. This is totally accurate and correct, there is >> no loss of data. > >unless the inertia tensor is not axis aligned already. Actually, by appropriate choice of axes, you can always diagonalise the = inertia tensor (inertia tensors are symmetrical, and therefore have = perpendicular eignevectors). Of course, that doesn't really help with = storage, because you'd still need to store the axes. >> Things will start to go a bit wrong when you need to transform >> to worldspace. You will have to need to use a proper 3x3 matrix >> to represent the inertia tensor's components if you want any kind >> of real rigid body simulation. > >but I don't transform TO worldspace, I trasform the force/torque to >object space... That's all well and good, but you're missing some steps. You also have = to then transform the angular momentum to object space. Remember that = angular momentum is conserved in world space, not object space. So even = with no torque applied, the angular momentum in object space will change = as object space changes relative to world space. You can then work back to an instantaneous angular velocity in object = space, which you then have to transform back to world space. Since the = object is rotating, this will change over time, even if no torque is = applied. And you still have to do two transforms here. I think you're still suffering from some confusion about what space all = your quantities are in, and when you can say quantities are conserved = and when you can't. The only relevant quantity which is conserved (i.e. stays constant if no = force/torque is applied) is angular momentum. And obviously we have to = be talking about a fixed frame of reference  which object space isn't = (since the object is rotating).  Tony 
From: Tony Cox <tonycox@mi...>  20030430 15:10:40

>> You method is certainly simple, but it only works if the >> inertia tensor is the identity. Which is true for uniformly >> dense spheres or cubes, and not generally true otherwise. > >inertial tensor in my book (not the accurate book) is a three >element vector. principle axes only. >what you are talking about is the accurate and correct method. The inertia tensor is not a three element vector. It is true that by = appropriate choice of axes, you can make the inertia tensor into a = diagonal matrix, but that's not quite the same thing. >> No, no it can't. Consider a nonsymmetrical rotating object, >> with no torque applied. It's axis of rotation can change (and >> indeed *will* change, unless it happened to already be >> rotating about a principal axis). Therefore its angular >> acceleration can be nonzero. And yet the applied torque is >> zero. Your reasoning is incorrect. > >this I don't understand at all, if there is no force, then the >torque vector will be zero, and whatever you multiply it by it >will be zero... Yes, that's true. The torque will be zero. The change in the angular = *momentum* will be zero. However, the change in the angular velocity may = well be nonzero, since the object is rotating. This can easily be seen = by considering the equation linking angular momentum with angular = velocity, for an intertia tensor specified in object space: AMom =3D WorldMatrix * InertiaTensor * InvWorldMatrix * AVel Those WorldMatrix terms are there to transform into the appropriate = space. The angular velocity and momentum are specified in world space. = The inertia tensor is typically specified in object space. Therefore, = you need to pre and post multiply the tensor by the (inverse) world = matrix, in order to make sure we're consistent about our spaces. This = pre and post multiply is characteristic of tensors, and is called the = tensor transform. Now, since the object is rotating, the world matrix changes. But if the = angular momentum is constant, in world space, that must mean that the = angular velocity changes, in world space (except in the case where the = axis of rotation is one of the eigenvectors of the inertia tensor). Does this make sense now? >unless you mean by modifying the inertial tensor, and in my book >that is a nono... Your book clearly never considers rotating objects. The tensor needs to = be transformed from the frame of reference where it is specified = (typically object space), into the frame of reference where you are = doing your calculation. This involves a transformation which changes as = the object rotates. >sorry, but I don't use matrix based interial tensors... too >little benefit for too much data and time... this is >GAMEdevalgos. Okay, well if you want to do something that's physically incorrect, then = go right ahead. Maybe it produces pleasing results for your game. = However, I know of many games that *do* do this correctly. And there are = people that would like to know how. If you're going to present a = noncorrect solution, please state that loud and clear up front  your = original posts implied that your procedure was correct, which is highly = misleading to someone without expertise in the subject. >Oh and by the way, the offset from the object origin means >that the tensor doesn't need to be multiplied by world matrix, >because the point of force application has already been >transformed to object space. Er, no. Computing the torque in object space is not especially useful, = since angular momentum is not conserved in object space, it's conserved = in world space (or any other fixed frame). You clearly don't understand this at all. >> Your procedure is simple, but it is also wrong. I make no >> apology for correcting it. >>  Tony > >I would agree with you but, I cannot say my method is wrong, it >is merely not accurate to real world phsyics.=20 Well, I say that your method is wrong *because* it is not accurate to = real world physics. What definition of 'wrong' were you using? >this does not mean >it is unusable. My method, and I am sure others are using it too, >is simple, fast, and REASONABLY accurate. As I said earlier, this >is GAME dev algos, and as such I personally think speed and >acceptability are more important than complete accuracy. If you're going to present an approximation, then say so. Don't present = your method as correct (which is what you were doing), when clearly it = isn't. And if you're going to present an approximation, please indicate = how it deviates from the correct solution, and what tradeoffs are = involved. You didn't do any of that. As it happens, your approximation is not an especially good one, but for = certain games where realism is unimportant it *may* produce acceptable = results. More and more developers these days *are* choosing to do the = right thing, though.  Tony 
From: Jeremiah Zanin <jeremiah@ou...>  20030430 13:58:39

Do you use gravity to keep the ellipsoid on the ground? jeremiah Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Glenn Fiedler Sent: Tuesday, April 29, 2003 11:06 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Physics and stairs if you model running movement with forces and a proper particle physics simulation vs. just move along the polygon this way, you'll reach a point around about knee height for which the force supplied to push the character up the stairs becomes greater than that supplied, so you can avoid these problems 
From: Christopher Phillips <cphillips@re...>  20030430 13:30:46

Richard Fabian wrote: > Tony Cox wrote: > > > > No, no it can't. Consider a nonsymmetrical rotating object, > > with no torque applied. It's axis of rotation can change (and > > indeed *will* change, unless it happened to already be > > rotating about a principal axis). Therefore its angular > > acceleration can be nonzero. And yet the applied torque is > > zero. Your reasoning is incorrect. > > this I don't understand at all, if there is no force, then the > torque vector will be zero, and whatever you multiply it by it > will be zero... This is true. In this instance, there is no force, and the torque vector is indeed zero. Hence, the angular momentum stays constant  in _world space_. However, the inertial tensor is constant in body space. As the object rotates, any uneven scaling of the torque by the inertial tensor will operate in different directions, leading to a change in the angular velocity vector. Tada  an angular acceleration. > > > > Your procedure is simple, but it is also wrong. I make no > > apology for correcting it. > >  Tony > > I would agree with you but, I cannot say my method is wrong, it > is merely not accurate to real world phsyics. this does not mean > it is unusable. My method, and I am sure others are using it too, > is simple, fast, and REASONABLY accurate. As I said earlier, this > is GAME dev algos, and as such I personally think speed and > acceptability are more important than complete accuracy. > Here I agree with you, Richard. I actually got this wrong in Driver 1 & 2, but the biggest problem with the physics in those games is not the resulting lack of precession, but the failure of the collision resolution to cope gracefully with the high speed collisions inflicted by some of our more violent nonplayervehicles ;) Cheers, Christopher Phillips.  Virus scanned and cleared ok 
From: Richard Fabian <algorithms@th...>  20030430 11:26:12

> >inertial tensor in my book (not the accurate book) is a three > >element vector. principle axes only. what you are talking > >about is the accurate and correct method. > > Well, actually, the inertia (no "l" at the end please) tensor > can always be made to be a three element vector (or rather: a > diagonal matrix. Which is a matrix with only nonzero elements > in the diagonal entries. And ofcourse, such a 3x3 matrix can be > completely accurately represented by a 3element vector), in its > own object space. This is the coordinate system that is rigidly > attached to the object. but I am not diagonalising the matrix, I am just using the x,y,z axes as my tensor. There is accuracy degradation, not much normally, but under certain situations, it could cause big problems. So I design the data to fit the engine. > So when you say you are using a 3element vector to represent > the inertia tensor, what you are _really_ doing is storing the > three diagonal entries of the diagonalised inertia tensor in > object space. This is totally accurate and correct, there is > no loss of data. unless the inertia tensor is not axis aligned already. > Things will start to go a bit wrong when you need to transform > to worldspace. You will have to need to use a proper 3x3 matrix > to represent the inertia tensor's components if you want any kind > of real rigid body simulation. but I don't transform TO worldspace, I trasform the force/torque to object space... > This only requires two matrix multiplies, and one "transposition" > of a matrix per object. Let me ask you: This is not too bad on modern > hardware, is it? nope, and you only have to add one transform per force acting upon the object. > Willem > > >  > 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: Mark Wayland <Mwayland@to...>  20030430 10:14:07

You can always switch collision geometries dynamically depending on the = situation... Cheers, Mark > Original Message > From: Glenn Fiedler [mailto:glenn@...] > Sent: Wednesday, 30 April 2003 7:14 PM > To: gdalgorithmslist@... > Subject: RE: [Algorithms] Physics and stairs >=20 >=20 > its likely we may choose to use a cylinder and the push up=20 > for the more standard walk physics sequences if these=20 > problems are bad, however, for the skiing at jetting, the=20 > sliding is actually the desired behavior, so an ellipsoid is=20 > ideal for us here, >=20 > cheers >=20 > Original Message > From: Mark Wayland [mailto:Mwayland@...] > Sent: Wednesday, 30 April 2003 6:59 PM > To: gdalgorithmslist@... > Subject: RE: [Algorithms] Physics and stairs >=20 >=20 > The problem we found with capsule or ellipsoid collisions was=20 > with sliding off edges of steps and cliffs  > it's okay if that's what you want, but try crossing a thin=20 > beam  you slip all over the place. We made an > obstacle course to test crouching, jumping, walking up=20 > varying slopes, walking through a 'V' pipe, > sliding etc. We found a cylinder gave us the best and most=20 > stable results, but YMMV... >=20 > Obvious stuff: > Either tweak the inertia tensor or setup some form of=20 > constraint to keep the player object vertical. You > may need to relax them if your game enables the player to=20 > lean. If you can crouch and then stand, make > sure your player's "head" doesn't go through geometry. You=20 > may want to do a "crouch jump" where instead > of bringing the head down, you move the feet up, enabling the=20 > player to jump into tight spots. > If you have doors that are opened, then check to make sure=20 > that the player being squashed against wall > is handled (or avoided). Ladders are interesting too... >=20 > Cheers, > Mark >=20 >=20 > > Original Message > > From: Glenn Fiedler [mailto:glenn@...] > > Sent: Wednesday, 30 April 2003 12:18 PM > > To: gdalgorithmslist@... > > Subject: RE: [Algorithms] Physics and stairs > >=20 > >=20 > > i would recommend having an ellipsoid collision volume and=20 > > properly handling grazing collisions  this is the approach=20 > > we are taking for stairs, bumps etc. in tribes3 > >=20 > > Original Message > > From: Charles Bloom [mailto:cbloom@...] > > Sent: Wednesday, 30 April 2003 11:51 AM > > To: gdalgorithmslist@... > > Subject: Re: [Algorithms] Physics and stairs > >=20 > >=20 > >=20 > > These are the standard old tricks, but what do people do who=20 > > are using a=20 > > "real" physics engine? What would Dave Wu do? > >=20 > > At 05:59 PM 4/29/2003 0700,=20 > phil_wilkins@... wrote: > >=20 > >=20 > >=20 > >=20 > > >What we did (and what I've seen other people do) was, upon=20 > > colliding with > > >something that looks like it might be a step, to try another=20 > > move offset > > >vertically by the maximum step height, and then, if=20 > > successfull, cast down > > >again to see just how high the step actually was. > > > > > >Cheers, > > >Phil > > > > > >PS IIRC there's an instructive thread somewhere in the=20 > > archives about this. > > >Doesn't Halo do it by having ramps over the actual stairs?=20 > > Only using the > > >actual stair geometry to fix up the feet for rendering purposes. > > > > > > > > > > > > > > > "Leonel A." > > > <caoss001@... > > > om.mx> =20 > > To > > > Sent by: =20 > > gdalgorithmslist@... > > > gdalgorithmslist .net > > > admin@... =20 > > cc > > > ceforge.net > > > =20 > > Subject > > > [Algorithms] Physics=20 > > and stairs > > > 04/29/2003 05:34 > > > PM > > > > > > > > > Please respond to > > > gdalgorithmslist > > > @lists.sourceforg > > > e.net > > > > > > > > > > > > > > > > > > > > > > > >Hi all > > > I like to make a First Person Shooter, and for that, I=20 > > have done a > > >physics simulator who work nicely for moving or resting=20 > > objects. I made the > > >player to move according to physics, If he need to move=20 > > forward, I apply a > > >force and in response, he moves. Till now, all work fine, he=20 > > clamp hills, > > >jump, fall. But I need to clamp an stair right now, and when=20 > > the player > > >bounding box collide the first stair step, the collision=20 > > system return an > > >opositive collision normal, so, the box bounce backward=20 > > instead of jump or > > >clamp as it does when a hill is found. > > > Is it a good idea to make the player a physic body? or=20 > > is best just > > >simulate the physics on it? Any way, could some one explain=20 > > how that FPS > > >clamp stairs with out cheating the collision system. > > > > > >Cheers > > > Leonel > > > > > > > > > > > >Do You Yahoo!? > > >Yahoo! Net: La mejor conexi=F3n a internet y 25MB extra a tu=20 > > correo por $100 > > >al mes. > > > > > > > > > > > > > > > > > >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_ida88 > >=20 > >=20 > >=20 > >  > > 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_ida88 > >=20 > >=20 > >  > > 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_ida88 > >=20 >=20 >=20 >  > 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_ida88 >=20 >=20 >  > 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_ida88 >=20 
From: David Clyde <dclyde@am...>  20030430 09:58:16

Recently I have been working on some terrain generation. I have been = doing some research on different methods of doing so and I am currently = using a method that involves randomly adding semispheres heights around = the map. Its very similar to = http://www.robotfrog.com/3d/hills/hill.html where I was exposed to the = idea. I have found that by tweaking the iterations, min/max random radii and = the overall min/max heights after I normalize the heights and run some = filters on them, that I can get some terrain that is close to what I = want. The problem in this is that I cant seem to find a pattern between = the tweaked settings to get an easily adjustable terrain. What I am striving for is something that generates a range of terrain = from semi/nearly flat like an open field with some bumps to rolling = hills. I have checked out a couple games and one I am using for = reference is Medieval Total War's terrain. The problems I am commonly getting with the semisphere method is I will = get portions of good terrain and then moguls. Another thing is that I = cannot find a smoothing method that will leave the good steady hills = alone, smooth out some of the lowmiddle/bumpy land for large groups of = actor movement, and yet still leave some lower areas for possible lakes. A couple things I have thought of are:  Using perlin noise to generate height rings (well not circular rings = but I cannot think of the name) and using those to generate the = different heights of the terrain.  Randomly seeding the terrain with a small number (maybe 610) points = which are assigned semi random heights designed to result in the wanted = terrain type. I would then interpolate their influence on other areas of = the terrain. Unfortunately I cannot think of a good way to do this = without everything looking too roundish. Anyone have any suggestions? PS: I cant seem to find where to search the archives of this list for = the life of me. Can someone toss me a link? 
From: Willem H. de Boer <Willem@mu...>  20030430 09:16:20

>inertial tensor in my book (not the accurate book) is a three >element vector. principle axes only. what you are talking >about is the accurate and correct method. Well, actually, the inertia (no "l" at the end please) tensor can always be made to be a three element vector (or rather: a diagonal matrix. Which is a matrix with only nonzero elements in the diagonal entries. And ofcourse, such a 3x3 matrix can be completely accurately represented by a 3element vector), in its own object space. This is the coordinate system that is rigidly attached to the object. This is totally accurate and correct, and follows from one of the fundamental and beautiful theorems of linear algebra that states that any real symmetric matrix can be diagonalised. So when you say you are using a 3element vector to represent the inertia tensor, what you are _really_ doing is storing the three diagonal entries of the diagonalised inertia tensor in object space. This is totally accurate and correct, there is no loss of data. Things will start to go a bit wrong when you need to transform to worldspace. You will have to need to use a proper 3x3 matrix to represent the inertia tensor's components if you want any kind of real rigid body simulation. This only requires two matrix multiplies, and one "transposition" of a matrix per object. Let me ask you: This is not too bad on modern hardware, is it? Willem 
From: John Bustard <John.Bustard@JustAddMonsters.com>  20030430 09:15:41

It all depends on what physical properties you want the player to have. In Kungfu Chaos we had fast moving ground surfaces that could be jumped between. In those situations you want to treat the character as an object stuck to the surface. Each frame working out the new speed of the character to travel with the ground and then add the velocity from the characters movement. To deal with stairs we used a lolipop model of the character (sphere with ray cast down) this got the character over most bumps. But often stairs are modelled to have each step more than half way up a character and you just have to mark them as special areas that when hit the player climbs on top of. By modelling the character as an attached object moved through velocity most of the physics interaction can be modelled correctly. For a physics engine integration this represents a game code driven impulse to the player to achieve the desired velocity (probably with some maximum impulse so characters can slide and be pushed about), this impulse represents the friction on the feet and any crazy balancing skills a character has, they can then collide with physical objects and react correctly. John 
From: Glenn Fiedler <glenn@ir...>  20030430 09:15:24

its likely we may choose to use a cylinder and the push up for the more = standard walk physics sequences if these problems are bad, however, for = the skiing at jetting, the sliding is actually the desired behavior, so = an ellipsoid is ideal for us here, cheers Original Message From: Mark Wayland [mailto:Mwayland@...] Sent: Wednesday, 30 April 2003 6:59 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Physics and stairs The problem we found with capsule or ellipsoid collisions was with = sliding off edges of steps and cliffs  it's okay if that's what you want, but try crossing a thin beam  you = slip all over the place. We made an obstacle course to test crouching, jumping, walking up varying slopes, = walking through a 'V' pipe, sliding etc. We found a cylinder gave us the best and most stable = results, but YMMV... Obvious stuff: Either tweak the inertia tensor or setup some form of constraint to keep = the player object vertical. You may need to relax them if your game enables the player to lean. If you = can crouch and then stand, make sure your player's "head" doesn't go through geometry. You may want to = do a "crouch jump" where instead of bringing the head down, you move the feet up, enabling the player to = jump into tight spots. If you have doors that are opened, then check to make sure that the = player being squashed against wall is handled (or avoided). Ladders are interesting too... Cheers, Mark > Original Message > From: Glenn Fiedler [mailto:glenn@...] > Sent: Wednesday, 30 April 2003 12:18 PM > To: gdalgorithmslist@... > Subject: RE: [Algorithms] Physics and stairs >=20 >=20 > i would recommend having an ellipsoid collision volume and=20 > properly handling grazing collisions  this is the approach=20 > we are taking for stairs, bumps etc. in tribes3 >=20 > Original Message > From: Charles Bloom [mailto:cbloom@...] > Sent: Wednesday, 30 April 2003 11:51 AM > To: gdalgorithmslist@... > Subject: Re: [Algorithms] Physics and stairs >=20 >=20 >=20 > These are the standard old tricks, but what do people do who=20 > are using a=20 > "real" physics engine? What would Dave Wu do? >=20 > At 05:59 PM 4/29/2003 0700, phil_wilkins@... wrote: >=20 >=20 >=20 >=20 > >What we did (and what I've seen other people do) was, upon=20 > colliding with > >something that looks like it might be a step, to try another=20 > move offset > >vertically by the maximum step height, and then, if=20 > successfull, cast down > >again to see just how high the step actually was. > > > >Cheers, > >Phil > > > >PS IIRC there's an instructive thread somewhere in the=20 > archives about this. > >Doesn't Halo do it by having ramps over the actual stairs?=20 > Only using the > >actual stair geometry to fix up the feet for rendering purposes. > > > > > > > > > > "Leonel A." > > <caoss001@... > > om.mx> =20 > To > > Sent by: =20 > gdalgorithmslist@... > > gdalgorithmslist .net > > admin@... =20 > cc > > ceforge.net > > =20 > Subject > > [Algorithms] Physics=20 > and stairs > > 04/29/2003 05:34 > > PM > > > > > > Please respond to > > gdalgorithmslist > > @lists.sourceforg > > e.net > > > > > > > > > > > > > > > >Hi all > > I like to make a First Person Shooter, and for that, I=20 > have done a > >physics simulator who work nicely for moving or resting=20 > objects. I made the > >player to move according to physics, If he need to move=20 > forward, I apply a > >force and in response, he moves. Till now, all work fine, he=20 > clamp hills, > >jump, fall. But I need to clamp an stair right now, and when=20 > the player > >bounding box collide the first stair step, the collision=20 > system return an > >opositive collision normal, so, the box bounce backward=20 > instead of jump or > >clamp as it does when a hill is found. > > Is it a good idea to make the player a physic body? or=20 > is best just > >simulate the physics on it? Any way, could some one explain=20 > how that FPS > >clamp stairs with out cheating the collision system. > > > >Cheers > > Leonel > > > > > > > >Do You Yahoo!? > >Yahoo! Net: La mejor conexi=F3n a internet y 25MB extra a tu=20 > correo por $100 > >al mes. > > > > > > > > > > > >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_ida88 >=20 >=20 >=20 >  > 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_ida88 >=20 >=20 >  > 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_ida88 >=20  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_ida88 
From: Mark Wayland <Mwayland@to...>  20030430 08:58:52

The problem we found with capsule or ellipsoid collisions was with = sliding off edges of steps and cliffs  it's okay if that's what you want, but try crossing a thin beam  you = slip all over the place. We made an obstacle course to test crouching, jumping, walking up varying slopes, = walking through a 'V' pipe, sliding etc. We found a cylinder gave us the best and most stable = results, but YMMV... Obvious stuff: Either tweak the inertia tensor or setup some form of constraint to keep = the player object vertical. You may need to relax them if your game enables the player to lean. If you = can crouch and then stand, make sure your player's "head" doesn't go through geometry. You may want to = do a "crouch jump" where instead of bringing the head down, you move the feet up, enabling the player to = jump into tight spots. If you have doors that are opened, then check to make sure that the = player being squashed against wall is handled (or avoided). Ladders are interesting too... Cheers, Mark > Original Message > From: Glenn Fiedler [mailto:glenn@...] > Sent: Wednesday, 30 April 2003 12:18 PM > To: gdalgorithmslist@... > Subject: RE: [Algorithms] Physics and stairs >=20 >=20 > i would recommend having an ellipsoid collision volume and=20 > properly handling grazing collisions  this is the approach=20 > we are taking for stairs, bumps etc. in tribes3 >=20 > Original Message > From: Charles Bloom [mailto:cbloom@...] > Sent: Wednesday, 30 April 2003 11:51 AM > To: gdalgorithmslist@... > Subject: Re: [Algorithms] Physics and stairs >=20 >=20 >=20 > These are the standard old tricks, but what do people do who=20 > are using a=20 > "real" physics engine? What would Dave Wu do? >=20 > At 05:59 PM 4/29/2003 0700, phil_wilkins@... wrote: >=20 >=20 >=20 >=20 > >What we did (and what I've seen other people do) was, upon=20 > colliding with > >something that looks like it might be a step, to try another=20 > move offset > >vertically by the maximum step height, and then, if=20 > successfull, cast down > >again to see just how high the step actually was. > > > >Cheers, > >Phil > > > >PS IIRC there's an instructive thread somewhere in the=20 > archives about this. > >Doesn't Halo do it by having ramps over the actual stairs?=20 > Only using the > >actual stair geometry to fix up the feet for rendering purposes. > > > > > > > > > > "Leonel A." > > <caoss001@... > > om.mx> =20 > To > > Sent by: =20 > gdalgorithmslist@... > > gdalgorithmslist .net > > admin@... =20 > cc > > ceforge.net > > =20 > Subject > > [Algorithms] Physics=20 > and stairs > > 04/29/2003 05:34 > > PM > > > > > > Please respond to > > gdalgorithmslist > > @lists.sourceforg > > e.net > > > > > > > > > > > > > > > >Hi all > > I like to make a First Person Shooter, and for that, I=20 > have done a > >physics simulator who work nicely for moving or resting=20 > objects. I made the > >player to move according to physics, If he need to move=20 > forward, I apply a > >force and in response, he moves. Till now, all work fine, he=20 > clamp hills, > >jump, fall. But I need to clamp an stair right now, and when=20 > the player > >bounding box collide the first stair step, the collision=20 > system return an > >opositive collision normal, so, the box bounce backward=20 > instead of jump or > >clamp as it does when a hill is found. > > Is it a good idea to make the player a physic body? or=20 > is best just > >simulate the physics on it? Any way, could some one explain=20 > how that FPS > >clamp stairs with out cheating the collision system. > > > >Cheers > > Leonel > > > > > > > >Do You Yahoo!? > >Yahoo! Net: La mejor conexi=F3n a internet y 25MB extra a tu=20 > correo por $100 > >al mes. > > > > > > > > > > > >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_ida88 >=20 >=20 >=20 >  > 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_ida88 >=20 >=20 >  > 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_ida88 >=20 
From: Richard Fabian <algorithms@th...>  20030430 08:48:21

> >aliright mister pedantic... > > > >so I forgot about angular mass.... (rotational inertia) > > It's not pedantic, it's very important, because the interia > tensor is not a simple scale factor, it's a tensor, which > means that angular velocity and angular momentum need not > even be in the same direction! I never said is was a scale factor, unless a factor can be three element... erm.. can it? :S > >the point remains, my method is simple and it works, you > need to ADD the > >intertial tensor stuff as a three component multiply, but if they are > >all 1.0f, then you don't. > > You method is certainly simple, but it only works if the > inertia tensor is the identity. Which is true for uniformly > dense spheres or cubes, and not generally true otherwise. inertial tensor in my book (not the accurate book) is a three element vector. principle axes only. what you are talking about is the accurate and correct method. > >torque = forcevector cross pointofaction > >torque can be multipled by the inertial tensor on an element > by element > >basis to create an acceleration. > > No, no it can't. Consider a nonsymmetrical rotating object, > with no torque applied. It's axis of rotation can change (and > indeed *will* change, unless it happened to already be > rotating about a principal axis). Therefore its angular > acceleration can be nonzero. And yet the applied torque is > zero. Your reasoning is incorrect. this I don't understand at all, if there is no force, then the torque vector will be zero, and whatever you multiply it by it will be zero... unless you mean by modifying the inertial tensor, and in my book that is a nono... The original poster never mentioned a change in the intertial tensor... > You also seem to be a little confused about how the inertia > tensor works. What do you mean by 'element by element'? You > realise that it's essentially a matrix multiply, right? And sorry, but I don't use matrix based interial tensors... too little benefit for too much data and time... this is GAMEdevalgos. > that the matrix in question changes as the object rotates > (since the inertia tensor needs to be transformed by the > world matrix of the object)? sure, this I agree with, in fact I agree with everything you say (that I understand), except I personally believe we go to far with this stuff, especially when three element rotational inertia values work so well. Oh and by the way, the offset from the object origin means that the tensor doesn't need to be multiplied by world matrix, because the point of force application has already been transformed to object space. > >and thus acceleration (a vector) can be integrated over time > to create a > >velocity vector. > > I guess, however, as noted above, it's not terribly easy to > compute the angular accleration. It's certainly doesn't work > the way you suggested. The correct procedure is to integrate > torque to compute the change in angular *momentum*, and then > apply the transformed inverse interia tensor at any given > *instant* to produce the *instantaneous* angular velocity. sure, I agree, using the CORRECT method. > >geeze. > > Your procedure is simple, but it is also wrong. I make no > apology for correcting it. >  Tony I would agree with you but, I cannot say my method is wrong, it is merely not accurate to real world phsyics. this does not mean it is unusable. My method, and I am sure others are using it too, is simple, fast, and REASONABLY accurate. As I said earlier, this is GAME dev algos, and as such I personally think speed and acceptability are more important than complete accuracy. 