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}

_{Dec}

S  M  T  W  T  F  S 





1
(4) 
2
(7) 
3
(3) 
4
(2) 
5
(25) 
6
(57) 
7
(27) 
8
(42) 
9
(5) 
10
(2) 
11
(12) 
12
(7) 
13
(14) 
14
(23) 
15
(11) 
16
(21) 
17
(6) 
18
(2) 
19
(9) 
20
(8) 
21
(19) 
22
(7) 
23
(10) 
24
(9) 
25
(2) 
26

27
(11) 
28
(22) 
29
(23) 
30
(4) 
31
(1) 
From: Dave Eberly <eberly@ma...>  20020811 21:45:39

 Original Message  From: "Pierre Terdiman" <p.terdiman@...> To: <gdalgorithmslist@...> Sent: Sunday, August 11, 2002 4:30 PM Subject: Re: [Algorithms] Sometimes I feel *so*stupid... > > Have you tried your code with a nonunitlength plane.n? > > No, but there's no way it can work with a nonunitlength plane normal. > > So let's say it requires the plane normals to be normalized. (shrug) Thus, confirming my disagreement with Jim's rewritten version of your code that was rewritten based on something Turkowski did ten years ago. Consequently, your line of code plane.d = (plane.d * plane.n  *transform.GetTrans())  plane.n; can be further optimized to plane.d = *transform.GetTrans()  plane.n;  Dave Eberly eberly@... http://www.magicsoftware.com http://www.wildmagic.com 
From: Pierre Terdiman <p.terdiman@wa...>  20020811 20:32:14

> Have you tried your code with a nonunitlength plane.n? No, but there's no way it can work with a nonunitlength plane normal. So let's say it requires the plane normals to be normalized. (shrug) Pierre 
From: Dave Eberly <eberly@ma...>  20020811 20:07:16

 Original Message  From: "Pierre Terdiman" <p.terdiman@...> To: <gdalgorithmslist@...> Sent: Sunday, August 11, 2002 2:37 PM Subject: Re: [Algorithms] Sometimes I feel *so*stupid... > Don't know what to say, it's pretty obvious....(unless I'm missing something > and my code doesn't work, but it looks like it does. Oh, well.) Have you tried your code with a nonunitlength plane.n?  Dave Eberly eberly@... http://www.magicsoftware.com http://www.wildmagic.com 
From: Pierre Terdiman <p.terdiman@wa...>  20020811 18:40:08

> Glad you found the problem, but I am now curious about > the plane transformation code. Since you indicate it is > Pierre's invention and he has used it successfully, I'd like > to know what I am missing about that code. I do not > think I screwed up on the mathematics of transforming > planes... Err, what ? What invention ? If we're speaking about the TransformPlane routine from Opcode, it's just exactly the same as what Ken Turkowski wrote more than 10 years ago, with that Transpose(Inverse()) machinery. I just rewrote it because:  I don't need Transpose(Inverse()) for my matrices (they just have a rotation and a translation, period).  so I don't "transform" my plane, I rotate it then translate it. I find it more intuitive to implement it that way... Code snippet below, it should always be the same as : new plane = Transpose(Inverse(transform)) * old plane ...provided "transform" is just made of a rotation and a translation. ("new plane" and "old plane" are treated as 4D vectors of course) Don't know what to say, it's pretty obvious....(unless I'm missing something and my code doesn't work, but it looks like it does. Oh, well.) Pierre //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////// /** * Transforms a plane by a 4x4 matrix. Same as Plane * Matrix4x4 operator, but faster. * \param plane [in/out] source plane (transformed on return) * \param transform [in] transform matrix */ //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////// inline void TransformPlane(Plane& plane, const Matrix4x4& transform) { // Catch the rotation part of the 4x4 matrix Matrix3x3 Rot = transform; // Rotate the normal plane.n *= Rot; // Compute new d plane.d = (plane.d * plane.n  *transform.GetTrans())  plane.n; } PS: "" is a dot product PPS: it's called "TransformPlane" despite what I wrote above, urrr.... bad ! 
From: Dave Eberly <eberly@ma...>  20020811 13:11:15

 Original Message  From: "Jim Offerman" <j.offerman@...> To: <gdalgorithmslist@...> Sent: Sunday, August 11, 2002 6:37 AM Subject: [Algorithms] Sometimes I feel *so*stupid... > Darned! I've found the bug in my frustum culling code... the actual code > went something like: <snip> Glad you found the problem, but I am now curious about the plane transformation code. Since you indicate it is Pierre's invention and he has used it successfully, I'd like to know what I am missing about that code. I do not think I screwed up on the mathematics of transforming planes...  Dave Eberly eberly@... http://www.magicsoftware.com http://www.wildmagic.com 
From: Jim Offerman <j.offerman@in...>  20020811 10:37:51

Darned! I've found the bug in my frustum culling code... the actual code went something like: CullResult Frustum::Cull(AABB &aabb, Matrix4 &transform) { CullResult result; for (short i = 0; i < 5; i++) { Plane plane = mPlanes[i]; plane.Transform(transform); result = aabb.CullToPlane(mPlanes[i]); // STUPID STUPID STUPID!!! ... } } So I was transforming the frustum planes, but never actually using them... grmbl! Jim Offerman Innovade http://www.innovade.com http://www.jimofferman.nl 
From: Pierre Terdiman <p.terdiman@wa...>  20020811 10:13:29

> True. But, according to Dave, your plane transformation code is wrong... I > just figured I'd let you know. What ? Guess I'll read the thread then... (later, no time right now). I would be surprised anyway if that code was wrong. I use it for a lot of things, never had any problem. Pierre 
From: Jim Offerman <j.offerman@in...>  20020811 09:55:31

> I didn't follow the thread but it seems the plane transformation is not the > problem, is it ? True. But, according to Dave, your plane transformation code is wrong... I just figured I'd let you know. Jim Offerman Innovade http://www.innovade.com http://www.jimofferman.nl 
From: Pierre Terdiman <p.terdiman@wa...>  20020811 08:54:01

> Unfortunately, your new plane > transformation function doesn't seem to fix anything :(. [snip] > PS. Pierre: I copide my original plane transformation algorithm from Opcode, > so you may want to look into it... I didn't follow the thread but it seems the plane transformation is not the problem, is it ? Pierre 
From: Jim Offerman <j.offerman@in...>  20020811 07:41:16

Dave, Thank you for that very detailed explanation. All your assumptions about my code are correct  full score there :). I think I can at least conclude from your last set of equations [N' = M^T * N and d' = d + Dot(N, C)] that I was right in using just the transpose of the world transformation matrix. Unfortunately, your new plane transformation function doesn't seem to fix anything :(. Niki suggested to me offline that, since I am using the (his & Gil's) plane extraction algorithm, I should just do: frustum.Extract(world * viewproject) Which works perfectly. I don't fully understand why transforming the frustum after it has been extracted from the view/project matrix doesn't work though, 'cause in my mind it should have... Jim Offerman Innovade http://www.innovade.com http://www.jimofferman.nl PS. Pierre: I copide my original plane transformation algorithm from Opcode, so you may want to look into it...  Original Message  From: "Dave Eberly" <eberly@...> To: <gdalgorithmslist@...> Sent: Sunday, August 11, 2002 6:04 AM Subject: Re: [Algorithms] Frustum Frustrations... >  Original Message  > From: "Jim Offerman" <j.offerman@...> > To: <gdalgorithmslist@...> > Sent: Saturday, August 10, 2002 12:29 PM > Subject: [Algorithms] Frustum Frustrations... > > Jim, you sent a response only to me, not to the list. It was: > > > %> > // Get inverse transpose of the inverse world matrix > %> > // Which is just the transpose of the world matrix. > %> > matrix = Transpose(node>GetWorldMatrix()); > %> <snip> > %> > Can anyone spot what's wrong here? > %> > %> Are your comments correct? Your plane transformation > %> code looks like it requires a matrix to be 4x4 in > %> homogeneous coordinates. > % > % True. But according to the Direct3DX docs you need to transform planes > (and > % normals) using the inverse transpose of the transformation matrix. > % > % In the above case, the transformation is the inverse of the world matrix > % since I'm transforming from world>local coords. Putting two and two > % together yields: > % > % Transpose(Inverse(Inverse(worldMatrix))); > % > % which (if I am not mistaken) equals: > % > % Transpose(worldMatrix); > % > % Hence I'm just taking the transpose... but I could still be in error of > % course... > > Based on your first email, I think I can assume that you have the > camera/frustum in world coordinates. A frustum plane is of the > form Dot(N,X) = d where N is a unitlength normal. [If E is the > eye point in world coordinates, then d = Dot(N,E) since E is > on each frustum plane.] > > A transformation is applied, Y = A*X+B, where A is invertible > with inverse denoted by A^{1}. Solving for X produces > X = A^{1}*(YB). Replacing this in the plane equation, > Dot(N,A^{1}*(YB)) = d. Some algebra leads to > Dot(A^{T}*N,Y) = Dot(A^{T}*N,B) + d where A^{T} > is the transpose of the inverse of A. Thus, the transformed plane > is Dot(N',Y) = d' where N' = A^{T}*N, d' = Dot(N',B)+d. > Note that the value of d is *added* on the righthand side. Your > Plane::Transform code has no such addition, so it cannot be correct. > Moreover, if your input matrix has scaling, you are not guaranteed > that N' is unit length. This might (or might not) be an issue if you > actually use d' as a measure of (signed) distance. > > Now about transforming the frustum into model space. If the > world transformation from model coordinates Y to world coordinates > X is X = M*Y+C, then Y = M^{1}*X  M^{1}*C. In terms of > the above notation, A = M^{1} and B = M^{1}*C. The > transformed plane has normal N' = M^T and constant > d' = d+Dot(N,C). I think your code indicates you are using the > OpenGL convention for representing matrices (translation > component occurs in last row, last column is [0 0 0 1]^T). If > this is the case, then the body of Plane::Transform should be > the following. Since I do not know how you allow access to > the coordinates of Vector3 and Vector4, I'll just use (x,y,z) for > a Vector3 and (x,y,z,w) for a Vector4. > > Vector4 xfrmPlane = Vector4(mNormal,mDistance)*matrix; > mNormal.x = xfrmPlane.x; > mNormal.y = xfrmPlane.y; > mNormal.z = xfrmPlane.z; > mDistance = xfrmPlane.w; > > If 'matrix' has scaling in it, and if you want a unitlength normal, > then additionally you need > Real length = mNormal.Length(); > mNormal /= length; > mDistance /= length; > >  > Dave Eberly > eberly@... > http://www.magicsoftware.com > http://www.wildmagic.com > > > > > >  > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Dave Eberly <eberly@ma...>  20020811 04:04:30

 Original Message  From: "Jim Offerman" <j.offerman@...> To: <gdalgorithmslist@...> Sent: Saturday, August 10, 2002 12:29 PM Subject: [Algorithms] Frustum Frustrations... Jim, you sent a response only to me, not to the list. It was: %> > // Get inverse transpose of the inverse world matrix %> > // Which is just the transpose of the world matrix. %> > matrix = Transpose(node>GetWorldMatrix()); %> <snip> %> > Can anyone spot what's wrong here? %> %> Are your comments correct? Your plane transformation %> code looks like it requires a matrix to be 4x4 in %> homogeneous coordinates. % % True. But according to the Direct3DX docs you need to transform planes (and % normals) using the inverse transpose of the transformation matrix. % % In the above case, the transformation is the inverse of the world matrix % since I'm transforming from world>local coords. Putting two and two % together yields: % % Transpose(Inverse(Inverse(worldMatrix))); % % which (if I am not mistaken) equals: % % Transpose(worldMatrix); % % Hence I'm just taking the transpose... but I could still be in error of % course... Based on your first email, I think I can assume that you have the camera/frustum in world coordinates. A frustum plane is of the form Dot(N,X) = d where N is a unitlength normal. [If E is the eye point in world coordinates, then d = Dot(N,E) since E is on each frustum plane.] A transformation is applied, Y = A*X+B, where A is invertible with inverse denoted by A^{1}. Solving for X produces X = A^{1}*(YB). Replacing this in the plane equation, Dot(N,A^{1}*(YB)) = d. Some algebra leads to Dot(A^{T}*N,Y) = Dot(A^{T}*N,B) + d where A^{T} is the transpose of the inverse of A. Thus, the transformed plane is Dot(N',Y) = d' where N' = A^{T}*N, d' = Dot(N',B)+d. Note that the value of d is *added* on the righthand side. Your Plane::Transform code has no such addition, so it cannot be correct. Moreover, if your input matrix has scaling, you are not guaranteed that N' is unit length. This might (or might not) be an issue if you actually use d' as a measure of (signed) distance. Now about transforming the frustum into model space. If the world transformation from model coordinates Y to world coordinates X is X = M*Y+C, then Y = M^{1}*X  M^{1}*C. In terms of the above notation, A = M^{1} and B = M^{1}*C. The transformed plane has normal N' = M^T and constant d' = d+Dot(N,C). I think your code indicates you are using the OpenGL convention for representing matrices (translation component occurs in last row, last column is [0 0 0 1]^T). If this is the case, then the body of Plane::Transform should be the following. Since I do not know how you allow access to the coordinates of Vector3 and Vector4, I'll just use (x,y,z) for a Vector3 and (x,y,z,w) for a Vector4. Vector4 xfrmPlane = Vector4(mNormal,mDistance)*matrix; mNormal.x = xfrmPlane.x; mNormal.y = xfrmPlane.y; mNormal.z = xfrmPlane.z; mDistance = xfrmPlane.w; If 'matrix' has scaling in it, and if you want a unitlength normal, then additionally you need Real length = mNormal.Length(); mNormal /= length; mDistance /= length;  Dave Eberly eberly@... http://www.magicsoftware.com http://www.wildmagic.com 
From: Ken Paulson <ken@dr...>  20020811 00:28:35

At 08:24 PM 8/7/2002, Leath Muller wrote: >>Most of our data is in a combination of XML + "unstructured blob" >>files. Our runtime and editing tools have always warned about resource >>conflicts, format errors, etc. No one noticed them because people either >>ignored them or ran away screaming at the volumes of spew. > >Is there any particular reason people don't use RDBMS for this stuff? I would guess that there isn't a large overlap in skills sets there. How many game developers are competent database developers? For a complex system you'll want skilled DB developers, and possibly someone who is capable of acting as a DBA. If you have an extremely simple system, then using RDBMS is overkill and likely not worth the effort. Having said that, if anyone is looking for a talented Oracle developer/DBA who has some (hobbylevel) experience with game development & DirectX, let me know. :) 