Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
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: Peter Lipson <peter@to...>  20021125 18:13:25

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! Peter Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Lars Wilke Sent: Monday, November 25, 2002 9:21 AM To: 'Joe Ante'; gdalgorithmslist@... Subject: RE: [Algorithms] Quaternion handedness This works fine for us, since we do allot of file conversions  often between left and righthand coordinate systems. On an intuitive level it makes perfect sense. <....> So, I'm not sure where the problem lies, I think I have to reread your original post. Lars 
From: Tom Forsyth <tomf@mu...>  20021125 17:29:43

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. 
From: Lars Wilke <lars@ch...>  20021125 17:21:39

This works fine for us, since we do allot of file conversions  often between left and righthand coordinate systems. On an intuitive level it makes perfect sense. The difference between one system and the other is that the direction of one of the cardinal axes is reversed (in the case I gave the Z axis). Also, the direction in which positive angles are measured is also reversed which in quaternions is represented by w ( cos[angle/2] ). So, I'm not sure where the problem lies, I think I have to reread your original post. Lars > Original Message > From: Joe Ante [mailto:joeante@...] > Sent: Saturday, November 23, 2002 6:18 PM > To: gdalgorithmslist@...; Lars Wilke > Subject: Re: [Algorithms] Quaternion handedness > > > Hi Lars, > > > To convert a quaternion back and forth between LH & RH > systems perform > > the following operation, assuming the (somewhat) standard > +Z into (LH) > > or out of (RH) the screen. > > > > q.w *= 1.0; q.z *= 1.0; > I tried this and it seems not to work. > I also setup a test which also failed. > I created a rotation matrix. Generated a quaternion from it. > Scaled the matrix by (1, 1, 1). And then did q.w *= 1.0; > q.z*= 1.0; on the quaternion. Then I multiplied by some > random vector. And the rotation matrix and quaternion > produced different results. > > Are you really sure that this works? > Do you have some special code in your quaternion class? > > Joe Ante > > 
From: Tyson Jensen <twjensen@sa...>  20021125 17:18:43

Well, q.w *= 1; q.z *= 1; is pretty random. It's assuming that the z axis is the axis which is inverted. A good assumption, if you have to make an assumption, because the "canonical" lh system is z with respect to the "canonical" rh system. But in a world where coordinate madness has crept in, all assumptions must be cast aside. The only hope is to derive the actual math you need. For example: Take a vector that is <0,0,+1> and rotate it with a quaternion constructed to rotate about the yaxis by 45 degrees such that the result is <~.707,0,~.707>. If the original input vector was in a righthanded system, we see that the result is rotating us about the y vector as we expect. If the original vector was in a lefthanded system (z inverted), then the *same* quaternion math, generating the *same* result, rotates us about our lefthanded yaxis in a left handed way! Thus, *no* change to the quaternion is needed in this specific case! That's why the formula given inverts *two* numbers of the quaternion. It is because sometimes, you want the same exact result as with the unmodified quaternion. But let us say that your coordinate systems differ by y, or x. Then you'll have to change the axis that is different, or do a rotate after you do your number invert. Doing the switch in matrix land is certainly more expensive, but it is also much easier to be correct, because you just derive the exact matrix you need, and multiply it with the matrix you want to convert (being careful of matrix multiply order). If you do this on paper, you can then go through everything symbolically to see what happens when you change the original matrix to a quaternion, and then see what happens when you change the converted matrix to a quaternion. That should then reduce to the formula you need. The point of doing this is to completely convince *yourself* of the correctness of the math so you can move on to see what might be wrong with the code or with the data. Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Jonas Meyer Sent: Monday, November 25, 2002 4:43 AM To: gdalgorithmslist@... Subject: Re: [Algorithms] Quaternion handedness  Original Message  From: "Joe Ante" <joeante@...> To: <gdalgorithmslist@...>; "Lars Wilke" <lars@...> Sent: Sunday, November 24, 2002 3:18 AM Subject: Re: [Algorithms] Quaternion handedness  Hi Lars,   > To convert a quaternion back and forth between LH & RH systems perform  > the following operation, assuming the (somewhat) standard +Z into (LH)  > or out of (RH) the screen.  >  > q.w *= 1.0; q.z *= 1.0;  I tried this and it seems not to work. Well, if youre shifting from coordinatesystem, you just need to change the axis of rotation, not the amount/direction of the rotation. just doing q.z *= 1.0 should flip the z axis, and thereby express the same axis of rotation in the other coordinatesystem(it should even work for both left>right & right>left). The other parts of the quaternion is unchanged. Jonas  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: Tyson Jensen <twjensen@sa...>  20021125 17:03:24

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: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: Shawn Hargreaves <shargreaves@cl...>  20021125 16:52:15

Thatcher Ulrich writes: > Interesting. I suppose you could make many levels of stippled alpha > by using varying alpha values in the texture, setting vertex alpha, > and doing alphatest? Could even interpolate alpha across tris. Multiple stipple patterns can create some weird interference artifacts where they overlap, but that would be very nice if you could work out the right alpha data to get a smooth transition between levels! To see alpha stippling in action, btw, just run something that tries to use alpha blending on a Matrox G100. Not at all pretty :) It works ok if you are running in high resolutions, though, especially if you are outputting to a TV or doing an AA downsample after the stage where the stippling takes place.  Shawn Hargreaves Climax Brighton 
From: Thatcher Ulrich <tu@tu...>  20021125 16:10:41

On Nov 25, 2002 at 12:54 0000, Shawn Hargreaves wrote: > Ignacio Casta?o writes: > > Actually, I don't know if you would be able to multipass and to cast > > shadows using this method. How is the stipple pattern selected? Has > > somebody tried that? > > Any kind of multipass or shadow rendering algorithm will work > perfectly with stippled alpha, because individual pixels are always > either fully opaque or not rendered at all, so there is no hardware > distinction between the ones that are rendered and a normal 100% > opaque surface. > > There are several possible ways you could implement the stipple pattern: > >  As a multitexture layer with alternate zero and solid alpha, mapped > to be linear in screen space, using alpha test to reject alternate > pixels. This is the most flexible technique, but does use up a texture > layer. Interesting. I suppose you could make many levels of stippled alpha by using varying alpha values in the texture, setting vertex alpha, and doing alphatest? Could even interpolate alpha across tris. Hm...  Thatcher Ulrich http://tulrich.com 
From: Shawn Hargreaves <shargreaves@cl...>  20021125 12:55:22

Ignacio Casta=F1o writes: > Actually, I don't know if you would be able to multipass and to cast=20 > shadows using this method. How is the stipple pattern selected? Has=20 > somebody tried that? Any kind of multipass or shadow rendering algorithm will work=20 perfectly with stippled alpha, because individual pixels are always=20 either fully opaque or not rendered at all, so there is no hardware=20 distinction between the ones that are rendered and a normal 100%=20 opaque surface. There are several possible ways you could implement the stipple = pattern:  As a multitexture layer with alternate zero and solid alpha, mapped to be linear in screen space, using alpha test to reject alternate=20 pixels. This is the most flexible technique, but does use up a texture layer.  Write the stipple into the stencil or zbuffer before drawing your=20 alpha polys. Very cheap once you've set up the depth buffer, and can=20 work on any hardware, but you have to repeat the expensive setup=20 process for every type of stipple that you want to use.  On hardware that supports it, if you are multisampling you can turn off framebuffer writes for each individual sample. This the cheapest way to do it where available (and you get really nice translucency out the end because the FSAA will end up merging everything back down into a true alpha blended result, so the stipple pattern never shows up on your monitor), but you have less control over the stippling and hence fewer possible levels of alpha than with the other techniques. =20 Shawn Hargreaves Climax Brighton 
From: Jonas Meyer <meyer@di...>  20021125 12:43:57

 Original Message  From: "Joe Ante" <joeante@...> To: <gdalgorithmslist@...>; "Lars Wilke" <lars@...> Sent: Sunday, November 24, 2002 3:18 AM Subject: Re: [Algorithms] Quaternion handedness  Hi Lars,   > To convert a quaternion back and forth between LH & RH systems perform  > the following operation, assuming the (somewhat) standard +Z into (LH)  > or out of (RH) the screen.  >  > q.w *= 1.0; q.z *= 1.0;  I tried this and it seems not to work. Well, if youre shifting from coordinatesystem, you just need to change the axis of rotation, not the amount/direction of the rotation. just doing q.z *= 1.0 should flip the z axis, and thereby express the same axis of rotation in the other coordinatesystem(it should even work for both left>right & right>left). The other parts of the quaternion is unchanged. Jonas 
From: Brinck, Andreas <Andreas.Brinck@di...>  20021125 09:33:28

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. 
From: Rowan Wyborn <rowan@ir...>  20021125 00:24:55

I haven't tested this out yet, but it is actually possible to add light contributions for transparent surfaces. If your're using yer standard srcalpa/invsrcalpha blending, then the blend equation looks like this: final =3D a*Src + (1a)*Dest now, just say Src is made up of multiple light contributions, so Src =3D = Src1 + Src2 + Src3. If you substitue this into the alpha equation, and rearang= e a bit, you get: final =3D a*Src1 + (1a)*Dest + a*Src2 + a*Src3 which is expresible over multiple passes: pass1 =3D srcalpha (Src1)  invsrcalpha (Dest) pass2 =3D srcalpha (Src2)  one (Dest) pass3 =3D srcalpha (Src3)  one (Dest) So its possible to add in the light contributions over multiple passes fo= r transparent objects... the problem is you have to redraw shadow volumes f= or each alpha objects individual set of light passes (unless you can guarant= ee that no alpha objects are overlapping in screen space). Hmmm i guess one possibility is to organise yer alpha objects into non overlapping sets, ie sort alpha objects back to front for each alpha object if object does not overlap (in screen space) any object in current set add object to current set else create new set add object to new set current set =3D new set You would then only have to redraw shadow volumes per set, rather than pe= r object. This is still fairly expensive thou... what i'm really wondering = is whether its possible to somehow shadow alpha objects during the main ligh= t passes over the non alpha'd scene. > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...]On Behalf Of > Ignacio Casta=F1o > Sent: Saturday, 23 November 2002 5:06 AM > To: gdalgorithmslist@... > Subject: Re: [Algorithms] casting shadows on semitransparent objects > > > Rowan Wyborn wrote: > > anyways, am i missing something really obvious here? is it really tha= t > hard > > to handle semitransparent objects in a full scene shadowing algorith= m? > i'd > > really aprreciate hearing how other people are handling this ;) > > Have you figured out how are you going to light transparent surfaces? Y= ou > cannot just add light contributions as if the surface were > opaque. The only > solution i found was to apply the lighting in a single pass, so I > just used > vertex lighting for them. My transparent surfaces were > transparent enough to > look ok without shadowing. Other solution is to have 'fluorescent' > transparent surfaces. That is, surfaces that emit light, so don't recie= ve > shadows. > > Hope that helps, > > > Ignacio Casta=F1o > castanyo@... > > > _______________________________________________________________ > Yahoo! Messenger > Nueva versi=F3n: Webcam, voz, y mucho m=E1s =A1Gratis! > Desc=E1rgalo ya desde http://messenger.yahoo.es > > >  > 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=3D6188 
From: Tom Hubina <tomh@3d...>  20021124 19:42:13

At 11:54 AM 11/22/2002, you 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. When you think about it, the basis of ROAM is providing a hierarchical variance table. This variance table describes the objectspace error at each split level for the mesh so you can scale the errors by distance and determine pretty quickly what the split level is for a mesh. The other part of it is the split/merge queue approach for maintaining a mesh. All of the height field stuff is just showing how that can be applied to a certain type of geometry, but it can definitely be used for other types. The paper (and most of the implementations I've seen so far) use height fields because the rigid structure makes it's possible to use much more simplistic code for determining which edge will be split (its always the hypotenuse of a right triangle) and what the connections are to other triangles (its implied in height fields) so you can insure a mesh without gaps (split propagation). It's also a convenient data source because anyone can get or make reasonable height field data ;) That said, it's definitely possible to use ROAM style hierarchical variance tables for meshes other than height fields. It should just be a matter of precomputing the variance map from the bottom up as well as being able to determine the edge connectivity so when a split occurs at runtime you know which triangles are affected. For feature reducing truly arbitrary meshes a solution like progressive meshes is probably going to perform better. You could probably get ROAM to work with something like this, but it just seems that the other methods are better documented and "solved" solutions. I wouldn't anticipate a ROAM solution working better or faster, so why bother? ;) ROAM becomes much more interesting for meshes with implied triangulation like height fields, Bezier quads/tris, subdivision surfaces, and even spheres (for planets) because the way the splits happen can be set up to be the same for every mesh so it's really only the way you compute vertex locations that changes. I hope that makes sense ... heh. I guess what I'm trying to say is that topologically they're the same, and they can be split in a consistent manner (the connectivity between triangles is implied in the structure) so the transition from ROAM examples should be pretty straightforward. ROAM uses right triangles in the example, but I don't see that as a requirement as much as an optimization that allows the splits to line up exactly with the height field data samples. With something like a subdivision surface, that optimization doesn't buy you anything. There's probably a better way to explain that, but the point is that you don't need right triangles ;) The benefit of using ROAM over just doing the standard triangulations is that you push a lot of the split process off into a preprocess, and splitdetermination becomes a much less CPUintensive operation (at the expense of storing the variance table). If you do things like split 16 or more triangles at each split level instead of just a single triangle, the variance tables become much smaller, and you end up getting a lot better performance out of current hardware (you're touching the vertex buffers a lot less frequently and using the CPU a lot less). There's a few other things that are important to mention. You describe your terrain as being dynamic. Which means areas that deformed areas will need to have their variance recomputed at runtime after being deformed. This is certainly possible, and can even be done in a "lazy" fashion as long as the deformations aren't too frequent. How often do you plan on doing things like this? You also mention "massive" ... I suspect that means you're going to want to page data from disk. This is certainly possible and not all that difficult, but that also means you'll have to write out deformed data to disk when it gets paged out. Or you could just drop the deformed data, but that has ugly implications for things where a deformation affects multiple areas, and only some of it gets paged out (and lost). Anyway .. just some ugliness to consider ;) OK .. this got longer than I thought it would ... best stop now ;) Tom 
From: Joe Ante <joeante@li...>  20021124 02:18:30

Hi Lars, > To convert a quaternion back and forth between LH & RH systems perform > the following operation, assuming the (somewhat) standard +Z into (LH) > or out of (RH) the screen. > > q.w *= 1.0; q.z *= 1.0; I tried this and it seems not to work. I also setup a test which also failed. I created a rotation matrix. Generated a quaternion from it. Scaled the matrix by (1, 1, 1). And then did q.w *= 1.0; q.z*= 1.0; on the quaternion. Then I multiplied by some random vector. And the rotation matrix and quaternion produced different results. Are you really sure that this works? Do you have some special code in your quaternion class? Joe Ante 
From: <castanyo@ya...>  20021123 14:20:06

Ignacio_Castaño wrote: > or course, on the PC side you can also use WGL_ARB_multisample with > GL_SAMPLE_ALPHA_TO_COVERAGE_ARB for order independant transparency. just to clear things out, let me quote PixelsFormatsAndMultisample.pdf from the nvidia dev site: "One of the simpler transparency techniques is known as screendoor transparency. Screendoor transparency uses a bit mask to cause certain pixels not to be rasterized. The percentage of bits in the bitmask which are set to 1 is equivalent to the transparency of the object. In OpenGL, screendoor transparency is usually implemented using polygon stippling." Actually, I don't know if you would be able to multipass and to cast shadows using this method. How is the stipple pattern selected? Has somebody tried that? Ignacio Castaño castanyo@... _______________________________________________________________ Yahoo! Messenger Nueva versión: Webcam, voz, y mucho más ¡Gratis! Descárgalo ya desde http://messenger.yahoo.es 
From: Brinck, Andreas <Andreas.Brinck@di...>  20021123 14:00:22

Ok, thanks for all the input. Unfortunately I already have an epsilon value in my clipping code but this doesn't seem to solve the problem. /A.B. Original Message From: christer_ericson@... To: gdalgorithmslist@... Sent: 20021123 00:14 Subject: RE: [Algorithms] Accuracy problems revisited I said: >Consider a plane parallel to the yzplane cutting through the xaxis at >some X. This plane would now be represented by the infinite slab between >Xepsilon and X+epsilon, where epsilon is your tolerance value. A point P >is now considered on the plane if (P.x >= Xepsilon  P.x <= X+epsilon) >and in front vs. behind otherwise. That should of course read "if (P.x >= Xepsilon && P.x <= X+epsilon)". Christer Ericson Sony Computer Entertainment, Santa Monica  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: <castanyo@ya...>  20021123 11:14:34

or course, on the PC side you can also use WGL_ARB_multisample with GL_SAMPLE_ALPHA_TO_COVERAGE_ARB for order independant transparency. Ignacio Castaño castanyo@... 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) and if you can live with the restriction of things with exactly 50% alpha, and with the restriction that no stippled things can overlap in screenspace. Shrek used it on their water plane  the shadows appeared on the water surface itself and on the floor below the water. Even with component inputs I couldn't see any artifacts. Cuban @bungie _______________________________________________________________ Yahoo! Messenger Nueva versión: Webcam, voz, y mucho más ¡Gratis! Descárgalo ya desde http://messenger.yahoo.es 
From: Adrian Perez <adrianpe@mi...>  20021123 02:00:01

One of the shrek programmers posted a fantastically awesome fix for this  just use stippled alpha with a checkerboard stipple pattern. =20 It's only reasonable on televisions (the stipple pattern gets lost in the noise and you can't see it) and if you can live with the restriction of things with exactly 50% alpha, and with the restriction that no stippled things can overlap in screenspace. Shrek used it on their water plane  the shadows appeared on the water surface itself and on the floor below the water. Even with component inputs I couldn't see any artifacts. Cuban @bungie Original Message From: Rowan Wyborn [mailto:rowan@...]=20 Sent: Thursday, November 21, 2002 5:34 PM To: Gdalgorithms Subject: [Algorithms] casting shadows on semitransparent objects howdy, soooo i've been wracking my brain trying to figure out an algorithm for casting stencil shadows on semitransparent objects. The most efficient thing i could come up with was to draw and shadow the entire solid scene first, and then go back and draw each semitransparent object back to front in its own 'mini' shadow pass, where for each object i have to rerender any shadow volumes that affect it. This is obviously gonna introduce a bucketload of scene processing overhead, not to mention chew up fillrate.... so i really don't think its feasible. The only other thing i could come up with was to just not cast shadows on semitransparent objects... which i guess could look okayish as long as the objects weren't tooo opaque. anyways, am i missing something really obvious here? is it really that hard to handle semitransparent objects in a full scene shadowing algorithm? i'd really aprreciate hearing how other people are handling this ;) thanks, rowan  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=3D6188 
From: <christer_ericson@pl...>  20021122 23:15:50

I said: >Consider a plane parallel to the yzplane cutting through the xaxis at >some X. This plane would now be represented by the infinite slab between >Xepsilon and X+epsilon, where epsilon is your tolerance value. A point P >is now considered on the plane if (P.x >= Xepsilon  P.x <= X+epsilon) >and in front vs. behind otherwise. That should of course read "if (P.x >= Xepsilon && P.x <= X+epsilon)". Christer Ericson Sony Computer Entertainment, Santa Monica 
From: <christer_ericson@pl...>  20021122 22:56:00

>Ok maybe I could have been more specific :) The problem doesn't seem to be >the test but rather the generation of the actual bsp tree. Your original post indicated you had problems with the 'test' bit, but with the additional info you provided it does indeed sound like your tree construction is the problem (which is also much more plausible, because a point test with a BSPtree is about as straightforward as it gets). >There is a lot of nearly coincident polygons in the original mesh which I >suspect may be the reason the tree works so poorly. >[...] >I was mostly wondering if there was any obvious gotchas that I might have >missed. To robustly address the problems of quasicoplanar faces etc. you need to treat your splitting planes as 'fat', i.e. having a thickness of some appropriate tolerance value. Consider a plane parallel to the yzplane cutting through the xaxis at some X. This plane would now be represented by the infinite slab between Xepsilon and X+epsilon, where epsilon is your tolerance value. A point P is now considered on the plane if (P.x >= Xepsilon  P.x <= X+epsilon) and in front vs. behind otherwise. Christer Ericson Sony Computer Entertainment, Santa Monica 
From: Fong, Jay <JFong@Blackisle.com>  20021122 22:46:50

The idea of using shadow volumes to block incoming light is interesting. Can you provide any details on how this is done? Thanks. > From: "John Pollard" <johnp@...> > To: <gdalgorithmslist@...> > Subject: Re: [Algorithms] Stopping shadow volumes from going > through geometry > Date: Thu, 21 Nov 2002 18:23:38 0600 > ReplyTo: gdalgorithmslist@... > > You won't get the double darkening if you do all your > = shadowvolumes at once at the end, and do the fullscreen > quad to darken, = but it still doesn't solve the problem > completely, as the ledge will now = go through walls, and > it's a never ending process, unless like you said, = the > whole scene cast shadows. But this method is such a pain, > and you = never really fix all the problems. > > Our shadowvolumes actually block imcoming light, so the > problem goes = away (which is how most people are doing it > these days I'm assuming). = The drawback, is you have to > interleve your light rendering code between = the > shadowvolume rendering. The advantage, is all those problems > go = away. You don't even need to make the entire scene cast > shadows. = Everything just works. 
From: Chris Butcher (BUNGIE) <cbutcher@mi...>  20021122 22:27:41

What is almost definitely happening is that you have some BSP leaves which are being incorrectly classified, or you have very thin sliver leaves which are protruding through one of your bounding surfaces without being chopped. BSP generation from illconditioned meshes is a black art and if you really need this to be absolutely robust you have a very difficult task ahead of you. You might like to consider implementing a windingorder test. http://www.geometryalgorithms.com/Archive/algorithm_0103/algorithm_0103. htm  Chris Original Message From: Brinck, Andreas [mailto:Andreas.Brinck@...]=20 Sent: Friday, November 22, 2002 14:08 To: 'gdalgorithmslist@...' Subject: RE: [Algorithms] Accuracy problems revisited Ok maybe I could have been more specific :) The problem doesn't seem to be the test but rather the generation of the actual bsp tree. The mesh is pretty low poly and used to roughly cull geometry. If I rasterize the volume by using the point in volume test I get small slivers that protrude from the original volume. It seems like the volumes created by the bsp tree isn't always convex (even if they should be in theory). It wouldn't be a problem if the volume defined by the bsp tree was a small over estimation of the original volume but the protruding slivers shoot out far enough to be a serious problem. There is a lot of nearly coincident polygons in the original mesh which I suspect may be the reason the tree works so poorly. Also, naturally there is also the possibility that (god forbid) there is a bug in my tree creation code. As for other ideas I've considered creating an approximation of the original mesh by using an oct tree. This seems like a more stable solution. I was mostly wondering if there was any obvious gotchas that I might have missed. A.B. Original Message From: christer_ericson@... To: gdalgorithmslist@... Sent: 20021122 20:09 Subject: Re: [Algorithms] Accuracy problems revisited >I'm trying to use a bsp tree to determine if a point is inside a volume >whose surface is a two dimensional closed manifold. Due to numerical >accuracy problems the test sometimes incorrectly reports that the point is >inside the volume even when it isn't. > >Does anyone have a robust solution for this that doesn't involve switching >to exact arithmetics? I would also be interested in alternative algorithms >that doesn't involve bsp trees. One possibility I've considered would be to >shoot an infinite ray from the point in an arbitrary direction and check the >orientation of the first polygon it intersects. Unfortunately I think this >solution is too slow to be useful. I think you need to elaborate more on what exactly you're seeing and what exactly you're expecting in order to get good advice. I.e. how incorrect is the result you see now, and just how exact must your answer be. Unless you switch to exact arithmetic you will always get some small number of incorrectly categorized points. One option is to use a tolerance value to guarantee that inclusion is always reported correctly (but which may include points just outside your volume). You're not providing enough information for us to tell whether this is a workable solution. Pointinclusion is a predicate test, so it can fairly easily be computed exactly. You have a few options: 1. Use integers only, making sure you don't overflow. You can remove any divisions by multiplying through by the denominator in the expressions involving divisions. 2. If you need floatingpoint, you can use the exact predicates of Jonathan Shewchuk to do the sidedness test of your BSPtree planes. However, if you've computed the BSPtree, you will already have inaccuracies in this tree, unless you're representing the planes exactly, so you might want to go for a tolerancebased solution. You really need to provide more information though if you expect anyone to help you. Christer Ericson Sony Computer Entertainment, Santa Monica  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=3D6188  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=3D6188 
From: Brinck, Andreas <Andreas.Brinck@di...>  20021122 22:07:51

Ok maybe I could have been more specific :) The problem doesn't seem to be the test but rather the generation of the actual bsp tree. The mesh is pretty low poly and used to roughly cull geometry. If I rasterize the volume by using the point in volume test I get small slivers that protrude from the original volume. It seems like the volumes created by the bsp tree isn't always convex (even if they should be in theory). It wouldn't be a problem if the volume defined by the bsp tree was a small over estimation of the original volume but the protruding slivers shoot out far enough to be a serious problem. There is a lot of nearly coincident polygons in the original mesh which I suspect may be the reason the tree works so poorly. Also, naturally there is also the possibility that (god forbid) there is a bug in my tree creation code. As for other ideas I've considered creating an approximation of the original mesh by using an oct tree. This seems like a more stable solution. I was mostly wondering if there was any obvious gotchas that I might have missed. A.B. Original Message From: christer_ericson@... To: gdalgorithmslist@... Sent: 20021122 20:09 Subject: Re: [Algorithms] Accuracy problems revisited >I'm trying to use a bsp tree to determine if a point is inside a volume >whose surface is a two dimensional closed manifold. Due to numerical >accuracy problems the test sometimes incorrectly reports that the point is >inside the volume even when it isn't. > >Does anyone have a robust solution for this that doesn't involve switching >to exact arithmetics? I would also be interested in alternative algorithms >that doesn't involve bsp trees. One possibility I've considered would be to >shoot an infinite ray from the point in an arbitrary direction and check the >orientation of the first polygon it intersects. Unfortunately I think this >solution is too slow to be useful. I think you need to elaborate more on what exactly you're seeing and what exactly you're expecting in order to get good advice. I.e. how incorrect is the result you see now, and just how exact must your answer be. Unless you switch to exact arithmetic you will always get some small number of incorrectly categorized points. One option is to use a tolerance value to guarantee that inclusion is always reported correctly (but which may include points just outside your volume). You're not providing enough information for us to tell whether this is a workable solution. Pointinclusion is a predicate test, so it can fairly easily be computed exactly. You have a few options: 1. Use integers only, making sure you don't overflow. You can remove any divisions by multiplying through by the denominator in the expressions involving divisions. 2. If you need floatingpoint, you can use the exact predicates of Jonathan Shewchuk to do the sidedness test of your BSPtree planes. However, if you've computed the BSPtree, you will already have inaccuracies in this tree, unless you're representing the planes exactly, so you might want to go for a tolerancebased solution. You really need to provide more information though if you expect anyone to help you. Christer Ericson Sony Computer Entertainment, Santa Monica  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: Tom Forsyth <tomf@mu...>  20021122 20:26:30

I believe you can, yes. If you search back in the list archives, you should find a discussion about using ROAM this way. 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: John Cannon [mailto:jcannon@...] > Sent: 22 November 2002 19:55 > To: gdalgorithms > Subject: [Algorithms] ROAM for arbitrary topology... > > > 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: Lars Wilke <lars@ch...>  20021122 20:15:33

To convert a quaternion back and forth between LH & RH systems perform the following operation, assuming the (somewhat) standard +Z into (LH) or out of (RH) the screen. q.w *= 1.0; q.z *= 1.0; Lars Wilke Credo Interactive Inc. > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On > Behalf Of Joe Ante > Sent: Friday, November 22, 2002 8:23 AM > To: gdalgorithmslist@... > Subject: [Algorithms] Quaternion handedness > > > Hi, > > I am trying to convert tangent space 3x3 matrices for dot3 > product bumpmapping to quaternions. > > I want to convert these 3x3 matrices into quaternions to do > the objectspace tangentspace transformation, because I need > to slerp my tangentspace transform when doing geomorphing on > my chunk lod mesh. The tangentspace orthonormal bases are > sometimes right handed, sometimes left handed. > > Unfortunately my matrix to quaternion algorithm seems not to > work on left handed matrices. (I am using the algorithm > availible at magicsoftware) > > > Is there any way to represent a lefthanded matrix as a quaternion? > > What do I have to do to convert my lefthanded orthonormal > matrix into a quaternion? > > Joe Ante > > > 
From: John Cannon <jcannon@zi...>  20021122 19:49:33

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. 