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

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

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

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

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

_{Jul}

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

_{Dec}

2012 
_{Jan}

_{Feb}
(7) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

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

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

_{Jun}

_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

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

_{Mar}
(2) 
_{Apr}

_{May}
(10) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(3) 
_{Dec}

2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(12) 
_{Nov}

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

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

_{Jun}
(1) 
_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1

2
(5) 
3
(2) 
4
(2) 
5

6
(6) 
7
(32) 
8
(19) 
9
(3) 
10
(17) 
11
(10) 
12
(3) 
13
(8) 
14
(9) 
15
(26) 
16
(13) 
17
(6) 
18
(6) 
19
(3) 
20
(13) 
21
(39) 
22
(24) 
23
(10) 
24
(6) 
25
(1) 
26
(1) 
27
(6) 
28
(25) 
29
(75) 
30
(75) 
31
(69) 

From: <castanyo@ya...>  20030110 23:47:40

Casey Muratori wrote: > I don't really understand what all the fuss is about. Matrices and > quaternions are interchangable so far as rotation is concerned. So why > would anyone be building a matrix of euler angle rotations and then > converting it to a quaternion? Of course! what the hell was I thinking about? Ignacio Castaño castanyo@... ___________________________________________________ Yahoo! Postales Felicita las Navidades con las postales más divertidas desde http://postales.yahoo.es 
From: Ian Elsley <ielsley@ku...>  20030110 23:16:42

Have you thought of defining your "slide position" by more than one location? Instead use 3 or 4 around the foot (or whole model) and define your slide depending on how many are on each surface. Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Charles Bloom Sent: Friday, January 10, 2003 2:35 PM To: gdalgorithmslist@... Subject: [Algorithms] more character motion trouble I'm having some trouble with "slide" surfaces. Essentially every game has this concept  there are "ground" surfaces and "slide" surfaces. Slide surfaces are steeper, and you're not allowed to stand on them, roughly. More pragmatically, you can stand still on a Ground surface. eg. gravity will not move you at all when you're on a Ground surface. In contrast, if you're on a Slide surface, gravity will move you, and you'll slide down it. In many games you also can't apply any more drive when you're on a Slide surface; this is done so you can't scale steep walls and otherwise get out of the playfield. The problem I'm having is that this is such a binary change, and binary changes cause great problems. The biggest problem occurs when you're standing right at the crease between a surface that's Ground and Slide. You can move epsilon in either direction and you'll change between being on a Slide and being on the Ground. Now, we also want to do "Quake Sliding" with character movement; eg. if you put the stick at an angle into a wall, you'll glide along it. If you just do normal velocity clamping with a Slide surface, your velocity will take you up onto the slide surface. In some ways, you want to treat it as if it were vertical. You cannot do that, however, because to do so would require that you know all the edges of intersection between the Slide surfaces and other polygons, and since we have Triangle Soup you might not get a proper 2d polyline of walls around your Ground (among other problems). There is no simple physical model that works here, eg. friction doesn't work. You never want the character to slide on a Ground surface, which he would do with a friction model. I've got a couple of evil things going on. One is that if you're on a Slide surface, I don't immediately start making you slide; instead I try to push you off it (back to Ground presumably). If you get back to ground, you don't slide; you only start sliding if you're on the Slide surface for > 1 second. This is ok, but the epsilon problem bites the other way  when you're barely on ground, you still need to be pushed away from the Slide surface. Anyway, I'm curious how other people deal with this. Largely, 1st person games can ignore a lot of these problems because you can't see your avatar so you can do things that feel good but look really strange. A lot of console games (eg. Jak & Daxter) use handmarked walkable areas, and you can essentially only walk on flat ground. We're trying to allow character motion on triangle soup.  Charles Bloom cbloom@... http://www.cbloom.com  This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Charles Bloom <cbloom@cb...>  20030110 22:35:40

I'm having some trouble with "slide" surfaces. Essentially every game has this concept  there are "ground" surfaces and "slide" surfaces. Slide surfaces are steeper, and you're not allowed to stand on them, roughly. More pragmatically, you can stand still on a Ground surface. eg. gravity will not move you at all when you're on a Ground surface. In contrast, if you're on a Slide surface, gravity will move you, and you'll slide down it. In many games you also can't apply any more drive when you're on a Slide surface; this is done so you can't scale steep walls and otherwise get out of the playfield. The problem I'm having is that this is such a binary change, and binary changes cause great problems. The biggest problem occurs when you're standing right at the crease between a surface that's Ground and Slide. You can move epsilon in either direction and you'll change between being on a Slide and being on the Ground. Now, we also want to do "Quake Sliding" with character movement; eg. if you put the stick at an angle into a wall, you'll glide along it. If you just do normal velocity clamping with a Slide surface, your velocity will take you up onto the slide surface. In some ways, you want to treat it as if it were vertical. You cannot do that, however, because to do so would require that you know all the edges of intersection between the Slide surfaces and other polygons, and since we have Triangle Soup you might not get a proper 2d polyline of walls around your Ground (among other problems). There is no simple physical model that works here, eg. friction doesn't work. You never want the character to slide on a Ground surface, which he would do with a friction model. I've got a couple of evil things going on. One is that if you're on a Slide surface, I don't immediately start making you slide; instead I try to push you off it (back to Ground presumably). If you get back to ground, you don't slide; you only start sliding if you're on the Slide surface for > 1 second. This is ok, but the epsilon problem bites the other way  when you're barely on ground, you still need to be pushed away from the Slide surface. Anyway, I'm curious how other people deal with this. Largely, 1st person games can ignore a lot of these problems because you can't see your avatar so you can do things that feel good but look really strange. A lot of console games (eg. Jak & Daxter) use handmarked walkable areas, and you can essentially only walk on flat ground. We're trying to allow character motion on triangle soup.  Charles Bloom cbloom@... http://www.cbloom.com 
From: Wolfgang Engel <wolfgang.engel@we...>  20030110 21:50:31

The source for this function is not available, but it might look like this: D3DXQUATERNION * D3DXQuaternionRotationYawPitchRoll ( D3DXQUATERNION * pOut, FLOAT yaw, FLOAT pitch, FLOAT roll) { FLOAT sinY, cosY, sinP, cosP, sinR, cosR; sinY = sin(0.5f * yaw); cosY = cos(0.5f * yaw); sinP = sin(0.5f * pitch); cosP = cos(0.5f * pitch); sinR = sin(0.5f * roll); cosR = cos(0.5f * roll); pOut>x = cosR * sinP * cosY + sinR * cosP * sinY; pOut>y = cosR * cosP * sinY  sinR * sinP * cosY; pOut>z = sinR * cosP * cosY  cosR * sinP * sinY; pOut>w = cosR * cosP * cosY + sinR * sinP * sinY; return pOut; }  Wolf gdalgorithmslist@... schrieb am 10.01.03 22:13:46: > I don't really understand what all the fuss is about. Matrices and > quaternions are interchangable so far as rotation is concerned. So why > would anyone be building a matrix of euler angle rotations and then > converting it to a quaternion? If you want Yaw * Pitch * Roll, then just > build the quaternions and multiply them. This will do the exact same > thing as compositing Yaw * Pitch * Roll matrices. Even the order is the > same. This is the whole concept behind quaternions for rotation in the > first place: they do the same thing as matrices. > > To be more explicit, you have > > P = [Sin(Pitch/2), 0, 0, Cos(Pitch/2)] > Y = [0, Sin(Yaw/2), 0, Cos(Yaw/2)] > R = [0, 0, Sin(Roll/2), Cos(Roll/2)] > > Q = YPR > > You can do this on the fly, or you can precompute what YPR is > algebraicly, and make something that builds the four elements of Q > directly from the input angles if you're concerned about the performance. > If you want an alternate Euler angle ordering, then just change the order > of multiplication. > > Also note that I have not implied a sign or a handedness or any of that > here, and I arbitrarily chose the axes for each quantity to be expressed > in (you could freely permute the variables if your axes are different). > >  Casey > > > >  > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > 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...>  20030110 21:03:43

I don't really understand what all the fuss is about. Matrices and quaternions are interchangable so far as rotation is concerned. So why would anyone be building a matrix of euler angle rotations and then converting it to a quaternion? If you want Yaw * Pitch * Roll, then just build the quaternions and multiply them. This will do the exact same thing as compositing Yaw * Pitch * Roll matrices. Even the order is the same. This is the whole concept behind quaternions for rotation in the first place: they do the same thing as matrices. To be more explicit, you have P = [Sin(Pitch/2), 0, 0, Cos(Pitch/2)] Y = [0, Sin(Yaw/2), 0, Cos(Yaw/2)] R = [0, 0, Sin(Roll/2), Cos(Roll/2)] Q = YPR You can do this on the fly, or you can precompute what YPR is algebraicly, and make something that builds the four elements of Q directly from the input angles if you're concerned about the performance. If you want an alternate Euler angle ordering, then just change the order of multiplication. Also note that I have not implied a sign or a handedness or any of that here, and I arbitrarily chose the axes for each quantity to be expressed in (you could freely permute the variables if your axes are different).  Casey 
From: Fong, Jay <JFong@Blackisle.com>  20030110 20:55:34

I'd love a copy of this pdf too please! Thanks! > Original Message > From: y o g i w p [mailto:yogiwp2@...] > Sent: Tuesday, January 07, 2003 8:02 PM > To: gdalgorithmslist@... > Subject: Re: [Algorithms] PVS Generation. > > >  Original Message  > From: "Charles Nicholson" <cnicholson@...> > > > > Seth Teller's Ph.D. thesis discusses generating perfect PVS > sets using > > portal penumbra/antipenumbra 'stabbing rays'. I don't remember > > seeing his thesis online, but I know the ACM has it > somewhere (I got a > > hard copy of the 200+page work a while back, since lost it =[ ) > > I got his '92 dissertation titled "Visibility Computations in > Densely Occluded Polyhedra Environments" in pdf (340K). Mail > me if anyone interested. > > > > >  > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something > 2 See! http://www.vasoftware.com > _______________________________________________ > GDAlgorithmslist mailing list GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: <castanyo@ya...>  20030110 18:37:16

Ignacio Castaño wrote: > Now that I think about this, it's completely wrong, so ignore it. :) Ok, after looking on my code, this is how I've done that in the past:  Compute the matrix that correspond to the euler rotations.  Extract the quaternion from the rotation matrix. Well, this is an obvious solution, but at least it is 'correct'. Ignacio Castaño castanyo@... ___________________________________________________ Yahoo! Postales Felicita las Navidades con las postales más divertidas desde http://postales.yahoo.es 
From: <castanyo@ya...>  20030110 18:09:24

Ignacio Castaño > You can do this using the yaw and pitch to build an axis and using the roll > as the angle around that axis. > This heavily depends on the order that you apply the rotations. Now that I think about this, it's completely wrong, so ignore it. :) Ignacio Castaño castanyo@... ___________________________________________________ Yahoo! Postales Felicita las Navidades con las postales más divertidas desde http://postales.yahoo.es 
From: Ron Levine <ron@do...>  20030110 17:57:16

On Fri, 10 Jan 2003 15:35:35 0000, you wrote: >Ignacio has already answered this question, but IMHO it deserves some = more >attention. > Actually, he has not >>This heavily depends on the order that you apply the rotations. > >IIRC, confusing factors also include handedness of matrices (left or >righthand rule), handedness of rotations (left or righthand grip = rule), >where we measure an angle from and exactly what we mean by up :) > This statement contains a bit of nonsense. Matrices don't have handedness, but nonsingular matrices may be handednesspreserving or handednessreversing, according to the sign of the determinant. Rotations do not have handedness. All rotations are handedness preserving. The axis/angle convention, however, does involve a hand convention, so mapping an axis/angle description to a rotation does involve a handconvention. Thus with a given hand convention a given rotation has two different axis/angle descriptions, the sense of the axis and the sign of the angle both differing between them. This ambiguity corresponds to the fact that a given rotation has two different quaternion representations. Considering the possibility of two different handconventions, a given rotation has four different axis/angle descriptions. >As Ignacio says, it's trivial to build a quat from an axis+angle pair = but >deciding which axis we want is the awkward part.=20 We can't "decide" what undirected axis (i.e. line) to choose, because that is a geometric invariant of the resultant rotation. Having determined that line, we are free to choose from the two possible senses for it, and for fixed hand convention, that will give us two different axis/angle descriptions and two different quaternions, negatives of each other. As I stated in another post, determining the (undirected) axis is essentially solving for the eigenvector of the rotation matrix. >Having decided what rules >to use, the code falls out of some basic trig  just like back in the = day, >before all these new fangled matrices and quats. > You need more than trig. You need eigenvector theory, which comes in the later part of an elementary linear algebra course, to get the axis. Once you have the axis, determining the angle may be said to be a problem in basic trig. >By way of example... > >Lets say I'm standing at the origin looking forward along the z axis, = the y >axis is pointing up and the x axis to my right. > >If I now move to look straight down at the xz plane (x pointing right, z >pointing up), my unrotated unit axis is pointing straight up with the = global >vector [ 0 , 0 , 1 ].=20 > >I'm going to apply yaw about the local y axis using the righthand grip >rule, so this vector will rotate counterclockwise as I view it. My new = unit >yaw vector is [ sin(yaw) , 0 , cos(yaw) ]. > >Next I want to apply pitch about the local x axis, so I move to view the >plane formed by my yaw axis pointing right and the global y axis = pointing >up. Moving counterclockwise again, my yawpitch vector becomes [ >sin(yaw)cos(pitch) , sin(pitch) , cos(yaw)cos(pitch) ]. > >This vector can now be used as the axis, together with roll as the = angle, to >a standard function that creates a quat from and angle+axis pair (using = the >righthand grip rule, of course :) > =46ollowing Ignacio, that is quite incorrect. That axis is not, in general, the axis of the resultant rotation. >Original Message >From: Ignacio Castano [mailto:castanyo@...] >Sent: Friday, January 10, 2003 2:32 PM >To: gdalgorithmslist@... >Subject: Re: [Algorithms] D3DXQuaternionRotationYawPitchRoll > > >Wolfgang Engel wrote: >> There is a Direct3D utility function, that creates a quaternion out = from >yaw, pitch and roll to build up a quaternion as an axisangle = representation >of angular displacement. >> There are some open source implementations of this function in the >internet. I would like to understand how the quaternion is created in = these >functions. I wasn't successful by looking into the source. Any hint = would be >very much appreciated. > >You can do this using the yaw and pitch to build an axis and using the = roll >as the angle around that axis. >This heavily depends on the order that you apply the rotations. > > >Ignacio Casta=F1o >castanyo@... > > > >This SF.NET email is sponsored by: >SourceForge Enterprise Edition + IBM + LinuxWorld =FFomething 2 See! >http://www.vasoftware.com >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_ida88 
From: Oscar Cooper <oscar.cooper@cr...>  20030110 15:44:37

Ignacio has already answered this question, but IMHO it deserves some = more attention. >This heavily depends on the order that you apply the rotations. IIRC, confusing factors also include handedness of matrices (left or righthand rule), handedness of rotations (left or righthand grip = rule), where we measure an angle from and exactly what we mean by up :) As Ignacio says, it's trivial to build a quat from an axis+angle pair = but deciding which axis we want is the awkward part. Having decided what = rules to use, the code falls out of some basic trig  just like back in the = day, before all these new fangled matrices and quats. By way of example... Lets say I'm standing at the origin looking forward along the z axis, = the y axis is pointing up and the x axis to my right. If I now move to look straight down at the xz plane (x pointing right, = z pointing up), my unrotated unit axis is pointing straight up with the = global vector [ 0 , 0 , 1 ].=20 I'm going to apply yaw about the local y axis using the righthand grip rule, so this vector will rotate counterclockwise as I view it. My new = unit yaw vector is [ sin(yaw) , 0 , cos(yaw) ]. Next I want to apply pitch about the local x axis, so I move to view = the plane formed by my yaw axis pointing right and the global y axis = pointing up. Moving counterclockwise again, my yawpitch vector becomes [ sin(yaw)cos(pitch) , sin(pitch) , cos(yaw)cos(pitch) ]. This vector can now be used as the axis, together with roll as the = angle, to a standard function that creates a quat from and angle+axis pair (using = the righthand grip rule, of course :) Original Message From: Ignacio Castano [mailto:castanyo@...] Sent: Friday, January 10, 2003 2:32 PM To: gdalgorithmslist@... Subject: Re: [Algorithms] D3DXQuaternionRotationYawPitchRoll Wolfgang Engel wrote: > There is a Direct3D utility function, that creates a quaternion out = from yaw, pitch and roll to build up a quaternion as an axisangle = representation of angular displacement. > There are some open source implementations of this function in the internet. I would like to understand how the quaternion is created in = these functions. I wasn't successful by looking into the source. Any hint = would be very much appreciated. You can do this using the yaw and pitch to build an axis and using the = roll as the angle around that axis. This heavily depends on the order that you apply the rotations. Ignacio Casta=F1o castanyo@... 
From: Ron Levine <ron@do...>  20030110 15:41:21

Ignacio Casta=F1o wrote: >Wolfgang Engel wrote: >> There is a Direct3D utility function, that creates a quaternion out = from >yaw, pitch and roll to build up a quaternion as an axisangle = representation >of angular displacement. >> There are some open source implementations of this function in the >internet. I would like to understand how the quaternion is created in = these >functions. I wasn't successful by looking into the source. Any hint = would be >very much appreciated. > >You can do this using the yaw and pitch to build an axis and using the = roll >as the angle around that axis. >This heavily depends on the order that you apply the rotations. > But of course, the roll about the roll axis is NOT the axis/angle of the rotation in question, the rotation represented by the yaw, pitch roll sequence (in some specified order) and also represented by the sought quaternion. One cannot give a specific answer to the OP's question without seeing the source code to which he his referring. However, the straightforward way to get the quaternion from the ypr sequence is first to get the rotation matrix for the resultant rotation by multiplying the elementary rotation matrices of the three Euler angle components, and, second, to extract the axis/angle of the resultant rotation from that matrix, essentially by solving the eigenvector problem. The axis of a rotation is the eigenspace of the corresponding rotation matrix (belonging to its one and only eigenvalue 1) . You can find in various publications formulas that result from that eigenvector solution. 
From: <castanyo@ya...>  20030110 14:29:08

Wolfgang Engel wrote: > There is a Direct3D utility function, that creates a quaternion out from yaw, pitch and roll to build up a quaternion as an axisangle representation of angular displacement. > There are some open source implementations of this function in the internet. I would like to understand how the quaternion is created in these functions. I wasn't successful by looking into the source. Any hint would be very much appreciated. You can do this using the yaw and pitch to build an axis and using the roll as the angle around that axis. This heavily depends on the order that you apply the rotations. Ignacio Castaño castanyo@... ___________________________________________________ Yahoo! Postales Felicita las Navidades con las postales más divertidas desde http://postales.yahoo.es 
From: John Bustard <John.Bustard@JustAddMonsters.com>  20030110 10:13:09

Hi there, How were you going to deal with intersections due to the skeletal animations. Is it enough just to give the attacker a huge mass and limit the distance the animation can move objects each simulation frame. If so you could probably do exactly what you suggest. Has anyone else tried this? My only concern would be that the thrown character would appear a bit lifeless. In our title we have animated throw responses between each of the characters. This means we can have very extravagant and cartoony throws. A lot of beatem 'ups have quite elaborate moves that require canned responses to make them look skillful. Also has anyone tried combining a physics system like ODE in an environment where they might have intersections. Possibly with a pre pass that tries to sort them out? Thanks, John  Original Message  From: "Vadim Macagon" <vadim_mcagon@...> To: "GDA List" <gdalgorithmslist@...> Sent: Friday, January 10, 2003 12:44 AM Subject: [Algorithms] Simulating Grabbing and Throwing > Hi everybody! > > I'm currently working on a 3d game that involves elements of a good old > beatem' up. We're thinking of using ODE for collision response and canned > skeletal animations for the actual moves (like punching, kicking, grabbing > etc.) Currently we're trying to figure out how to simulate grab & throw > moves. > > We were thinking of specifying some "tags" on the characters' bodies, then > during a grab move the "hand" joints of the character doing the grabbing > will be attached to one or two of the tags on the opponent. We'll have to > ensure the characters are the right distance apart and are oriented > correctly before allowing the grab to occur. After that we just play the > canned "throw" animation for the character that just did the grabbing, the > tags will move with the hand joints and the opponent's body should move with > the tags. The actual physical body of the opponent will be simulated in ODE, > so we'll have to figure out some way of getting ODE to do what we need just > by the movement of the tags. > > Well that's my half baked idea, of course since there are plenty of 3d > beatem' ups out there I figured people might have better ideas. So any > links, ideas, comments will be greatly appreciated :) > > > Cheers, > > Vadim. > > >  > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > 
From: Jacob Turner (Core Design Ltd) <JacobT@CoreDesign.com>  20030110 09:08:44

Hi We just use canned animations for grabbing and throwing, once the object being thrown has left the "hands" then a physical simulation takes over e.g. projectile flight + collision response (ragdoll) When the player wants to grab someone then the player control takes over control of both objects and plays the correct animations and moves things to the correct places e.g. player plays grabbing animations, object plays being grabbed animation. We only support one grabbing animation (e.g. from the front) and just move our objects around to get them into the correct position and orientation (these values come from the players grabbing animation which are set by the animators and correspond to the position and orientation of the object the animators have actually used to animate to). Jake Original Message From: Vadim Macagon [mailto:vadim_mcagon@...] Sent: 10 January 2003 00:44 To: GDA List Subject: [Algorithms] Simulating Grabbing and Throwing Hi everybody! I'm currently working on a 3d game that involves elements of a good old beatem' up. We're thinking of using ODE for collision response and canned skeletal animations for the actual moves (like punching, kicking, grabbing etc.) Currently we're trying to figure out how to simulate grab & throw moves. We were thinking of specifying some "tags" on the characters' bodies, then during a grab move the "hand" joints of the character doing the grabbing will be attached to one or two of the tags on the opponent. We'll have to ensure the characters are the right distance apart and are oriented correctly before allowing the grab to occur. After that we just play the canned "throw" animation for the character that just did the grabbing, the tags will move with the hand joints and the opponent's body should move with the tags. The actual physical body of the opponent will be simulated in ODE, so we'll have to figure out some way of getting ODE to do what we need just by the movement of the tags. Well that's my half baked idea, of course since there are plenty of 3d beatem' ups out there I figured people might have better ideas. So any links, ideas, comments will be greatly appreciated :) Cheers, Vadim.  This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Wolfgang Engel <wolfgang.engel@we...>  20030110 07:13:40

There is a Direct3D utility function, that creates a quaternion out from yaw, pitch and roll to build up a quaternion as an axisangle representation of angular displacement. There are some open source implementations of this function in the internet. I would like to understand how the quaternion is created in these functions. I wasn't successful by looking into the source. Any hint would be very much appreciated.  Wolf 
From: y o g i w p <yogiwp2@gm...>  20030110 03:57:34

 Original Message  From: "Andrew Vidler" <avidler@...> > Any ideas on how to implement occluder fusion nicely? If you're referring to dynamic occluders, then there're two methods that I can remember:  Occlusion tree/shadow volume BSP, paper: "Hierarchical Visibility Culling with Occlusion Trees".  Hierarchical occlusion maps, paper: "Visibility Culling using Hierarchical Occlusion Maps". In practice however, both tend to take alot of runtime processing. If anyone had success doing occluder merging I'd really like to hear it. If you're referring to static occluders, then your PVS generation algorithm should take care of them? 
From: Vadim Macagon <vadim_mcagon@ho...>  20030110 00:44:22

Hi everybody! I'm currently working on a 3d game that involves elements of a good old beatem' up. We're thinking of using ODE for collision response and canned skeletal animations for the actual moves (like punching, kicking, grabbing etc.) Currently we're trying to figure out how to simulate grab & throw moves. We were thinking of specifying some "tags" on the characters' bodies, then during a grab move the "hand" joints of the character doing the grabbing will be attached to one or two of the tags on the opponent. We'll have to ensure the characters are the right distance apart and are oriented correctly before allowing the grab to occur. After that we just play the canned "throw" animation for the character that just did the grabbing, the tags will move with the hand joints and the opponent's body should move with the tags. The actual physical body of the opponent will be simulated in ODE, so we'll have to figure out some way of getting ODE to do what we need just by the movement of the tags. Well that's my half baked idea, of course since there are plenty of 3d beatem' ups out there I figured people might have better ideas. So any links, ideas, comments will be greatly appreciated :) Cheers, Vadim. 