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
(31) 
2
(28) 
3
(10) 
4
(15) 
5
(22) 
6
(21) 
7
(30) 
8
(30) 
9
(44) 
10
(6) 
11
(5) 
12
(50) 
13
(33) 
14
(61) 
15
(68) 
16
(43) 
17
(24) 
18
(14) 
19
(85) 
20
(33) 
21
(30) 
22
(38) 
23
(1) 
24
(5) 
25
(6) 
26
(6) 
27
(29) 
28
(34) 
29
(81) 
30
(61) 
31
(10) 
From: Brian Hook <bwh@wk...>  20010309 22:45:16

Damn Gil, that's a pretty cool derivation, and way intuitive. And I remember when people used to bitch that word problems in school were a waste of time =) Thanks, Brian 
From: Eric Lengyel <lengyel@C4Engine.com>  20010309 22:19:34

Pretty neat. > The "transforming planes" derivation seem sound to me, but I actually came > up with this from a different angle. Using the opengl way of writing things: > > clip_space_point = M * local_space_point > > local_space_point is a 4 vector with a one in the last component. Break this > down into components: > > clip_space_point.x = row(M,0) dot local_space_point > clip_space_point.y = row(M,1) dot local_space_point > clip_space_point.z = row(M,2) dot local_space_point > clip_space_point.w = row(M,3) dot local_space_point > > Now lets look at the clip space inequalities: > > w<x<w > w<y<w > w<z<w > > You look at these one at a time. I'll just do x<w: > > clip_space_point.x < clip_space_point.w > > substitute in from above > > row(M,0) dot local_space_point < row(M,3) dot local_space_point > > do some algebra > > 0 < row(M,3) dot local_space_point  row(M,0) dot local_space_point > > 0< (row(M,3)  row(M,0)) dot local_space_point > > Now this is in the form of a plane equation with the 4 coefficients being > (row(M,3)  row(M,0)) > > Then you do something similar for the other 5 planes. The plane equations you > get are not normalized....i.e. the normal is not of unit length. For culling > you don't need to worry about it. If you want a normalized plane equation, > divide all 4 coefficients by the length of the plane normal. > Gil 
From: Eric Lengyel <lengyel@C4Engine.com>  20010309 22:17:53

Brian Hook wrote: > At 10:39 PM 3/8/01 0800, Eric Lengyel wrote: >> This whole thing about frustum plane extraction from the projection matrix is >> a snap if you look at it in the following way. Let P be the 4x4 projection >> matrix which transforms points from eye space into normalized clip space. >> Then Inverse(P) transforms points from clip space into eye space. The >> frustum planes in clip space are dirt simple: >> >> left = (1,0,0,1) >> right = (1,0,0,1) >> top = (0,1,0,1) >> bottom = (0,1,0,1) >> near = (0,0,1,1) >> far = (0,0,1,1) >> >> This is because the view frustum is a cube centered on the origin in clip >> space and each plane is one unit from the origin. > > Aha, this is what I didn't get  the derivation is based on using known > clip space planes and computing the inverse transform that takes them into > eye space. This presumes that you have inward facing normals and a > lefthanded clip space coordinate system, however. Something to be careful > of (OpenGL is natively righthanded, but I think it switches to lefthanded > for clip space...I'll have to look that up though). Yes, clip space in OpenGL is lefthanded. X points to the right, Y points up, and Z points in the direction you're looking. The lefthandedness is also revealed by the fact that the determinants of the OpenGL projection matrices are negative. >> Now planes are transformed using the inverse transpose of a matrix, so to >> transform these planes from clip space into eye space, we need to use >> Transpose(Inverse(Inverse(P))) = Transpose(P). Thus, the coefficients of the >> above planes tell us by what to multiply each column of Transpose(P), which >> are also the rows of P itself. So using the notation P[i] to represent >> (zerobased) row i of P, we have for the eye space frustum planes: >> >> left = P[0] + P[3] >> right = P[0] + P[3] >> top = P[1] + P[3] >> bottom = P[1] + P[3] >> near = P[2] + P[3] >> far = P[2] + P[3] > > There's a bit that gets muddled in here, so please bear with me. Are you > assuming that P is initially a row major matrix, or are you thinking it's > an OpenGL style column major matrix that happens to be used in a row major, > righthanded system? =) I am treating P as a matrix which operates on 4x1 column vectors on the left (OpenGL style). That is, given a column vector V, we transform like V' = P * V . > Factoring out any API specifics, let's assume that M is a row major matrix > such that: > > M*v = c > > where 'v' is a point in object space and 'c' is the final clipspace > coordinate. M is the matrix that goes from object space to clip space (in > OpenGL terms, this is the concatenation of the modelview and projection > matrices). > > Now, to go from clip space to object space we need to take the Transpose of > M and multiply it against the clip space planes. > > T*c = f (where T = Transpose(M)) > > left.clip = (1,0,0,1) > therefore > left.object = T*left.clip = M.column0 + M.column3 > > Does that seem correct? I'm not exactly sure what you mean by "rowmajor matrix" here, but it sounds like you're using the DirectX style transforms, where vectors are treated as 1x4 row matrices. In that case, we transform like c = v * M . Then we have left.object = left.clip * Transpose(M) = [ 1 0 0 1 ] * Transpose(M) = Transpose(M).row0 + Transpose(M).row3 = M.column0 + M.column3 So, yes, it seems correct.  Eric Lengyel 
From: Christer_Ericson@Playstation.sony.com  20010309 19:51:12

Actually, if you reread what I wrote you'll see that I did comment on the 3 element case. The part I didn't bother to state was that given two of them in the same row, you can determine the third value in that row, and you now have your four values. Christer Ericson Sony Computer Entertainment, Santa Monica David Notario <dnotario@...> To: gdalgorithmslist@... Sent by: cc: gdalgorithmslistadmin@... Subject: RE: [Algorithms] quaternions in a 3d engine eforge.net 03/09/2001 12:12 AM Please respond to gdalgorithmslist #a31 = sqrt (1a11^2a21^2) #a32 = sqrt (1a12^2a22^2) #a13 = sqrt (1a11^2a12^2) #a23 = sqrt (1a21^2a22^2) #a33 = sqrt (a11^2+a12^2+a21^2+a22^21) # #which requires five square roots and four squares which if we have a #square root table counts as 4M+5T or, if we also have a squares table, #is just 9T. Yes, this is the 4 element version... i was asking for the 3 element, Ron has just sent a post which I think covers it, I will try to decipher it when I have time to burn some brain cycles. Thanks David... PS: People is telling me that in other lists my messages come with garbage at the end, is this true for this list too? _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist 
From: D. Stimits <stimits@id...>  20010309 18:59:53

> Amir Latif wrote: > > > > Hold your breath and have a look : > > > http://www.math.niu.edu/~rusin/knownmath/collection/master.html > > > I can ping the site with very low lag, but any web browsing just > sits > > and hangs without reply. > > Think it works ok ... just takes a looooooong time to load. > > amir. It works fine today; last night it would stall at 0 bytes. 
From: Andy Ross <andy@ne...>  20010309 18:59:39

Robert Dibley wrote: > > > If anyone also has info on 128bit fixedpoint math libraries > > that work exceedingly well, I may use that instead. > > No references for you, but if you do a little maths I think you'll find 128 > bit integers would be plenty  it gives you something like the entire > universe down to micrometre accuracy (ok, I'm exaggerating a little) so > you won't need to worry about floating point. I beg to differ, you're actually UNDER estimating a bit: Speed of light: 3 x 10^8 m/s Length of year: Pi x 10^7 seconds (within a few percent) Size of visible universe: 1 x 10^10 light years (a rough age for the universe) um per meter: 1 x 10^6 Multiply that all out, and you get: Size of universe in micrometers: 10^32 Biggest value representable in 128 bits: 10^38 Bingo. So 128 bits actually represents the universe to within a picometer, not a micrometer. Thbbt! More to the point: why on earth would anyone NEED this in a computer simulation? This is precision to the point of absurdity; even double precision floating point is more than sufficient for pretty much anything someone would care to represent. Andy  Andrew J. Ross NextBus Information Systems Senior Software Engineer Emeryville, CA andy@... http://www.nextbus.com (510)4203126 Why Wait? 
From: Dave Eberly <eberly@ma...>  20010309 17:59:34

Offtopic, but I was quite entertained by this (its been a long day...) I wrote: > Well, I am sure Pertti Lounesto will remind you that the octonians > have to do with R^7 and the fact that cross product can only be > made meaningful in R^3 and R^7. :) For those of you who use Outlook Express and have Microsoft Word installed with spell checker, you should be entertained by the suggested words for the unrecognized "Pertti Lounesto" ("Pretty" "Looniest").  Dave Eberly eberly@... http://www.magicsoftware.com http://www.wildmagic.com 
From: Dave Eberly <eberly@ma...>  20010309 17:54:50

From: "Charles Bloom" <cbloom@...> > At 03:12 PM 3/9/2001 +0000, you wrote: > >Dave Eberly wrote: > > > > >... A rotation matrix can be represented > > >as R = exp(S) where S is skewsymmetric. ... > > This is just a quaternion in disguise, of course... you're > working with S in it's SO(3) representation and the quat is > just the SU(2) double cover of SO(3). If you look at my original post, the context was that R is a rotation in ndimensions. The "disguised" quaternion is, of course, only for n = 3. > Anyway, about Ron's earlier note about quaternions being the only > neato algebraic cover of the rotations, I believe that the octonions > fit up there somewhere. I can't remember where, but I do remember > that they end up falling out nicely in string theory. I think > they might make a good representation of SO(10) or something like > that... Well, I am sure Pertti Lounesto will remind you that the octonians have to do with R^7 and the fact that cross product can only be made meaningful in R^3 and R^7. :)  Dave Eberly eberly@... http://www.magicsoftware.com http://www.wildmagic.com 
From: Charles Bloom <cbloom@cb...>  20010309 17:29:05

At 03:12 PM 3/9/2001 +0000, you wrote: >Dave Eberly wrote: > > >... A rotation matrix can be represented > >as R = exp(S) where S is skewsymmetric. ... This is just a quaternion in disguise, of course... you're working with S in it's SO(3) representation and the quat is just the SU(2) double cover of SO(3). >The thing to understand is that the Euler rotations are not in >genreral rotations about coordinate axes, but rather rotations in >coordinate planes, and the rotations in a plane have dimension 1. In >3space there is a 11 correspondence between coordinate axes and >coordinate planes, but not in higher dimensions. Since it takes two >coordinate axes to determine a coordinate plane, the number of >different coordinate planes in nspace is the number of different ways >of choosing a subset of 2 things out of a set of n things, i.e. the >binomial coefficient C(n,2) = n(n1)/2 There are lots of amazing things about 3 dimensions. For example, 3 dimensions are the only place where "knots" exist  that is, you can define a mapping of a 1d interval to 3d points which cannot be converted to a simple loops with a homotopy transform. This turns out to have powerful consequences for physics, in which the topology of a particle's path in spacetime can determine it's very *type*. In fact, in some string theories the identity of the particle can come from its knot. There's also the fantastic Feynman "belt trick" (do a search on the web for "candle dances") which only happens in 3d. The best book on this is the 1986 Dirac Memorial lecture. Here are some links : http://newton.umsl.edu/~philf/candles.html http://math.ucr.edu/home/baez/spin.stat.html http://math.ucr.edu/home/baez/harmonic.html I strong recommend John Baez's book "Gauge Fields, knots, and Gravity". It's got a super introduction to the basic of differential geometry, differential forms and whatnot. You can write stuff like the cross product of 'a' and 'b' in any number of dimentsions is just *(a/\b) . The differential geometers like to say that 3d is cool because the "hodge dual" of a plane (which is a tensor, of course) is a vector, which is unique to 3d. In 4d you almost have an algebraic cover; since (4*3)/2 = 6 you can represent rotations in 4d with two 3d rotation, such as two SU(2) spinors. This is the common SU(2)xSU(2) representation of the special relativity symmetry group. You can think of these as the first SU(2) being all planes without 't' (xy, yz,zx) and the second SU(2) being all planes with 't' (xt,yt,zt). Anyway, about Ron's earlier note about quaternions being the only neato algebraic cover of the rotations, I believe that the octonions fit up there somewhere. I can't remember where, but I do remember that they end up falling out nicely in string theory. I think they might make a good representation of SO(10) or something like that...  Charles Bloom cbloom@... http://www.cbloom.com 
From: Tom Forsyth <tomf@mu...>  20010309 17:01:50

Doh! Yes. I'll separate my statement to two statements. You can lock a subrange. You can lock with cunning flags & the driver can multibuffer. You're right that trying to do both won't achieve terribly useful things (and will possibly cause a copy). Tom Forsyth  Muckyfoot bloke. What's he up to now? http://www.muckyfoot.com/startopia/cam.html > Original Message > From: Javier Arevalo [mailto:jare@...] > Sent: 09 March 2001 16:40 > To: gdalgorithmslist@... > Subject: Re: [Algorithms] VIPM, VDPM, ROAM questions > > > Hrm?!? Maybe I missed something, however, picture this: you > lock a subrange > of a VB in overwrite mode, fill it, then then submit a > DrawPrimitive that > uses the whole Vertex Buffer range... How could the driver > know in advance > if it can relocate the subrange to a different place? Seems > to me the driver > can only doublebuffer an entire VB, not a subrange. > > Javier Arevalo > Pyro Studios > >  Original Message  > From: "Tom Forsyth" <tomf@...> > To: <gdalgorithmslist@...> > Sent: Friday, March 09, 2001 12:30 PM > Subject: RE: [Algorithms] VIPM, VDPM, ROAM questions > > > > No, there's no additional copies. The D3D interface allows > you to lock a > > subregion of a Vertex or Index Buffer with a flag saying > "I promise to > > overwrite everything in this region, and not rely on > existing data". Which > > means the driver can point you at any region of spare > memory it wants  > the > > app doesn't care. So the driver can multibuffer as it chooses. > > > > Equivalent functionality, just a slightly different mechanism. > > > > > > Tom Forsyth  Muckyfoot bloke. > > > > What's he up to now? > > http://www.muckyfoot.com/startopia/cam.html > > > > > > > > > Original Message > > > From: Tom Hubina [mailto:tomh@...] > > > Sent: 08 March 2001 22:02 > > > To: gdalgorithmslist@... > > > Subject: RE: [Algorithms] VIPM, VDPM, ROAM questions > > > > > > > > > At 04:20 AM 3/8/2001, you wrote: > > > >Swapping in chunks shouldn't be a problem  this comes under the > > > >completelydynamic "lock buffer and completely overwrite > > > contents" category, > > > >which is fine (coz the driver multibuffers behidn your back > > >  at least it > > > >does in D3D). > > > > > > In OpenGL you make use of the fence and flush operations > (NVIDIA only > > > extensions AFAIK) to break a large chunk of AGP memory > into multiple > > > smaller chunks make sure that a chunk of the AGP memory is > > > finished being > > > processed before you write over it. In other words, all > > > double (triple, > > > whatever) buffering is under the application's control > and there's no > > > copying of the memory by the driver except to the video card > > > through DMA. > > > I'm not certain if the doublebuffering for D3D you > describe implies > > > additional copies on the CPU or not. > > > > > > Tom > > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > 
From: Cem UZUNLAR <turing@an...>  20010309 16:35:43

I resolved the problem. Now I call glPixelStorei( GL_UNPACK_ALIGNMENT, 1 ); ______________________________ Cem UZUNLAR turing@... >Original Message >From: gdalgorithmslistadmin@... >[mailto:gdalgorithmslistadmin@...]On Behalf Of Cem >UZUNLAR >Sent: Friday, March 09, 2001 4:33 PM >To: Algorithms >Subject: [Algorithms] Mipmapping > > >I have a small problem with mipmaps. >When viewed from a long distance( possibly when gl is using small mipmap >levels), they are getting greenish, yellowish smoothly. >I save all the mipmap levels to disk and examined them but there is nothing >wrong >Textures are mapped using repeat wrap mode in both directions. They are 24 >bit RGB textures. All mipmap levels uploaded.. > >______________________________ >Cem UZUNLAR turing@... > > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist 
From: Javier Arevalo <jare@py...>  20010309 16:35:25

Hrm?!? Maybe I missed something, however, picture this: you lock a subrange of a VB in overwrite mode, fill it, then then submit a DrawPrimitive that uses the whole Vertex Buffer range... How could the driver know in advance if it can relocate the subrange to a different place? Seems to me the driver can only doublebuffer an entire VB, not a subrange. Javier Arevalo Pyro Studios  Original Message  From: "Tom Forsyth" <tomf@...> To: <gdalgorithmslist@...> Sent: Friday, March 09, 2001 12:30 PM Subject: RE: [Algorithms] VIPM, VDPM, ROAM questions > No, there's no additional copies. The D3D interface allows you to lock a > subregion of a Vertex or Index Buffer with a flag saying "I promise to > overwrite everything in this region, and not rely on existing data". Which > means the driver can point you at any region of spare memory it wants  the > app doesn't care. So the driver can multibuffer as it chooses. > > Equivalent functionality, just a slightly different mechanism. > > > Tom Forsyth  Muckyfoot bloke. > > What's he up to now? > http://www.muckyfoot.com/startopia/cam.html > > > > > Original Message > > From: Tom Hubina [mailto:tomh@...] > > Sent: 08 March 2001 22:02 > > To: gdalgorithmslist@... > > Subject: RE: [Algorithms] VIPM, VDPM, ROAM questions > > > > > > At 04:20 AM 3/8/2001, you wrote: > > >Swapping in chunks shouldn't be a problem  this comes under the > > >completelydynamic "lock buffer and completely overwrite > > contents" category, > > >which is fine (coz the driver multibuffers behidn your back > >  at least it > > >does in D3D). > > > > In OpenGL you make use of the fence and flush operations (NVIDIA only > > extensions AFAIK) to break a large chunk of AGP memory into multiple > > smaller chunks make sure that a chunk of the AGP memory is > > finished being > > processed before you write over it. In other words, all > > double (triple, > > whatever) buffering is under the application's control and there's no > > copying of the memory by the driver except to the video card > > through DMA. > > I'm not certain if the doublebuffering for D3D you describe implies > > additional copies on the CPU or not. > > > > Tom 
From: Dave Eberly <eberly@ma...>  20010309 16:06:31

From: "Ron Levine" <ron@...> > Oh Dave, look out, you are treading dangerously close to > the abyss of Lie groups and Lie algebras. I've already been through the abyssmy first thesis topic in mathematics was in the area of symmetry groups for differential equations. I tried extending the ideas to functional operators, but changed fields after reading AMS translations of papers by Russian mathematicians who had already done it. > But you can arrive at the same number by less esoteric > considerations than the exponential of a matrix, namely, > by considering good old Euler angles plus elementary > combinatorics. <snip> Cute. I've never thought of it this way. Well, never too old to learn something new.  Dave Eberly eberly@... http://www.magicsoftware.com http://www.wildmagic.com 
From: Robert Dibley <RDibley@ac...>  20010309 16:00:20

> If anyone also has info on 128bit fixedpoint math libraries > that work exceedingly well, I may use that instead. No references for you, but if you do a little maths I think you'll find 128 bit integers would be plenty  it gives you something like the entire universe down to micrometre accuracy (ok, I'm exaggerating a little) so you won't need to worry about floating point. Robert 
From: Gary McTaggart <gary@va...>  20010309 15:52:37

What card/driver are you running on? I've run into something similar on a Quadro/notsurewhatdriver. Gary > Original Message > From: Cem UZUNLAR [mailto:turing@...] > Sent: Friday, March 09, 2001 6:33 AM > To: Algorithms > Subject: [Algorithms] Mipmapping > > > I have a small problem with mipmaps. > When viewed from a long distance( possibly when gl is using > small mipmap > levels), they are getting greenish, yellowish smoothly. > I save all the mipmap levels to disk and examined them but > there is nothing > wrong > Textures are mapped using repeat wrap mode in both > directions. They are 24 > bit RGB textures. All mipmap levels uploaded.. > > ______________________________ > Cem UZUNLAR turing@... > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > 
From: Ron Hay <rhay@cy...>  20010309 15:40:32

I have two questions, first does anyone have experience with a good highprecision (128 bit+) floatingpoint math library? I've done plenty of web searching and found many different libraries, but have no idea about their stability, speed, etc. I'll be using it as part of a solar system sim, where the student is able to hang out on the surfaces of planets as well as cruise into orbital views of the solar system. I wrote a prototype last Spring, and doubles run out of room fairly quickly. Second, does anyone know where i can find performance statistics on such libraries  ie how slow is a double double. If anyone also has info on 128bit fixedpoint math libraries that work exceedingly well, I may use that instead. Thanks! Ron Hay Cybernet Systems Corp. 
From: <ron@do...>  20010309 15:12:22

Dave Eberly wrote: >... A rotation matrix can be represented >as R =3D exp(S) where S is skewsymmetric. This is the >easy way to remember the dimension of the rotations of >nspace. An nbyn skewsymmetric matrix has >n(n1)/2 independent components.=20 Oh Dave, look out, you are treading dangerously close to the abyss of Lie groups and Lie algebras. In fact, that is how I reminded myself of the n(n1)/2 value. But you can arrive at the same number by less esoteric considerations than the exponential of a matrix, namely, by considering good old Euler angles plus elementary combinatorics. =20 The thing to understand is that the Euler rotations are not in genreral rotations about coordinate axes, but rather rotations in coordinate planes, and the rotations in a plane have dimension 1. In 3space there is a 11 correspondence between coordinate axes and coordinate planes, but not in higher dimensions. Since it takes two coordinate axes to determine a coordinate plane, the number of different coordinate planes in nspace is the number of different ways of choosing a subset of 2 things out of a set of n things, i.e. the binomial coefficient C(n,2) =3D n(n1)/2 
From: Michael Harrison <mharrison@pe...>  20010309 14:45:37

First, I apologize for the offtopic post. If you feel inclined to flame me for it, please do it privately and not to the list. This is the most diverse (and intelligent) list I'm aware of, so I thought I'd ask here rather than just some random place on the net. Do any of you use Alienbrain for your source control? We're evaluating it now and while it appears to offer almost as many features as Sourcesafe (and nxn appear to be scrambling to add what Alienbrain is currently missing) the one thing I haven't been able to find out is just how reliable the software is. A search of the net and newsgroups would seem to indicate that Alienbrain is either not widely used or not widely talked about. Have any of you used it in a full production environment and if so, what are your thoughts on the product?  Michael Harrison Senior Software Engineer Paradigm Entertainment Voice 9724886393 
From: Cem UZUNLAR <turing@an...>  20010309 14:32:11

I have a small problem with mipmaps. When viewed from a long distance( possibly when gl is using small mipmap levels), they are getting greenish, yellowish smoothly. I save all the mipmap levels to disk and examined them but there is nothing wrong Textures are mapped using repeat wrap mode in both directions. They are 24 bit RGB textures. All mipmap levels uploaded.. ______________________________ Cem UZUNLAR turing@... 
From: Gil Gribb <ggribb@ra...>  20010309 14:21:15

The "transforming planes" derivation seem sound to me, but I actually came up with this from a different angle. Using the opengl way of writing things: clip_space_point = M * local_space_point local_space_point is a 4 vector with a one in the last component. Break this down into components: clip_space_point.x = row(M,0) dot local_space_point clip_space_point.y = row(M,1) dot local_space_point clip_space_point.z = row(M,2) dot local_space_point clip_space_point.w = row(M,3) dot local_space_point Now lets look at the clip space inequalities: w<x<w w<y<w w<z<w You look at these one at a time. I'll just do x<w: clip_space_point.x < clip_space_point.w substitute in from above row(M,0) dot local_space_point < row(M,3) dot local_space_point do some algebra 0 < row(M,3) dot local_space_point  row(M,0) dot local_space_point 0< (row(M,3)  row(M,0)) dot local_space_point Now this is in the form of a plane equation with the 4 coefficients being (row(M,3)  row(M,0)) Then you do something similar for the other 5 planes. The plane equations you get are not normalized....i.e. the normal is not of unit length. For culling you don't need to worry about it. If you want a normalized plane equation, divide all 4 coefficients by the length of the plane normal. Gil > At 10:39 PM 3/8/01 0800, Eric Lengyel wrote: > >This whole thing about frustum plane extraction from the projection matrix > >is a snap if you look at it in the following way. Let P be the 4x4 > >projection matrix which transforms points from eye space into normalized > >clip space. Then Inverse(P) transforms points from clip space into eye > >space. The frustum planes in clip space are dirt simple: > > > >left = (1,0,0,1) > >right = (1,0,0,1) > >top = (0,1,0,1) > >bottom = (0,1,0,1) > >near = (0,0,1,1) > >far = (0,0,1,1) > > > >This is because the view frustum is a cube centered on the origin in clip > >space and each plane is one unit from the origin. > > Aha, this is what I didn't get  the derivation is based on using known > clip space planes and computing the inverse transform that takes them into > eye space. This presumes that you have inward facing normals and a > lefthanded clip space coordinate system, however. Something to be careful > of (OpenGL is natively righthanded, but I think it switches to lefthanded > for clip space...I'll have to look that up though). > > >Now planes are > >transformed using the inverse transpose of a matrix, so to transform these > >planes from clip space into eye space, we need to use > >Transpose(Inverse(Inverse(P))) = Transpose(P). Thus, the coefficients of > >the above planes tell us by what to multiply each column of Transpose(P), > >which are also the rows of P itself. So using the notation P[i] to > >represent (zerobased) row i of P, we have for the eye space frustum planes: > > > >left = P[0] + P[3] > >right = P[0] + P[3] > >top = P[1] + P[3] > >bottom = P[1] + P[3] > >near = P[2] + P[3] > >far = P[2] + P[3] > > There's a bit that gets muddled in here, so please bear with me. Are you > assuming that P is initially a row major matrix, or are you thinking it's > an OpenGL style column major matrix that happens to be used in a row major, > righthanded system? =) > > Factoring out any API specifics, let's assume that M is a row major matrix > such that: > > M*v = c > > where 'v' is a point in object space and 'c' is the final clipspace > coordinate. M is the matrix that goes from object space to clip space (in > OpenGL terms, this is the concatenation of the modelview and projection > matrices). > > Now, to go from clip space to object space we need to take the Transpose of > M and multiply it against the clip space planes. > > T*c = f (where T = Transpose(M)) > > left.clip = (1,0,0,1) > therefore > left.object = T*left.clip = M.column0 + M.column3 > > Does that seem correct? > > Brian Hook > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist 
From: Dave Eberly <eberly@ma...>  20010309 13:35:36

From: "Ron Levine" <ron@...> <snip of (1) reduction to three parameters and (2) the reconstruction of rotation using a sqrt and solving a quadratic equation> A different view that requires about the same amount of calculation time. A rotation matrix can be represented as R = exp(S) where S is skewsymmetric. This is the easy way to remember the dimension of the rotations of nspace. An nbyn skewsymmetric matrix has n(n1)/2 independent components. When R is 3x3, S is 3x3 and has 3 independent components, S01 = z, S02 = y, and S12 = x. You can just store the 3 values (x,y,z). Define L to be the length of (x,y,z). Then R = I + (sin(L)/L)*S + ((1cos(L))/L^2)*S^2 (Look familiar? :) To reconstruct R you need L (a sqrt calculation), sin(L), and cos(L), the expensive portion of the process. If you can rely on the math library to calculate sin(L) and cos(L) at the same time, you reduce to only 2 expensive operations. However, if you are willing to store 5 floats; x, y, z, sin(L)/L, and (1cos(L))/L^2, then reconstruction only involves *,+,, perhaps a reasonable tradeoff of space and time.  Dave Eberly eberly@... http://www.magicsoftware.com http://www.wildmagic.com 
From: Matt Godbolt <matthew@ar...>  20010309 12:49:20

> Actually, this is really oldschool stuff. I believe I saw Ian Bell > of Elite fame mentioning this being used in Elite in which case is > has been used since at least 1984. [Surfing.] Ah, yes, there's > a mentioning of the principle here: > > http://home.clara.net/iancgbell/maths/rot3d.htm > If you feel like reading the most unreadable 6502 assembler ever written (I mean, it's even worse than mine!) check out: http://home.clara.net/cjpinder/elite.html ..and you could check...I started reading it but gave up after about ten minutes! Matt ==  Matt Godbolt Coder, Argonaut Games PLC 
From: Neal Tringham <neal@ps...>  20010309 12:46:28

From: Rui Ferreira <rui.ferreira@...> > What's the deal with EXT_compiled_vertex_array ??... > > This thing is supposed to be faster, but on my G200 all I got is a 40 > percent drop on frame rate ! I know matrox drivers are bad  I still have > kill_matrox_bug_x booleans lurking around  but I can't believe this is > just it. > > Compiled vertices arrays are the original extension to > glDrawRangeElements(). You just do a Lock() after the arrays setup, call > multiple DrawElements and Unlock() it and it magically caches and > accelerates you vertex xforms, right ?? > > I'm throwing in pure indexed strips, and I'm sure I don't change state > between the locking and unlocking or do any other weird "crap the hardware" > thing. > > Does anyone on this list with old and decrepit 3d boards had such a problem > ? Is it just driver or is there any hidden variable I should know ? As I recall, compiled vertex arrays provide significant speedups even on old and decrepit boards with dubious drivers as long as: 1) You are actually reusing a significant number of locked vertices (i.e. using the compiled vertex array extension allows you to save a significant amount of transform work compared to not using it), and 2) You use the Quake 3 vertex format (spatial vertex, colour and two UV arrays, I _think_) and entry point (glDrawElements for indexed triangle data). This second point really only applies to the more dubious drivers  the point is that some old drivers can only be guaranteed to optimise the driver path for Quake 3. Incidentally, you may get a more helpful response to this question on the OpenGL gamedev list  http://groups.yahoo.com/group/openglgamedevl Neal Tringham (Sick Puppies / Empire Interactive) neal@... neal@... 
From: Tom Forsyth <tomf@mu...>  20010309 11:29:46

No, there's no additional copies. The D3D interface allows you to lock a subregion of a Vertex or Index Buffer with a flag saying "I promise to overwrite everything in this region, and not rely on existing data". Which means the driver can point you at any region of spare memory it wants  the app doesn't care. So the driver can multibuffer as it chooses. Equivalent functionality, just a slightly different mechanism. Tom Forsyth  Muckyfoot bloke. What's he up to now? http://www.muckyfoot.com/startopia/cam.html > Original Message > From: Tom Hubina [mailto:tomh@...] > Sent: 08 March 2001 22:02 > To: gdalgorithmslist@... > Subject: RE: [Algorithms] VIPM, VDPM, ROAM questions > > > At 04:20 AM 3/8/2001, you wrote: > >Swapping in chunks shouldn't be a problem  this comes under the > >completelydynamic "lock buffer and completely overwrite > contents" category, > >which is fine (coz the driver multibuffers behidn your back >  at least it > >does in D3D). > > In OpenGL you make use of the fence and flush operations (NVIDIA only > extensions AFAIK) to break a large chunk of AGP memory into multiple > smaller chunks make sure that a chunk of the AGP memory is > finished being > processed before you write over it. In other words, all > double (triple, > whatever) buffering is under the application's control and there's no > copying of the memory by the driver except to the video card > through DMA. > I'm not certain if the doublebuffering for D3D you describe implies > additional copies on the CPU or not. > > Tom 
From: Rui Ferreira <rui.ferreira@mo...>  20010309 11:15:43

What's the deal with EXT_compiled_vertex_array ??... This thing is supposed to be faster, but on my G200 all I got is a 40 percent drop on frame rate ! I know matrox drivers are bad  I still have kill_matrox_bug_x booleans lurking around  but I can't believe this is just it. Compiled vertices arrays are the original extension to glDrawRangeElements(). You just do a Lock() after the arrays setup, call multiple DrawElements and Unlock() it and it magically caches and accelerates you vertex xforms, right ?? I'm throwing in pure indexed strips, and I'm sure I don't change state between the locking and unlocking or do any other weird "crap the hardware" thing. Does anyone on this list with old and decrepit 3d boards had such a problem ? Is it just driver or is there any hidden variable I should know ? Thanks in advance. Rui 