gdalgorithms-list

Re: [Algorithms] Decals and deferred rendering

[Jeff R. <je...@8m...>]

My vote would be for drawing them into the G-buffer - proper lighting and
compositing are important. Depending on what you're storing, blending may
not actually be that bad (even if the blending math is not completely
correct, it may still look ok, you'd be surprised). Also some newer fancier
graphics APIs allow you to set separate blending functions for each render
target output, if that helps. And there's always alpha test.

-- 
Jeff Russell
Engineer, 8monkey Labs
www.8monkeylabs.com

Re: [Algorithms] Decals and deferred rendering

[Megan F. <sha...@gm...>]

I'd also suggest G-Buffer, including blending.  As far as the diffuse
channel of the G-Buffer goes, the results will always be right (since
decals are one of the few cases where you can guarantee sorting / not
require depth peeling / etc), and as far as any lighting parameters,
it "should" read right so long as the lighting parameters of your
decal aren't grossly different from the surface being decalled.

... but for that reason, you would need to reign in your decals and
keep them reasonable.  A high-specular shiny decal thrown onto a
low-specular muddy wall would look silly indeed unless it was
hard-edged, given that the lighting properties will be entirely
hard-edged.

I'd wonder, though, if you couldn't mask the edge with a bit of
alpha-blending even on those properties?  So long as you're not
changing any of the values that are rigid (ie. specular mul is
probably safe, but any ID-buffer-esque data is not), you'd be able to
mask the edges pretty nicely with the blend.  So, again, you're
seemingly safe so long as the lighting properties of your decal aren't
grossly removed from that of the surface.

Just depends what kind of game you're doing, really.  Personally, I'd
just make sure the decals matched, since that'd probably look better
period, and bake them into the G-Buffer to allow the much-improved
lighting, AO et al they'd get that way.

-- 
Megan Fox
http://www.shalinor.com/

Re: [Algorithms] Decals and deferred rendering

[Diogo de A. <dio...@ne...>]

Hi all,

I'm not sure I understood what you and Jeff are recommending, to be
honest...

Clarifying:

I start rendering to the G-Buffer... I have the buffers organized like this:

Rt0.xyz=normal (world space)
Rt0.w=depth (0..1 normalized)
Rt1.xyz=albedo
Rt1.w=ambient intensity
Rt2.x=specular intensity
Rt2.y=specular gloss
Rt2.z=diffuse intensity
Rt2.w=emissive intensity
Rt3.xyz=position (world space)
Rt3.w=unused

Let's imagine I have a maze... I render all walls to these buffers, and now
it's time to render the decals themselves.

With the G-Buffer still as the rendertarget, I draw the geometry that makes
up the decals (obtained through intersection of the world geometry with the
decal frustum)...
Now, the part I don't understand is how to achieve blending (which would be
sweet), without having the G-Buffer simultaneously as a render target and as
input texture (which I think is not allowed under the majority of the
videocards). If I could have that, I'd be able to do whatever I wanted in
the way of blending and such...
To be honest, now that I think about it, I'm not even seeing how I can make
a shader to render the decal in a way it only influences the albedo, even if
it is a simple replace, without using colorwrite masks (which I didn't want
to use because they makes me have to switch states). What I'm trying to
achieve (but may be impossible) is to have a "decal sheet", which has all
the decals, so that with a single draw I can get all decals up... not sure
if that's possible...

Thanks all,

Diogo

Re: [Algorithms] Decals and deferred rendering

[Jeff R. <je...@8m...>]

Well, since its a decal, you shouldn't need to use Rt3 as output (you're not
modifying positions of anything, just painting new material properties over
the existing geometry). So maybe we confused the terms, I was recommending
you render into albedo, normal, specular, etc. but not position.

Jeff

On Wed, Jan 13, 2010 at 11:14 AM, Diogo de Andrade <
dio...@ne...> wrote:

> Hi all,
>
> I'm not sure I understood what you and Jeff are recommending, to be
> honest...
>
> Clarifying:
>
> I start rendering to the G-Buffer... I have the buffers organized like
> this:
>
> Rt0.xyz=normal (world space)
> Rt0.w=depth (0..1 normalized)
> Rt1.xyz=albedo
> Rt1.w=ambient intensity
> Rt2.x=specular intensity
> Rt2.y=specular gloss
> Rt2.z=diffuse intensity
> Rt2.w=emissive intensity
> Rt3.xyz=position (world space)
> Rt3.w=unused
>
> Let's imagine I have a maze... I render all walls to these buffers, and now
> it's time to render the decals themselves.
>
> With the G-Buffer still as the rendertarget, I draw the geometry that makes
> up the decals (obtained through intersection of the world geometry with the
> decal frustum)...
> Now, the part I don't understand is how to achieve blending (which would be
> sweet), without having the G-Buffer simultaneously as a render target and
> as
> input texture (which I think is not allowed under the majority of the
> videocards). If I could have that, I'd be able to do whatever I wanted in
> the way of blending and such...
> To be honest, now that I think about it, I'm not even seeing how I can make
> a shader to render the decal in a way it only influences the albedo, even
> if
> it is a simple replace, without using colorwrite masks (which I didn't want
> to use because they makes me have to switch states). What I'm trying to
> achieve (but may be impossible) is to have a "decal sheet", which has all
> the decals, so that with a single draw I can get all decals up... not sure
> if that's possible...
>
> Thanks all,
>
> Diogo
>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>



-- 
Jeff Russell
Engineer, 8monkey Labs
www.8monkeylabs.com

Re: [Algorithms] Decals and deferred rendering

[Diogo de A. <dio...@ne...>]

Ehehe, I didn't explain myself too well. J

 

Let's imagine I just need to do an albedo change, and I want to do it with
blending (as you suggested, if I recal).

 

I'd get a pixel shader something like:

 

float4 decal_pixel_shader(INPUT_DATA in)

{

     float4 source_color=tex2D(rt1,in.uv_screen);

     float4 decal_color=tex2D(decal_texture,in.uv_decal);

     return float4(decal_color.xyz* decal_color.a+rt1.xyz*(1-decal_color.a);

}

 

So I need to use rt1 as both input and output, and I think that's a no-no in
a modern video card. So I fail to see how can I do blending operations on
the G-Buffer.

 

Diogo

 

From: Jeff Russell [mailto:je...@8m...] 
Sent: quarta-feira, 13 de Janeiro de 2010 17:20
To: Game Development Algorithms
Subject: Re: [Algorithms] Decals and deferred rendering

 

Well, since its a decal, you shouldn't need to use Rt3 as output (you're not
modifying positions of anything, just painting new material properties over
the existing geometry). So maybe we confused the terms, I was recommending
you render into albedo, normal, specular, etc. but not position.

Jeff

On Wed, Jan 13, 2010 at 11:14 AM, Diogo de Andrade
<dio...@ne...> wrote:

Hi all,

I'm not sure I understood what you and Jeff are recommending, to be
honest...

Clarifying:

I start rendering to the G-Buffer... I have the buffers organized like this:

Rt0.xyz=normal (world space)
Rt0.w=depth (0..1 normalized)
Rt1.xyz=albedo
Rt1.w=ambient intensity
Rt2.x=specular intensity
Rt2.y=specular gloss
Rt2.z=diffuse intensity
Rt2.w=emissive intensity
Rt3.xyz=position (world space)
Rt3.w=unused

Let's imagine I have a maze... I render all walls to these buffers, and now
it's time to render the decals themselves.

With the G-Buffer still as the rendertarget, I draw the geometry that makes
up the decals (obtained through intersection of the world geometry with the
decal frustum)...
Now, the part I don't understand is how to achieve blending (which would be
sweet), without having the G-Buffer simultaneously as a render target and as
input texture (which I think is not allowed under the majority of the
videocards). If I could have that, I'd be able to do whatever I wanted in
the way of blending and such...
To be honest, now that I think about it, I'm not even seeing how I can make
a shader to render the decal in a way it only influences the albedo, even if
it is a simple replace, without using colorwrite masks (which I didn't want
to use because they makes me have to switch states). What I'm trying to
achieve (but may be impossible) is to have a "decal sheet", which has all
the decals, so that with a single draw I can get all decals up... not sure
if that's possible...

Thanks all,

Diogo



----------------------------------------------------------------------------
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list




-- 
Jeff Russell
Engineer, 8monkey Labs
www.8monkeylabs.com

Re: [Algorithms] Decals and deferred rendering

[Steve L. <sm...@go...>]

Why can't you use alphablending for this?  If you are worried that you need
to leave the alpha channel untouched then you can either use
D3DRS_COLORWRITEENABLE to write to just the RGB channels, or you could use
D3DRS_SEPARATEALPHABLENDENABLE and set the alpha blend mode to ZERO/ONE/ADD.

 

From: Diogo de Andrade [mailto:dio...@ne...] 
Sent: 13 January 2010 5:56pm
To: 'Game Development Algorithms'
Subject: Re: [Algorithms] Decals and deferred rendering

 

Ehehe, I didn't explain myself too well. J

 

Let's imagine I just need to do an albedo change, and I want to do it with
blending (as you suggested, if I recal).

 

I'd get a pixel shader something like:

 

float4 decal_pixel_shader(INPUT_DATA in)

{

     float4 source_color=tex2D(rt1,in.uv_screen);

     float4 decal_color=tex2D(decal_texture,in.uv_decal);

     return float4(decal_color.xyz* decal_color.a+rt1.xyz*(1-decal_color.a);

}

 

So I need to use rt1 as both input and output, and I think that's a no-no in
a modern video card. So I fail to see how can I do blending operations on
the G-Buffer.

 

Diogo

 

From: Jeff Russell [mailto:je...@8m...] 
Sent: quarta-feira, 13 de Janeiro de 2010 17:20
To: Game Development Algorithms
Subject: Re: [Algorithms] Decals and deferred rendering

 

Well, since its a decal, you shouldn't need to use Rt3 as output (you're not
modifying positions of anything, just painting new material properties over
the existing geometry). So maybe we confused the terms, I was recommending
you render into albedo, normal, specular, etc. but not position.

Jeff

On Wed, Jan 13, 2010 at 11:14 AM, Diogo de Andrade
<dio...@ne...> wrote:

Hi all,

I'm not sure I understood what you and Jeff are recommending, to be
honest...

Clarifying:

I start rendering to the G-Buffer... I have the buffers organized like this:

Rt0.xyz=normal (world space)
Rt0.w=depth (0..1 normalized)
Rt1.xyz=albedo
Rt1.w=ambient intensity
Rt2.x=specular intensity
Rt2.y=specular gloss
Rt2.z=diffuse intensity
Rt2.w=emissive intensity
Rt3.xyz=position (world space)
Rt3.w=unused

Let's imagine I have a maze... I render all walls to these buffers, and now
it's time to render the decals themselves.

With the G-Buffer still as the rendertarget, I draw the geometry that makes
up the decals (obtained through intersection of the world geometry with the
decal frustum)...
Now, the part I don't understand is how to achieve blending (which would be
sweet), without having the G-Buffer simultaneously as a render target and as
input texture (which I think is not allowed under the majority of the
videocards). If I could have that, I'd be able to do whatever I wanted in
the way of blending and such...
To be honest, now that I think about it, I'm not even seeing how I can make
a shader to render the decal in a way it only influences the albedo, even if
it is a simple replace, without using colorwrite masks (which I didn't want
to use because they makes me have to switch states). What I'm trying to
achieve (but may be impossible) is to have a "decal sheet", which has all
the decals, so that with a single draw I can get all decals up... not sure
if that's possible...

Thanks all,

Diogo



----------------------------------------------------------------------------
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list




-- 
Jeff Russell
Engineer, 8monkey Labs
www.8monkeylabs.com

Re: [Algorithms] Decals and deferred rendering

[Jeff R. <je...@8m...>]

Yes, use alpha blending (this is not done in the shader, but instead as
Steve described). You are right that you can't read and write the same
texture in a shader, but you don't need to. It's done in the output merger
stage, which runs after your pixel shader.

Jeff

On Wed, Jan 13, 2010 at 12:04 PM, Steve Legg <sm...@go...> wrote:

>  Why can’t you use alphablending for this?  If you are worried that you
> need to leave the alpha channel untouched then you can either use
> D3DRS_COLORWRITEENABLE to write to just the RGB channels, or you could use
> D3DRS_SEPARATEALPHABLENDENABLE and set the alpha blend mode to ZERO/ONE/ADD.
>
>
>
> *From:* Diogo de Andrade [mailto:dio...@ne...]
> *Sent:* 13 January 2010 5:56pm
>
> *To:* 'Game Development Algorithms'
> *Subject:* Re: [Algorithms] Decals and deferred rendering
>
>
>
> Ehehe, I didn’t explain myself too well… J
>
>
>
> Let’s imagine I just need to do an albedo change, and I want to do it with
> blending (as you suggested, if I recal)…
>
>
>
> I’d get a pixel shader something like:
>
>
>
> float4 decal_pixel_shader(INPUT_DATA in)
>
> {
>
>      float4 source_color=tex2D(rt1,in.uv_screen);
>
>      float4 decal_color=tex2D(decal_texture,in.uv_decal);
>
>      return float4(decal_color.xyz*
> decal_color.a+rt1.xyz*(1-decal_color.a);
>
> }
>
>
>
> So I need to use rt1 as both input and output, and I think that’s a no-no
> in a modern video card… So I fail to see how can I do blending operations on
> the G-Buffer…
>
>
>
> Diogo
>
>
>
> *From:* Jeff Russell [mailto:je...@8m...]
> *Sent:* quarta-feira, 13 de Janeiro de 2010 17:20
> *To:* Game Development Algorithms
> *Subject:* Re: [Algorithms] Decals and deferred rendering
>
>
>
> Well, since its a decal, you shouldn't need to use Rt3 as output (you're
> not modifying positions of anything, just painting new material properties
> over the existing geometry). So maybe we confused the terms, I was
> recommending you render into albedo, normal, specular, etc. but not
> position.
>
> Jeff
>
> On Wed, Jan 13, 2010 at 11:14 AM, Diogo de Andrade <
> dio...@ne...> wrote:
>
> Hi all,
>
> I'm not sure I understood what you and Jeff are recommending, to be
> honest...
>
> Clarifying:
>
> I start rendering to the G-Buffer... I have the buffers organized like
> this:
>
> Rt0.xyz=normal (world space)
> Rt0.w=depth (0..1 normalized)
> Rt1.xyz=albedo
> Rt1.w=ambient intensity
> Rt2.x=specular intensity
> Rt2.y=specular gloss
> Rt2.z=diffuse intensity
> Rt2.w=emissive intensity
> Rt3.xyz=position (world space)
> Rt3.w=unused
>
> Let's imagine I have a maze... I render all walls to these buffers, and now
> it's time to render the decals themselves.
>
> With the G-Buffer still as the rendertarget, I draw the geometry that makes
> up the decals (obtained through intersection of the world geometry with the
> decal frustum)...
> Now, the part I don't understand is how to achieve blending (which would be
> sweet), without having the G-Buffer simultaneously as a render target and
> as
> input texture (which I think is not allowed under the majority of the
> videocards). If I could have that, I'd be able to do whatever I wanted in
> the way of blending and such...
> To be honest, now that I think about it, I'm not even seeing how I can make
> a shader to render the decal in a way it only influences the albedo, even
> if
> it is a simple replace, without using colorwrite masks (which I didn't want
> to use because they makes me have to switch states). What I'm trying to
> achieve (but may be impossible) is to have a "decal sheet", which has all
> the decals, so that with a single draw I can get all decals up... not sure
> if that's possible...
>
> Thanks all,
>
> Diogo
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>
>
>
>
> --
> Jeff Russell
> Engineer, 8monkey Labs
> www.8monkeylabs.com
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>



-- 
Jeff Russell
Engineer, 8monkey Labs
www.8monkeylabs.com

Re: [Algorithms] Decals and deferred rendering

[Diogo de A. <dio...@ne...>]

Doh. I forgot about the D3DRS_SEPARATEALPHABLENDENABLE state, and while
looking it up I found the COLORWRITEENABLE1..4 which I never saw before...

So, ok, I can mask and apply operation on all the channels pretty well,
which kind of makes the G-Buffer approach the most interesting for all sorts
of reasons (can already smell particle systems in the G-Buffer aswell, for
lit particles...).

 

The only final issue is how to manage the system itself... Since we're on
topic, I'm thinking of writing a small tool that grabs a text definition of
a series of decal types and builds the shaders and renderstates for it,
something akin to:

 

Operations= { none, replace, replace_alpha, mul, mul_alpha, add, sub..... }

 

decal_type="bullet_hole"

{

color=mul_alpha

normal=replace

ambient=none

diffuse=none

specular_power=replace

specular_gloss=replace

emissive=replace

}

 

Decal_type="footprints_muddy"

{

            color=none

            normal=replace_alpha

            ambient=none

diffuse=none

specular_power=none

specular_gloss=none

emissive=none

}

 

Decal_type="footprints_dusty"

{

            color=mul_alpha

            normal=none

            ambient=none

diffuse=none

specular_power=none

specular_gloss=none

emissive=none

}

 

Decal_type="plasma_residue"

{

            color=replace

            normal=none

            ambient=none

diffuse=none

specular_power=none

specular_gloss=none

emissive=replace

}

 

Something like this... this assumes that the definition of the decal itself
contains enough data for the diffuse, normal, etc... I was thinking on using
a kind of "decal sheet" to minimize texture switches. Each decal sheet would
contain basically 3 textures (of which some could be NULL): diffuse (rgba),
normal (xyz), specular_power (x), specular_gloss (y), emissive (z). (to be
honest, I can't see the point of changing the ambient and/or the diffuse
components at this time on a decal). Besides the 3 textures, we would need
of course texture coordinates for each of the decals on the sheet.

 

Then, I'd only need one draw per decal type/decal sheet, which doesn't seem
like too bad, especially considering we can probably typify the decal types
so they aren't as specific as the above examples...

 

So, any ideas and/or suggestions?

Diogo

 

From: Jeff Russell [mailto:je...@8m...] 
Sent: quarta-feira, 13 de Janeiro de 2010 18:21
To: Game Development Algorithms
Subject: Re: [Algorithms] Decals and deferred rendering

 

Yes, use alpha blending (this is not done in the shader, but instead as
Steve described). You are right that you can't read and write the same
texture in a shader, but you don't need to. It's done in the output merger
stage, which runs after your pixel shader.

Jeff

On Wed, Jan 13, 2010 at 12:04 PM, Steve Legg <sm...@go...> wrote:

Why can't you use alphablending for this?  If you are worried that you need
to leave the alpha channel untouched then you can either use
D3DRS_COLORWRITEENABLE to write to just the RGB channels, or you could use
D3DRS_SEPARATEALPHABLENDENABLE and set the alpha blend mode to ZERO/ONE/ADD.

 

From: Diogo de Andrade [mailto:dio...@ne...] 
Sent: 13 January 2010 5:56pm


To: 'Game Development Algorithms'
Subject: Re: [Algorithms] Decals and deferred rendering

 

Ehehe, I didn't explain myself too well. J

 

Let's imagine I just need to do an albedo change, and I want to do it with
blending (as you suggested, if I recal).

 

I'd get a pixel shader something like:

 

float4 decal_pixel_shader(INPUT_DATA in)

{

     float4 source_color=tex2D(rt1,in.uv_screen);

     float4 decal_color=tex2D(decal_texture,in.uv_decal);

     return float4(decal_color.xyz* decal_color.a+rt1.xyz*(1-decal_color.a);

}

 

So I need to use rt1 as both input and output, and I think that's a no-no in
a modern video card. So I fail to see how can I do blending operations on
the G-Buffer.

 

Diogo

 

From: Jeff Russell [mailto:je...@8m...] 
Sent: quarta-feira, 13 de Janeiro de 2010 17:20
To: Game Development Algorithms
Subject: Re: [Algorithms] Decals and deferred rendering

 

Well, since its a decal, you shouldn't need to use Rt3 as output (you're not
modifying positions of anything, just painting new material properties over
the existing geometry). So maybe we confused the terms, I was recommending
you render into albedo, normal, specular, etc. but not position.

Jeff

On Wed, Jan 13, 2010 at 11:14 AM, Diogo de Andrade
<dio...@ne...> wrote:

Hi all,

I'm not sure I understood what you and Jeff are recommending, to be
honest...

Clarifying:

I start rendering to the G-Buffer... I have the buffers organized like this:

Rt0.xyz=normal (world space)
Rt0.w=depth (0..1 normalized)
Rt1.xyz=albedo
Rt1.w=ambient intensity
Rt2.x=specular intensity
Rt2.y=specular gloss
Rt2.z=diffuse intensity
Rt2.w=emissive intensity
Rt3.xyz=position (world space)
Rt3.w=unused

Let's imagine I have a maze... I render all walls to these buffers, and now
it's time to render the decals themselves.

With the G-Buffer still as the rendertarget, I draw the geometry that makes
up the decals (obtained through intersection of the world geometry with the
decal frustum)...
Now, the part I don't understand is how to achieve blending (which would be
sweet), without having the G-Buffer simultaneously as a render target and as
input texture (which I think is not allowed under the majority of the
videocards). If I could have that, I'd be able to do whatever I wanted in
the way of blending and such...
To be honest, now that I think about it, I'm not even seeing how I can make
a shader to render the decal in a way it only influences the albedo, even if
it is a simple replace, without using colorwrite masks (which I didn't want
to use because they makes me have to switch states). What I'm trying to
achieve (but may be impossible) is to have a "decal sheet", which has all
the decals, so that with a single draw I can get all decals up... not sure
if that's possible...

Thanks all,

Diogo



----------------------------------------------------------------------------
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list




-- 
Jeff Russell
Engineer, 8monkey Labs
www.8monkeylabs.com


----------------------------------------------------------------------------
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list




-- 
Jeff Russell
Engineer, 8monkey Labs
www.8monkeylabs.com