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

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

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

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

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

_{Jul}

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

_{Dec}

2012 
_{Jan}

_{Feb}
(7) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

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

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

_{Jun}

_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

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

_{Mar}
(2) 
_{Apr}

_{May}
(10) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(3) 
_{Dec}

2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(12) 
_{Nov}

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

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

_{Jun}
(1) 
_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

2017 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1
(5) 
2
(6) 
3
(15) 
4
(20) 
5
(18) 
6
(4) 
7
(3) 
8
(14) 
9
(21) 
10
(24) 
11
(5) 
12
(12) 
13
(7) 
14

15
(6) 
16
(13) 
17
(1) 
18
(6) 
19
(8) 
20
(6) 
21
(1) 
22
(6) 
23
(11) 
24
(21) 
25
(8) 
26
(15) 
27
(25) 
28
(8) 
29
(19) 
30
(26) 




From: Grisha Spivak <_grisha@tu...>  20020430 06:56:30

> A common mistake when interpolating Quaternions is to forget that there > are two paths that interpolate two Quaternions  the long way around and > the short way around. Preprocess your quaternion sequence to make sure > that the dot product of adjacent quaternions is greater than zero. If > it is not, flip the signs of one of the two quaternions. > > Lars Wilke > Credo Interactive Inc. > Oh, yes. I did this test in SLERP, but forget about it here. Now it works fine.  ЮСИАСWWW  первый правовой стандарт для всех! ПОДКЛЮЧАЙТЕСЬ К ПРАВУ СЕЙЧАС И С ОСОБЫМИ УСЛОВИЯМИ! В новой системе более 25000 нормативных актов, комментариев, справочников, образцов, ВЭД России и т.п. http://www.iparegistr.com/jusias 
From: Jon Watte <hplus@mi...>  20020429 21:14:14

> > 1. Can somebody point at paper or to suggest something about > such technique > > but for rigid bodies, i.e. not only points [...] > > I typically put "objects" inside "areas" separated by "portals". Each area > acts as a container of these objects (and these portals) so that rendering > an area renders all the objects in that room and all the portals > to adjacent > rooms. There's an additional pokethrough problem when you use "warped" geometry though. ASCII art time! Room 1: \ / \____+ppp+_____/ Room 2: /\ /\ / ~~~+ppp+~~ \ / \ If these two room segments (as seen from above) are joined at the "+ppp+" portals, then the geometry "spikes" of room 2 will poke through the walls of room 1. This will not happen with "regular" geometry because the Z buffer will prevent it. A fix for "warped" geometry is to use the stencil buffer, where you increment the stencil value for each level of recursion, and only render if the render stencil value is LESS than the stencil buffer value. Clear stencil to max initially. Cheers, / h+ 
From: <phil_wilkins@pl...>  20020429 20:57:11

George Warner <geowar@...>: > By the time I'm done I've again almost spend enough time on the editor that I could have written it from scratch. We've gone the route of extending our graphics package (in this case Maya, but I understand Max has a fully exposed & extensible API as well), and leveraging it's interface. Worked quite well on our last title, but this one's a bit more involved, so we'll see. I think it's the way to go long term though. Means everyone's working in the same app, and you're not completely buggered when your editor programmer leaves. Cheers, Phil PS Of course this does mean you have to buy everyone on the team a seat for your package, although if you factor the cost of tying up a coder writing an editor, it's a bit more attractive. 
From: George Warner <geowar@ap...>  20020429 19:48:51

On Mon, 29 Apr 2002 15:31:01 +0300, "Sergei Miloikov" <sergei@...> wrote: > 1. Can somebody point at paper or to suggest something about such technique > but for rigid bodies, i.e. not only points [...] I typically put "objects" inside "areas" separated by "portals". Each area acts as a container of these objects (and these portals) so that rendering an area renders all the objects in that room and all the portals to adjacent rooms. > 2. The actual data structures and editing all that! Currently I create a > solid space chunks of geometry sealed with portals and then connect the > chunks  but this is done from the code, the actual connecting of segments > may be done by writing my own editor (bad!), besides there is a problem if > two connected portals' shapes do not fit! And the pure geometrical > connecting from an editor do not work for the case when you want to put > bigger volume inside a smaller one. As much as I liked the 4D net level of marathon I try to keep my models as "real" as possible (no imaginary dimensions); All vertices are in world coordinates; Adjacent areas are separated by portals made up of the same (not just identical) vertices. Thus adjusting the vertice of a portal in one area will adjust the same vertice of its mirror portal in the next area because they are one and the same. Note: individual vertices are loaded, cached and disposed of whenever my viewpoint (usually the player) changes areas. The loading mechanism creates an index on the fly that I then use to pass to OpenGL for rendering or to my physics engine for collision, IK, etc. and these world vertices are kept separate from my local object vertices which are also loaded, cached and unloaded as necessary when I change areas. > From the code that is done by assigning IDs to portals and then doing some > sort of IDx vs IDy connecting with rotation as parameter. So, you can see it > is not userfriendly at all. Your portals need to be much more virtual. Their only real purpose is to segment your worlds data into smaller chunks so your engines aren't as data bound. As far as editors go, I'm really tired of "reinventing the wheel". Every "canned" (off the shelf) editor I've ever used has always fell short on some feature that I've wanted and "writing my own" has always taken every bit as much time as writing the game it supposed to be creating levels for. Ouch! I've "borrowed" editors from other games and "tweaked" them for my use. Again I seem to spend as much time writing utility apps that take their (usually illogical, or outoforder) data and convert it into the format or order that my games expects. By the time I'm done I've again almost spend enough time on the editor that I could have written it from scratch. Hopefully, your mileage will vary... Considerably! ;)  Enjoy, George Warner, Mixed Mode Magic Fragment Scientist Apple Developer Technical Support (DTS) 
From: Lars Wilke <lars@ch...>  20020429 19:25:30

A common mistake when interpolating Quaternions is to forget that there are two paths that interpolate two Quaternions  the long way around and the short way around. Preprocess your quaternion sequence to make sure that the dot product of adjacent quaternions is greater than zero. If it is not, flip the signs of one of the two quaternions. Lars Wilke Credo Interactive Inc. > Original Message > From: gdalgorithmslistadmin@... [mailto:gdalgorithms > listadmin@...] On Behalf Of Grisha Spivak > Sent: Sunday, April 28, 2002 1:15 PM > To: GDAlgorithmslist@... > Subject: [Algorithms] Quaternion map to 4D vector > > I'm looking for implementing smooth camera movement. > Orientation defined as > quaternion. First thing that I tried was simple SLERP but > it looks too > twitched. I found some papers describing how to map > quaternoins to 4D > coordinates, interpolate them, then map back to quaternion. > Now camera > flying very smooth but sometimes it's makes 'roll over the > head' and I don't > know how to fix it. > Here is my code: > void QuatToVect4( vect4 dest, const quat q ) // map > quaternion to 4D > vector > { > float inv_x5 = 1.f/2.f*(float)sqrt( ( 1.f  q[W] )/2.f ); > dest[X] = q[X]*inv_x5; > dest[Y] = q[Y]*inv_x5; > dest[Z] = q[Z]*inv_x5; > dest[W] = ( 1.f  q[W] )*inv_x5; > } > > void Vect4ToQuat( quat dest, const vect4 v ) // map 4D > vector to > quaternion > { > float inv_q5 = 1.f/( v[X]*v[X] + v[Y]*v[Y] + v[Z]*v[Z] + > v[W]*v[W] ); > dest[X] = 2.f*v[X]*v[W]*inv_q5; > dest[Y] = 2.f*v[Y]*v[W]*inv_q5; > dest[Z] = 2.f*v[Z]*v[W]*inv_q5; > dest[W] = ( v[X]*v[X] + v[Y]*v[Y] + v[Z]*v[Z]  v[W]*v[W] > )*inv_q5; > } > // > // interpolation: > // u  interpolation parameter > float a, b, c, d; // CatmullRom spline coefficents > a = u*( 1  u )*( 1  u )*0.5f; > b = 1.f  2.5f*u*u + 1.5f*u*u*u; > c = u*( 0.5f + 2.f*u  1.5f*u*u ); > d = u*u*( 1  u )*0.5f; > > vect4 v0, v1, v2, v3; > QuatToVect4( v0, q0 ); > QuatToVect4( v1, q1 ); > QuatToVect4( v2, q2 ); > QuatToVect4( v3, q3 ); > vect4 res; > res[X] = a*v0[X] + b*v1[X] + c*v2[X] + d*v3[X]; > res[Y] = a*v0[Y] + b*v1[Y] + c*v2[Y] + d*v3[Y]; > res[Z] = ... > res[W] = ... > quat resQuat; > Vect4ToQuat( resQuat, res ); > > // > > ( And sorry for my poor english ) > 
From: Christian Lykawka <business@ja...>  20020429 19:04:05

Hi all, The final solution for my question (tested and works fine) is the following code: #define REAL float #define TWOPI (REAL)6.28318530717958647692528676655901 #define DEGREES_TO_RADIANUS (TWOPI / (REAL)360.0) #define RADIANUS_TO_DEGREES ((REAL)360.0 / TWOPI) void VectorToAngles(REAL *afVec, REAL *pfPitch, REAL *pfYaw) { if(afVec[PX] == 0) { if(afVec[PZ] < 0) *pfYaw = 180; else *pfYaw = 0; } else *pfYaw = RADIANUS_TO_DEGREES * (REAL)atan2(afVec[PX], afVec[PZ]); *pfPitch = RADIANUS_TO_DEGREES * (REAL)asin(afVec[PY]); } void AnglesToVector(REAL fPitch, REAL fYaw, REAL *afVec) { REAL fAngle, fSp, fSy, fCp, fCy; fAngle = fYaw * (PI / (REAL)180.0); fSy = (REAL)sin(fAngle); fCy = (REAL)cos(fAngle); fAngle = fPitch * (PI / (REAL)180.0); fSp = (REAL)sin(fAngle); fCp = (REAL)cos(fAngle); afVec[PX] = fCp * fSy; afVec[PY] = fSp; afVec[PZ] = fCp * fCy; } Thanks! Christian 
From: Chris Haarmeijer <c.haarmeijer@ke...>  20020429 18:10:29

Hi, We're about to implement a coupling between our visualisation system and a tobeimplementedorbought simulation system. We want to support the following couplings via some sort of bridge pattern:  singlethreaded coupling  multithreaded coupling  networked coupling Anybody has any pointers to research done in this area? Chris  Keep IT Simple Software Van Alphenstraat 12 7514 DD Enschede W: http://www.keepitsimple.nl E: mailto:info@... T: +31 53 4356687 
From: phil_wilkins@Playstation.sony.com  20020429 18:03:34

So I've got these two boxes, and I need to know if they collide... ...no, stop hitting me, aaaarghhhh! Cheers, Phil PS Y'know, the right answer to the original question would've been one word, "Trigonometry", and one website, "Google". 
From: Daniel Vogel <vogel@ep...>  20020429 17:49:03

> was wrong. As it turned out, the axis assignment that Christian had > in mind was more standard in the graphics world than Vogel's guess, > EXCEPT for the unorthodox assignment of positive heading angles to > directions west of north. You are right, I should've pointed out that we are using a kind of wacky coordinate system for this. In a world where everyone is a licensee we wouldn't have this problem. *ducks*  Daniel, Epic Games Inc. 
From: Jon Watte <hplus@mi...>  20020429 17:39:54

> 1. Can somebody point at paper or to suggest something about such > technique > but for rigid bodies, i.e. not only points  Unreal and every > engine I know > implement the noneuclidean portal scheme just for point (point > of view), so > if character get a stick and push it through a portal, he/she > won't see the > other end of the stick anywhere else, but only through the portal > he/she is > facing! (imagine the portal rotates the 'space' at 180 degrees at XZ and Actually, I think they do. That's how you do mirrors in a portal engine. The thing is, to make mirrors look good, they clip everything in front of the mirror, so you see things BEYOND the mirror portal, not HITHER of it. It seems to me that the naive portal algorithm: set visibility to viewing frustum paint(): paint current zone within visibility foreach portal visible: recursively paint() with constrained visibility and new transform will work just fine for the "warped physics" you're thinking of. Cheers, / h+ 
From: Ron Levine <ron@do...>  20020429 17:21:47

Graham Rhodes wrote: >Yes, but the pair of angles pitch and yaw can determine the orientation of a >single vector. Only when you add in a third angle, roll, do you get the >orientation of an entire set of bodyaligned principal axes. > Not disputing that two angles can determine the direction of a vector. The question is which two angles and what do you call them. >> Probably, you mean what an astronomer calls "altitude and azimuth" in >> discussing the vector that tells where his telescope is pointing (for >> some types of telescope mounting) > >True. Really, pitch and yaw/altitude and azimuth are different names for the >same thing. > No. Pitch and yaw are most widely used to mean quite a different thing (see below). True, the confusion is not uncommon, but one should not let it pass without comment. >I think the real key is defining which is the pitch/altitude axis and which >is the yaw/azimuth axis. In the notation of airplane design, for example, >the pitch axis is the y axis and the yaw axis is the z axis, with positive y >out the right wing and positive towards the top of the airplane. > Well, the assignment of x,y,z to these axes is not standard, but I do AGREE that these are the standard assignments of "pitch", "yaw", and "roll" to the body axes of the aircraft. There are two important points to make in this connection. First, these are NOT the axes that the OP had in mind. Rather his yaw, was a heading with respect to a direction fixed in the world about an axis fixed in the world, i.e. what is more correctly called "azimuth", or "heading". It had nothing to do with rotations about the body axes of his craft or camera or whatever his object is, which was not stated. Second, for the real pitch, yaw, and roll, there are generally no fixed reference directions by which we can assign absolute values of these angles that will give the orientation of the craft. Rather, we can only talk about rotations about these axes, i.e. changes, or deltas, in these angles, and this concept makes the most quantitative sense when we restrict to small changes, increments, or even infinitesimal changes, for then the order of application of the three Euler stages does not matter, or does not matter very much. And this is one context in which the Euler construction is very useful, because, in typical craftsships, planes, spacecraftsthe torques that produce change of orientation are usually about well defined axes fixed in the body, but not fixed in the world. I elaborate on this in http://www.dorianresearch.com/orientation.htm 
From: Nik Hemmings <nikh@ar...>  20020429 16:57:30

Ron Levine wrote: > Ron Hay wrote: > >> And as for the clarity, I believe there is not a single person on this >> list that didn't understand what Christian wanted, *including* yourself. > > Wrong. If you reread the thread you will see that the first > respondent to give a definitive answer had blah blah blah blah blah... > > Blah blah blah, blah blah blah blah blah blah... > > Etc. Mr Levine, for the sake of this list, please give this up. The question and answers have come and gone. I think it would be reasonable to say noone else on this list cares for your eternal pedantry on this subject. Please just stop. Thanks, Nik Hemmings, Programmer, Argonaut Games Plc. 
From: Ron Levine <ron@do...>  20020429 16:39:07

Ron Hay wrote: > >And as for the clarity, I believe there is not a single person on this list >that didn't understand what Christian wanted, *including* yourself. > Wrong. If you reread the thread you will see that the first respondent to give a definitive answer had interpreted the question wrongly and so gave a wrong or misleading answer. Even if he had interpreted it correctly, it would be wrong to let the incorrect, or at best questionable, nonstandard nomenclature pass without comment. To be clear, we have to guard the meanings of our words, else all our dialogue degenerates into nonsense. There were two parts to the lack of clarity in the question. First, the use of "pitch", "yaw" nomenclature, which is, admittedly and unfortunately not a rare practice. The other was the omission of the choice of axes with respect to which these Euler angles were defined. I referred to both points in my response. Vogel.s guess on the second was wrong. As it turned out, the axis assignment that Christian had in mind was more standard in the graphics world than Vogel's guess, EXCEPT for the unorthodox assignment of positive heading angles to directions west of north. 
From: Graham Rhodes <grhodes@se...>  20020429 16:32:42

Ron wrote, > Please define what you mean by "pitch and yaw angles of a vector"? > These do not have standard definitions. Usually one uses the terms > "pitch" and "yaw" in reference to a frame, not a single vector, and > the most sensible meanings of these words pertain not to angles but to > changes of orientation....not quite the same thing (although that does > not prevent lots of folks from using them imprecisely, so > nonmathematically). Specifically, the usual meanings of "pitch" and > "yaw" pertain to changes in orientation of a body referred to a set of > principal axes of that body. Yes, but the pair of angles pitch and yaw can determine the orientation of a single vector. Only when you add in a third angle, roll, do you get the orientation of an entire set of bodyaligned principal axes. > Probably, you mean what an astronomer calls "altitude and azimuth" in > discussing the vector that tells where his telescope is pointing (for > some types of telescope mounting) True. Really, pitch and yaw/altitude and azimuth are different names for the same thing. I think the real key is defining which is the pitch/altitude axis and which is the yaw/azimuth axis. In the notation of airplane design, for example, the pitch axis is the y axis and the yaw axis is the z axis, with positive y out the right wing and positive towards the top of the airplane. Graham Rhodes 
From: Mark Webster <mark@aw...>  20020429 16:20:07

Could the OTness of this thread PLEASE DIE NOW? And throw in a bit more political correctness while you're at it. Thanks! Mark Webster  Original Message  From: "Andrew Howe" <andrew@...> To: <gdalgorithmslist@...> Sent: Monday, 29 April, 2002 16:42 Subject: Re: [Algorithms] Vector to pitch and yaw > >From: "Ron Hay" <rhay@...> > > (Ron, your "sweetie" must be a saint  "Kiss you? You'll have to be a bit > more > > precise, as you have neither specified the desired anatomical target of > that kiss, > > nor the degree of pressure with which is should be applied." Heh. ;) > > Fuck me! It's Mr. Logic (he's a pain in the arse) out of Viz! 
From: Andrew Howe <andrew@co...>  20020429 15:42:15

>From: "Ron Hay" <rhay@...> > (Ron, your "sweetie" must be a saint  "Kiss you? You'll have to be a bit more > precise, as you have neither specified the desired anatomical target of that kiss, > nor the degree of pressure with which is should be applied." Heh. ;) Fuck me! It's Mr. Logic (he's a pain in the arse) out of Viz! Mr Logic is in charge of the till at the local OffLicense (Drink Shop). Armed Robber: No nonsense. Just give me all your money. Mr Logic: I shall commence by pointing out to you that my demeanour is not one which could be described as nonsensical. Consequently I can attest you have no cause to reprimand me on your first point. On to your second point: Bearing in mind the potentially lethal situation in which I find myself, to wit: your presence in conjuction with the presumably loaded firearm which is presently levelled at my cranium, I will comply with your request comprehensively, albeit reluctantly. Here, twentyseven pence. Armed Robber: Twentyseven pence? Fuck off. There's more than that in the till. Mr Logic: Indeed, undoubtedly so. However your request was for *my* money. The currency in the till belongs to a third party and is therefore not "my money". However, if you are still desirous of said money I would suggest that you rephrase your original statement to recognise and incorporate this important distinction. Armed Robber: "Bang." 
From: Ron Hay <rhay@cy...>  20020429 14:20:35

Ron Levine wrote: > > sky). An aviator would call these angles "attitude and heading" Actually, "attitude" includes both what is commonly called "pitch" and "roll" combined, hence the "attitude indicator" which is the floating ball indicator so popular in movies. And as for the clarity, I believe there is not a single person on this list that didn't understand what Christian wanted, *including* yourself. :D (Ron, your "sweetie" must be a saint  "Kiss you? You'll have to be a bit more precise, as you have neither specified the desired anatomical target of that kiss, nor the degree of pressure with which is should be applied." Heh. ;) 
From: Sergei Miloikov <sergei@ha...>  20020429 12:30:35

I am trying to make an engine that support noneuclidean world geometry, in terms of portals only. So, things like large rooms inside a small buildings, infinite labyrinths and so on will be possible. The main thing I like about it is the warping you may introduce in the levels and the cheap change in the map topology one can archieve by just switching portals. But there is two problems: 1. Can somebody point at paper or to suggest something about such technique but for rigid bodies, i.e. not only points  Unreal and every engine I know implement the noneuclidean portal scheme just for point (point of view), so if character get a stick and push it through a portal, he/she won't see the other end of the stick anywhere else, but only through the portal he/she is facing! (imagine the portal rotates the 'space' at 180 degrees at XZ and then you may see the stick's end point towards you, and moving as you move it with your hands!). However this introduces some sort of model clipping and replicating... 2. The actual data structures and editing all that! Currently I create a solid space chunks of geometry sealed with portals and then connect the chunks  but this is done from the code, the actual connecting of segments may be done by writing my own editor (bad!), besides there is a problem if two connected portals' shapes do not fit! And the pure geometrical connecting from an editor do not work for the case when you want to put bigger volume inside a smaller one. From the code that is done by assigning IDs to portals and then doing some sort of IDx vs IDy connecting with rotation as parameter. So, you can see it is not userfriendly at all. Any suggestions will be appreciated! Sergei Miloikov 
From: Tom Forsyth <tomf@mu...>  20020429 12:23:46

Seconded. Generally, you will need very different data structures for each part (rendering and collision), different mesh resolutions, different workaround and shortcuts (what does alphatest mean to a collision engine for example), and frequently you will have the two sides done in different modules, at different rates, and sometimes even in different threads. Additionally, you usually have collisions happening in parts of the world that are not rendered. Trying to use the same data for both just makes both halves slower, and leads to cache pollution and poor paging performance. In practice there is almost no useful data sharing going on. In some particular cases, we go so far as to author two different Max/Maya models, one for collision and one for rendering. However we usually start from the same model and generate the two different data sets  far more efficient. But for some things it is useful to be able to make two completely separate models. Tom Forsyth  purely hypothetical Muckyfoot bloke. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > Original Message > From: Sam McGrath [mailto:sammy@...] > Sent: 28 April 2002 11:11 > To: gdalgorithmslist@... > Subject: RE: [Algorithms] Collision and Visual triangle data > structures > > > I find it's generally a smart idea to separate these out. I > would keep > two separate structures for your collision and your visual > geometry, and > do whatever you need to do with the copy to make it suitable for your > collision system. > > Our engine uses convex surfaces only for collision, and these are > represented as a series of planes rather than vertex/face > data. As far > as the engine is concerned, these are two distinct and separate > structures, not dependent on each other in any way. > > Sam 
From: Charles Bloom <cbloom@cb...>  20020429 04:48:03

See the paper on the "rational map" by Johnstone and Williams, which I gather you have. They address these issues here. For one thing, any mapping between quats (S3) and euclidean space (R4) will have a pole somewhere (actually S3>R4 is no problem, R4>S3 is a problem). With the "rational map" you must choose your pole such that it is not near the quats you care about. You can even change your mapping on the fly to move the pole around. Your "roll over its head" problem may be totally unrelated; it may be an error in the way you're doing the spline interpolation, or an error in the way you're loading the camera matrix from the quats; I would look at the quat values and see if they look continuous. It looks from your QuatToVect4 that you've chosen a mapping that is singular when q[W] > 1 ; that's a pole at the identity quat, though your lack of parentheses on the inv_x5 line are somewhat confusing. At 11:15 PM 4/28/2002 +0300, Grisha Spivak wrote: >void QuatToVect4( vect4 dest, const quat q ) >{ > float inv_x5 = 1.f/2.f*(float)sqrt( ( 1.f  q[W] )/2.f ); > dest[X] = q[X]*inv_x5; > dest[Y] = q[Y]*inv_x5; > dest[Z] = q[Z]*inv_x5; > dest[W] = ( 1.f  q[W] )*inv_x5; >} Here's a mapping with a pole at the 180 degree rotation around X : const Vec4 RationalMap(const Quat & q) { // assert q is not at the pole : ASSERT( ! fisone( q.DotProduct( Quat(1,0,0,0) ) ) ); return Vec4( q.y, q.z, q.w, 1  q.x ); } See Johnstone and Williams for more.  Charles Bloom cb@... http://www.cbloom.com 
From: Grisha Spivak <_grisha@tu...>  20020428 20:15:38

I'm looking for implementing smooth camera movement. Orientation defined as quaternion. First thing that I tried was simple SLERP but it looks too twitched. I found some papers describing how to map quaternoins to 4D coordinates, interpolate them, then map back to quaternion. Now camera flying very smooth but sometimes it's makes 'roll over the head' and I don't know how to fix it. Here is my code: void QuatToVect4( vect4 dest, const quat q ) // map quaternion to 4D vector { float inv_x5 = 1.f/2.f*(float)sqrt( ( 1.f  q[W] )/2.f ); dest[X] = q[X]*inv_x5; dest[Y] = q[Y]*inv_x5; dest[Z] = q[Z]*inv_x5; dest[W] = ( 1.f  q[W] )*inv_x5; } void Vect4ToQuat( quat dest, const vect4 v ) // map 4D vector to quaternion { float inv_q5 = 1.f/( v[X]*v[X] + v[Y]*v[Y] + v[Z]*v[Z] + v[W]*v[W] ); dest[X] = 2.f*v[X]*v[W]*inv_q5; dest[Y] = 2.f*v[Y]*v[W]*inv_q5; dest[Z] = 2.f*v[Z]*v[W]*inv_q5; dest[W] = ( v[X]*v[X] + v[Y]*v[Y] + v[Z]*v[Z]  v[W]*v[W] )*inv_q5; } // // interpolation: // u  interpolation parameter float a, b, c, d; // CatmullRom spline coefficents a = u*( 1  u )*( 1  u )*0.5f; b = 1.f  2.5f*u*u + 1.5f*u*u*u; c = u*( 0.5f + 2.f*u  1.5f*u*u ); d = u*u*( 1  u )*0.5f; vect4 v0, v1, v2, v3; QuatToVect4( v0, q0 ); QuatToVect4( v1, q1 ); QuatToVect4( v2, q2 ); QuatToVect4( v3, q3 ); vect4 res; res[X] = a*v0[X] + b*v1[X] + c*v2[X] + d*v3[X]; res[Y] = a*v0[Y] + b*v1[Y] + c*v2[Y] + d*v3[Y]; res[Z] = ... res[W] = ... quat resQuat; Vect4ToQuat( resQuat, res ); // ( And sorry for my poor english ) 
From: Ron Levine <ron@do...>  20020428 17:49:30

Tim C. Schr=F6der wrote: >> I think you can find reasonably well documented code for it on Dave >> Eberly's website gdalgorithmslist@... > >I own that book, lots of good interesection test in there. Unfortunatly = that >code >he presents is really long and has rarely any comments that would help = me to >not only copy & paste the code but actually understand it. I also can't = find >a >yes/no intersection test. Some simple solution that does only deal with >infinite >cylinders and does not even calculate any intersection point would be >perfect. >I really want to understand how to modify my ray/ray distance test to = work >with line segments. =46irst, of course, as everyone can realize, I pasted in the wrong URL for Dave's siteit's http://www.magicsoftware.com/ =20 Don't know about the code that comes on the CD with the book, but the code on the website does have comments, and, I think is not THAT long. The point is that you cannot determine even the binary intersection question with a simple rayray distance test. You have actually to solve for the intersections of the ray with three surfaces of the cylinderthe two circular planar endcaps and the piece of the of the infinite circular cylider that they cut out. There are a few cases to check, which makes the code look a little longer, but each case involves only very elementary 3D mathematics. Let me spell it out 1. Find if the ray intersects the infinite circular cylinder. Write down the implicit equation of the infinite cylnder. This is of the form =20 dist(X, L) =3D r,=20 where X is an arbitrary point on the cylinder (i.e., a 3vector), L is its axial line and r is its radius, or to eliminate square roots in the final algebra, you'll want to use it in the squared form dist(X, L)^2 =3D r^2 Let X be any point in space and P0 a point on the axis line, (say the center of the base of the finite cylinder) and let A be a unit vector along the axis of the cylinder. Then,=20 (X  P0) dot A)A is a vector from P0 to the perpendicular projection of X on L=20 and so Y =3D (X  P0)  ((X  P0) dot A)A =20 is a vector that is perpendicular to L, and which runs from the projection of X on L to X, so whose length is the distance of X from L. (BTW, this expression is the key step in the GramSchmidt construction that I have mentioned in previous posts and, no doubt, will mention again. You will find the full GS procedure in your basic linear algebra book ) So Y dot Y is the square of the distance from X to the line l. So =20 Y dot Y =3D r^2=20 is the implicit equation of the infinite cylinder. I've written this in terms of Y for brevity, but it is an equation in the unknown vector X, which has three unknown components, call them (x, y, z) (note that what I'm writing is case sensitive). So this is a scalar quadratic equation in the three variables (x, y, z), when you write it out, which you should be able to do with the elementary algebra skills that are needed in the 3D programmer's toolkit, although you will have to be patient and careful to avoid little algebra errors that even the gods of mathematics commit all the time. Always double check your work. Now the ray whose intersection you want to test has a parametric representation=20 Q + tV , t>0 (so Q is the position of your light source, and V a vector that gives the direction of the ray). Again this is a vector expression, equivalent to three scalar expressions giving the three components (x, y, z) of an arbitrary point on the ray as linear functions of the single parameter t. Substitute these three scalar expressions into the implicit equation of the cylinder and the latter becomes a quadratic equation in the single variable t, which you ought to have learned to solve sometime in your education and is worth relearning if you've forgotten it. It has zero, one or two solutions, not surprising since a ray can have zero, one or two distinct intersections with an infinite cylinder. You are interested only in solutions t>0, for negative t does not give you a point on the ray (but on its mirror image). If you find solutions for t then you have to plug them back into the parametric representation for the ray to get the actual intersection points and then check whether those points lie on the finite portion of the infinite cylinder between the endcaps. =20 If X is a point of intersection with the infinite cylinder and P0 and P1 are the center points of the two endcaps, then X lies between the two endcaps if and only if=20 0 <=3D (X  P0) dot (P1  P0) <=3D (P1  P0) dot (P1  P0) which again can be easily derived from what one might have learned from course in elementary vector geometry, which one usually gets in a freshman/sophomore level calculus course, well worth reviewing if you want to do 3D graphics. 2. If you don'f find any intersections in 1. then you still have to check the possibility of intersection with the planar endcaps (unless you have further restricting information on the relative position of the cylinder and the light source). If you know from 1. that there is no intersection with the curved side, and you know that the light source is not inside the cylinder, then you have only to check one endcap, because any ray from outside intersecting one endcap necessarily intersects the cylinder side or the other endcap. Of course, if you are dealing with a line segment, not a ray, as your subject line indicates, then you have to check against both endcaps. To check whether you intersect an endcap, you first find the intersection, if any, between the ray and its plane....I won't spell that out because it's much simpler than finding the intersection of the ray with a quadric surface, again, there are plenty of sources in =46AQ's, textbooks, etc . Then when you find that intersection of the ray with the plane of the endcap, you have to test whether it is actually on the endcap, i.e., that its distance from the center of the endcap is not greater than the radius of the cylinder. So in order to satisfy your stated wish of understanding Dave Eberly's code, you have to understand basic vector geometry. Of course, this is not the first question I have answered that made extensive use of basic vector geometry. Seems to me it's a pretty common theme in 3D graphics problems. I have a book I'm writing on it, but only very slowly in my spare time. No time to work on it today, because I'm off on a very hilly 60mile bike ride. 
From: Pierre Terdiman <p.terdiman@wa...>  20020428 17:44:40

Hi everyone, Just found this, seems pretty excellent : http://wwwrocq.inria.fr/~redon/research.htm Check out the videos. Pierre 
From: Ron Levine <ron@do...>  20020428 15:39:26

Tim C. Schr=F6der wrote: >Thanks Ron, > >From the shadow image that code produced I already started to assume >that I was actually checking a ray and not a segment. Also the code I = came >up with looked suspeciuously similar to the Ray/Cyl intersection code = from >Graphic Gems IV ;( > >So, give me the luxury to as for help again ;) Anyone out there know of= a >good way to make a line segment cylinder/intersection ? Preferred for = finite >cyliders, but I also would be very happy about code/formula/explanation = for >one that intersects with a cylinder that extents infinitely along its = axis. > >I really can't derive that solution my own. I use the code from GGems IV= for >my intersection point calculation, but I don't fully understand the last >part. > >Thanks, >Tim > I think you can find reasonably well documented code for it on Dave Eberly's website gdalgorithmslist@... >.... snip >> >>I tried to come up with a binary intersection test for cylinders. >... > >The distance that this code uses as the intersection criterion is not >necessarily the distance between the two line segments, but rather the >distance between the infinite lines containing them. > >The distance between two lines is the length of their mutual >perpendicular, which is what you compute, but this is the distance >between the two segments only in the case that the two feet of that >mutual perpendicular acutally lie on the respective segments. > > 
From: Ron Levine <ron@do...>  20020428 15:19:22

Jason Allen wrote: >Emailing this on behalf of Tim C. Schr=F6der who is having trouble = getting email to the list. > >"Hello, > >I tried to come up with a binary intersection test for cylinders. >The cylinder is defined by the center of it's base circle (m_vPos), >the axis of mirror (m_vAxis) and it's height (hardcoded 999.0f here). > >Since I use this test for shadow calculations in a ray tracer, I want >to calculate the intersection of a line segment. I try to find the=20 >intersection by calculating the distance between the axis line of the=20 >cylinder and the intersecting line. I use the cross to find the plane >which lays on the one line and is parallel to the other. Then I use a dp >to project the distance between two points on the the two lines on the >normal of the plane. This gives me a distance I can compare to the >cylinder's radius. > >Unfortunately this is not completely working. I see the correct shadow >for the cylinder, but this shadow expands also to the light and = continues >mirrored from that position on. Looks like two shadow cones with the >light as mirror axis. No idea ;( > >Here's the code, please take a look: > >bool CCylinder::DoesBlock(const Vector3D& vStart,=20 > const Vector3D& vEnd,=20 > const Vector3D& vDir) const >{ > Vector3D A =3D vStart; > Vector3D B =3D vEnd; > Vector3D C =3D m_vPos; > Vector3D D =3D m_vPos + (m_vAxis * 999.0f); > Vector3D vNormal =3D (B  A) ^ (C  D); > vNormal.Normalize(); > float fDist =3D fabs(vNormal * (D  A)); > if (fDist <=3D m_fRadius) > return true; > return false; >} > >Thanks for your time, >Tim" The distance that this code uses as the intersection criterion is not necessarily the distance between the two line segments, but rather the distance between the infinite lines containing them. The distance between two lines is the length of their mutual perpendicular, which is what you compute, but this is the distance between the two segments only in the case that the two feet of that mutual perpendicular acutally lie on the respective segments. 