Is there Peter Panning/Surface Acne in Ray Tracing when it comes to shadows?

Started by
8 comments, last by NikiTo 5 years, 3 months ago

I am having an argument about this with a buddy now, and we don't believe each other.

Advertisement

There is no peter panning with RT if you trace from the shading surface to the light source, because precision near the ray origin and so the surface is best.

With shadow mapping it's the opposite: You have great precision at the light source, but bad precision to differentiate between surface and occluder if they are both close to each other but distant to the light source.

Even worse with shadow mapping is that occluder and surface could fall within the same texel of the shadow map. You then don't know if the shadow map value comes front the surface or the occluder. By adding a bias you try to eliminate the self shadowing that could happen form surface to the same surface, but you risk to miss an occluder close to the surface, which causes the peter panning effect.

 

Surface Acne can happen in RT too. If you start the ray exactly at the surface, the triangle check with itself might return a false positive. 

To avoid this, add a small offset along the normal from the surface (but then you risk to miss a very close occluder),

or (if you have manifolds) do a backface check like (ray.Dir.Dot(triangle.normal) < 0) to get rid of self shadowing. 

The former case with the offset still works much better in RT than the bias in shadow maps, because you have good precision near the surface / ray origin.

 

Another cause of artifacts are rays exactly at the surface (e.g. reflection looking at shallow angle). Here the normal offset helps too, or / and a reduced weighting of the ray result in that case.

 

So i would answer: It is easy to get rid of those artifacts with RT, but impossible with shadow maps.

 

 

 

You can picture shadow mapping as a voxelisation technique. Each pixel in the shadow map is a thin frustum, extending out from the light/shadow camera. The depth value for a pixel in the shadow map then lets you slice that thin frustum twice (if using integer depth values, at depth-0.5 and depth+0.5) to produce a little frustum voxel, or "froxel". The shadow map only tells you that there is a blocker / shadow caster somewhere within that froxel. Shadow acne is directly related to this - when these froxels intersect your surfaces at an angle, you'll get an on/off aliasing pattern as their corners alternate between being hidden or poking out of the surface. Peter panning is used to hide acne: it adds a bias value to push those froxel corners deeper into surfaces (and causing shadows on the other side to disconnect from their casters). Without voxelising the scene, you don't need to apply voxel workarounds :)

3 minutes ago, Hodgman said:

You can picture shadow mapping as a voxelisation technique. Each pixel in the shadow map is a thin frustum, extending out from the light/shadow camera. The depth value for a pixel in the shadow map then lets you slice that thin frustum twice (if using integer depth values, at depth-0.5 and depth+0.5) to produce a little frustum voxel, or "froxel". The shadow map only tells you that there is a blocker / shadow caster somewhere within that froxel. Shadow acne is directly related to this - when these froxels intersect your surfaces at an angle, you'll get an on/off aliasing pattern as their corners alternate between being hidden or poking out of the surface. Peter panning is used to hide acne: it adds a bias value to push those froxel corners deeper into surfaces (and causing shadows on the other side to disconnect from their casters). Without voxelising the scene, you don't need to apply voxel workarounds :)

Is it an yes or a no?

I read in various papers, Ray Tracing needs to use epsilon too, in order to avoid acne. And, peter panning and acne are the two sides of the same coin.

image.png.e51d2cb022823a714787045028451aae.png

the source of the image

image.png.0df307562c118b93632420d86407fb9f.png

Source of image

Should i understand your answer as "ray tracing is more precise than shadow mapping because of voxelization"?

Virtually, my projection is faking it everything, so in shadow mapping, virtually every light ray hits perpendicularly the shadow map 2D projection(in shadow mapping it is all a little bit wicked). Still my BIAS depends of the angle of the light ray, but i don't think of this as a problem of voxels, because each voxel stores a 32 bit floating point Z distance. Although, it could be explained with voxels, i guess.

The frustum in my API ranges from -1.0 to +1.0, although i don't know how if it is scaled down to -0.5 to +0.5 by the hardware. It is hard for me to tell which is better as toward zero the precision grows, but i can't go infinitely toward zero. In other APIs it is from 0.0 to +1.0.


(By the way, i compare 32 bit floating point depth map to ray tracing using 32 bit floating points for the math)


EDIT:

My point is that virtually it all reduces down to the same "not enough floating point precision for Z sorting" problem.

iuhjhg.thumb.jpg.610053cf4a43a057c41b4a606ee2fa83.jpg

Maybe the size of the shadow map, which is a limited integer, could introduce some quantization into the rendering, making the Ray Tracing more precise...... but Ray Tracing is imprecise hitting thin triangles, so....

 

11 hours ago, NikiTo said:

Maybe the size of the shadow map, which is a limited integer, could introduce some quantization into the rendering

After all this confusion about projection, you just answered your own question. :)

Because shadow map size is finite, its content is accurate only at texel centers, and interpolation with texture filters gives only a coarse approximation of how the scene might look like in between. ('undersampling')

If the shadow map would have infinite resolution, there would be no artifacts (except precision issues which are not the real problem usually).

In ray tracing, precision loss can also come from the ray being too far from the world origin, so the constant epsilon offset no longer working correctly. There is an interesting article on lightmapping mentioning this and suggesting the following workaround:


position += sign(normal) * abs(position * 0.0000002)

So instead of constant epsilon, the epsilon gets increased further away from the origin. Although I remember that it didn't work well for me when I tried, so I kept the constant epsilon.

On 1/10/2019 at 9:54 AM, NikiTo said:

Is it an yes or a no?

Yes and no :D 

In any project where you represent surface positions as floating point numbers, that is a quantization as well, which you can think of as a kind of voxelisation of the scene. Except with floating point numbers, these voxels are unimaginably small when close to the origin (smaller than an atom!!!), and get bigger when you move far away from the origin. If working in meters, then at ~4km from the origin the voxels are about 0.5mm in width.

So yes, you might have to implement some kind of biasing regardless of your rendering algorithm (on small scenes, you may not even need any biasing at all)... but if you're only biasing due to floating point precision, it will be extremely small compared to the typical amount of biasing required by shadow mapping.

Also, when using shadow-mapping, you typically aren't storing the distance from the light to the surface in the shadow map -- you're storing the post-projection z/w value, which is much less precise.

Lastly, if writing an offline / non-realtime ray-tracer, there's also no requirement that you use floating point numbers. You can work with exact representations of the math if you're ok with it taking longer to compute in order to get exact results :D 

13 minutes ago, Hodgman said:

In any project where you represent surface positions as floating point numbers, that is a quantization as well, which you can think of as a kind of voxelisation of the scene.

Can i then win the argument saying to my buddy:
"There IS Acne/Panning in Ray Tracing as well as in Shadow Mapping. Although, in Ray Tracing it is much smaller."

This topic is closed to new replies.

Advertisement