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

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

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

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

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

_{Jul}

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

_{Dec}

2012 
_{Jan}

_{Feb}
(7) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

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

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

_{Jun}

_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

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

_{Mar}
(2) 
_{Apr}

_{May}
(10) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(3) 
_{Dec}

2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(12) 
_{Nov}

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

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

_{Jun}
(1) 
_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(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: Daniel Vogel <vogel@ep...>  20020307 23:39:07

> If your hardware has reasonably flexible render to texture, you > can do this kind of effects quite easily, without using any > readbacks. The HW has even something better ;) http://www.nvidia.com/dev_content/nvopenglspecs/GL_NV_occlusion_query.txt  Daniel, Epic Games Inc. 
From: Jack Mathews <jack@re...>  20020307 23:36:11

Thanks very much Chris, you're a class act. And that's quite clever :) Jack Original Message From: Chris Butcher (BUNGIE) [mailto:cbutcher@...] Sent: Thursday, March 07, 2002 4:22 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] [OT] Another cool Halo effect  How?! > Original Message > From: Jack Mathews [mailto:jack@...] > Sent: Thursday, March 07, 2002 10:08 > To: gdalgorithmslist@... > Subject: RE: [Algorithms] [OT] Another cool Halo effect  How?! > > > Well, I read nothing into that, because you told us nothing. Kind of goes against the spirit of the list > to say "Oh yeah, I know this algorithm, but unless you're on this OTHER list, I can't give it out. But > it's way cool, trust me." > > Does talk like this really _help_ anyone? How would you feel if you had a legitimate question, and > someone replied with something like that? > That's a very valid point. Tony didn't want to divulge the exact details of how we do everything about the effect, which I think is fine, but it's not fair to the list to keep posting about it without letting you in on the interesting parts. One effect involves reading how much of the sun polygon passed the Z test, and using this to scale the brightness of a large translucent lensflare. The other effect is done by rendering to an offscreen buffer only where the Z test passed in the main framebuffer, and then radially stretching/blurring it before compositing back into the primary buffer. It produces a rather nice fake raysstreamingthroughleaves effect when the sun is viewed through foliage. Our friends in the UK should finally be able to check this effect out firsthand in a week or so. :)  Chris Butcher AI Engineer  Halo Bungie Studios butcher@... _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 
From: Jason G Doig <jasephys@py...>  20020307 23:14:42

If your hardware has reasonably flexible render to texture, you can do this kind of effects quite easily, without using any readbacks. Render a poly with Z test disabled over the area you are interested in sampling into either destination alpha, or an offscreen buffer using the screen Z buffer. Set the alpha to 0. Render the same poly with Z test enabled at the Z of the sun/light. Set the alpha to 255 (or 1.0, according to API :). You should now have an alpha mask of the visible areas. Using a bilinear filter you can progressively shrink this down to a single pixel (thus getting an average coverage value), and then use the resulting pixel as a texture to render into the alpha component of your flare texture. Or you can do as Chris mentions, and blur it outwards to create the illusion of shafts of light, though you'd probably want to layer up a few sprites tested at different Z's to give it some depth. Pretty simple effect if your hardware can do it, but extremely effective. Cheers, Jase.  Original Message  From: "Chris Butcher (BUNGIE)" <cbutcher@...> > One effect involves reading how much of the sun polygon >passed the Z test, and using this to scale the brightness of a >large translucent lensflare. The other effect is done by rendering >to an offscreen buffer only where the Z test passed in the main >framebuffer, and then radially stretching/blurring it before >compositing back into the primary buffer. It produces a rather >nice fake raysstreamingthroughleaves effect when the sun >is viewed through foliage. 
From: Chris Butcher (BUNGIE) <cbutcher@mi...>  20020307 22:22:28

> Original Message > From: Jack Mathews [mailto:jack@...] > Sent: Thursday, March 07, 2002 10:08 > To: gdalgorithmslist@... > Subject: RE: [Algorithms] [OT] Another cool Halo effect  How?! >=20 >=20 > Well, I read nothing into that, because you told us nothing. Kind of = goes against the spirit of the list > to say "Oh yeah, I know this = algorithm, but unless you're on this OTHER list, I can't give it out. = But=20 > it's way cool, trust me." >=20 > Does talk like this really _help_ anyone? How would you feel if you = had a legitimate question, and=20 > someone replied with something like that? >=20 That's a very valid point. Tony didn't want to divulge the exact = details of how we do everything about the effect, which I think is fine, = but it's not fair to the list to keep posting about it without letting = you in on the interesting parts. One effect involves reading how much of the sun polygon passed the Z = test, and using this to scale the brightness of a large translucent = lensflare. The other effect is done by rendering to an offscreen buffer = only where the Z test passed in the main framebuffer, and then radially = stretching/blurring it before compositing back into the primary buffer. = It produces a rather nice fake raysstreamingthroughleaves effect when = the sun is viewed through foliage. Our friends in the UK should finally be able to check this effect out = firsthand in a week or so. :) =20 Chris Butcher=20 AI Engineer  Halo=20 Bungie Studios=20 butcher@...=20 
From: George Warner <geowar@ap...>  20020307 21:02:24

On Wed, 6 Mar 2002 19:34:44 0600 , "Gribb, Gil" <ggribb@...> wrote: > The below solution is imprecise (what exactly is the signed distance to a > line?) but more or less correct if you replace "signed distance to line" > with signed distance to a plane containing the edge and not parallel to the > triangle plane. Consistently oriented, of course. On a plane where you have a line defined by two points the "signed distance to line" function returns positive values for all points to the right of the line and negative values for all points to the left where the first point is the origin and the second describes the vector away from this point. This right/left direction is arbitrary. It's only important that the directions are all the same for all edges of the polygon. Since it's impossible for a point to be outside all edges (unless it's off the plane) the then only case where all the directions are the same is when the point is inside. > A hate to pull a Ron, but sheesh people at least take 5 minutes to play with > it on paper. You just need to "think it through". If the point and the triangle are all coplainer then you don't need to think 3D. Your "signed distance to a plane" turns into my "signed distance to a line". I've lost count of the number of apps that I've written that work this way. For me it's part of my standard 3D toolbox. You go play with your paper; I've got working code already shipping. ;)  Enjoy, George Warner, Mixed Mode Magic Fragment Scientist Apple Developer Technical Support (DTS) 
From: akbara <akbar_a@ac...>  20020307 20:07:53

hey, there's a formula or saying or something like that in physics.. can't remember what it is. but the general jist is, that even if you get better tools and they reduce the amount of time it takes to do that exact same job. we will always find ways to increase the amount of itme.. for example. luxo jr. took forever to render back in the days, then we got faster computers, etc.. so in theory, movie and short rendering time should have stayed the same.. but it didn't. are needs and wants just changed... there's a saying for that.. i forget any of you, recall what it is? list is been dead for a while to.. l8rz, akbar ;mysite>http://vertexabuse.cjb.net 
From: Jon Watte <hplus@mi...>  20020307 19:11:48

When you say "shadow drawing" it's unclear what it's doing now. Stencil shadow? Shadow buffer? Projected geometry? Oval spot aligned with the ground? To make a fuzzy shadow, you can use a projected shadow texture, and make the resolution of the shadow texture low, so interpolation ("magnification filtering") will make it fuzzier. A better magnification filter may lead to better results; linear gets pretty ugly when you go beyond about a factor 2. For stencil and friends, it's harder; you need rendertosmallertexture to get the same effect (and as the effect is then in screen space, it's not the same thing anyway). To make it softer further away, you can multiply texture alpha with some falling function depending on distancefromlight. This can be implemented with texture coordinate generation and a 1D texture (and thus a second texture unit) or through a cunning combination of vertex + pixel shader. Cheers, / h+ > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...]On Behalf Of > MHarmon@... > Sent: Thursday, March 07, 2002 9:40 AM > To: GDAlgorithmslist@... > Subject: [Algorithms] Improving look of Shadows > > > Can I do something to a shadow draw routine to make it: > a) look a little fuzzy or blurry > b) get a little lighter (more transparent) at the point farthest away > from the "light source". what i mean here is that the shadow would look a > little darker at its base, and a little lighter at its peak > > what would these algorithms be, lets say on a PC or PS2 > > > respectfully, > m > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Jack Mathews <jack@re...>  20020307 18:08:06

Well, I read nothing into that, because you told us nothing. Kind of goes against the spirit of the list to say "Oh yeah, I know this algorithm, but unless you're on this OTHER list, I can't give it out. But it's way cool, trust me." Does talk like this really _help_ anyone? How would you feel if you had a legitimate question, and someone replied with something like that? Jack Original Message From: Tony Cox [mailto:tonycox@...] Sent: Monday, February 25, 2002 7:29 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] [OT] Another cool Halo effect  How?! >Ahh, interesting, I think you're right on. I wouldn't really call the effect wobbling btw  it's more >that the global illumination changes. What we were checking out was right at the start of chapter 2. >Exit the escape pod and turn left about 270 degrees, before you even cross the bridge. Aim your gun at >the sky and move back in forth in front of the tree. If more of the sun is occluded by the tree, the >whole frame gets darker. > >Even sicker, it's nothing as simple as tweaking the gamma ramp, there's a radial falloff from the sun >center to the edges of the frame. Yeah, looks way cool though. I remember a few weeks back some of the Bungie guys gave a bunch of us other Xbox devs a download on how some of the tech worked, including that effect. Obviously if the Bungie people don't want to say, then I won't either, but suffice to say that my thought at the time was "You did *what*? You guys are crazier than I thought!". Read into that what you will. Tony Cox  Development Lead, Hockey Microsoft Games Studios  Sports _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 
From: PierreEmmanuel Chaut <pierre@cs...>  20020307 17:45:50

>Can I do something to a shadow draw routine to make it: > a) look a little fuzzy or blurry Render it into a small texture, you resample and texture again : you render your object into a small texture, you use that image as a texture to render into antoher (larger) texture .. and here is you blurred shadow .. 
From: Willem H. de Boer <Willem@mu...>  20020307 17:40:59

Are you talking about projective shadow maps? If so. a) get some gaussian blur going on. You could render the shadow to a smaller buffer and let bilinear filtering do the rest, but that looks pants. (ie, blockyblurry if you know what I mean). b) If you draw your shadow map as a separate pass, have a vertex alpha with a value depending on the distance from vertex to lightsource. Or have a separate 1d texture gradient texture and calculate uv for each vertex depending on distance from light, and draw multipass. Willem MuckyFoot Goat Boy In A Hurry (tm) > Original Message > From: MHarmon@... [mailto:MHarmon@...] > Sent: 07 March 2002 17:40 > To: GDAlgorithmslist@... > Subject: [Algorithms] Improving look of Shadows > > > Can I do something to a shadow draw routine to make it: > a) look a little fuzzy or blurry > b) get a little lighter (more transparent) at the point > farthest away > from the "light source". what i mean here is that the shadow > would look a > little darker at its base, and a little lighter at its peak > > what would these algorithms be, lets say on a PC or PS2 > > > respectfully, > m > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: <MHarmon@bl...>  20020307 17:32:24

Can I do something to a shadow draw routine to make it: a) look a little fuzzy or blurry b) get a little lighter (more transparent) at the point farthest away from the "light source". what i mean here is that the shadow would look a little darker at its base, and a little lighter at its peak what would these algorithms be, lets say on a PC or PS2 respectfully, m 
From: Jon Watte <hplus@mi...>  20020307 16:13:52

> How are you doing such multitexturing terrain ? You either accept the performance loss with extra layers, or you start baking larger single textures procedurally (with distance/view dependent LOD for what MIP map levels to create). If you go for the performance loss, you could at least start doing blending using multitexturing and pixel shaders (or, if you're on OpenGL, various vendor specific extensions); you might still need to bake some kind of alpha or weight texture(s) for this case. I imagine http://www.vterrain.org/ has more info on various approaches. Cheers, / h+ 
From: Ron Levine <ron@do...>  20020307 15:43:21

Marius Elvert wrote: >Thanx all. I wrote this yesterday: >http://www.gamedev.net/community/forums/topic.asp?topic_id=83577 >and I was wondering whether and how fast that works. >I think it's a bit similar to Ron's algo, but without all the dot and cross >products >(BTW it's for 3D) Not quite. This approach is based on EXACTLY the same ideas as mine, (basis vectors for a 2D subspace of a 3D vector space), but it is not quite correctly carried through for the general 3D case. The point is that we have three scalar equations in two unknowns (your u, v; my z1, z2), an overdetermined system. It has a solution only if the three equations are linearly dependent, i.e., if the point is actually in the plane of the triangle, and there are different ways that this linear dependence can occur. Your approach of just solving the x,y equations for u,v works some of the time, but NOT for every possible orientation of the triangle in 3space. Specifically, it fails when the first two equations alone are linearly dependent, i.e., when the plane of the triangle is vertical. Also, even when the x,y equations are linearly independent, your algorithm for solving that pair fails in the case that your ACy is zero. So your execution of an originally good idea is not correct for the general case, in fact, not correct on two different levels, both the level of reducing from 3 variables to 2 variables and the level of reducing from 2 variables to 1 variable. My point in taking dot products is to project the 2D linear algebra problem cleanly to the plane of the triangle in a way that works no matter how the triangle is oriented in 3D space. That is the content of my result that d is not zero if the triangle is not degenerate, no matter how it is oriented in 3D space. That is why my approach is more elegant and more correct. The dot product is your friend. Division by zero is your enemy. It IS true that my solution is overkill in the purely 2D case, the case where the z components of all four given points are equal, an inefficiency that I chose to pay for elegance. Ron 
From: Pierre Terdiman <p.terdiman@wa...>  20020307 15:17:43

I didn't follow the thread but just in case, and after a 2seconds search in my saved Flipcode threads : http://www.flipcode.com/cgibin/msg.cgi?showThread=00003017&forum=3dtheory&i d=1 Might be helpful. Pierre 
From: Stephen J Baker <sjbaker@li...>  20020307 14:46:53

On Wed, 6 Mar 2002, Gareth Lewin wrote: > So if your triangle points are A,B,C and the point you are testing is P you > need to sum up the angles > > AP>BP > BP>CP > CP>AP > > and if the sum is 360 ( PI*2 ) then your point is in the triangle, if not > then you are outside the triangle ( You will probably want to use some > tolerance value, so say from 359 to 361 degrees ) In fact, if you are inside the triangle, the sum of the angles will be either +360 or 360 (with some roundoff errors) and if you are outside the triangle, it'll be zero (with some roundoff errors)  so the safest thing is to say: if ( totalAngle > 180  totalAngle < 180 ) ...we are inside... ; else ...we are outside... ; ...which leaves maximum room for *huge* roundoff errors. Having said all that, I don't use that method at all. I compute the signs of the distances from my point to the three sides of the triangle  if they are all the same then we are inside, if some are positive and others negative then we are outside. I prefer this because the nasty special cases (when the point is exactly on an edge or [worse] exactly on a vertex) show up as a zero distance to one or two edges  so you can *control* what happens in those cases. The angle measuring test has nasty illconditioned things happening to the numbers when you are on the perimeter of the triangle. (Ask yourself: What is the angle AP>BP when A==P? What happens when P is within a couple of leastsignificantbits of A? Urgh!)  Steve Baker (817)6192657 (Vox/VoxMail) L3Com/Link Simulation & Training (817)6192466 (Fax) Work: sjbaker@... http://www.link.com Home: sjbaker1@... http://www.sjbaker.org 
From: Tom Forsyth <tomf@mu...>  20020307 12:58:35

I think mine might be for linear space, i.e. they just show the relative perception of "brightness" of the three channels according to the eye. 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: Willmott, Andrew [mailto:AWillmott@...] > Sent: 07 March 2002 00:16 > To: GDAlgorithmslist@... > Subject: RE: Re[2]: [Algorithms] Gamma > > > Ironically enough, for this discussion, these weights vary > depending on the gamma etc. of the display device. The > numbers Daniel gives are for NTSC, with gamma = 2.2. For a > linear colour space, you have 0.3086, 0.6094, 0.0820. > > Not sure where Tom's come from; maybe they're for PAL =) > > Cheers, > > Andrew > > Original Message > From: Hansen, Daniel [mailto:Daniel.Hansen@...] > Sent: Wednesday, March 06, 2002 8:08 AM > To: GDAlgorithmslist@... > Subject: RE: Re[2]: [Algorithms] Gamma > > > From the colorspace faq: > > Y = 0.299*Red+0.587*Green+0.114*Blue > > http://www.neuro.sfc.keio.ac.jp/~aly/polygon/info/colorspacefaq.html > section 5.6 > > > Original Message > From: Tom Forsyth [mailto:tomf@...] > Sent: den 6 mars 2002 16:53 > To: Oles V. Shishkovtsov; GDAlgorithmslist@... > Subject: RE: Re[2]: [Algorithms] Gamma > > > That doesn't look right. The one I've always used, which is slightly > approximated from one I looked up somewhere authoritative, is: > > luminance = 0.35f * red + 0.45f * green + 0.2f * blue; > > > 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: Oles V. Shishkovtsov [mailto:oles@...] > > Sent: 06 March 2002 15:49 > > To: GDAlgorithmslist@... > > Subject: Re[2]: [Algorithms] Gamma > > > > > > Hello Mickael, > > > > Wednesday, March 06, 2002, 17:38:37, you wrote: > > > > >> > > >> BTW: If you're looking to change saturation, you can > > actually avoid the > > >> conversion to HSV. Paul Haeberli and Douglas Voorhies present a > > >> really cool > > >> method of changing saturation (amongst other things) using > > a lerp between > > >> the image and a greyscale version of it on the Grafica > > Obscura site: > > >> http://www.sgi.com/grafica/interp/index.html > > > > MP> This document simply presents a basic linear > > interpolation. Nothing special > > MP> in it except the cool sample pictures... > > > > MP> Of course, if you assume that red, green and blue values > > avec the same > > MP> brightness (this is wrong), you can do the conversion on > > the fly, no need > > MP> to have an already made grey picture (or even to store it) > > > > MP> for each y > > MP> for each x > > MP> get r,g,b from pixel > > MP> grey=(r+g+b)/3 > > MP> new_r=grey+(rgrey)*factor > > MP> new_g=grey+(ggrey)*factor > > MP> new_b=grey+(bgrey)*factor > > MP> write back new_r,new_g,new_b to pixel > > > > Actually following code will work somewhat better :) > > > > // Approximate values for each component's contribution to > luminance. > > // Based upon the NTSC standard described in ITUR > > Recommendation BT.709. > > grey = r * 0.2125f + g * 0.7154f + b * 0.0721f; > > > >  > > Best regards, > > Oles V. Shishkovtsov > > GSCGame World > > oles@... > > _______________________________________________ > 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: <LtJax@t...>  20020307 12:55:41

Thanx all. I wrote this yesterday: http://www.gamedev.net/community/forums/topic.asp?topic_id=83577 and I was wondering whether and how fast that works. I think it's a bit similar to Ron's algo, but without all the dot and cross products (BTW it's for 3D) Jax 
From: Stefan Maton <metron@sk...>  20020307 08:45:03

Hi, I working on some terrain stuff right now and I wonder which way the textures should be applied to the terrain. Actually, I'm currently using multitexturing to blend in the different layer of texture type. I'll explain : Imagine a multilayer with ie. 3 layers : 1 grass, 1 rock and 1 mud. Those 3 layers are superposed like this :  rock  mud  grass The grass layer is that one which is the base of the terrain. The other layers are blended in depending on an alpha value at a given vertex : 0 1 **       ** 2 3 Each * represents a vertex. The blend table looks like this : Vertex  grass  mud  rock +++ 0  100%  0%  0% 1  100%  50%  0% 2  100%  0%  50% 3  100%  25%  25% Now, to blend those layers, I do the first layer with normal rendering (since everything is 100%), the second and third pass the layer with blending included in the color component (alpha value). The texture itself is applied as a tiling texture (means no big texture for the whole terrain). This gives me a very nice result for the terrain but the performance drops with every supplementary layer and pass. How are you doing such multitexturing terrain ? Kind regards, Stefan Maton  Programmer Resources Site http://www.sunamoon.org  
From: James Johnson <James.Johnson@si...>  20020307 07:16:23

This implementation is not entirely efficient. This method test for the point being interior to the triangle, edges are somewhat fuzzy (which I presume you have issue with). However the logic is sound. typ_bool IsPointInTriangle(const typ_Point2i *abc, const typ_Point2i &pt) { typ_bool isInterior = false; typ_Point2i ptEPV[3]; typ_Point2i ptPEV[3]; typ_long sign[3]; ptEPV[0].x = (abc[1].y  abc[0].y); ptEPV[0].y = abc[1].x  abc[0].x; ptEPV[1].x = (abc[2].y  abc[1].y); ptEPV[1].y = abc[2].x  abc[1].x; ptEPV[2].x = (abc[0].y  abc[2].y); ptEPV[2].y = abc[0].x  abc[2].x; ptPEV[0] = abc[0]  pt; ptPEV[1] = abc[1]  pt; ptPEV[2] = abc[2]  pt; sign[0] = ptEPV[0].DotProduct(ptPEV[0]) & 0x80000000; sign[1] = ptEPV[1].DotProduct(ptPEV[1]) & 0x80000000; sign[2] = ptEPV[2].DotProduct(ptPEV[2]) & 0x80000000; isInterior = (sign[0] == sign[1]) && (sign[1] == sign[2]); return isInterior; } James Original Message From: Gribb, Gil To: 'James Johnson '; 'gdalgorithmslist@... ' Sent: 3/6/2002 5:34 PM Subject: RE: [Algorithms] Point in Triangle? >Actually you don't have to perform the real distance to line calculation. Simply calculating the dot of a vector constructed from the point in question to a point on the line is sufficient. This doesn't work, at all. Show me the code and I will provide a counter example (hint a triangle with an interior angle greater than 90 degrees). The below solution is imprecise (what exactly is the signed distance to a line?) but more or less correct if you replace "signed distance to line" with signed distance to a plane containing the edge and not parallel to the triangle plane. Consistently oriented, of course. A hate to pull a Ron, but sheesh people at least take 5 minutes to play with it on paper. Gil on 3/6/02 12:16 PM, gdalgorithmslistrequest@... at <gdalgorithmslistrequest@...> wrote: > what's the fastest/most accurate algorithm to determine whether a point = > is in a triangle? > I don't need to know that for polygons other than triangles. thx If we're talking 3D space then first you have to determine if a point is even in the same plane as the triangle. A simple "distance_to_plane" function can return this: typedef struct GL_V3F_Struct { GLfloat x,y,z; }GL_V3F_Rec,*GL_V3F_Ptr; typedef struct GL_Plane3D_Struct { GL_V3F_Rec o; // origin (any point on the plane) GL_V3F_Rec n; // the normal for this plane }GL_Plane3D_Rec,*GL_Plane3D_Ptr; static __inline__ GL_Plane3D_Rec GLM_SetPlane3D( const GL_V3F_Rec& pVectorA, const GL_V3F_Rec& pVectorB, const GL_V3F_Rec& pVectorC) { GL_Plane3D_Rec plane; plane.o = pVectorA; plane.n = GLM_NormCrossV3F(GLM_SubV3F(pVectorB,pVectorA), GLM_SubV3F(pVectorC,pVectorA)); return plane; } static __inline__ GLfloat GLM_DistanceToPlane3D( const GL_Plane3D_Rec& pPlane,const GL_V3F_Rec& pPoint3D) { return GLM_DotV3F(GLM_SubV3F(pPoint3D,pPlane.o),pPlane.n); } This will return a +/ value where a positive value is on the normal side of the plane and a negative value is on the side opposite the normal. A zero value would be "on the plane" So now that you know it's "on the plane" of the triangle you can do a "distance_to_line" for each edge of your triangle to determine if the point is inside or outside. For a clockwise triangle all the inside points are a positive "distance_to_line" for all edges. Any points on or outside the triangle will have a negitave or zero distance to line.  Enjoy, George Warner, Mixed Mode Magic Fragment Scientist Apple Developer Technical Support (DTS) _______________________________________________ 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...>  20020307 04:45:03

Willmott, Andrew wrote: >> And I could eliminate the two divides from the algorithm at the cost >> of giving up some of the early outs. The tradeoff could be decided by >> whether you'd expect most of the cases to be tested would be inside or >> outside the triangle, and also on whether you'd want to test many >> points against one triangle, since the quantity d depends only on the >> triangle and not on the point. > >You don't have to give up the early outs  just multiply through. Ah yes, of course. What I overlooked in my statement is that you can count on d >=0 since d = u11*u22  u12^2 = W1^2*W2^2  (W1W2cos(ang12))^2 = ( W1*W2)^2*(1  cos^2) and God! how I hate doing algebra in ASCII. Ron 
From: Ron Levine <ron@do...>  20020307 04:03:07

Willmott, Andrew wrote: >There are a number of ways of deriving of this approach, including treating >each triangle bounding line as a halfspace. It's kind of cool how these >different conceptual approaches interrelate. > Right. That coolness is a big part of what Mathematics is all about. Ron 
From: Willmott, Andrew <AWillmott@ma...>  20020307 03:42:49

> And I could eliminate the two divides from the algorithm at the cost > of giving up some of the early outs. The tradeoff could be decided by > whether you'd expect most of the cases to be tested would be inside or > outside the triangle, and also on whether you'd want to test many > points against one triangle, since the quantity d depends only on the > triangle and not on the point. You don't have to give up the early outs  just multiply through. You do have to give up the barycentric coords, which is why I have two versions of this routine, with and without the divide. (You often don't need the barycentric coords if you're just shadow casting, fer instance.) There are a number of ways of deriving of this approach, including treating each triangle bounding line as a halfspace. It's kind of cool how these different conceptual approaches interrelate. A. 
From: Ron Levine <ron@do...>  20020307 03:24:19

Gribb, Gil wrote: >This yeilds an algorithm straight off, and it actually doesn't require any >particular ordering as stated. But ron used a different fact: > >The (signed) area of the "little" triangles _always_ adds up to the (signed) >area of the "big" triangle regardless of the location of the point (with >consistent ordering, of course). You can see this on paper by defining the >signed area to be the area, but negative if the triangle is counter >clockwise. You can verify the statement is true by looking at all 7 cases on >paper. > >Now in order for both statement above to be true, the little triangles must >have different signs for their signed area, only when the point is outside >the triangle. You can also see this directly on paper by trying all 7 cases. > >In light of this final fact, all you need to compute are the signs of the >signed areas of the little triangles and you don't even need the area. You >don't need a divide, you don't need a sqrt to do this. > Actually, neither the words "signed area" nor any pictures of such a thing, ever crossed my mind in deriving the algorithm. Rather I was thinking of "linear dependence", "basis vectors", "dimensionality", and the basic linear properties of the dot product, in writing down the 2x2 linear system whose unknowns happened to be two of the barycentric coordinates of the point with respect to the triangle. These concepts apply equally well in spaces of any dimension. And I could eliminate the two divides from the algorithm at the cost of giving up some of the early outs. The tradeoff could be decided by whether you'd expect most of the cases to be tested would be inside or outside the triangle, and also on whether you'd want to test many points against one triangle, since the quantity d depends only on the triangle and not on the point. Ron 
From: Ron Levine <ron@do...>  20020307 02:08:19

Gribb, Gil wrote: >A hate to pull a Ron, but sheesh people at least take 5 minutes to play with >it on paper. And I would like a little credit, please, for having bitten my tongue and refrained from any comment on the previously proposed solutions, thank you. Ron 
From: Gribb, Gil <ggribb@ra...>  20020307 02:07:56

Well speak of the devil...perfect algorithm sniped. Brief explanation of the algorithm: The astute reader will notice that I have broken down a Cramer's rule solution to a 2x2 linear system, to get the early outs in the cases of noncontainment. The 2x2 linear system is easily derived from elementary vector geometry and elementary linear algebra. The solutions z1, z2, of the 2x2 linear system, together with 1z1z2, are the barycentric coordinates of P with respect to the given triangle. A more visual way to look at it is: Draw your triangle, put the point inside of it. Look at these 3 triangles: v0 v1 p v1 v2 p v2 v0 p these three little triangles make up the big original triangle v0,v1,v2 Now draw another triangle, and put the point outside of it. Look at the 3 "little" triangles for this case: v0 v1 p v1 v2 p v2 v0 p Notice that: Point in triangle iff the (unsigned) area of the three "little" triangles adds up to the area of the big triangle. If the point is outside the triangle then the (unsigned) area of the three little triangles adds up to more than than the area of the big triangle. Easy enough to see on paper doesn't require any algebra or proof. This yeilds an algorithm straight off, and it actually doesn't require any particular ordering as stated. But ron used a different fact: The (signed) area of the "little" triangles _always_ adds up to the (signed) area of the "big" triangle regardless of the location of the point (with consistent ordering, of course). You can see this on paper by defining the signed area to be the area, but negative if the triangle is counter clockwise. You can verify the statement is true by looking at all 7 cases on paper. Now in order for both statement above to be true, the little triangles must have different signs for their signed area, only when the point is outside the triangle. You can also see this directly on paper by trying all 7 cases. In light of this final fact, all you need to compute are the signs of the signed areas of the little triangles and you don't even need the area. You don't need a divide, you don't need a sqrt to do this. ;) Gil 