Hey Jp,

I'm rendering at 1536x864 which I know is a bit of an unconventional resolution, but I use it to help ensure that my scenes and effects can be rendered without imposing limitations on windowed client dimensions. The artifacts I mentioned above do still show up if I use more traditional dimensions like 1280x720 or 1920x1080. I'm glad you mentioned using a power of 2 texture, though, because when I tested tonight by setting the output to 1024x512 and 1024x1024, the stair-like artifacts did seem to be alleviated, though some artifacts remain. I wonder if I need to revisit the way I'm building my hi-z buffer due to not using power of two textures. I will look into that tomorrow when I get some time and see if that helps out.

Thanks,

WFP

Actually, I got a little extra time this evening to work on it and wanted to update with a screenshot of running at 1024x512. The power of two texture is clearly helping the stepping artifacts (I tried on several other power of 2 combinations, as well) so now I need to see what I can do to adapt that to non-power of two resolutions. Any ideas?

The interlaced lines I'm confident can be repaired by updating the epsilon. I haven't tested it much in my code yet, but I'm guessing just moving it closer to something like below will help a lot.

static const float2 HIZ_CROSS_EPSILON = float2(texelWidth, texelHeight) * exp2(HIZ_START_LEVEL);

There are a few other artifacts that appear under things like spheres and character arms that I think I can solve by using the min and max depth in combination with one another to walk behind objects - these are examples of the nonsensical intersections Bruzer mentioned.

Anyway, I'm calling it a night right now, but will be working more on it as soon as I get a chance.

-WFP

Screenshot at 1024x512:

https://www.dropbox.com/s/3uvq0mrczps6vc0/screenshot_5.png

Only some minor updates to provide at the moment. I've been able to confirm a few suspicions from my previous posts.

The first is that using power of two textures removes the stair-step artifacts.

The second is that setting the HIZ_CROSS_EPSILON to what I mentioned in the post above did indeed remove the interlaced lines. I also found through testing though, that I could move the HIZ_START_LEVEL and HIZ_STOP_LEVEL to 0.0f and leave the epsilon to be the texel sizes and it would also remove the interlaced lines. With either of these setups, the results were dramatically better and the only noticeable artifact in the ray-tracing portion is the nonsensical intersection stuff that can be solved by properly using the min/max buffer. Here's what I landed on for HIZ_CROSS_EPSILON and it works well on both start/stop levels I've tested on (2.0f and 0.0f).

static const float2 HIZ_CROSS_EPSILON = float2(texelWidth, texelHeight) * exp2(HIZ_START_LEVEL + 1.0f);

I've included another screenshot to show the same scene (a stack of boxes - i.e., wonderful programmer art) with the interlaced lines gone.

If anyone has any ideas to get rid of my power of two texture size constraints that would be most appreciated. The only thing I can think of right now is copying the necessary resources to a power of two texture before starting the effect, but I feel like that's bound to introduce its own set of problems, especially from copying the depth buffer to a different size. Any other ideas?

Screenshot at 1024x512:

https://www.dropbox.com/s/7qfs04tvx8vpf09/screenshot_6.png

Edit: grammar

OK so I've found one way to address the power of two issue, but I'm still very open to suggestions if anyone has any. I've updated my getMinimumDepthPlane method (below) to always sample level 0.0f (largest mip level) at the texture coordinates provided. This does seem to fix my issues with the stair-like artifacts, but it doesn't sit well with me because if this were the correct solution, why would the author have passed in level and rootLevel in the first place? Anyway, the ray tracing steps currently work fairly well now (still need to address other artifacts using min/max values) at any resolution and stepping through in the VS2013 graphics debugger shows that it converges on a solution (for most pixels tested) in about 13 iterations (far less than my 64 limit).

float getMinimumDepthPlane(float2 ray, float level, float rootLevel)
{
	// not sure why we need rootLevel for this - for textures that are non-power-of-two, 0.0f works better
	return hiZBuffer.SampleLevel(sampPointClamp, ray.xy, 0.0f).r;
}

Screenshot at 1536x864:

https://www.dropbox.com/s/eo2wkiz87bswgz5/screenshot_7.png

You might have some issues with that, once your scene has a bit more depth complexity. You are basically ignoring most of the depth values in a cell, which if you are at a lower mip level, could be quite a lot.

Just wanted to check in on this thread. Still haven't gotten much of anywhere removing the stair-like artifacts without forcing the mip level to 0 (which we know is wrong). I tried using a trilinear sampler instead of the point sampler, but as I expected all that did was make the stair artifacts into slopes, but they still noticeably exists.

@jgrenier Have you had any time to port your code to HLSL and if so have you had any luck with it or experienced artifacts similar to what I'm seeing?

@Bruzer100 Could you tell us about the samplers you used during the different steps of building out your hi-z, convolution, and integration buffers? I'm using a point sampler for everything but the cone-tracing step (which in my code is currently disabled), and am wondering if perhaps I'm using an incorrect addressing mode or border mode (I currently use clamped borders).

Thanks,

WFP

Quick question. Regarding the visibility buffer. Isn't there a "- minZ" missing on page 173. If this is to be the percentage of empty volume of a cell, it doesn't make sense to me that we do the integration with the fine values directly. i.e. integration should be:

float4 integration = (fineZ.xyzw - minZ) * abs(coarseVolume) * visibility.xyzw;

Or am I missing something?

Even the 4.9 (page 159) figure doesn't really make sense to me either. To me it looks like MIP-1 should have visibilities calculated as [25%, 100%] (since 1/4 of the first two MIP-0 cell is empty). I feel like I'm missing something here :(

Hey Jp,

Regarding your first question - honestly I'm not sure. I seem to have "better" results when I use the code presented in the book for the visibility pass (although I do include a divide by 0 check on that first division). That being said, I currently have the cone-tracing part of the technique disabled in mine as mentioned in one of my above comments as I'm still a ways from figuring out the ray marching part. When I do enable it, the results are not even to the point where I think it would be useful to post an image of them, so there's a lot of work I need to do on it, but I haven't been spending much time or energy on it due to the issues I've been having getting the ray marching to work.

As for your second question, I think the book is correct in the diagram provided, if not a little confusing to look at. The first four bars represent mip level 0 and all have 100% visibility. The next two bars, the grey and the white, represent mip level 1, which they're obtaining by just accounting for the two nearest bars - halving the resolution of the first mip level (in the actual implementation, this is four values instead of two like shown in the book). This gives the 50% and 100% values as shown. And obviously along these lines the final blackish bar is the combination of the mip level 1 values into mip level 2. When going down a mip level in the visibility buffer, the value can always be the same or less than the value before it in the visibility buffer mip chain, but never above that value.

If I've missed something or misunderstood your question, let me know and I'll try to update my explanation. :)

-WFP