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}

S  M  T  W  T  F  S 






1
(12) 
2
(4) 
3

4
(21) 
5
(3) 
6
(27) 
7
(31) 
8
(21) 
9
(2) 
10
(2) 
11
(14) 
12
(19) 
13
(24) 
14
(17) 
15
(27) 
16

17
(2) 
18
(2) 
19
(6) 
20
(1) 
21
(17) 
22
(12) 
23
(1) 
24
(1) 
25
(4) 
26
(16) 
27
(17) 
28
(7) 
29

30

31
(1) 






From: Adam Moravanszky <amoravanszky@dp...>  20020301 22:05:57

I think you can assume 2manifold geometry (actually, you might as well go and detect non2manifold places :) ). All I'm saying is that holes have become annoying for certain shadow volume tech, like what I use. There was a thread on that a few days ago. I agree with whoever posted that patching holes is not trivial, but finding them is. The meshes I use for shadowing don't have texture coordinates, so what you call "geometrical matching" are taken care of and welded... for me only real holes are an issue, which would be visible if it wouldn't be for other parts of the mesh obstructing it  the usual case where the artist has deleted some faces which are invisible and 'inside' the model, but now break shadows.   Adam Moravanszky http://n.ethz.ch/student/adammo/ 
From: Sim Dietrich <SD<ietrich@nv...>  20020301 21:50:56

Hmmm...so what you are saying is the function should find edges that are not geometrically matched, but may appear to be distinct for some other reason, like texture coordinates, ... ? If I can assume 2manifold geometry, this is not hard at all. Original Message From: Adam Moravanszky [mailto:amoravanszky@...] Sent: Friday, March 01, 2002 12:32 PM To: gdalgorithmslist@... Subject: Re: [Algorithms] Skinning + Tangent vectors Sim! Wait! Before you release this, could you perhaps consider adding functionality that finds and highlights all boundary edges (indicating holes in the mesh, indicating where it will be broken when using it for shadow volumes). Follow up for everyone: Since this morning I have been thinking about how nice it would be if there was a programming environment which let one write simple scripts for mesh manipulation, using primarily pattern matching. The idea being that most mesh processing involves a relatively simple process, of maybe a few special cases, that has to be applied the same way to thousands of vertices, faces, or edges. In a special language, all the data storage, format conversion, and looping needed in a C program would fall away, and special syntax woud simplify the rest. Of course, built in support for simple textured mesh rendering and picking would be needed as well. I haven't found anything like this yet on the web. The ideal language would be something that let me specify something like a Loop subdivision mask and it 'apply' it to the mesh correctly with a minimal ammount of instructions on how exactly to do that. Does anyone know something that fits that description, or do you think this is easy enough in C? Thanks,   Adam Moravanszky http://n.ethz.ch/student/adammo/ _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Adam Moravanszky <amoravanszky@dp...>  20020301 20:36:14

Sim! Wait! Before you release this, could you perhaps consider adding functionality that finds and highlights all boundary edges (indicating holes in the mesh, indicating where it will be broken when using it for shadow volumes). Follow up for everyone: Since this morning I have been thinking about how nice it would be if there was a programming environment which let one write simple scripts for mesh manipulation, using primarily pattern matching. The idea being that most mesh processing involves a relatively simple process, of maybe a few special cases, that has to be applied the same way to thousands of vertices, faces, or edges. In a special language, all the data storage, format conversion, and looping needed in a C program would fall away, and special syntax woud simplify the rest. Of course, built in support for simple textured mesh rendering and picking would be needed as well. I haven't found anything like this yet on the web. The ideal language would be something that let me specify something like a Loop subdivision mask and it 'apply' it to the mesh correctly with a minimal ammount of instructions on how exactly to do that. Does anyone know something that fits that description, or do you think this is easy enough in C? Thanks,   Adam Moravanszky http://n.ethz.ch/student/adammo/ 
From: Gary McTaggart <gary@va...>  20020301 19:13:04

> And, if you do get it all correct, no one will care, and > you're better off just > providing a "brightness" setting in your display options... I disagree. . . ignoring gamma issues lends itself to pretty ugly results. 
From: Gareth Lewin <GL<ewin@cl...>  20020301 18:48:55

Look at AT&T's dot tool. > Original Message > From: Dave Smith [mailto:dave.smith@...] > Sent: 01 March 2002 18:36 > To: gdalgorithmslist@... > Subject: [Algorithms] Graph Drawing Algorithms > > > AlgoFolks, > I am currently looking for graph drawing algorithms: > binarytree, generaltree, > 2D. > I want to be able to draw nodes and arcs and have it formatted nicely. > Any pointers or links would be appreciated, > Thanks, > DaveS > > ps. FYI, I'm googl'ing now. :) > > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Dave Smith <dave.smith@sd...>  20020301 18:35:56

AlgoFolks, I am currently looking for graph drawing algorithms: binarytree, generaltree, 2D. I want to be able to draw nodes and arcs and have it formatted nicely. Any pointers or links would be appreciated, Thanks, DaveS ps. FYI, I'm googl'ing now. :) 
From: Charles Bloom <cbloom@cb...>  20020301 17:31:13

Yeah, do NOT gamma correct textures. If you want to get it right, you need to know what gamma the textures were made at (including the "effective gamma" from the lighting environment where your artists work), and then you need to know the gamma of the monitor + lighting environment of the player. Then, you can adjust the gamma to just compensate for this difference. For example, most TV shows are shot at a Gamma of 1.3 ; then the TV applies a Gamma of 1.7 ; this is based on an expected average environment gamma of 2.2 in the living room. Anyway, for utility textures like height maps, normal maps, light maps you should have a Gamma of 1.0 in the texture; if they were hand painted by an artist with some gamma != 1.0 , then you should correct it. And, if you do get it all correct, no one will care, and you're better off just providing a "brightness" setting in your display options... At 09:55 AM 3/1/2002 +0200, Johan Hammes wrote: >sorry, to bring up an old thread... >what exactly was the conclusion of the previos thread about gamma ? Do you >set your monitor gamma to 1, and pre bake gamma into your textures, or do >you try to pursuade users to set there monitor gamma up? (is 2.2 a generally >acepted value for this?) > >dont you get blending artifatcs if you prebake gamma into textures ? > >johan > > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188  Charles Bloom cbloom@... http://www.cbloom.com 
From: Sim Dietrich <SD<ietrich@nv...>  20020301 15:30:16

Early next week ( possibly today ) I hope to release the NVMeshMender, which is a simple function that processes meshes, and, among other things, can calculate texture space bases for you, including handling many of the nasty cases that real meshes have. The NVMeshMender uses the perface S,T and SxT to detect discontinuities across an edge of neighboring faces. If this 'crease angle' is too great ( either due to flipped textures, or just a really distorted mapping ), it duplicates edges to fix the problem. After an edge is duplicated, the face that has the new edge is not smoothed with that neighbor anymore, so you don't have artifacts when you perform lighting. After the smoothing step, the perface SxT is tossed out, and the pervertex normal is used instead. The one thing that I want to add to the NVMeshMender is the ability to detect & correct completely degenerate bases ( where a triangle only traces out a point or line in texture space ). Original Message From: Tom Forsyth To: Oscar Blasco; gdalgorithmslist@... Sent: 3/1/2002 3:51 AM Subject: RE: [Algorithms] Skinning + Tangent vectors Does anyone actually store both SxT _and_ the normal? They should be the same thing, surely? Obviously both are approximations, but they are the same concept  the normal to the face. I would definately go with the technique of finding S & T per face, then averaging at each vertex (making sure to weight by the angle that face has at the vertex, otherwise different tesselation levels will change the lighting, which is not what you want), then take the actual exported normal as the "real" normal (that way the artists can control it well), and make S & T perpendicular to it and each other. So SxT doesn't really come into it. If you want to only pass two vectors to the vertex shader to save bandwidth, I would pass in something like S and the normal, and calculate T using SxN and a sign bit, rather than degrading the most important part of the shading equation  the normal. Tom Forsyth  purely hypothetical Muckyfoot bloke. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > Original Message > From: Oscar Blasco [mailto:traxnet@...] > Sent: 01 March 2002 11:22 > To: gdalgorithmslist@... > Subject: RE: [Algorithms] Skinning + Tangent vectors > > > I completely agree with Sim Dietrich: > > >a) You should always use the Normal instead of SxT ( this is not > only > >cheaper, but helps with flipped textures ) > > Also it has the effect to 'smooth' the light vector > > Answering the email from Adam: > >  [Adam]: Hmm. But if we assume c), then doesn't that imply that > Normal == SxT *SIGNBIT , making your point a) be meaningless? > > Depends in how you are calculating the S,T vector: Normally S,T are > calculated perface using the face normal. Then S,T are 'averaged' > per vertex. At this point using the vertex normal helps to reorient > the basis back to a slightly better position (just using the normal > directly or using it to orthonormalize the basis for example with the > GramSchmidt orthogonalization). Try using the vertex normal instead > of SxT*sing and you may find that it improves the lighting. > > >c) The assumption that S & T & Normal vectors are orthonormal is a > >good > >assumption if your texels are mapped to be square. Because this is > >usually > >true, or supposed to be true, it tends should work out if you make > >the > >assumption that the tangent basis is orthonormal. > > As I said you can also orthonormalize the basis. > > The worst problem with local ilumination using S,T,N is when two > adjacent faces have S or/and T in opposite directions (not necessary > completly opposite, just TdotT' < 0). This produces the vector L to > flip from one face to the other thus inverting the bumps. Best > solution I have found: do the lighting in model space > transform L > instead of S, T, N. > > Oscar Blasco > oscar@... > > >Original Message > >From: John Harries > >To: Adam Moravanszky; Algorithms List > >Sent: 2/28/2002 6:58 AM > >Subject: RE: [Algorithms] Skinning + Tangent vectors > > > >:) > >That should have read: > >Since S, T, SxT IDEALLY form an orthonormal basis you can transform > >S > >and > >your > >normal and then perform a crossproduct to calculate T. Easy in a > >vertex > >shader. > > > >John > > > >> Original Message > >> From: Adam Moravanszky [mailto:amoravanszky@...] > >> Sent: Thursday, February 28, 2002 8:53 AM > >> To: John Harries; Algorithms List > >> Subject: Re: [Algorithms] Skinning + Tangent vectors > >> > >> > >> Yes, this does help, as did Tom's reply. > >> > >> I don't agree with S,T and SxT forming an orthonormal basis, > >>though. > >This > >> is only the case when we have 'perfect' texture mapping > >> coordinates with no > >> distortion  not very likely. I believe S and T have to follow > >> the texture > >> mapping directions, even if the UV directions are not orthogonal. > >>On > >the > >> other hand, S cross T is usually (close to) the normal, so the > >> optimization > >> in my vertex shaders is that I leave the normal away, and compute > >>that > >on > >> the fly as > >> SIGNBIT * (S x T) > >> > >> Adam > >>  Original Message  > >> From: John Harries > >> To: Adam Moravanszky ; Algorithms List > >> Sent: Thursday, February 28, 2002 3:01 PM > >> Subject: RE: [Algorithms] Skinning + Tangent vectors > >> > >> > >> Yes, you need to retransform. > >> > >> Your tangent space is defined by the vectors S, T and SxT. (Where > >>SxT > >is > >> cross_product(S, T)). > >> > >> Note that SxT is also the vertex normal. > >> > >> S and T should be derived from the texture coordinate derivatives > >> only once. > >> > >> Since S, T, SxT forms an orthonormal basis you can transform S > and > >your > >> normal and then perform a crossproduct to calculate T. Easy in a > >vertex > >> shader. > >> > >> Does this help? > >> > >> John > >> > >> > > > > > > > >_______________________________________________ > >GDAlgorithmslist mailing list > >GDAlgorithmslist@... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > >_______________________________________________ > >GDAlgorithmslist mailing list > >GDAlgorithmslist@... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > _______________________________________________ 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...>  20020301 11:52:30

Does anyone actually store both SxT _and_ the normal? They should be the same thing, surely? Obviously both are approximations, but they are the same concept  the normal to the face. I would definately go with the technique of finding S & T per face, then averaging at each vertex (making sure to weight by the angle that face has at the vertex, otherwise different tesselation levels will change the lighting, which is not what you want), then take the actual exported normal as the "real" normal (that way the artists can control it well), and make S & T perpendicular to it and each other. So SxT doesn't really come into it. If you want to only pass two vectors to the vertex shader to save bandwidth, I would pass in something like S and the normal, and calculate T using SxN and a sign bit, rather than degrading the most important part of the shading equation  the normal. Tom Forsyth  purely hypothetical Muckyfoot bloke. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > Original Message > From: Oscar Blasco [mailto:traxnet@...] > Sent: 01 March 2002 11:22 > To: gdalgorithmslist@... > Subject: RE: [Algorithms] Skinning + Tangent vectors > > > I completely agree with Sim Dietrich: > > >a) You should always use the Normal instead of SxT ( this is not > only > >cheaper, but helps with flipped textures ) > > Also it has the effect to 'smooth' the light vector > > Answering the email from Adam: > >  [Adam]: Hmm. But if we assume c), then doesn't that imply that > Normal == SxT *SIGNBIT , making your point a) be meaningless? > > Depends in how you are calculating the S,T vector: Normally S,T are > calculated perface using the face normal. Then S,T are 'averaged' > per vertex. At this point using the vertex normal helps to reorient > the basis back to a slightly better position (just using the normal > directly or using it to orthonormalize the basis for example with the > GramSchmidt orthogonalization). Try using the vertex normal instead > of SxT*sing and you may find that it improves the lighting. > > >c) The assumption that S & T & Normal vectors are orthonormal is a > >good > >assumption if your texels are mapped to be square. Because this is > >usually > >true, or supposed to be true, it tends should work out if you make > >the > >assumption that the tangent basis is orthonormal. > > As I said you can also orthonormalize the basis. > > The worst problem with local ilumination using S,T,N is when two > adjacent faces have S or/and T in opposite directions (not necessary > completly opposite, just TdotT' < 0). This produces the vector L to > flip from one face to the other thus inverting the bumps. Best > solution I have found: do the lighting in model space > transform L > instead of S, T, N. > > Oscar Blasco > oscar@... > > >Original Message > >From: John Harries > >To: Adam Moravanszky; Algorithms List > >Sent: 2/28/2002 6:58 AM > >Subject: RE: [Algorithms] Skinning + Tangent vectors > > > >:) > >That should have read: > >Since S, T, SxT IDEALLY form an orthonormal basis you can transform > >S > >and > >your > >normal and then perform a crossproduct to calculate T. Easy in a > >vertex > >shader. > > > >John > > > >> Original Message > >> From: Adam Moravanszky [mailto:amoravanszky@...] > >> Sent: Thursday, February 28, 2002 8:53 AM > >> To: John Harries; Algorithms List > >> Subject: Re: [Algorithms] Skinning + Tangent vectors > >> > >> > >> Yes, this does help, as did Tom's reply. > >> > >> I don't agree with S,T and SxT forming an orthonormal basis, > >>though. > >This > >> is only the case when we have 'perfect' texture mapping > >> coordinates with no > >> distortion  not very likely. I believe S and T have to follow > >> the texture > >> mapping directions, even if the UV directions are not orthogonal. > >>On > >the > >> other hand, S cross T is usually (close to) the normal, so the > >> optimization > >> in my vertex shaders is that I leave the normal away, and compute > >>that > >on > >> the fly as > >> SIGNBIT * (S x T) > >> > >> Adam > >>  Original Message  > >> From: John Harries > >> To: Adam Moravanszky ; Algorithms List > >> Sent: Thursday, February 28, 2002 3:01 PM > >> Subject: RE: [Algorithms] Skinning + Tangent vectors > >> > >> > >> Yes, you need to retransform. > >> > >> Your tangent space is defined by the vectors S, T and SxT. (Where > >>SxT > >is > >> cross_product(S, T)). > >> > >> Note that SxT is also the vertex normal. > >> > >> S and T should be derived from the texture coordinate derivatives > >> only once. > >> > >> Since S, T, SxT forms an orthonormal basis you can transform S > and > >your > >> normal and then perform a crossproduct to calculate T. Easy in a > >vertex > >> shader. > >> > >> Does this help? > >> > >> John > >> > >> > > > > > > > >_______________________________________________ > >GDAlgorithmslist mailing list > >GDAlgorithmslist@... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > >_______________________________________________ > >GDAlgorithmslist mailing list > >GDAlgorithmslist@... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > 
From: Oscar Blasco <traxnet@gm...>  20020301 11:22:44

I completely agree with Sim Dietrich: >a) You should always use the Normal instead of SxT ( this is not= only >cheaper, but helps with flipped textures ) Also it has the effect to 'smooth' the light vector Answering the email from Adam:  [Adam]: Hmm. But if we assume c), then doesn't that imply= that Normal =3D=3D SxT *SIGNBIT , making your point a) be meaningless? Depends in how you are calculating the S,T vector: Normally S,T= are calculated perface using the face normal. Then S,T are= 'averaged' per vertex. At this point using the vertex normal helps to= reorient the basis back to a slightly better position (just using the= normal directly or using it to orthonormalize the basis for example with= the GramSchmidt orthogonalization). Try using the vertex normal= instead of SxT*sing and you may find that it improves the lighting. >c) The assumption that S & T & Normal vectors are orthonormal is= a >good >assumption if your texels are mapped to be square. Because this= is >usually >true, or supposed to be true, it tends should work out if you= make >the >assumption that the tangent basis is orthonormal. As I said you can also orthonormalize the basis. The worst problem with local ilumination using S,T,N is when two= adjacent faces have S or/and T in opposite directions (not= necessary completly opposite, just TdotT' < 0). This produces the vector L= to flip from one face to the other thus inverting the bumps. Best solution I have found: do the lighting in model space >= transform L instead of S, T, N. Oscar Blasco oscar@... >Original Message >From: John Harries >To: Adam Moravanszky; Algorithms List >Sent: 2/28/2002 6:58 AM >Subject: RE: [Algorithms] Skinning + Tangent vectors > >:) >That should have read: >Since S, T, SxT IDEALLY form an orthonormal basis you can= transform >S >and >your >normal and then perform a crossproduct to calculate T. Easy in= a >vertex >shader. > >John > >> Original Message >> From: Adam Moravanszky [mailto:amoravanszky@...] >> Sent: Thursday, February 28, 2002 8:53 AM >> To: John Harries; Algorithms List >> Subject: Re: [Algorithms] Skinning + Tangent vectors >> >> >> Yes, this does help, as did Tom's reply. >> >> I don't agree with S,T and SxT forming an orthonormal basis, >>though. >This >> is only the case when we have 'perfect' texture mapping >> coordinates with no >> distortion  not very likely. I believe S and T have to= follow >> the texture >> mapping directions, even if the UV directions are not= orthogonal. >>On >the >> other hand, S cross T is usually (close to) the normal, so= the >> optimization >> in my vertex shaders is that I leave the normal away, and= compute >>that >on >> the fly as >> SIGNBIT * (S x T) >> >> Adam >>  Original Message  >> From: John Harries >> To: Adam Moravanszky ; Algorithms List >> Sent: Thursday, February 28, 2002 3:01 PM >> Subject: RE: [Algorithms] Skinning + Tangent vectors >> >> >> Yes, you need to retransform. >> >> Your tangent space is defined by the vectors S, T and SxT.= (Where >>SxT >is >> cross_product(S, T)). >> >> Note that SxT is also the vertex normal. >> >> S and T should be derived from the texture coordinate= derivatives >> only once. >> >> Since S, T, SxT forms an orthonormal basis you can transform= S and >your >> normal and then perform a crossproduct to calculate T. Easy= in a >vertex >> shader. >> >> Does this help? >> >> John >> >> > > > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > 
From: Oscar Cooper <oscar.cooper@cr...>  20020301 10:54:48

Hiya, I've just had an almost identical artefact, which seems to have been caused by subdividing the heightfield using a depth first traversal. When I switched to breadth first, the nasty peaks disappeared (kinda obvious when you think about it :). Before working this out, I'd switched to using Tom's method for subdividing the edges, so maybe this is a factor too... Oscar Cooper. Creature Labs. Original Message From: David Zaadstra [mailto:mythomania@...] Sent: 27 February 2002 20:12 To: gdalgorithmslist@... Subject: [Algorithms] midpoint displacement problems Hello everybody, I have a problem with the midpoint displacement algorithm (from GPG1). I get strange little peaks all around my landscape. I've been looking for the bug for hours now and starting to believe that I'm a complete idiot. Could it be that the peaks are normal? That would explain why an erosion filter was added to the example file in GPG... Please take a look at this screenshot to see what I mean: http://www.gameprogramming.de/screen.jpg (not a very good one, i know) Thanks for your help, David 
From: Johan Hammes <jhammes@mw...>  20020301 07:56:03

sorry, to bring up an old thread... what exactly was the conclusion of the previos thread about gamma ? Do you set your monitor gamma to 1, and pre bake gamma into your textures, or do you try to pursuade users to set there monitor gamma up? (is 2.2 a generally acepted value for this?) dont you get blending artifatcs if you prebake gamma into textures ? johan 