Hi I am implementing a Floating point Cube map in my application and I have run into a small issue. Here is a screenshot: The textures used in this example is in the A32R32G32B32F format. I have tried converting it to a 64 - bit image, with the same result. Maybe I am doing it wrong. So the question is how do you convert an image from A32R32G32B32F to a A16R16G16B16F format, such that I still keep the entire range of information? (not just clamping the range ) Or maybe the problem is else where? Hope to get some answers [smile] [Edited by - thallish on April 11, 2007 8:28:12 AM]

Nudge

Your problem is the black area in the middle of the image?

Given the brightness surrounding it that strikes me as being more likely due to an FP exception than the storage format. Some sort of division by zero generating a +/- INF or NaN code that is being rasterized as 0/black.

Either fetch the texture back and scan for error codes or write a simple test into the shader to output a different colour.

FP32 to FP16 is a precision thing - for the most part they can express the same range, just they will be equivalent rather than equal.

hth
Jack

Hi Jack

Quote:Original post by jollyjeffers
Your problem is the black area in the middle of the image?

yup

Quote:
Given the brightness surrounding it that strikes me as being more likely due to an FP exception than the storage format. Some sort of division by zero generating a +/- INF or NaN code that is being rasterized as 0/black.

Hmmmm oay. I'll see if I can find some information on that

Quote:
Either fetch the texture back and scan for error codes

How do I do that?

Quote:
or write a simple test into the shader to output a different colour.

You mean instead of black? or instead of the skybox? or some thing else?
Hmm I can try to turn of my HDR rendering and see if that produces another result, that would probably help narrow down the problem.

Quote:
FP32 to FP16 is a precision thing - for the most part they can express the same range, just they will be equivalent rather than equal.

Thanks for the answer[wink]

It really does look like every pure white pixel is generating a NaN or something like that. Check if it's a problem with your program or the texture. Open up the texture in an image editor, and see if the black patch is there. If it isn't, then it's a problem with your program.

Remember that FP16 has a max range of about 65000, so if your rendertarget is in a FP16 format, you might have generated an infinity or NaN somewhere in your program.

Quote:Original post by thallish

Quote:
Either fetch the texture back and scan for error codes

How do I do that?

IDirect3DDevice9::GetRenderTargetData() should do the trick. Then iterate through every pixel and see if you can find any erronous values - I forget exactly how to check them, but if you're expecting data to be in (for example) +10...-10 then you can OutputDebugString() on anything that fails such a test.

Quote:Original post by thallish

Quote:
or write a simple test into the shader to output a different colour.

You mean instead of black? or instead of the skybox? or some thing else?

At the end of the shader you can do something like:

if(isnan(colour)) return float4( 1,0,0,1 ); // red
else if( isinf(colour)) return float4( 0,1,0,1 ); // green
else if( isfinite(colour)) return float4( 0,0,1,1); //blue

As mentioned, the rasterizer might output (0,0,0,1) in error conditions but you move the check before this and you can draw a known colour to the frame buffer where the error occurs.

Quote:Original post by thallish
Hmm I can try to turn of my HDR rendering and see if that produces another result, that would probably help narrow down the problem.

Process of elimination can be very useful when debugging shaders.

hth
Jack

Quote:Original post by jollyjeffers

Quote:Original post by thallish

Quote:
or write a simple test into the shader to output a different colour.

You mean instead of black? or instead of the skybox? or some thing else?

At the end of the shader you can do something like:

if(isnan(colour)) return float4( 1,0,0,1 ); // red
else if( isinf(colour)) return float4( 0,1,0,1 ); // green
else if( isfinite(colour)) return float4( 0,0,1,1); //blue

As mentioned, the rasterizer might output (0,0,0,1) in error conditions but you move the check before this and you can draw a known colour to the frame buffer where the error occurs.

Ok I am trying to use those is* functions, but it only result in an compiler error. I am using a float4 as input, which is allowed as far as I can see.

This is the error specification, or lack of should I say:

Microsoft (R) D3D10 Shader Compiler 9.18.904.0013Copyright (C) Microsoft Corporation 2002-2006. All rights reserved.c:\Documents and Settings\S°ren\Desktop\Thesis\Demo\shaders\hdr.fx(458,26): ID3DXEffectCompiler::CompileEffect: There was an error compiling expressionID3DXEffectCompiler: Compilation failedcompilation failed; no code producedProject : error PRJ0019: A tool returned an error code from "Performing Custom Build Step"

Build with this:

fxc.exe /T fx_2_0 /Fc shaders/hdr.txt shaders/hdr.fx

Does it have anything to do with that it is using: 'Microsoft (R) D3D10 Shader Compiler 9.18.904.0013', or is that just the new name, even when I am compiling for DX9?

Update: Well I tried to turn off the HDR rendering and just render the skybox directly onto the backbuffer and that removed the problem completely. So the problem is narrowed down to the HDR pipeline.

I then tried to turn off my bloom and that minimized the problem, so the problem has to be somewhere before that step.

So if I could just get those is* function to work I would be even better off. So any ideas on to how to solve this is very much appreciated.

[Edited by - thallish on April 12, 2007 3:21:55 AM]