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:jeffdr@8monkeylabs.com]
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 <smlegg@googlemail.com> 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:diogo.andrade@netvisao.pt]
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:jeffdr@8monkeylabs.com]
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 <diogo.andrade@netvisao.pt> 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
GDAlgorithms-list@lists.sourceforge.net
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
GDAlgorithms-list@lists.sourceforge.net
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