Re: [Algorithms] Decals and deferred rendering
Brought to you by:
vexxed72
Menu
▾
▴
Re: [Algorithms] Decals and deferred rendering
|
From: Diogo de A. <dio...@ne...> - 2010-01-14 09:34:38
|
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
|
