Jump to content

  • Log In with Google      Sign In   
  • Create Account

#Actualunbird

Posted 02 June 2013 - 04:37 PM

I haven't explicitly done anything to disable blending, but I do not have a blend state set for the technique to generate the G-buffer. Does this suffice, or is there something else I should do?

The default blend state is opaque, so it should be ok. Although, if you have set another one any time before it will still be active, and you should reset it to NULL in the G-Buffer generation pass.
 

About the normals, I was a bit confused as to what to do about that. I saw different code samples just writing the normals out, and some encoding it. I changed mine to do the encoding just now.

As said, depends on the format. A UNorm format can only store values from 0 to 1, that's why the encode/decode is needed.

I've also changed the sampler to use point sampling. Does this automatically correct for the 0.5 offset, or do I need to do that myself?

It does not correct the offset actually, it just doesn't matter anymore since no interpolation is happening. So yeah, fine.

I noticed a problem which I also fixed, and this seemed to have the most effect on the output. The textures I was rendering to were created with DXGI_FORMAT_R8G8B8A8_UNORM, and I changed that to DXGI_FORMAT_R16G16B16A16_FLOAT, as that is what is needed to hold the G-buffer.

DXGI_FORMAT_R8G8B8A8_UNORM is definitively too low for the position buffer. Since your output smells like there's still a quantization problem, start with full blown 32 bit floats for all buffers until it works and lower the precision only afterwards. This format is also good for debugging (e.g. comparing outputs to full precision). Not sure if this is actually the problem, though, I think your shader is fine. Maybe I give it a shot tomorrow.

Edit: And ninja-ed. Also corrected the link, since this is D3D10.

#2unbird

Posted 02 June 2013 - 04:18 PM

I haven't explicitly done anything to disable blending, but I do not have a blend state set for the technique to generate the G-buffer. Does this suffice, or is there something else I should do?

The default blend state is opaque, so it should be ok. Although, if you have set another one any time before it will still be active, and you should reset it to NULL in the G-Buffer generation pass.
 

About the normals, I was a bit confused as to what to do about that. I saw different code samples just writing the normals out, and some encoding it. I changed mine to do the encoding just now.

As said, depends on the format. A UNorm format can only store values from 0 to 1, that's why the encode/decode is needed.

I've also changed the sampler to use point sampling. Does this automatically correct for the 0.5 offset, or do I need to do that myself?

It does not correct the offset actually, it just doesn't matter anymore since no interpolation is happening. So yeah, fine.

I noticed a problem which I also fixed, and this seemed to have the most effect on the output. The textures I was rendering to were created with DXGI_FORMAT_R8G8B8A8_UNORM, and I changed that to DXGI_FORMAT_R16G16B16A16_FLOAT, as that is what is needed to hold the G-buffer.

DXGI_FORMAT_R8G8B8A8_UNORM is definitively too low for the position buffer. Since your output smells like there's still a quantization problem, start with full blown 32 bit floats for all buffers until it works and lower the precision only afterwards. This format is also good for debugging (e.g. comparing outputs to full precision). Not sure if this is actually the problem, though, I think your shader is fine. Maybe I give it a shot tomorrow.

#1unbird

Posted 02 June 2013 - 04:17 PM

I haven't explicitly done anything to disable blending, but I do not have a blend state set for the technique to generate the G-buffer. Does this suffice, or is there something else I should do?

The default blend state is opaque, so it should be ok. Although, if you have set another one any time before it will still be active, and you should reset set it to NULL in the G-Buffer generation pass.
 

About the normals, I was a bit confused as to what to do about that. I saw different code samples just writing the normals out, and some encoding it. I changed mine to do the encoding just now.

As said, depends on the format. A UNorm format can only store values from 0 to 1, that's why the encode/decode is needed.

I've also changed the sampler to use point sampling. Does this automatically correct for the 0.5 offset, or do I need to do that myself?

It does not correct the offset actually, it just doesn't matter anymore since no interpolation is happening. So yeah, fine.

I noticed a problem which I also fixed, and this seemed to have the most effect on the output. The textures I was rendering to were created with DXGI_FORMAT_R8G8B8A8_UNORM, and I changed that to DXGI_FORMAT_R16G16B16A16_FLOAT, as that is what is needed to hold the G-buffer.

DXGI_FORMAT_R8G8B8A8_UNORM is definitively too low for the position buffer. Since your output smells like there's still a quantization problem, start with full blown 32 bit floats for all buffers until it works and lower the precision only afterwards. This format is also good for debugging (e.g. comparing outputs to full precision). Not sure if this is actually the problem, though, I think your shader is fine. Maybe I give it a shot tomorrow.

PARTNERS