Adjusting Polygon offset factor about ray-tracing-renderer

[jaxry]

Is there a way to adjust the polygon offset factor of the material

I can't think of a way. Three's polygonOffset uses glPolygonOffset which transposes depth values of the rasterized image. RayTracingRenderer doesn't use a depth buffer at all, since ray tracing traverses a BVH instead. Do you have some ideas how we could prevent z-fighting in other ways?

[ManishJu]

Sorting of objects from back to front is already done with threejs by default.

But the the nvidia guy gave multiple options:
https://devtalk.nvidia.com/default/topic/913414/optix/how-can-optix-solve-the-problem-of-z-fighting-/

1. Increase BVH precision,
2. Offset the ray origin a little from the primitive surface (not good for transparent objects)
3. Unique primitive IDS, but a lot complicated when using instancing, which has now started heavily being used in webgl rendering .

What do you think ?

[jaxry]

Wonderful resource, thanks for finding this. Correct me if I'm mistaken, but this forum post addresses how to avoid self-intersection with the same triangle? What you're describing involves z-fighting between two triangles that are close together? I can see how 1. would fix that, but what about 2. and 3.?

1. The BVH precision is using the max built-in texture storage of 32-bit float. I'm not sure how easy it would be to increase this.
2. I think we're doing this already! We offset the ray origin, from the surface, by a fixed small amount of 0.0005. It avoids the self-intersection problem described in the post.
   https://github.com/hoverinc/ray-tracing-renderer/blob/master/src/renderer/glsl/chunks/sampleShadowCatcher.glsl#L117
3. This solution is interesting and sounds like something we could explore. We'd need to allocate extra memory in the BVH for primitive IDs, but that's doable. But would it offer an advantage over ray origin offsetting?

[ManishJu]

1. Yes you cannot go beyond 32 bit float precision in WebGL2 :(
2. Oh that's great, but we are having self intersection problems with thin planes, currently managing with tricks.
3. Yes when geometry is quite thin and almost overlapping, this should be really useful :)