Hi Lukas,

Glad to see there are still a few readers on this thread :). I was actually able to get the code working to walk behind objects using the min/max version of the Hi-Z buffer. There are still a few issues that can creep up when a ray simply doesn't have the data at its endpoint, but my solution solved for a great deal of missing data (screenshots below).

You're right, in the book the author mentions only using the min version, but then obviously uses the min/max variant in the implementation snippets provided. So when you're building out your Hi-Z buffer, you simply want to to track both the minimum and maximum values, and return something like (it sounds like you're doing this correctly, but for the sake of future readers):

return float2(
	min(min(minDepth.r, minDepth.g), min(minDepth.b, minDepth.a)),
	max(max(maxDepth.r, maxDepth.g), max(maxDepth.b, maxDepth.a)));

And then you make a few small updates to the ray tracing step, namely:

// note that this now returns a float2 and samples both the red and green components
float2 getMinimumDepthPlane(float2 ray, float level)
{
	return hiZBuffer.Load(int3(ray.xy, level)).rg;
}

and in the main ray-tracing loop, you update it like so:

// above as before

float2 zminmax = getMinimumDepthPlane(oldCellIdx, level);
		
// intersect only if ray depth is between the minimum and maximum depth planes
float3 tmpRay = intersectDepthPlane(o, d, min(max(ray.z, zminmax.r), zminmax.g));

// below as before

In regards to the visibility buffer, I actually ended up going with what the book provided. When I looked at the results of the visibility buffer in Visual Studio Graphics Debugger, RenderDoc, or NSight, I was seeing a lot of artifacts using the suggested updates. Your mileage may vary, but the provided implementation is what I recommend starting with.

Below are two screenshots, the first is before the code to walk behind objects was added (notice the large empty space between the soldiers hand and foot where rays were incorrectly being blocked) and the second is after the code was added. Like I said, you may still see a few ray misses with the code present, but they are generally due to actual data missing due to occlusion, rather than incorrect hits.

Before: https://www.dropbox.com/s/9nj523ieryvfb7a/screenshot_31.png?dl=0

After: https://www.dropbox.com/s/l245n2lpwwreihw/screenshot_32.png?dl=0

Thanks,

WFP

Hi Lukas,

The way I handled rays that point back towards the camera is simply to disallow them. This is one of the concessions I made in trying to keep my sanity in tact while battling some of the artifacts I was getting with the effect initially. Probably a better approach (and one I may revisit in the future) would be to fade the effect, where a ray pointing directly back at the camera would have zero contribution, and rays pointing almost perpendicular to the look vector but still pointing backwards slightly would only be faded a little. Then blend the faded result with your fallback method (local cubemaps, etc.).

Below is what I currently use to lop off rays pointing back to the camera

float3 reflectVS = reflect(toPositionVS, normalVS);
// reject pixels pointing back to camera - update to fade instead of outright cutoff
float rDotV = saturate(dot(reflectVS, toPositionVS));
if(rDotV < 0.1f)
{
	return 0.0f;
}

With that in place, a situation where viewPos.z + viewReflect.z <= 0 shouldn't be possible. A potentially better approach would be something like below (untested):

float3 reflectVS = reflect(toPositionVS, normalVS);
//fade pixels fading back
float rDotV = dot(reflectVS, toPositionVS);
float fade = 0.0f;
if(rDotV < 0.0f)
{
    // when rDotV is -1.0f, fade completely, else interpolate to no fade as ray becomes perpendicular
    fade = lerp(0.0f, 1.0f, abs(rDotV));
}

If you go that route, you would want to hold off applying the fade until after the ray-marching loop - in other words, you need something to apply the fade to - as opposed to the way I do now and use it as an early exit.

Let me know if you have any questions or if I missed something.

Thanks,

WFP

Hi Lukas,

Glad you got the first issue taken care of.

The reason to use oldCellIdx is because newCellIdx could be too far of a jump (probably what you're seeing when you say it looks worse). newCellIdx not being equal to oldCellIdx simply tells you that you need to in fact keep moving a long the ray, but you send oldCellIdx to intersectCellBoundary so you don't trace too far in one jump and miss something.

As far as HIZ_CROSS_EPSILON goes, remember that I'm using texel width and height, not texture width and height. In other words, I'm using the equivalent of:

static const float2 HIZ_CROSS_EPSILON = float2(1.0f / textureWidth, 1.0f / textureHeight);

But it turns out that even that was too large of a step in many cases. I've found the below to give a good result:

static const float2 HIZ_CROSS_EPSILON = float2(texelWidth, texelHeight) * 0.5f; // just needs to make sure in the next pixel, not skipping them entirely

You're right, you do want it to be a small value - in fact, it needs to be just enough to ensure you're in the next pixel along the ray.

Hope that helps and let me know if you have any more questions.

Thanks,

WFP

Hi Lukas, I was also very annoyed that the case where the z components approaches zero fails. I worked around it by changing the algo a bit on my side. I just simply advance the ray from it's current position in the ray without starting at the 'o' position which was reprojected in the near clipping plane (which requires the division by the z component). I also handle raymarching backwards with only the min h-zi structure (i.e. supporting negative z components of a reflection rays). Heres a code snippet.

float3 intersectDepthPlane(float3 o, float3 d, float t)
{
	return o + d * t;
}

float3 advanceRay(float3 o, float3 d, float t)
{
	if(d.z > 0) {
		d /= abs(d.z);
		return o + d * t;
	} else {
		return o;
	}
}

float1 level = HIZ_START_LEVEL;
float2 hiZSize = getCellCount(level);

float3 ray = p.xyz;
float3 d = v;

float1 cross_epsilon = ((1.0 / 512.0) / 2.0) * ssr_cross_threshold * 0.01;
float2 cross_step = float2(d.x >= 0.0f ? 1.0f : -1.0f, d.y >= 0.0f ? 1.0f : -1.0f);
float2 cross_offset = float2(cross_step.xy) * cross_epsilon;
cross_step.xy = saturate(cross_step.xy);

float2 rayCell = getCell(ray.xy, hiZSize.xy);
ray = intersectCellBoundary(ray, d, rayCell, hiZSize.xy, cross_step.xy, cross_offset.xy);

// =======================================================================================
// RAY-MARCHING - RAY-MARCHING - RAY-MARCHING - RAY-MARCHING - RAY-MARCHING - RAY-MARCHING
// RAY-MARCHING - RAY-MARCHING - RAY-MARCHING - RAY-MARCHING - RAY-MARCHING - RAY-MARCHING

float min_z;
int iterations = 0;
while(level >= HIZ_STOP_LEVEL && iterations < MAX_ITERATIONS)
{
	// get the minimum depth plane in which the current ray resides
	min_z = getMinimumDepthPlane(ray.xy, level);
	float max_z = getMaximumDepthPlane(ray.xy, level);

	// get the cell number of the current ray
	float2 cell_count = getCellCount(level);
	float2 old_cell_id = getCell(ray.xy, cell_count);

	// intersect only if ray depth is below the minimum depth plane
	float3 debug_point_color = float3(0,0,0);
	float3 tmp_ray = ray;

	[branch]
	if(v.z > 0) {
		if((min_z - ray.z) > 0){
			tmp_ray = advanceRay(ray, d, min_z-ray.z);
		}
		float2 new_cell_id = getCell(tmp_ray.xy, cell_count);
		if(crossedCellBoundary(old_cell_id, new_cell_id)){
			tmp_ray = intersectCellBoundary(ray, d, old_cell_id, cell_count.xy, cross_step.xy, cross_offset.xy);
			level = min(HIZ_MAX_LEVEL, level + 2.0f);
		}

	}
	else{
		if(ray.z < min_z) {
			tmp_ray = intersectCellBoundary(ray, d, old_cell_id, cell_count.xy, cross_step.xy, cross_offset.xy);
			level = min(HIZ_MAX_LEVEL, level + 2.0f);
		}
	}

	ray.xyz = tmp_ray.xyz;
	--level;
	++iterations;

}

Hi Lukas,

Sorry you're still having trouble with the algorithm, but I'm not sure it's in your intersectCellBoundary method. This is what I'm currently using and the results I'm getting are pretty decent.

float3 intersectCellBoundary(float3 o, float3 d, float2 cellIndex, float2 cellCount, float2 crossStep, float2 crossOffset)
{
	float2 index = cellIndex + crossStep;
	index /= cellCount;
	index += crossOffset;
	float2 delta = index - o.xy;
	delta /= d.xy;
	float t = min(delta.x, delta.y);
	return intersectDepthPlane(o, d, t);
}

Regarding these lines

float2 delta = index - o.xy;
delta /= d.xy;
float t = min(delta.x, delta.y);
return intersectDepthPlane(o, d, t);

think of it like this. "delta" is a vector pointing from the origin of the ray to "index" which is a point along the ray between "o" and "d" (where z = 0 at o and z = 1 at d). Dividing delta by d.xy gives you a percentage of how far along the ray each component is. You take the minimum of the two to decide how far to move between "o" and "d".

At this time, I'm unsure where the artifacts in the image you posted are coming from, but I hope the above explanation helps clear some things up for you. :)

Thanks,

WFP