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

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

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

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

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

_{Jul}

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

_{Dec}

2012 
_{Jan}

_{Feb}
(7) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

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

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

_{Jun}

_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

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

_{Mar}
(2) 
_{Apr}

_{May}
(10) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(3) 
_{Dec}

2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(12) 
_{Nov}

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

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

_{Jun}
(1) 
_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

2017 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(17) 
2
(3) 
3
(4) 
4
(14) 
5
(12) 
6
(16) 
7
(28) 
8
(28) 
9
(12) 
10
(5) 
11
(17) 
12
(16) 
13
(37) 
14
(26) 
15
(10) 
16
(1) 
17
(2) 
18
(11) 
19
(9) 
20
(22) 
21
(14) 
22
(23) 
23
(4) 
24
(2) 
25
(16) 
26
(6) 
27
(3) 
28
(5) 
29
(4) 
30
(2) 
From: Thatcher Ulrich <tu@tu...>  20021130 18:35:36

On Nov 29, 2002 at 11:07 0000, Tom Forsyth wrote: > From: Pierre Terdiman [mailto:p.terdiman@...] > > There was that thing called "clipmaps" in SIG97... IIRC the > > texture was like 40 million * 20 million texels. Nice :) > > Virtual texturing is a much cooler technology than clipmaps > though. It's got finer granularity, is (oddly) easier to implement, > and has a wider application. > > Now we just have to wait for more than one IHV to implement it. It's > not the new lensflare, but it is the new bumpmapping, in that it's > cool tech, everyone agrees it's cool tech, but it'll take ten years > after it was shown to work to get mainstream use :) If you can't wait that long, use quadtree tiling :). There's an example in the chunked LOD demo. It's a coarsegrained method to solve the same problem without using any hardware extensions. Public domain code at the usual place: http://sourceforge.net/projects/tutestbed One interesting advantage of doing it this way is that I could use JPEG compression on the textures, so a 32K x 32K texture that normally would have consumed several GB uncompressed, or 512MB (using conventional hardware compression @ 4 bits/texel), instead took ~150MB. By the same token, it's a good framework for doing some procedural stuff. On the other hand there's the usual time/space tradeoff to deal with decompression.  Thatcher Ulrich http://tulrich.com 
From: Thatcher Ulrich <tu@tu...>  20021130 18:20:52

On Nov 29, 2002 at 10:28 0000, Tom Forsyth wrote: > Four! Four techniques. Ah ah ah ah ah <thunder+lightning> > > (geomipmapping, VIPM, chunks with CPU morph, chunks with GPU morph) > > > Agreed that in real "large world" apps the paging in and out of data > is also a very interesting problem. Though I can't help thinking the > basics of mipmapping (and swizzling, so that a square region is a > single linear access) heightfields should solve half the problem, > and a good asyncloading streamer should solve the other half. Does > it need to be any fancier? No, I don't think so. There are also some tradeoffs with whether and how to compress the data. The point is that with modern hardware, the details of HD and RAM storage & paging are crucially important, since any reasonable LOD algorithm can pretty quickly exhaust the data you can fit in RAM.  Thatcher Ulrich http://tulrich.com 
From: Tom Forsyth <tomf@mu...>  20021129 11:10:07

Virtual texturing is a much cooler technology than clipmaps though. It's got finer granularity, is (oddly) easier to implement, and has a wider application. Now we just have to wait for more than one IHV to implement it. It's not the new lensflare, but it is the new bumpmapping, in that it's cool tech, everyone agrees it's cool tech, but it'll take ten years after it was shown to work to get mainstream use :) Tom Forsyth  Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > Original Message > From: Pierre Terdiman [mailto:p.terdiman@...] > Sent: 29 November 2002 10:54 > To: gdalgorithmslist@... > Subject: Re: [Algorithms] ROAM > > > > Agreed that in real "large world" apps the paging in and > out of data is > also > > a very interesting problem. Though I can't help thinking > the basics of > > mipmapping (and swizzling, so that a square region is a > single linear > > access) heightfields should solve half the problem, and a good > asyncloading > > streamer should solve the other half. Does it need to be > any fancier? > > There was that thing called "clipmaps" in SIG97... IIRC the > texture was like > 40 million * 20 million texels. Nice :) > > Pierre 
From: Conor Stokes <cstokes@tp...>  20021129 11:07:09

Don't forget brute force + bulk culling (maybe with a "get rid of stupid triangles" pre process). If your view distance isn't that long, then it is very much an option. Not only that, it looks great, never pops and you never have to worry about the differences in display in multiplayer (which is a concern which has been voiced on this list in the past, iirc). Conor Stokes > True, but for a real applestoapples comparison it probably needs to be in > the same framework/application. Also, Thatcher's chunklod is yet _another_ > separate case because he's doing vertex morphing as well, which again pushes > CPU time up but also increases qualitypertriangle. > > So that's three methods Josh missed  any more want to pile in while we're > ripping him a new one :) > > > Tom Forsyth  Muckyfoot bloke and Microsoft MVP. > > This email is the product of your deranged imagination, > and does not in any way imply existence of the author. > > > Original Message > > From: Charles Bloom [mailto:cbloom@...] > > Sent: 28 November 2002 16:40 > > To: gdalgorithmslist@... > > Subject: RE: [Algorithms] ROAM > > > > > > > > You can compare to Thatcher's chunkloddemo : > > > > http://sourceforge.net/project/showfiles.php?group_id=31763&re > > lease_id=103643 > > > > At 12:44 PM 11/28/2002 0000, you wrote: > > >I'd still like to see it compared with CPUlight schemes > > like VIPM and even > > >the really simple one of geomipmapping. Both of these put > > the load almost > > >entirely on the video card, which is essential if you want > > to actually have > > >an application, rather than just fly around a terrain. > > > > >  > > Charles Bloom cb@... http://www.cbloom.com > > > > >  > This SF.net email is sponsored by: Get the new Palm Tungsten T > handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgibin/redirect.pl?palm0002en > _______________________________________________ > 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...>  20021129 10:55:43

> Agreed that in real "large world" apps the paging in and out of data is also > a very interesting problem. Though I can't help thinking the basics of > mipmapping (and swizzling, so that a square region is a single linear > access) heightfields should solve half the problem, and a good asyncloading > streamer should solve the other half. Does it need to be any fancier? There was that thing called "clipmaps" in SIG97... IIRC the texture was like 40 million * 20 million texels. Nice :) Pierre 
From: Tom Forsyth <tomf@mu...>  20021129 10:31:25

Four! Four techniques. Ah ah ah ah ah <thunder+lightning> (geomipmapping, VIPM, chunks with CPU morph, chunks with GPU morph) Agreed that in real "large world" apps the paging in and out of data is also a very interesting problem. Though I can't help thinking the basics of mipmapping (and swizzling, so that a square region is a single linear access) heightfields should solve half the problem, and a good asyncloading streamer should solve the other half. Does it need to be any fancier? Tom Forsyth  Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > Original Message > From: Charles Bloom [mailto:cbloom@...] > Sent: 28 November 2002 21:09 > To: gdalgorithmslist@... > Cc: josh@... > Subject: RE: [Algorithms] ROAM > > > > At 04:57 PM 11/28/2002 0000, Tom Forsyth wrote: > >True, but for a real applestoapples comparison it probably > needs to be in > >the same framework/application. Also, Thatcher's chunklod > is yet _another_ > >separate case because he's doing vertex morphing as well, > which again pushes > >CPU time up but also increases qualitypertriangle. > > The morph can be done in a vshader at the cost of more bandwidth. > Anyway, with terrain, the problem is not actually rendering, it's > managing the huge amount of data needed. You could render the entire > earth at apparent 1pixel screenspace error  the speed of the > algorithms is not the problem  it's the fact that the dataset is > collosal. > > Clever paging and streaming are much harder than the rendering bits. > >  > Charles Bloom cb@... http://www.cbloom.com 
From: Charles Bloom <cbloom@cb...>  20021128 21:08:54

At 04:57 PM 11/28/2002 0000, Tom Forsyth wrote: >True, but for a real applestoapples comparison it probably needs to be in >the same framework/application. Also, Thatcher's chunklod is yet _another_ >separate case because he's doing vertex morphing as well, which again pushes >CPU time up but also increases qualitypertriangle. The morph can be done in a vshader at the cost of more bandwidth. Anyway, with terrain, the problem is not actually rendering, it's managing the huge amount of data needed. You could render the entire earth at apparent 1pixel screenspace error  the speed of the algorithms is not the problem  it's the fact that the dataset is collosal. Clever paging and streaming are much harder than the rendering bits.  Charles Bloom cb@... http://www.cbloom.com 
From: Tom Forsyth <tomf@mu...>  20021128 17:01:05

True, but for a real applestoapples comparison it probably needs to be in the same framework/application. Also, Thatcher's chunklod is yet _another_ separate case because he's doing vertex morphing as well, which again pushes CPU time up but also increases qualitypertriangle. So that's three methods Josh missed  any more want to pile in while we're ripping him a new one :) Tom Forsyth  Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > Original Message > From: Charles Bloom [mailto:cbloom@...] > Sent: 28 November 2002 16:40 > To: gdalgorithmslist@... > Subject: RE: [Algorithms] ROAM > > > > You can compare to Thatcher's chunkloddemo : > > http://sourceforge.net/project/showfiles.php?group_id=31763&re > lease_id=103643 > > At 12:44 PM 11/28/2002 0000, you wrote: > >I'd still like to see it compared with CPUlight schemes > like VIPM and even > >the really simple one of geomipmapping. Both of these put > the load almost > >entirely on the video card, which is essential if you want > to actually have > >an application, rather than just fly around a terrain. > > >  > Charles Bloom cb@... http://www.cbloom.com 
From: Charles Bloom <cbloom@cb...>  20021128 16:39:40

You can compare to Thatcher's chunkloddemo : http://sourceforge.net/project/showfiles.php?group_id=31763&release_id=103643 At 12:44 PM 11/28/2002 0000, you wrote: >I'd still like to see it compared with CPUlight schemes like VIPM and even >the really simple one of geomipmapping. Both of these put the load almost >entirely on the video card, which is essential if you want to actually have >an application, rather than just fly around a terrain. >  Charles Bloom cb@... http://www.cbloom.com 
From: Tom Forsyth <tomf@mu...>  20021128 12:47:35

I'd still like to see it compared with CPUlight schemes like VIPM and even the really simple one of geomipmapping. Both of these put the load almost entirely on the video card, which is essential if you want to actually have an application, rather than just fly around a terrain. I'm not saying they're necessarily better (OK, actually I am :), I'd just like to see all the options compared sidebyside. Tom Forsyth  Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > Original Message > From: Josh [mailto:joshbklr@...] > Sent: 28 November 2002 04:56 > To: gdalgorithmslist@... > Cc: josh@... > Subject: Re: [Algorithms] ROAM > > > I'd just like to announce that the code for my research implementation > is now available at http://www.technomagi.com/josh/vis2002/ . > > I'm sure more optimizations are possible (I'm not using tristrips, > for instance). I get about 18M tri/sec on a laptop GeForce 4. > > Someone already sent me some changes to get it working with Linux > (not very difficult), but I haven't had time to verify and incorporate > them yet (I'm very busy trying to finish my thesis these days). > > Josh Levenberg > (please cc: josh@... on replies since I don't > regularly read > this list) > > Mark Duchaineau wrote (July 30th): > * SNIP* > > Simplest case: use an AGP chunk of 256 uniformsize > triangles to draw each > > "ROAM triangle". I've got free source that gets 40M > tri/sec draw rates > > right now with a fractal terrain created on the fly using this. > > > > Adaptive case: use adaptive chunks, precomputed (see Alex > Pomeranz's thesis > > at http://www.cognigraph.com/ROAM_homepage) or cached (see > upcoming IEEE Vis paper > > by Joshua Levenberg). The cache entries are static until replaced. > > Both have research implementations that are not avaiable > yet. Thatcher > > Ulrich's chunk demo is very similar in flavor in terms of > the way chunks > > are built, but the way boundaries are handled are much simpler with > > the ROAMstyle approach (there are no special fixups on > the boundary > > at all). > * SNIP * > > > >  > This SF.net email is sponsored by: Get the new Palm Tungsten T > handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgibin/redirect.pl?palm0002en > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Josh <joshbklr@pa...>  20021128 04:57:48

I'd just like to announce that the code for my research implementation is now available at http://www.technomagi.com/josh/vis2002/ . I'm sure more optimizations are possible (I'm not using tristrips, for instance). I get about 18M tri/sec on a laptop GeForce 4. Someone already sent me some changes to get it working with Linux (not very difficult), but I haven't had time to verify and incorporate them yet (I'm very busy trying to finish my thesis these days). Josh Levenberg (please cc: josh@... on replies since I don't regularly read this list) Mark Duchaineau wrote (July 30th): * SNIP* > Simplest case: use an AGP chunk of 256 uniformsize triangles to draw each > "ROAM triangle". I've got free source that gets 40M tri/sec draw rates > right now with a fractal terrain created on the fly using this. > > Adaptive case: use adaptive chunks, precomputed (see Alex Pomeranz's thesis > at http://www.cognigraph.com/ROAM_homepage) or cached (see upcoming IEEE Vis paper > by Joshua Levenberg). The cache entries are static until replaced. > Both have research implementations that are not avaiable yet. Thatcher > Ulrich's chunk demo is very similar in flavor in terms of the way chunks > are built, but the way boundaries are handled are much simpler with > the ROAMstyle approach (there are no special fixups on the boundary > at all). * SNIP * 
From: Thatcher Ulrich <tu@tu...>  20021127 21:26:00

> > So why can't we just adopt math's convention of using > > predominantly righthanded operations and live saner lives where > > we never have to have a thread like this again? </rant> The least significant byte should have the lowest address! <duck>  Thatcher Ulrich http://tulrich.com 
From: Jon Watte <hplus@mi...>  20021127 18:54:59

> y rotated pi/2 about x should be z. This is the case in both lefthanded and righthanded coordinate systems. Cheers, / h+ 
From: Richard Fabian <algorithms@th...>  20021127 15:18:33

> So why can't we just > adopt math's convention of using predominantly righthanded > operations and > live saner lives where we never have to have a thread like this again? > </rant> hear hear! i x j should be equal to k. y rotated pi/2 about x should be z. 
From: Casey Muratori <gda@fu...>  20021126 22:00:41

> A unit quaternion is no more and no less than than a rotation around an > axis  handedness (relative to the coordinate frame) is explicit, > because the signs of each of the sine and cosine components are included > in the quaternion. OK I think this thread is starting to get out of control, so here we go: Quaternions have no handedness. I'm not sure how the initial concept that a quaternion has a handedness got started, but to quote Marsellus Wallace, "it don't". Just like vectors, there is only a handedness to your _operations_. You wouldn't call your vectors lefthanded or righthanded, would you? But you _would_ (or I certainly hope you would!) call your crossproduct lefthanded or righthanded, correct? The same situation applies to quaternions. When you wrote your quaternion multiply, you used a cross product (or, as is apparently more likely, if you cut and pasted somebody else's code, THEY used a cross product). If your/their cross product is righthanded, then your/their quaternions are going to multiply righthanded. If it's left, they'll multiply left. It's really that simple. Or, if you prefer, "it's really that complicated". And so forth. Now as for this this: > I'd love to see Ron's (or some other mathematician's) explanation of how > handedness is incorporated into this representation. I have my own > explanation, but I'm not a mathematician myself! Thankfully, the explanation is simple and doesn't require a mathematician. As everyone has seen many times, quaternion operations are all defined by setting up multiplication rules for the imaginary components i, j, and k. Well, if you had been ignoring those derivations previously, now's your chance to stop ignoring them. Go back and look, and you'll see that the "handedness" is baked into those initial definitions. If you change the initial multiplication rules to be lefthanded, then all the operations will come out lefthanded. Right handed systems have: i^2 = j^2 = k^2 = ijk = 1 i = jk = kj j = ki = ik k = ij = ji and left handed systems have: i^2 = j^2 = k^2 = ijk = 1 i = jk = kj j = ki = ik k = ij = ji And that's all there is to it. k is the "zaxis". If you want to invert your z axis, you just define the fact that i (xaxis) and j (yaxis) multiply together to get negative k. Obviously, you don't have to restrict yourself to making k negative, you could've negated something else instead. For some reason, Shoemake never presented the lefthanded version (as far as I'm aware), so I guess nobody ever thought about it? Not sure. Anyhow, go ahead and do the quaternion multiplication (w + xi + yj + zk) (d + ai + bj + ck) with each rule set and see what you get. You'll find that you get a righthanded cross product when you use the righthanded rules, and a left handed cross product when you use the lefthanded rules, and otherwise the two will be identical. <rant> Now I would simply like to say hey, if I had to hazard a guess as to why everyone thinks quaternions are inherently righthanded, and the lefthanded definition doesn't ever show up, I'd say it's because that's the way most math is written by default: righthanded. So when you go and read something in a math book, it's probably righthanded. So why do some people still insist on using these lefthanded coordinate frames? For the love of god, people, stop using lefthanded coordinate systems so we can put an end to all this useless conversion confusion. There's no advantage to one or the other  they're the same in every way. So why can't we just adopt math's convention of using predominantly righthanded operations and live saner lives where we never have to have a thread like this again? </rant>  Casey 
From: Tyson Jensen <twjensen@sa...>  20021126 17:44:19

Actually, technically a quaternion multiply (unit or otherwise) represents a screw transform. The typical way quaternions are applied, ie qvq* where q is a unit quaternion, insures that the translational element is removed leaving a pure rotation. Since we game programmers haven't really gotten into screw theory, all of our quaternions represent rotations. As with many mathematical constructions, our plans for how we are going to use them make a big difference in what they represent. For example, a matrix can do all kinds of things besides rotate and translate but the only thing we typically do outside of those is a perspective transform. Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Nick Pelling Sent: Tuesday, November 26, 2002 2:52 AM To: 'gdalgorithmslist@...' Subject: RE: [Algorithms] Quaternion handedness A unit quaternion is no more and no less than than a rotation around an axis  handedness (relative to the coordinate frame) is explicit, because the signs of each of the sine and cosine components are included in the quaternion. Also: in normal rotation matrices, the resulting matrix is composited out of a sequences of rotation matrices, and is both ordersensitive and handednesssensitive. However, for a rotation angle 3tuple, the handedness is implicit, as are its axis association and order. So: when linking between rotation angle 3tuples and quaternions, you need to get all the implicit stuff right, or you'll get a load of nonsense. Unsurprisingly, "This Often Happens". :/ I could put a load of quaternion maths in here to demonstrate this basic point, but it really shouldn't be necessary. :) Cheers, .....Nick Pelling..... Original Message From: Peter Lipson [mailto:peter@...] Sent: 25 November 2002 18:16 To: gdalgorithmslist@... Subject: RE: [Algorithms] Quaternion handedness This whole discussion seems to be lacking any answer based on the theoretical basis for using quaternions to hold the rotations. I know quaternions used for rotation are constructed by using the axis and sin/cos of the angle, but I have a less firm grasp of the theoretical underpinnings that guarantee this 'works'. I'd love to see Ron's (or some other mathematician's) explanation of how handedness is incorporated into this representation. I have my own explanation, but I'm not a mathematician myself!  This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgibin/redirect.pl?palm0002en _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Guillaume Provost <Guillaume@ps...>  20021126 14:37:48

Ron, This is actually all the help I needed. I'm familiar with Jacobian matrices and I think I can take it from here. Thanks alot! Guillaume. Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Ron Levine Sent: Tuesday, November 26, 2002 3:42 AM To: gdalgorithmslist@... Subject: Re: [Algorithms] Normal space transforms for nonlinear deformatio ns Guillaume Provost wrote: > > Thought I would have a neat problem for you math freaks. > We have >been deforming meshes in hardware using single axis aligned quadratic >7point blend >deforms. (You basically take one of the axis and you transform it through a >quadratic). > >I have until now approximated the normal transforms using a standard >rigid body matrix that best averaged this transform, but I'm now facing some >highly >glossy surfaces, and the defects in the shading are showing up. Do any of >you have source >materials/ideas on how I could better approximate the correct normal >transforms in such a case? > >The basic math : > >The Power vector: [x y z 1 xx xy xz] // Quadratic deform along the x axis. > >// where rx ry rz tx is your standard rigid deform (these are vectors) >// and rxx rxy rxz are the quadratic blend factors along the x axis >7 point blend: [rx ry rz tx rxx rxy rxz] > >transformed point = Power vector * (7 Point blend) > >// Currently : >normal = Inverse_Transpose(rx ry rz tx) > > Guillaume. > OK I haven't had the time to figure out your nonlinear mapping specification, except to see that it is an analytic nonlinear, nonaffine (quadratic?) mapping of R^3 to itself. But I will try to steer you in the direction of the theory that will help you, which generally comes under the rubrique "Advanced Calculus" (taught in the second year in US universities). The normal you want to the image (transformed) surface is (or is supposed to represent) the normal to its tangent plane. So you have to figure out what your mapping does to the tangent plane at any point of the source surface (however that may be defined). The tangent plane at any point is spanned by the (vector ) partial derivatives of the vector function of a parametric representation of the surface. So it should not be a surprise that the correct mapping of the tangent plane must involve the the partial derivatives of the mapping you have defined. To make a long story short, the transformation matrix you need is called 'the Jacobian matrix' of your defined nonlinear mapping. IF we symbolise your mapping as vector function written out in components (x',y',z') = (x'(x,y,z), y'(x,y,z), (z'(x,y,z)) where (x,y,z) is a general point of the domain of your mapping and (x',y',z') is its image under the mapping, (showing that each of (x',y',z') is a function of (x, y, z)), THEN the Jacobian of the mapping is the 3x3 matrix of all possible partial derivatives of each of (x',y',z') with respect to each of (x, y, z). That is the neatest way I can think of to define the Jacobian in ASCII, (and my distaste for casting math notation into ASCII is one reason I'm not going into more detail) The Jacobian of a linear mapping is just its matrix, and so is constant. The Jacobian of an affine mapping is just the matrix of its linear part. If one understood exactly the definition of your quadratic mapping, computing its Jacobian is a simple exercise in differential calculus of several variables. It will not be constant, but a function of (x,y,z) Now you cannot just apply the Jacobian to the source normal vector to get the image normal vector, because the Jacobian is not likely to be orthogonal and so it will not necessarily preserve cross products. But it will map tangent plane to tangent plane. So, in principle, for any source normal vector at a particular point, you have to get a couple of independent vectors orthogonal to it, apply the Jacobian to them, take the cross product of the result, and normalize. That's all the time I have, maybe someone else will pick up the ball and fill in holes I'm leaving. At least, I hope that's push in a direction you might find rewarding.  This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgibin/redirect.pl?palm0002en _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Ron Levine <ron@do...>  20021126 12:41:16

Guillaume Provost wrote: > > Thought I would have a neat problem for you math freaks. > We have >been deforming meshes in hardware using single axis aligned quadratic >7point blend >deforms. (You basically take one of the axis and you transform it through a >quadratic). > >I have until now approximated the normal transforms using a standard >rigid body matrix that best averaged this transform, but I'm now facing some >highly >glossy surfaces, and the defects in the shading are showing up. Do any of >you have source >materials/ideas on how I could better approximate the correct normal >transforms in such a case? > >The basic math : > >The Power vector: [x y z 1 xx xy xz] // Quadratic deform along the x axis. > >// where rx ry rz tx is your standard rigid deform (these are vectors) >// and rxx rxy rxz are the quadratic blend factors along the x axis >7 point blend: [rx ry rz tx rxx rxy rxz] > >transformed point = Power vector * (7 Point blend) > >// Currently : >normal = Inverse_Transpose(rx ry rz tx) > > Guillaume. > OK I haven't had the time to figure out your nonlinear mapping specification, except to see that it is an analytic nonlinear, nonaffine (quadratic?) mapping of R^3 to itself. But I will try to steer you in the direction of the theory that will help you, which generally comes under the rubrique "Advanced Calculus" (taught in the second year in US universities). The normal you want to the image (transformed) surface is (or is supposed to represent) the normal to its tangent plane. So you have to figure out what your mapping does to the tangent plane at any point of the source surface (however that may be defined). The tangent plane at any point is spanned by the (vector ) partial derivatives of the vector function of a parametric representation of the surface. So it should not be a surprise that the correct mapping of the tangent plane must involve the the partial derivatives of the mapping you have defined. To make a long story short, the transformation matrix you need is called 'the Jacobian matrix' of your defined nonlinear mapping. IF we symbolise your mapping as vector function written out in components (x',y',z') = (x'(x,y,z), y'(x,y,z), (z'(x,y,z)) where (x,y,z) is a general point of the domain of your mapping and (x',y',z') is its image under the mapping, (showing that each of (x',y',z') is a function of (x, y, z)), THEN the Jacobian of the mapping is the 3x3 matrix of all possible partial derivatives of each of (x',y',z') with respect to each of (x, y, z). That is the neatest way I can think of to define the Jacobian in ASCII, (and my distaste for casting math notation into ASCII is one reason I'm not going into more detail) The Jacobian of a linear mapping is just its matrix, and so is constant. The Jacobian of an affine mapping is just the matrix of its linear part. If one understood exactly the definition of your quadratic mapping, computing its Jacobian is a simple exercise in differential calculus of several variables. It will not be constant, but a function of (x,y,z) Now you cannot just apply the Jacobian to the source normal vector to get the image normal vector, because the Jacobian is not likely to be orthogonal and so it will not necessarily preserve cross products. But it will map tangent plane to tangent plane. So, in principle, for any source normal vector at a particular point, you have to get a couple of independent vectors orthogonal to it, apply the Jacobian to them, take the cross product of the result, and normalize. That's all the time I have, maybe someone else will pick up the ball and fill in holes I'm leaving. At least, I hope that's push in a direction you might find rewarding. 
From: Atman Binstock <ajb@pa...>  20021126 12:36:22

Adrian Perez wrote: >One of the shrek programmers posted a fantastically awesome fix for this > just use stippled alpha with a checkerboard stipple pattern. >It's only reasonable on televisions (the stipple pattern gets lost in >the noise and you can't see it) Charles Bloom wrote: >though if you have a crappy TV (like many consumers do) the samples will >bleed together pretty well. This is all xbox specific... It's actually the horizontal and (adaptive) vertical filtering performed by the video chip does that blends the samples, and it works pretty well. The only really visible artifacts are a slight loss in apparent resolution (noticeable on edges) and a bit more interlace flickering (as Charles noted). The real problem is on progressive component out (we used 480p)  the video chip does no filtering (which IMO is a mistake) and the stipple patter is clearly visible on a good TV. Atman Binstock ajb@... 
From: Nick Pelling <NPelling@cl...>  20021126 10:51:52

A unit quaternion is no more and no less than than a rotation around an axis  handedness (relative to the coordinate frame) is explicit, because the signs of each of the sine and cosine components are included in the quaternion. Also: in normal rotation matrices, the resulting matrix is composited out of a sequences of rotation matrices, and is both ordersensitive and handednesssensitive. However, for a rotation angle 3tuple, the handedness is implicit, as are its axis association and order. So: when linking between rotation angle 3tuples and quaternions, you need to get all the implicit stuff right, or you'll get a load of nonsense. Unsurprisingly, "This Often Happens". :/ I could put a load of quaternion maths in here to demonstrate this basic point, but it really shouldn't be necessary. :) Cheers, .....Nick Pelling..... Original Message From: Peter Lipson [mailto:peter@...] Sent: 25 November 2002 18:16 To: gdalgorithmslist@... Subject: RE: [Algorithms] Quaternion handedness This whole discussion seems to be lacking any answer based on the theoretical basis for using quaternions to hold the rotations. I know quaternions used for rotation are constructed by using the axis and sin/cos of the angle, but I have a less firm grasp of the theoretical underpinnings that guarantee this 'works'. I'd love to see Ron's (or some other mathematician's) explanation of how handedness is incorporated into this representation. I have my own explanation, but I'm not a mathematician myself! 
From: Mark Duchaineau <duchaine@ll...>  20021125 19:20:34

Hi John, Great question. Lot's of pointers here. I have some old code showing ROAM on surfaces with subdivisionsurface connectivity (think of a subdivision surface with displacements). This should handle things like arches, cliffs, simple caves, etc. For really detailed topology, the holes, handles, components etc would need to be simplified as well, and ROAM (nor progressive meshes) can deal with that as is. Methods that allow topology simplification are based on vertex clustering, or use implicit 3D density or signeddistance fields with surface contouring. A couple of pointers would be: 1) Luebke's original siggraph paper on viewdependent display with vertex clustering hierarchies http://www.cs.virginia.edu/~luebke  Luebke's current homepage http://www.cs.virginia.edu/~luebke/publications/sig97.html  main paper 2) my old demo code showing the data structures etc for ROAM with subdivisionsurface connectivity http://www.cognigraph.com/ROAM_homepage  see the introductory source code and notes (Linux) Note that the image on the top, the hollow tet thing, was generated with this code. More recent intro code shows a complete splitmerge ROAM but not with subdivision surfaces: http://www.cognigraph.com/ROAM_homepage/Roamsteps  Win32 and Linux There is also a source/demo of chunkbased ROAM: http://www.cognigraph.com/ROAM_homepage/LibGenROAM20020716.tar.gz  Linux 3) new 3D ROAM paper (contouring a density field using a 3D ROAM mesh) http://graphics.cs.ucdavis.edu/~gregorsk/  see IEEE Vis 2002 paper There are upsides and downsides to all these methods. One thing that is a little different and more in the spirit of recent work discussed on this list is chunked ROAM. The idea is to do ROAM on triangle bintrees, but draw each triangle as a patch of triangles from AGP memory. More on continuity of the chunk edges later. The important idea here is that you can put arbitrary meshes inside each chunk, including interesting topology like an arch, hole, separate components, etc. The main trick is that all topology changes must occur on the interior of a patch diamond during split/merge. Since diamonds alternate where there interiors are every other level of detail, you can put topology changes most anywhere *except* at the chunk corner vertices that already exist. In other words, if topology must change right on a vertex in the base mesh, then put the final (fine res) topology there to start with in that neighborhood. You can always move your base mesh a little (just slide it around a bit) to avoid this altogether (Simplification of Simplicity, anyone?). You keep continuity by ensuring that the base edge or each triangle patch has the same edges as each of its two potential neighbors (the base neighbor can be from the same LOD or one coarser level). You can make this constraint hold through a simple scheme such as Josh Levenberg uses, by picking some uniform refinement for the edge (each patch edge becomes four, eight or sixteen small edges). There are fancier schemes to allow adaptive patch edge refinements, such as Alex Pomeranz's work. The papers on these ideas are here: http://www.technomagi.com/josh/  see "Fast ViewDependent LevelofDetail Rendering Using Cached Geometry http://www.cognigraph.com/ROAM_homepage  see "ROAM Using Surface Triangle Clusters (RUSTiC)" So this doesn't answer in detail the very interesting question at the heart of this: can you modify the split/merge operations to allow topology changes? I heven't worked out the details on doing this for finegrained split/merges, only for chunks. It shouldn't be too difficult to come up with a minial set of changes. Something like: 1) normal split/merge of a diamond (two triangles become four with one new vertex). 2) a handle gets added (two verts instead of one) 3) a component gets added (usual split but a fourpoint floating tet gets added as well) Cheers, Mark John Cannon wrote: > > I'm considering using chunked, crackfree ROAM to adaptively simplify only > the distant views of a massive dynamic terrain represented as a quadbased > subdivision surface. > > Can you use ROAMbintree simplifications for arbitrary topology terrains (or > at least nonheightfield) ? > Does it require vertex regularity and hence only suitable for semiregular > meshes (I imagine it can still work around extraordinary vertices) ? > ROAM seems suited to quadbased subdivision (eg, CatmullClark) due to > rightangle triangle requirement, but can it work for trianglebased > subdivision (eg, Loop) ? > Topology simplication would be nice (eg, small archway in distant view can > be flattened out to pave the way for better simplification), but I think > edgecollapse (one that doesn't retain 2manifold) or something other than > ROAM is required for that ? > > I should probably work these out for myself but any thoughts/comments are > appreciated. > > John. 
From: Shawn Hargreaves <shargreaves@cl...>  20021125 18:29:55

Charles Bloom writes: > IMHO you can see the water in Shrek (Xbox) flickering in > a weird way. Which could arguably be part of the water effect :) The huge problem with relying on a TV to smooth this out for you is that it depends so much on the type of TV. It might look great when you test through an RF lead, but what about people using a SCART adaptor, or (shudder) HDTV? I don't much like the idea of using rendering techniques that look worse the better a TV you display them on!  Shawn Hargreaves Climax Brighton 
From: Guillaume Provost <Guillaume@ps...>  20021125 18:26:20

Hey! Thought I would have a neat problem for you math freaks. We have been deforming meshes in hardware using single axis aligned quadratic 7point blend deforms. (You basically take one of the axis and you transform it through a quadratic). I have until now approximated the normal transforms using a standard rigid body matrix that best averaged this transform, but I'm now facing some highly glossy surfaces, and the defects in the shading are showing up. Do any of you have source materials/ideas on how I could better approximate the correct normal transforms in such a case? The basic math : The Power vector: [x y z 1 xx xy xz] // Quadratic deform along the x axis. // where rx ry rz tx is your standard rigid deform (these are vectors) // and rxx rxy rxz are the quadratic blend factors along the x axis 7 point blend: [rx ry rz tx rxx rxy rxz] transformed point = Power vector * (7 Point blend) // Currently : normal = Inverse_Transpose(rx ry rz tx) Guillaume. 
From: Gareth Lewin <GLewin@cl...>  20021125 18:18:28

Beware though, a lot of them have a ring of But Maya Can Do It +3 > Original Message > From: Tom Forsyth [mailto:tomf@...] > Sent: 25 November 2002 17:27 > To: gdalgorithmslist@... > Subject: RE: [Algorithms] Accuracy problems solved > > > Do you want to borrow my Heavy Stick of Artist Enlightenment +3? > > > Tom Forsyth  Muckyfoot bloke and Microsoft MVP. > > This email is the product of your deranged imagination, > and does not in any way imply existence of the author. > > > Original Message > > From: Tyson Jensen [mailto:twjensen@...] > > Sent: 25 November 2002 17:02 > > To: gdalgorithmslist@... > > Subject: RE: [Algorithms] Accuracy problems solved > > > > > > And another programmer discovers why we generally only give artists > > triangles. :) > > > > Original Message > > From: gdalgorithmslistadmin@... > > [mailto:gdalgorithmslistadmin@...] On Behalf Of > > Brinck, Andreas > > Sent: Monday, November 25, 2002 1:33 AM > > To: 'gdalgorithmslist@...' > > Subject: RE: [Algorithms] Accuracy problems solved > > > > Doh! I found the problem with my point classification. The > > artists have > > been > > allowed to construct the cull volumes with quads as well as > triangles > > and it > > turns out that a _lot_ of the quads were non planar. > > > > I don't know why I didn't bother to check this before I started > > generating > > the tree, temporary insanity perhaps. > > > > /A.B. > > > > >  > This SF.net email is sponsored by: Get the new Palm Tungsten T > handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgibin/redirect.pl?palm0002en > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Charles Bloom <cbloom@cb...>  20021125 18:13:56

Yeah, stipple alpha works great when you're doing AA. If you are supersampling with 2x2 blocks, you can do 0%,25%,50%,75% alpha perfectly. Without AA, it becomes kinda questionable. It works kinda ok at really high res (1600x1200) on a PC, and it works kinda ok on a TV. On a TV, it works really well if you can reliably hit 60 fps, and you offset your pattern from one frame to the next, because the two interlaced fields kind of blur together. If you're running at 30 fps, it doesn't work nearly as well, though if you have a crappy TV (like many consumers do) the samples will bleed together pretty well. IMHO you can see the water in Shrek (Xbox) flickering in a weird way. This technique gets really bad if/when your frame rate takes a hit. This method also works poorly for when alpha objects go over other alpha objects. In fact, where the stipple patterns line up you can get some really strange anomalies, because one of the objects typically stops contributing, or the background stops contributing, etc..  Charles Bloom cb@... http://www.cbloom.com 