Ok I think I finally understood how the "intersectCellBoundary" function works.

But could it be, that the *crossStep* and *crossOffset* should be computed after the ray direction was 'normalized'?

I mean instead of this:

// get the cell cross direction and a small offset to enter the next cell when doing cell crossing float2 crossStep = float2(v.x >= 0.0f ? 1.0f : -1.0f, v.y >= 0.0f ? 1.0f : -1.0f); float2 crossOffset = float2(crossStep.xy * HIZ_CROSS_EPSILON.xy); crossStep.xy = saturate(crossStep.xy); // scale vector such that z is 1.0f (maximum depth) float3 d = v.xyz / v.z;

Maybe this?

// scale vector such that z is 1.0f (maximum depth) float3 d = v.xyz / v.z; // get the cell cross direction and a small offset to enter the next cell when doing cell crossing float2 crossStep = float2(d.x >= 0.0f ? 1.0f : -1.0f, d.y >= 0.0f ? 1.0f : -1.0f); float2 crossOffset = float2(crossStep.xy * HIZ_CROSS_EPSILON.xy); crossStep.xy = saturate(crossStep.xy);

Because when v.z is negative, d.x and d.y will be fliped.

I still don't get correct results, but it seems to be more logical for me right now.

**UPDATE:**

I finally found a problem: Currently the ray-marching through the Hi-Z buffer does not work correctly for NPOT (non-power-of-two) resolutions.

With the ray-marching visualization I noticed that the 'cells' where not located correctly.

As you can see in the screenshot below I now use temporarily a resolution of 512x512, where the cells are correct:

I tried to modify the "GetCellCount" function to always have even 'counts':

vec2 GetCellCount(vec2 size, float level) { return floor(size / (level > 0.0 ? exp2(level) : 1.0)); // return size / (level > 0.0 ? exp2(level) : 1.0) ; }

But that didn't work.

And I still have wrong results when the ray dir Z is negative. But I stay tuned :-)

**Edited by LukasBanana, 04 November 2014 - 12:22 PM.**