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
(3) 
2
(3) 
3
(20) 
4
(14) 
5
(12) 
6
(6) 
7
(16) 
8
(3) 
9
(4) 
10
(36) 
11
(7) 
12
(2) 
13
(5) 
14
(9) 
15
(14) 
16
(5) 
17
(11) 
18
(15) 
19
(16) 
20
(26) 
21
(7) 
22
(10) 
23
(1) 
24
(3) 
25
(15) 
26
(31) 
27
(24) 
28
(23) 
29
(6) 
30
(5) 
31
(44) 





From: Diogo de Andrade <Diogo.Andrade@sp...>  20030331 23:17:55

Hey all! Just to say that I've made the TrueType to polygon application working and online (with source, of course) at http://www.spellcasterstudios.com/~diogo.andrade/code.htm, if someone wants to take a look/use it... I've just ended using the GLUT tesselator (internally, it must be a VERY nice piece of code, very stable and usable)... Thanks all for the help Diogo de Andrade diogo.andrade@... 
From: Ron Hay <rhay@cy...>  20030331 21:44:45

And don't forget Max quaternion weirdness  3dsmax has the clockwise rotation direction but the rotation is counterclockwise in opengl or d3d. Ron Troy Gilbert wrote: >>MAX is righthanded >>Maya is righthanded >>SoftImage is righthanded >>Lightwave is lefthanded >> >>I don't know about RenderWare or NetImmerse. >> >> > >Max is righthanded, but don't forget that in Max Z is up. You gotta put a >90degree rotation on the Xaxis to fix that (if it matters to you). Maya >let's you choose either Y is up or Z is up. > >RenderWare is righthanded, and Y is up. > >Troy >Developer Relations >Criterion Software >www.csl.com > > > > > >This SF.net email is sponsored by: ValueWeb: >Dedicated Hosting for just $79/mo with 500 GB of bandwidth! >No other company gives more support or power for your dedicated server >http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > 
From: Michael Pohoreski <MPohoreski@cy...>  20030331 21:04:40

Once caveat with RenderWare is that it uses a negated X axis. Interesting that NI, er Gamebro, supports that. Original Message From: Tom van Dijck [mailto:tom@...]=20 Sent: Monday, March 31, 2003 3:37 PM To: gdalgorithmslist@... Subject: Re: [Algorithms] coordinate systems quoted from the documentation Renderware is Righthanded. (RW 3.4) "RenderWare Graphics uses an orthogonal righthanded coordinate system for its 3D spaces." NetImmerse supports both through the NiRenderer::SetLeftRightSwap mode: (NI 4.2.1) "Leftright swap, when enabled will flip the scene lefttoright as it is rendered into the port." which does not really make the Z negative, but the X... (which has the same effect I guess). by default the system is righthanded though. 
From: Tom van Dijck <tom@ri...>  20030331 20:37:04

quoted from the documentation Renderware is Righthanded. (RW 3.4) "RenderWare Graphics uses an orthogonal righthanded coordinate system for its 3D spaces." NetImmerse supports both through the NiRenderer::SetLeftRightSwap mode: (NI 4.2.1) "Leftright swap, when enabled will flip the scene lefttoright as it is rendered into the port." which does not really make the Z negative, but the X... (which has the same effect I guess). by default the system is righthanded though. Tom van Dijck.  Original Message  From: "Casey Muratori" <gda@...> To: <gdalgorithmslist@...> Sent: Monday, March 31, 2003 19:38 Subject: Re: [Algorithms] coordinate systems > > All I asked for btw, was what is the most commonly used system in 3D > > application such as max, maya, or thirdparty engines such as renderware, > > netimmerse, qzr, and things like that... > > MAX is righthanded > Maya is righthanded > SoftImage is righthanded > Lightwave is lefthanded > > I don't know about RenderWare or NetImmerse. Personally, I always pick > righthanded, because the two primary game art tools (ie., MAX & Maya) use > it, the vast majority of math books use it, and neither OpenGL nor D3D > care which you use so long as you are loading your own matrices and not > using their matrix building routines (which I never do anyhow). > > Plus, with righthanded, you CAN use OpenGL & D3D's libraries if you want, > because if I'm not mistaken, OpenGL is always righthanded and D3D can be > set to use righthanded in its newer releases (someone correct me on this > if that's not the case  I never use these routines). > > > And if I understand correctly, using a right handed system, the 3 columns in > > a matrix point right (+X), up(+Y) en backward(+Z), and the crossproduct of > > X cross Y, which is counterclockwise, should also point backward (+Z). > > backward in terms of "out of the screen". > > Correct. > > > How about quaternions, do they have a handedness? and if so, how can you > > determine that? > > Just like a crossproduct, it can be made any way you choose. Normally, > quaternions are made so that they obey the handedness of the underlying > coordinate system. But you could write them so they're opposite it (ie., > so they rotate clockwise instead of counterclockwise, etc.). See my > previous post about quaternion handedness, where I do the i/j/k > derivation. > >  Casey > > > >  > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > 
From: Troy Gilbert <TroyG@cs...>  20030331 20:21:30

> MAX is righthanded > Maya is righthanded > SoftImage is righthanded > Lightwave is lefthanded > > I don't know about RenderWare or NetImmerse. Max is righthanded, but don't forget that in Max Z is up. You gotta put a 90degree rotation on the Xaxis to fix that (if it matters to you). Maya let's you choose either Y is up or Z is up. RenderWare is righthanded, and Y is up. Troy Developer Relations Criterion Software http://www.csl.com 
From: <christer_ericson@pl...>  20030331 20:00:57

> > > X =3D <1,1,1> > > > > > > X' =3D AX =3D <4, 3, 2> > > > X" =3D BX =3D <1/4, 1/3, 1/2> > > > > > > Now, the magnitude of X' and X'' is different, but the direction is=20 the same > > > (i.e. X' =3D=3D X"). So, as long as you're only interested in=20 directions, > > > you are in the green, no matter which matrix you use. > > [...] > > If you mean by X', the length of the vector X' > > Doh! Ouch! Aargh! > > I must have got my wires crossed, because I meant the *normalized* X',=20 which > should =5Fobviously=5F be written as X' / X'. Now it suddenly all makes= =20 sense, > eh? Even normalized, they don't look very similar at all: =BB a =3D [4 3 2] a =3D 4 3 2 =BB b =3D [1/4 1/3 1/2] b =3D 0.2500 0.3333 0.5000 =BB a =3D a / sqrt(a * a') a =3D 0.7428 0.5571 0.3714 =BB b =3D b / sqrt(b * b') b =3D 0.3841 0.5121 0.7682 Christer Ericson Sony Computer Entertainment, Santa Monica 
From: Zafar Qamar <zafar.qamar@sw...>  20030331 17:58:12

Hi, If I have a vertex p in the world and I render it with a perpective camera C (of FOV A) it transforms at a particular point on the screen. What I want to do is move vertex p such that a change in FOV (say to FOV B) still gives the same apparent location on the screen (if you see what I mean). The reason why I need this is: In our FPS we have a Gun rendered at a different FOV to the world, and I'm trying to draw a "fudged" effect in the world to make it look like it's coming from the gun (in the gun's FOV) and hitting a point in the world (in the world's FOV). I know I can do it by transforming using a Camera with FOV B (effectively giving screen coords) and then inversetransforming with the Camera of FOV B to put it back into the world. I believe there's a maths solution something to do with scaling by tan((FOV A)*0.5f)/tan((FOV B)*0.5f) but can't quite get it right. Can anyone work this out? Much thanks in advance Zafar __________________________________________________________ This mail has been scanned for all known viruses by UUNET delivered through the MessageLabs Virus Control Centre. 
From: Casey Muratori <gda@fu...>  20030331 17:38:38

> All I asked for btw, was what is the most commonly used system in 3D > application such as max, maya, or thirdparty engines such as renderware, > netimmerse, qzr, and things like that... MAX is righthanded Maya is righthanded SoftImage is righthanded Lightwave is lefthanded I don't know about RenderWare or NetImmerse. Personally, I always pick righthanded, because the two primary game art tools (ie., MAX & Maya) use it, the vast majority of math books use it, and neither OpenGL nor D3D care which you use so long as you are loading your own matrices and not using their matrix building routines (which I never do anyhow). Plus, with righthanded, you CAN use OpenGL & D3D's libraries if you want, because if I'm not mistaken, OpenGL is always righthanded and D3D can be set to use righthanded in its newer releases (someone correct me on this if that's not the case  I never use these routines). > And if I understand correctly, using a right handed system, the 3 columns in > a matrix point right (+X), up(+Y) en backward(+Z), and the crossproduct of > X cross Y, which is counterclockwise, should also point backward (+Z). > backward in terms of "out of the screen". Correct. > How about quaternions, do they have a handedness? and if so, how can you > determine that? Just like a crossproduct, it can be made any way you choose. Normally, quaternions are made so that they obey the handedness of the underlying coordinate system. But you could write them so they're opposite it (ie., so they rotate clockwise instead of counterclockwise, etc.). See my previous post about quaternion handedness, where I do the i/j/k derivation.  Casey 
From: Per Vognsen <vognsen@fr...>  20030331 17:29:40

Hey Willem,  Original Message =20 From: "Willem H. de Boer" <Willem@...> To: <gdalgorithmslist@...> Sent: Monday, March 31, 2003 6:16 PM Subject: RE: [Algorithms] transforming vectors... > Now we now that both a and b transform similarily under A: > so, let's call Av, x, both equations reduce to:=20 >=20 > a =3D Sx > b =3D S^{1}x >=20 > So, yes, you're assumption was right. a, and b will be colinear Actually, this is only true if S is a scalar matrix (i.e. it represents = a uniform scale operation). This is easy to see by looking at a concrete = example. Suppose S =3D [[2, 0], [0, 3]] and thus S^{1} =3D [[1/2, 0], = [0, 1/3]]. Letting x =3D [1 1], we have Sx =3D [2 3] and S^{1}x =3D = [1/2 1/3]. These are not parallel vectors. (If they were, there would = exist a scalar k so that 2 =3D k 1/2 and 3 =3D k 1/3. The first equation = gives us k =3D 4 and the second gives us k =3D 9; a contradiction.) Per 
From: Christopher Phillips <cphillips@re...>  20030331 17:26:18

> From: Willem H. de Boer [mailto:Willem@...] > Sent: 31 March 2003 17:16 > To: gdalgorithmslist@... > Subject: RE: [Algorithms] transforming vectors... > .... > > M^{1} = (S A)^{1} = S^{1} A^{1} = S^{1} A^t ... No, M^{1} = (S A)^{1} = A^{1} S^{1} = A^t S^{1} This is why: (A B) (inv(B) inv(A)) = A (B inv(B)) inv(A) = A I inv(A) = A inv(A) = I = (A B) inv(A B) .: inv(A B) = inv(B) inv(A) Try rotating 90 degrees around X then scaling Y by 2. If you want to undo that, you have to scale Y by half _before_ you undo the rotation, otherwise you will scale down the wrong axis. Christopher.  Virus scanned and cleared ok 
From: Jamie Fowlston <jamief@qu...>  20030331 17:23:11

No. (M^{1})^t = (S^{1} A^t)^t = (S^{1})^t (A^t)^t = S^{1} A is not true. t(AB) = t(B)t(A), so t(inv(M)) = t(inv(S) t(A)) = t(t(A)) t(inv(S)) = A inv(S) (_not_ inv(S) A) Regardless, my previous post showed that if a = Sx b = S^{1}x then a and b are not in general colinear. Jamie Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Willem H. de Boer Sent: 31 March 2003 17:16 To: gdalgorithmslist@... Subject: RE: [Algorithms] transforming vectors... >And it wouldn't work for any scalings (apart from the trivial >one: all 1's) either. Because a matrix that contains a scaling >in whatever direction is not an orthogonal matrix. Before anyone >starts objecting: With orthogonal I mean M^T M = I, it's what >many people would call orthonormal. Actually, it _would_ work for scalings, as I've just found out. [People not interested in maths should click away, NOW] Suppose M is a transformation (an NxN matrix), composed of two other transformations M = SA, where both S and A are NxN matrices. S is a scaling matrix, and is thus diagional. And A is an orthogonal matrix (or orthonormal, if you will). Now we want to "prove" that for a given vector v: Mv . Nv = Mv Nv (1) Or, the vector a=Mv, is colinear but not necessarily of same magnitude to the vector b=Nv, where N is the inverse transpose of M. Let's calculate the inverse transpose of M, firstly, its inverse: M^{1} = (S A)^{1} = S^{1} A^{1} = S^{1} A^t The last bit comes from the fact that the inverse of an orthogonal matrix is just its transpose. Now let's take the transpose of M^{1} (M^{1})^t = (S^{1} A^t)^t = (S^{1})^t (A^t)^t = S^{1} A The last bit coming from the fact that the transpose of a diagonal matrix (S^{1}, in this case, the inverse of S) is the same matrix. And the transpose of the transpose of a matrix A, is just A. So, now back to the original statement (1). We can rewrite the vector a as: a = Mv = (SA)v and b: b = M^tv = (S^{1} A)v Now we now that both a and b transform similarily under A: so, let's call Av, x, both equations reduce to: a = Sx b = S^{1}x So, yes, you're assumption was right. a, and b will be colinear but of different magnitudes, if and only if M is a transformation that consists only of rotations, and scalings (even nonuniform ones). Willem  This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Pierre Terdiman <p.terdiman@wa...>  20030331 17:01:52

> Of course, if there were scaling factors embedded in the transformation > matrix (currently not allowed in my engine), the length of the > transformed vector would be different, but the direction would still be > correct  which is all I'm interested in. There's some confusion in the thread (I'll let the "Maths Police" handle that) but your first post was right. It's worth recalling this opens the door to much much more confusion when scaling is out. For example :  You rotate your normal using your 3x3 "rotation submatrix". In D3D's vector * matrix parlance it goes like : RotatedNormal = OriginalNormal * RotationSubMatrix So no inversetranspose to hint the reader about what's happening. We know from the names we're rotating a normal but it's not always obvious.  Then later you want to rotate, say a normal in world space back into an object's local space. Imagine previous 3x3 RotationSubMatrix was extracted from the 4x4 world matrix. In theory you would have to invert the object's world matrix, then rotate as above using vector * matrix. But since the 4x4 matrix only contains position and rotation parts, and since you're not transforming a point but a normal, you end up simply writing this : RotatedNormal = RotationSubMatrix * OriginalNormal Which shortcuts all the maths and gives the correct answer, but uh ! Your poor reader now has no clue what the hell you're doing or what conventions you're using. Of course, whether it's good or bad practice is a topic for Sweng. As far as the algorithmic part is concerned, go ahead (I plead guilty, my code is full of similar things)  Pierre http://www.codercorner.com 
From: Jim Offerman <j.offerman@cr...>  20030331 16:46:19

Hey, > If you mean by X', the length of the vector X' Doh! Ouch! Aargh! I must have got my wires crossed, because I meant the *normalized* X', which should _obviously_ be written as X' / X'. Now it suddenly all makes sense, eh? As many times before (look in the archives), the biggest hurdle for me when it comes to math is getting it written down in such a form that other people actually understand what I'm saying... gotta work on that skill ;). Oh well, at least I'm a good programmer... (akward silence) no really... I am... (watches everyone turn away, shaking their heads) ;) Jim Offerman Crevace Games http://www.crevace.com 
From: Willem H. de Boer <Willem@mu...>  20030331 16:38:03

Forget that last proof I sent to the list. It's built around that (faulty!) assumption. Sorry. Jim got me into believing something without checking it out first for myself. My fault. > Original Message > From: Jamie Fowlston [mailto:jamief@...] > Sent: 31 March 2003 16:40 > To: gdalgorithmslist@... > Subject: RE: [Algorithms] transforming vectors... > > > <snip> > Now, the magnitude of X' and X'' is different, but the > direction is the same > </snip> > > Nonsense :) > > 16 * X" = <4, 16 / 3, 8> > > which is clearly not the same direction as <4, 3, 2>. > > Jamie > > > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...]On Behalf Of Jim > Offerman > Sent: 31 March 2003 15:04 > To: gdalgorithmslist@... > Subject: Re: [Algorithms] transforming vectors... > > > Willem, > > >>4 0 0 > >>0 3 0 > >>0 0 2 > >> > >> > >Let's call it A. > >Now take a column vector X with components (1, 1, 1), and > leftmultiply > >it by A: > > > > AX = X' > > > >X' will have components (4,3,1). So not only is the magnitude of X' > >different from X, but so is its direction. > > > Certainly, but that wasn't my point at all... my point was: > > A: > 4 0 0 > 0 3 0 > 0 0 2 > > B: > 1/4 0 0 > 0 1/3 0 > 0 0 1/2 > (this is the inverse of A or, if you will, the > inversetranspose of A  > doesn't really matter, as in this specific case they are both > the same) > > X = <1,1,1> > > X' = AX = <4, 3, 2> > X" = BX = <1/4, 1/3, 1/2> > > Now, the magnitude of X' and X'' is different, but the > direction is the same > (i.e. X' == X"). So, as long as you're only interested in > directions, > you are in the green, no matter which matrix you use. > > Let me rephrase my original question: > > Given: > v = a *true* 3d vector (represented in 4d as <x,y,z,0>) > M = a transformation matrix composed of only (non)uniform scales, > rotations and translations > N = Inverse(Transpose(M)) > > v' = Mv > v" = Nv > > Does v' == v" hold true, i.e. do v' and v" have the same > direction? > > I *think* this is at least true for the case where M contains only > rotations, translations and uniform scales... question > remains if this is > also true in general. > > Jim Offerman > Crevace Games > http://www.crevace.com > > > > >  > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > >  > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Willem H. de Boer <Willem@mu...>  20030331 16:18:45

>And it wouldn't work for any scalings (apart from the trivial >one: all 1's) either. Because a matrix that contains a scaling >in whatever direction is not an orthogonal matrix. Before anyone >starts objecting: With orthogonal I mean M^T M = I, it's what >many people would call orthonormal. Actually, it _would_ work for scalings, as I've just found out. [People not interested in maths should click away, NOW] Suppose M is a transformation (an NxN matrix), composed of two other transformations M = SA, where both S and A are NxN matrices. S is a scaling matrix, and is thus diagional. And A is an orthogonal matrix (or orthonormal, if you will). Now we want to "prove" that for a given vector v: Mv . Nv = Mv Nv (1) Or, the vector a=Mv, is colinear but not necessarily of same magnitude to the vector b=Nv, where N is the inverse transpose of M. Let's calculate the inverse transpose of M, firstly, its inverse: M^{1} = (S A)^{1} = S^{1} A^{1} = S^{1} A^t The last bit comes from the fact that the inverse of an orthogonal matrix is just its transpose. Now let's take the transpose of M^{1} (M^{1})^t = (S^{1} A^t)^t = (S^{1})^t (A^t)^t = S^{1} A The last bit coming from the fact that the transpose of a diagonal matrix (S^{1}, in this case, the inverse of S) is the same matrix. And the transpose of the transpose of a matrix A, is just A. So, now back to the original statement (1). We can rewrite the vector a as: a = Mv = (SA)v and b: b = M^tv = (S^{1} A)v Now we now that both a and b transform similarily under A: so, let's call Av, x, both equations reduce to: a = Sx b = S^{1}x So, yes, you're assumption was right. a, and b will be colinear but of different magnitudes, if and only if M is a transformation that consists only of rotations, and scalings (even nonuniform ones). Willem 
From: Greg Seegert <greg@st...>  20030331 15:56:26

A good resource is here: http://www.gignews.com/realtime020100.htm Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Per Vognsen Sent: Monday, March 31, 2003 9:00 AM To: gdalgorithmslist@... Subject: Re: [Algorithms] transforming vectors...  Original Message  From: "Jim Offerman" <j.offerman@...> To: <gdalgorithmslist@...> Sent: Monday, March 31, 2003 1:13 PM Subject: [Algorithms] transforming vectors... > While we're all in maththeory mode... I just want to check something: > > When transforming vectors (i.e. directions, normals, etc.)  as opposed > to points  you need to use inversetranspose of the original No. When transforming a vector you simply use the matrix and not its inverse transpose. However, note that normals are not vectors; that's why we need to give them special treatment! In the very special case of threedimensional Euclidean space, it is okay to pretend that normals are vectors as long as we observe certain rules concerning their behavior under transformations. Physicists call these gadgets pseudovectors. Cliffordalgebraists call them bivectors. Anyway, let's try to work out how the normal "vector" transforms when the points on the plane are transformed. My claim is that it is transformed by the inverse transpose. Here's a proof: Let's assume for convenience that the plane in consideration goes through the origin; then its equation is n.x = 0 where n is the normal vector. Now a linear transformation given by a matrix A is applied to all points on the plane, i.e. all points x for which n.x = 0. Now we want to figure out how n transforms. Thus we seek a matrix B so that n.x = 0 if and only if (B n).(A x) = 0. Note that the dot product on the lefthand side can be written as (B n)^t (A x) = n^t B^t A x. Thus n.x = 0 = n^t x if and only if B^t = A^(1) which implies B = (A^(1))^t. Done. Hope this helps. Per  This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ 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...>  20030331 15:48:28

> I *think* this is at least true for the case where M contains > only rotations, translations and uniform scales... question > remains if this is also true in general. And it wouldn't work for any scalings (apart from the trivial one: all 1's) either. Because a matrix that contains a scaling in whatever direction is not an orthogonal matrix. Before anyone starts objecting: With orthogonal I mean M^T M = I, it's what many people would call orthonormal. Willem 
From: Jamie Fowlston <jamief@qu...>  20030331 15:39:42

<snip> Now, the magnitude of X' and X'' is different, but the direction is the same </snip> Nonsense :) 16 * X" = <4, 16 / 3, 8> which is clearly not the same direction as <4, 3, 2>. Jamie Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Jim Offerman Sent: 31 March 2003 15:04 To: gdalgorithmslist@... Subject: Re: [Algorithms] transforming vectors... Willem, >>4 0 0 >>0 3 0 >>0 0 2 >> >> >Let's call it A. >Now take a column vector X with components (1, 1, 1), and leftmultiply >it by A: > > AX = X' > >X' will have components (4,3,1). So not only is the magnitude of X' >different from X, but so is its direction. > Certainly, but that wasn't my point at all... my point was: A: 4 0 0 0 3 0 0 0 2 B: 1/4 0 0 0 1/3 0 0 0 1/2 (this is the inverse of A or, if you will, the inversetranspose of A  doesn't really matter, as in this specific case they are both the same) X = <1,1,1> X' = AX = <4, 3, 2> X" = BX = <1/4, 1/3, 1/2> Now, the magnitude of X' and X'' is different, but the direction is the same (i.e. X' == X"). So, as long as you're only interested in directions, you are in the green, no matter which matrix you use. Let me rephrase my original question: Given: v = a *true* 3d vector (represented in 4d as <x,y,z,0>) M = a transformation matrix composed of only (non)uniform scales, rotations and translations N = Inverse(Transpose(M)) v' = Mv v" = Nv Does v' == v" hold true, i.e. do v' and v" have the same direction? I *think* this is at least true for the case where M contains only rotations, translations and uniform scales... question remains if this is also true in general. Jim Offerman Crevace Games http://www.crevace.com  This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Willem H. de Boer <Willem@mu...>  20030331 15:32:36

>Now, the magnitude of X' and X'' is different, but the >direction is the same (i.e. X' == X"). So, as long as >you're only interested in directions, you are in the green, >no matter which matrix you use. Quick, before Ron Levine and the Maths Police find out where you live! If you mean by X', the length of the vector X', then you are contradicting yourself. You say yourself "the magnitudes of X' and X'' are different", so there is _no way_ X' == X" can be true! I think you mean: X' . X'' = X' X'' Which says that the inner product . is proportional to the product of the lengths of both vectors. > > Let me rephrase my original question: > > Given: > v = a *true* 3d vector (represented in 4d as <x,y,z,0>) > M = a transformation matrix composed of only (non)uniform scales, > rotations and translations > N = Inverse(Transpose(M)) I think you mean N = (M^{1})^t, the inverse transpose of M means the transpose of the inverse of M. So it's the other way around. > v' = Mv > v" = Nv > > Does v' == v" hold true, i.e. do v' and v" have the same > direction? If M is an orthogonal matrix (ie M^T M = I, where I is the identity matrix), then the inverse transpose of M is exactly M. So the answer would be yes. > I *think* this is at least true for the case where M contains > only rotations, translations and uniform scales... question > remains if this is also true in general. > I don't believe it would hold for translations. Because a 4x4 matrix that contains a translation is not an orthogonal matrix. At least, last time I checked :) Willem 
From: Jim Offerman <j.offerman@cr...>  20030331 15:10:42

Hey Per, >No. (snip) Done. Hope this helps. > Thanks for the theory update! So now there's points, vectors *and* normals (or bivectors or pseudovectors  whichever jargon you prefer)... boy, this math stuff just keeps getting more interesting ;). However, being the practical type: What are the realworld consequences? Given that the rotation matrix R will remain unchanged by the inversetranspose operation, because R^t = R(1) and thus (R(1))^t = (R(1))(1) = R. We've already established that true 3d vectors aren't affected by translations stored in a 4x4 matrix (see my little discussion with Willem), so it seems to me that I just go ahead and use R to transform my normals...  Jim Offerman Crevace Games http://www.crevace.com 
From: Jim Offerman <j.offerman@cr...>  20030331 14:00:59

Willem, >>4 0 0 >>0 3 0 >>0 0 2 >> >> >Let's call it A. >Now take a column vector X with components (1, 1, 1), and leftmultiply >it by A: > > AX = X' > >X' will have components (4,3,1). So not only is the magnitude of X' >different from X, but so is its direction. > Certainly, but that wasn't my point at all... my point was: A: 4 0 0 0 3 0 0 0 2 B: 1/4 0 0 0 1/3 0 0 0 1/2 (this is the inverse of A or, if you will, the inversetranspose of A  doesn't really matter, as in this specific case they are both the same) X = <1,1,1> X' = AX = <4, 3, 2> X" = BX = <1/4, 1/3, 1/2> Now, the magnitude of X' and X'' is different, but the direction is the same (i.e. X' == X"). So, as long as you're only interested in directions, you are in the green, no matter which matrix you use. Let me rephrase my original question: Given: v = a *true* 3d vector (represented in 4d as <x,y,z,0>) M = a transformation matrix composed of only (non)uniform scales, rotations and translations N = Inverse(Transpose(M)) v' = Mv v" = Nv Does v' == v" hold true, i.e. do v' and v" have the same direction? I *think* this is at least true for the case where M contains only rotations, translations and uniform scales... question remains if this is also true in general. Jim Offerman Crevace Games http://www.crevace.com 
From: Per Vognsen <vognsen@fr...>  20030331 13:52:16

 Original Message =20 From: "Jim Offerman" <j.offerman@...> To: <gdalgorithmslist@...> Sent: Monday, March 31, 2003 1:13 PM Subject: [Algorithms] transforming vectors... > While we're all in maththeory mode... I just want to check something: >=20 > When transforming vectors (i.e. directions, normals, etc.)  as = opposed=20 > to points  you need to use inversetranspose of the original=20 No. When transforming a vector you simply use the matrix and not its = inverse transpose. However, note that normals are not vectors; that's = why we need to give them special treatment! In the very special case of = threedimensional Euclidean space, it is okay to pretend that normals = are vectors as long as we observe certain rules concerning their = behavior under transformations. Physicists call these gadgets = pseudovectors. Cliffordalgebraists call them bivectors. Anyway, let's try to work out how the normal "vector" transforms when = the points on the plane are transformed. My claim is that it is = transformed by the inverse transpose. Here's a proof: Let's assume for = convenience that the plane in consideration goes through the origin; = then its equation is n.x =3D 0 where n is the normal vector. Now a = linear transformation given by a matrix A is applied to all points on = the plane, i.e. all points x for which n.x =3D 0. Now we want to figure = out how n transforms. Thus we seek a matrix B so that n.x =3D 0 if and = only if (B n).(A x) =3D 0. Note that the dot product on the lefthand = side can be written as (B n)^t (A x) =3D n^t B^t A x. Thus n.x =3D 0 =3D = n^t x if and only if B^t =3D A^(1) which implies B =3D (A^(1))^t. = Done. Hope this helps. Per 
From: Willem H. de Boer <Willem@mu...>  20030331 13:07:05

Jim, Your matrix >4 0 0 >0 3 0 >0 0 2 Let's call it A. Now take a column vector X with components (1, 1, 1), and leftmultiply it by A: AX = X' X' will have components (4,3,1). So not only is the magnitude of X' different from X, but so is its direction. Willem > Original Message > From: Jim Offerman [mailto:j.offerman@...] > Sent: 31 March 2003 13:48 > To: gdalgorithmslist@... > Subject: Re: [Algorithms] transforming vectors... > > > Hi Willem, > > >(snip) > >So I assume that when you say > >"3d vector" you mean, a 4d vector with a 4th component which is > >set to 1. > > > You're absolutely right... I should have mentioned I was > talking about > homogenous vectors ;). > > Which is actually why I brought it up... I was getting a bit tired of > all the problems that popped up because the 3d vectors <x,y,z> in my > engine were implicitely treated as 4d vectors <x,y,z,1> (as I'm sure > many engine out there do), so I decided to make things > explicit and have > a Vector3 and Point3 class. > The former is treated as a true 3d vector (or, if you will, a > 4d vector > <x,y,z,0>) and the latter is treated as a homoegenous 4d vector. > > Poof... away went all my troubles. > > I just wanted to check I made the right call on the inversetranspose > thing... > > >That's not necessarily true. Only if a transformation scales > uniformly > >in all directions (x, y, and z), does the direction of a > vector remain > >unchanged. > > > I was under the impression that this also holds true for a > nonuniform scale, given that the inverse(transpose) of the > following scaling matrix: > > 4 0 0 > 0 3 0 > 0 0 2 > > is: > > 1/4 0 0 > 0 1/3 0 > 0 0 1/2 > > So no matter which matrix you use to transform the vector the > resulting direction is the same, as <4,3,2> == <1/4,1/3,1/2>. > > Of course, this is just a simple case... it will probably go > horribly wrong if you have a complex transformation that > combines several rotations, nonuniforms scales and translations. > > But then I already mentioned that I didn't allow any scales > in my engine ;). > > Jim Offerman > Crevace Games > http://www.crevace.com > > > > >  > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Diogo de Andrade <Diogo.Andrade@sp...>  20030331 12:52:00

Do a search on RAPID... It has some stuff that may be relevant, if robustness is your key point... There's a bunch of papers on the topic (if I'm not mistaken, written by Gottchalk et all) Diogo de Andrade > > So: does anyone know a robust method for finding the edge/edge > > contacts (points+normals) for three dimensional convex/convex objects > > (speed is secondary)? 
From: Jim Offerman <j.offerman@cr...>  20030331 12:44:32

Hi Willem, >(snip) >So I assume that when you say >"3d vector" you mean, a 4d vector with a 4th component which is >set to 1. > You're absolutely right... I should have mentioned I was talking about homogenous vectors ;). Which is actually why I brought it up... I was getting a bit tired of all the problems that popped up because the 3d vectors <x,y,z> in my engine were implicitely treated as 4d vectors <x,y,z,1> (as I'm sure many engine out there do), so I decided to make things explicit and have a Vector3 and Point3 class. The former is treated as a true 3d vector (or, if you will, a 4d vector <x,y,z,0>) and the latter is treated as a homoegenous 4d vector. Poof... away went all my troubles. I just wanted to check I made the right call on the inversetranspose thing... >That's not necessarily true. Only if a transformation scales uniformly >in all directions (x, y, and z), does the direction of a vector remain >unchanged. > I was under the impression that this also holds true for a nonuniform scale, given that the inverse(transpose) of the following scaling matrix: 4 0 0 0 3 0 0 0 2 is: 1/4 0 0 0 1/3 0 0 0 1/2 So no matter which matrix you use to transform the vector the resulting direction is the same, as <4,3,2> == <1/4,1/3,1/2>. Of course, this is just a simple case... it will probably go horribly wrong if you have a complex transformation that combines several rotations, nonuniforms scales and translations. But then I already mentioned that I didn't allow any scales in my engine ;). Jim Offerman Crevace Games http://www.crevace.com 