Render To Texture: Z-Buffer Error using DirectX 9 driver

[davex]

Hello,

I'm trying to create a night vision camera effect. I want to have a small image on the hud that shows the scene from the current camera but using a different set of models (with some heat vision textures on them).

I have more or less managed this by following the render to texture tutorial. Only problem is that when I render my scene (with the night vision textures on) to the texture the z-ordering is all wrong This only seems to happen using the DirectX 9 driver (which is my prefered choice).

Is this a known problem? Is there a work around? Should I post huge amounts of source code?

Thanks for any help or tips

[hybrid]

We have had some bug fixes for such a problem in the 1.6 branch. This was due to wrong anti-aliasing settings in the render target. You might want to check out the SVN branch for the 1.6 release, or wait some more time for the official release.

[robmar]

Does this problem still exist in 1.7.3? Rendering objects based on depth I'm seeing a fine splattering of pixels with major depth errors which change as I pan the scene.

[hybrid]

Maybe you just have some standard z-fighting occuring? This problem has been so vague that we cannot say anything about whether there even was a real problem inside Irrlicht or not.

[robmar]

Yes sorry, I´ve been pulling my hair out over this one, but now have it fixed. It was soooo painful!

There were multiple problems which made the whole thing appear very confusing.

I had to simplify everything in my code, and work up from the ground up very slowly.

Using ARGB8 depth buffer, 8-bits of depth caused quite large changes in depth across objects´ surfaces - I had to check each pixel value to find that.

So I tried to the f16r texture, and that solved it. I was pleased to see that the float texture, just 16-bits on R, worked well.

Is there any performance hit on using f16r over argb8? I guess that the stream processors or whatever they are called work first in floating point, and in some case emulate integer math, or so I read, and that only PS-4 has true integer processor instructions.

The next problem was that the HLSL PS-3 compiler refused to recognise "break". Grantye kindly told me that the compile flag for HLSL in Irrlicht for branching was disabled, though yet to find that.

For now I worked around setting the for loop counter high to break.

Then, the most frustrating, was that the "%" modulos operator in HLSL does not, unless I got that wrong too, work the same as it does in VS C++!

That really caused me a headache... I have no debugger for HLSL DX9, I read that the PIX debugger with the Windows 2007 SDK works on Windows 7 for HLSL debugging, will give that a go soon.

So I changed to use the fmod function with round, and the math in my shader started working!

Halleluiah! What a set of headaches but now the depth display of the fish in my virtual aquarium works! Makes me realize that my brain is at times full of mud, and that the five Ps are very important: Planning Prevents Pathetically Poor Performance!

Any news on the DX10/11 driver, then debugging would be a little easier!

I would go for Mantle really, but with only a 23% speed improvement so said, is it worth it?