## Re: [Algorithms] Lightmapping method

 Re: [Algorithms] Lightmapping method From: Paul Johnson - 2007-02-23 09:11:24 ```Hmmm, maybe I'm missing something here. When I have a triangle that's basically a near-degenerate sliver at 45 degrees, all it's going to draw is some dots. Fattening up just isn't working for me in those cases. Maybe my UV are off generally, but I don't think so - I've spent time looking at pixel centre issues already. I'm starting to feel like filling the whole rectangle and then using barycentrics to map backwards might be safer. Heh, it'll certainly mask any innacuracies in my texel coord calculations if nothing else :) I'm not sure why you're asking about the need for lerping the normals tbh, as the lumels need an accurate lighting normal after all. =20 Regards, Paul Johnson. =20 Managing Director, Rubicon Mobile, Ltd. http://www.rubiconmobile.com =20 =20 -----Original Message----- From: Jon Watte [mailto:hplus@...]=20 Sent: 23 February 2007 03:21 To: Game Development Algorithms Subject: Re: [Algorithms] Lightmapping method That's actually how it's done. You have to be careful with the gutter=20 around the lit triangle ("fattening" as you call it) and with getting=20 the same light level for the same vertex when matching up neighboring=20 triangles. Making sure you understand the pixel/texel/UV coordinate=20 mapping of your API is important. You can also check out light mappers such as Giles or DeleD, and see=20 what they generate for your geometry. However, if you are using light mapping, what are you using interpolated normals for? Cheers, / h+ Paul at Home wrote: > Hi. I've been trying to get a lightmapping tool working lately and I've come=20 > close but no cigar. It's for standard triangular meshed models. As there=20 > seems to be twenty definitions of lightmapping, mine is a static set of=20 > textures mapped onto my models that directly modulate the original texture=20 > below > > What I've been attempting is to allocate a rectangle of texture space for=20 > each triangle, then fill that in with pixels using a software triangle > scan-converter. The colour of the pixels obviously being my light level.=20 > (Which for now is a simple lambertian mungeing of the normals' y component) > > The problem I have is that the scan-converted triangles don't work as you=20 > can't store sub-pixel accuracy after you've finished with each point. A very=20 > thin sliver is gonna resolve to a line of dots whatever you do. I've tried=20 > various thickening techniques for the plotted triangle but there's always a=20 > case that doesn't work. There's also the issue that I'm interpolating=20 > normals along the edge steppings, so when the edges are "fattened" then the=20 > normals won't quite align and you get seems anyway. > > I've about come to the conclusion that this technique is never going to work=20 > and I'm wasting my time. I'm looking for alternatives if anyone can suggest=20 > any ? > > One thing I thought of was to fill the entire bounding rectangle with=20 > colour. How I'd calculate the colour would be some sort of back projection=20 > onto the plane that the triangle represents, but I'm not sure how I'd then=20 > work out an interpolated normal from that. I'm sure this would work=20 > seamlessly wrt texels always mapping over all the triangle, but I have no=20 > clue what calculation to make for lerping the normals, assuming one is > possible. Some of the point's in the rectangle won't even be over my=20 > triangle! > > Anyone ? Many thanks in advance.... > > Regards, > Paul Johnson. > > Managing Director, > Rubicon Mobile, Ltd. > http://www.rubiconmobile.com > > > ------------------------------------------------------------------------ - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > > =20 ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V _______________________________________________ GDAlgorithms-list mailing list GDAlgorithms-list@... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 ```

 Re: [Algorithms] Lightmapping method From: Paul Johnson - 2007-02-23 09:11:24 ```Hmmm, maybe I'm missing something here. When I have a triangle that's basically a near-degenerate sliver at 45 degrees, all it's going to draw is some dots. Fattening up just isn't working for me in those cases. Maybe my UV are off generally, but I don't think so - I've spent time looking at pixel centre issues already. I'm starting to feel like filling the whole rectangle and then using barycentrics to map backwards might be safer. Heh, it'll certainly mask any innacuracies in my texel coord calculations if nothing else :) I'm not sure why you're asking about the need for lerping the normals tbh, as the lumels need an accurate lighting normal after all. =20 Regards, Paul Johnson. =20 Managing Director, Rubicon Mobile, Ltd. http://www.rubiconmobile.com =20 =20 -----Original Message----- From: Jon Watte [mailto:hplus@...]=20 Sent: 23 February 2007 03:21 To: Game Development Algorithms Subject: Re: [Algorithms] Lightmapping method That's actually how it's done. You have to be careful with the gutter=20 around the lit triangle ("fattening" as you call it) and with getting=20 the same light level for the same vertex when matching up neighboring=20 triangles. Making sure you understand the pixel/texel/UV coordinate=20 mapping of your API is important. You can also check out light mappers such as Giles or DeleD, and see=20 what they generate for your geometry. However, if you are using light mapping, what are you using interpolated normals for? Cheers, / h+ Paul at Home wrote: > Hi. I've been trying to get a lightmapping tool working lately and I've come=20 > close but no cigar. It's for standard triangular meshed models. As there=20 > seems to be twenty definitions of lightmapping, mine is a static set of=20 > textures mapped onto my models that directly modulate the original texture=20 > below > > What I've been attempting is to allocate a rectangle of texture space for=20 > each triangle, then fill that in with pixels using a software triangle > scan-converter. The colour of the pixels obviously being my light level.=20 > (Which for now is a simple lambertian mungeing of the normals' y component) > > The problem I have is that the scan-converted triangles don't work as you=20 > can't store sub-pixel accuracy after you've finished with each point. A very=20 > thin sliver is gonna resolve to a line of dots whatever you do. I've tried=20 > various thickening techniques for the plotted triangle but there's always a=20 > case that doesn't work. There's also the issue that I'm interpolating=20 > normals along the edge steppings, so when the edges are "fattened" then the=20 > normals won't quite align and you get seems anyway. > > I've about come to the conclusion that this technique is never going to work=20 > and I'm wasting my time. I'm looking for alternatives if anyone can suggest=20 > any ? > > One thing I thought of was to fill the entire bounding rectangle with=20 > colour. How I'd calculate the colour would be some sort of back projection=20 > onto the plane that the triangle represents, but I'm not sure how I'd then=20 > work out an interpolated normal from that. I'm sure this would work=20 > seamlessly wrt texels always mapping over all the triangle, but I have no=20 > clue what calculation to make for lerping the normals, assuming one is > possible. Some of the point's in the rectangle won't even be over my=20 > triangle! > > Anyone ? Many thanks in advance.... > > Regards, > Paul Johnson. > > Managing Director, > Rubicon Mobile, Ltd. > http://www.rubiconmobile.com > > > ------------------------------------------------------------------------ - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > > =20 ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V _______________________________________________ GDAlgorithms-list mailing list GDAlgorithms-list@... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 ```
 Re: [Algorithms] Lightmapping method From: Sebastian Sylvan - 2007-02-23 12:54:51 ```On 2/23/07, Paul Johnson wrote: > Hmmm, maybe I'm missing something here. When I have a triangle that's > basically a near-degenerate sliver at 45 degrees, all it's going to draw > is some dots. Fattening up just isn't working for me in those cases. > Maybe my UV are off generally, but I don't think so - I've spent time > looking at pixel centre issues already. > Sounds like you should reconsider your fill convention. In a normal rasterizer you want a fill convention so that adjacent triangles don't fill the same pixels. This means that some triangles will skip certain pixels it covers, so that adjacent triangles can render them instead. This is not what you want for lightmapping. You want to render lighting information for *every* pixel that's even partially covered by your triangle. Adjust your float->int truncations when you generate scanlines. If you're doing it right, you will never get any "dots" for a sliver, you'll always get at least a line. -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ```
 Re: [Algorithms] Lightmapping method From: Jon Watte - 2007-02-24 00:11:02 ``` Paul Johnson wrote: > Hmmm, maybe I'm missing something here. When I have a triangle that's > basically a near-degenerate sliver at 45 degrees, all it's going to draw > is some dots. Fattening up just isn't working for me in those cases. > Maybe my UV are off generally, but I don't think so - I've spent time > looking at pixel centre issues already. > > If you rasterize the triangle as the union of the inside and its edge lines, and then fatten up, you'll get more than a few dots. Mapping backwards can work, too, as you say, but you have to clamp to the nearest point within the triangle. Also make sure to leave enough gutter for MIP mapping. Because of gutters (and other filtering and efficiency reasons), good light mappers will attempt to create as large connected charts as possible for the light maps, btw. Cheers, / h+ ```
 Re: [Algorithms] Lightmapping method From: Paul at Home - 2007-02-24 01:53:15 ```I have the basic idea about rasterising the triangle. I was trying to set a texel box if the line passed anywhere through it as opposed to just the right side of centre. I think I must've had some bugs or alignment issues going on though as even after outline filtering it I still saw the occasional gap or crack. I've switched over to my plan B after someone mentioned barycentric coordinates to me and it all dropped into place. I now run over the entire rectangle, use bary to get the right point/normal on the triangle and bobs your uncle. I appreciate that with care a triangle plotter could/shoud be workable, but this new (to me) method is a lot more robust. I get no seams, no gaps, no anything and the new code took 10 minutes to slot in. Having opened my post with a call for help, I'd now feel confident recommending this method to anyone, if only for its ease of implementation. I didn't clamp those barycentrics btw, which is why it works so well, I think. Sure the accuracy drops off as you start scanning outside the triangle, but this fall-off is linear and gradual and the source normals should all be fairly similar to begin with, so it's not noticeable in practice. Not to me anway. A better still way would probably to switch to the "other" triangle as soon as you pass out of the first one, but so far in my reasonably complicated test case, I don't see anywhere where this refinement is needed - it all looks great as it is :) Good point about using bigger polygons where possible. My current first pass just puts one triangle into a rectangle and is very wasteful. I was thinking about reflections into the 'other' corner to reuse space, but using larger areas to begin with will help there too. I might need to look at my packing routine a bit though so it's not dependent on outer bounding rectangles so much as smaller divisions for "L" shaped polys. One other thing that overscanning back-projection may solve is the differences between renderers. It's been a long time since I did any OGL, but I remember at least at some point the texel offset rules were different to D3D for example. This may of course apply to any other rendering solutions too, so a triangle plotting solution would need to overcompensate for this possibility too ? Regards, Paul Johnson. Managing Director, Rubicon Mobile, Ltd. http://www.rubiconmobile.com ----- Original Message ----- From: "Jon Watte" To: "Game Development Algorithms" Sent: Saturday, February 24, 2007 12:10 AM Subject: Re: [Algorithms] Lightmapping method > > > Paul Johnson wrote: >> Hmmm, maybe I'm missing something here. When I have a triangle that's >> basically a near-degenerate sliver at 45 degrees, all it's going to draw >> is some dots. Fattening up just isn't working for me in those cases. >> Maybe my UV are off generally, but I don't think so - I've spent time >> looking at pixel centre issues already. >> >> > > If you rasterize the triangle as the union of the inside and its edge > lines, and then fatten up, you'll get more than a few dots. Mapping > backwards can work, too, as you say, but you have to clamp to the > nearest point within the triangle. Also make sure to leave enough gutter > for MIP mapping. Because of gutters (and other filtering and efficiency > reasons), good light mappers will attempt to create as large connected > charts as possible for the light maps, btw. > > Cheers, > > / h+ > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > ```
 Re: [Algorithms] Lightmapping method From: Thatcher Ulrich - 2007-02-25 17:14:06 ```On 2/24/07, Paul at Home wrote: > I have the basic idea about rasterising the triangle. I was trying to set a > texel box if the line passed anywhere through it as opposed to just the > right side of centre. I think I must've had some bugs or alignment issues > going on though as even after outline filtering it I still saw the > occasional gap or crack. > > I've switched over to my plan B after someone mentioned barycentric > coordinates to me and it all dropped into place. I now run over the entire > rectangle, use bary to get the right point/normal on the triangle and bobs > your uncle. I appreciate that with care a triangle plotter could/shoud be > workable, but this new (to me) method is a lot more robust. I get no seams, > no gaps, no anything and the new code took 10 minutes to slot in. Having > opened my post with a call for help, I'd now feel confident recommending > this method to anyone, if only for its ease of implementation. > > I didn't clamp those barycentrics btw, which is why it works so well, I > think. Sure the accuracy drops off as you start scanning outside the > triangle, but this fall-off is linear and gradual and the source normals > should all be fairly similar to begin with, so it's not noticeable in > practice. Not to me anway. > > A better still way would probably to switch to the "other" triangle as soon > as you pass out of the first one, but so far in my reasonably complicated > test case, I don't see anywhere where this refinement is needed - it all > looks great as it is :) 1. I'm guessing you're not computing shadows yet. Smooth lighting can hide many fudges in a lightmapper, but shadow edges tend to expose them. 2. If and when you start mapping larger connected pieces of the mesh into one chart (as Jon mentioned), I think you will have problems with your technique, i.e. what do you do with interior edges? What worked for me was an antialiased renderer; i.e. compute exact texel coverage along boundaries. I used an additive blending/precomputed alpha scheme for rendering, so the coverage went into the alpha channel. After the chart was rendered, I bled unfilled texels using nearby filled texels (fattening). And then, divide through by alpha to get the correct final color. This makes interior edges and fattened texels behave pretty well. Another random trick (for the record): on the boundary of a chart, snap vertex mappings to texel centers. -T > Good point about using bigger polygons where possible. My current first pass > just puts one triangle into a rectangle and is very wasteful. I was thinking > about reflections into the 'other' corner to reuse space, but using larger > areas to begin with will help there too. I might need to look at my packing > routine a bit though so it's not dependent on outer bounding rectangles so > much as smaller divisions for "L" shaped polys. > > One other thing that overscanning back-projection may solve is the > differences between renderers. It's been a long time since I did any OGL, > but I remember at least at some point the texel offset rules were different > to D3D for example. This may of course apply to any other rendering > solutions too, so a triangle plotting solution would need to overcompensate > for this possibility too ? > > Regards, > Paul Johnson. > > Managing Director, > Rubicon Mobile, Ltd. > http://www.rubiconmobile.com > > ----- Original Message ----- > From: "Jon Watte" > To: "Game Development Algorithms" > Sent: Saturday, February 24, 2007 12:10 AM > Subject: Re: [Algorithms] Lightmapping method > > > > > > > > Paul Johnson wrote: > >> Hmmm, maybe I'm missing something here. When I have a triangle that's > >> basically a near-degenerate sliver at 45 degrees, all it's going to draw > >> is some dots. Fattening up just isn't working for me in those cases. > >> Maybe my UV are off generally, but I don't think so - I've spent time > >> looking at pixel centre issues already. > >> > >> > > > > If you rasterize the triangle as the union of the inside and its edge > > lines, and then fatten up, you'll get more than a few dots. Mapping > > backwards can work, too, as you say, but you have to clamp to the > > nearest point within the triangle. Also make sure to leave enough gutter > > for MIP mapping. Because of gutters (and other filtering and efficiency > > reasons), good light mappers will attempt to create as large connected > > charts as possible for the light maps, btw. > > > > Cheers, > > > > / h+ > > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share > > your > > opinions on IT & business topics through brief surveys-and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDAlgorithms-list@... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > > > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > ```
 Re: [Algorithms] Lightmapping method From: Paul at Home - 2007-02-25 17:20:02 ```Thanks, I'll bear this in mind. You guessed right about shadows. I've actually started doing that, but I've had to move on to redoing my octree stuff as it was a port from an old engine and there's some bugs in that too! Not a good weekend so far :( Regards, Paul Johnson. Managing Director, Rubicon Mobile, Ltd. http://www.rubiconmobile.com ----- Original Message ----- From: "Thatcher Ulrich" To: "Game Development Algorithms" Sent: Sunday, February 25, 2007 5:13 PM Subject: Re: [Algorithms] Lightmapping method > On 2/24/07, Paul at Home wrote: >> I have the basic idea about rasterising the triangle. I was trying to set >> a >> texel box if the line passed anywhere through it as opposed to just the >> right side of centre. I think I must've had some bugs or alignment issues >> going on though as even after outline filtering it I still saw the >> occasional gap or crack. >> >> I've switched over to my plan B after someone mentioned barycentric >> coordinates to me and it all dropped into place. I now run over the >> entire >> rectangle, use bary to get the right point/normal on the triangle and >> bobs >> your uncle. I appreciate that with care a triangle plotter could/shoud be >> workable, but this new (to me) method is a lot more robust. I get no >> seams, >> no gaps, no anything and the new code took 10 minutes to slot in. Having >> opened my post with a call for help, I'd now feel confident recommending >> this method to anyone, if only for its ease of implementation. >> >> I didn't clamp those barycentrics btw, which is why it works so well, I >> think. Sure the accuracy drops off as you start scanning outside the >> triangle, but this fall-off is linear and gradual and the source normals >> should all be fairly similar to begin with, so it's not noticeable in >> practice. Not to me anway. >> >> A better still way would probably to switch to the "other" triangle as >> soon >> as you pass out of the first one, but so far in my reasonably complicated >> test case, I don't see anywhere where this refinement is needed - it all >> looks great as it is :) > > 1. I'm guessing you're not computing shadows yet. Smooth lighting can > hide many fudges in a lightmapper, but shadow edges tend to expose > them. > > 2. If and when you start mapping larger connected pieces of the mesh > into one chart (as Jon mentioned), I think you will have problems with > your technique, i.e. what do you do with interior edges? > > What worked for me was an antialiased renderer; i.e. compute exact > texel coverage along boundaries. I used an additive > blending/precomputed alpha scheme for rendering, so the coverage went > into the alpha channel. After the chart was rendered, I bled unfilled > texels using nearby filled texels (fattening). And then, divide > through by alpha to get the correct final color. This makes interior > edges and fattened texels behave pretty well. > > Another random trick (for the record): on the boundary of a chart, > snap vertex mappings to texel centers. > > -T > >> Good point about using bigger polygons where possible. My current first >> pass >> just puts one triangle into a rectangle and is very wasteful. I was >> thinking >> about reflections into the 'other' corner to reuse space, but using >> larger >> areas to begin with will help there too. I might need to look at my >> packing >> routine a bit though so it's not dependent on outer bounding rectangles >> so >> much as smaller divisions for "L" shaped polys. >> >> One other thing that overscanning back-projection may solve is the >> differences between renderers. It's been a long time since I did any OGL, >> but I remember at least at some point the texel offset rules were >> different >> to D3D for example. This may of course apply to any other rendering >> solutions too, so a triangle plotting solution would need to >> overcompensate >> for this possibility too ? >> >> Regards, >> Paul Johnson. >> >> Managing Director, >> Rubicon Mobile, Ltd. >> http://www.rubiconmobile.com >> >> ----- Original Message ----- >> From: "Jon Watte" >> To: "Game Development Algorithms" >> >> Sent: Saturday, February 24, 2007 12:10 AM >> Subject: Re: [Algorithms] Lightmapping method >> >> >> > >> > >> > Paul Johnson wrote: >> >> Hmmm, maybe I'm missing something here. When I have a triangle that's >> >> basically a near-degenerate sliver at 45 degrees, all it's going to >> >> draw >> >> is some dots. Fattening up just isn't working for me in those cases. >> >> Maybe my UV are off generally, but I don't think so - I've spent time >> >> looking at pixel centre issues already. >> >> >> >> >> > >> > If you rasterize the triangle as the union of the inside and its edge >> > lines, and then fatten up, you'll get more than a few dots. Mapping >> > backwards can work, too, as you say, but you have to clamp to the >> > nearest point within the triangle. Also make sure to leave enough >> > gutter >> > for MIP mapping. Because of gutters (and other filtering and efficiency >> > reasons), good light mappers will attempt to create as large connected >> > charts as possible for the light maps, btw. >> > >> > Cheers, >> > >> > / h+ >> > >> > >> > ------------------------------------------------------------------------- >> > Take Surveys. Earn Cash. Influence the Future of IT >> > Join SourceForge.net's Techsay panel and you'll get the chance to share >> > your >> > opinions on IT & business topics through brief surveys-and earn cash >> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> > _______________________________________________ >> > GDAlgorithms-list mailing list >> > GDAlgorithms-list@... >> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> > Archives: >> > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >> > >> > >> > >> > >> >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share >> your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> GDAlgorithms-list mailing list >> GDAlgorithms-list@... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >> >> > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > ```