-
Notifications
You must be signed in to change notification settings - Fork 380
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect intersection results when using RTC_SCENE_FLAG_ROBUST #387
Comments
FYI, I'm using the latest Embree 3.13.4 on macOS. |
After a closer inspection of the data, I realized that the failing "triangle" actually has vertices that are basically collinear. The weird intersection result is less surprising now that the input geometry is not very reasonable. That said, I found that if I tweak the ray, it doesn't give such false positive results, so it's not consistently failing when given collinear "triangles". It will be nice if Embree can handle such cases more elegantly. :) |
This robustness problem has been with embree for some time. Even with 100% water tight geometry and the ROBUST flag on the ray will sometimes report "a miss" in some cases when it intersects an edge. I suppose no-one will notice this when used for visualization but for other applications it is frustrating. Sadly, if you posted such a question on the Optix forum you would get an answer instantly and a follow up from an nVidia dev. Yet here we are nearly a year later with no comment. |
The ray-triangle intersection algorithm used by embree is not perfectly watertight. I don't know why the developers do not choose Woop algorithm as suggested by DXR, even it has been implemented in embree. https://github.com/embree/embree/blob/0fcb306c9176221219dd15e27fe0527ed334948f/kernels/bvh/bvh8_factory.cpp#L497-L507 |
Could you please try out if that experimental BVH8Triangle4vIntersector1Woop works better for you? The ray/triangle intersection of it should be watertight. Just enable the ENABLE_WOOP_TEST in code block above and enable RTC_SCENE_FLAG_ROBUST for your scenes? You need to compile and run on AVX enabled machine for this codepath to be selected, but if that help we could fix that and give you a compile time option to enable this. |
Dear Dr Woop @svenwoop , I read your paper on watertight intersections, very cool work! And then I found of course there are open source implementations of it ... I have been testing some scenes that have lots of ray-to-vertex and ray-to-edge direct hits and I am seeing lots of holes in the results returned back from embree. I have tried two wrappers thus far:
Interestingly, both wrappers give me similar holes (i.e. lack of ray returns) but NOT identical outputs for the exact same bit-for-bit rays. Based upon your comment above, it seems you suggest trying embree version 4 (i.e. HEAD in this repo) and to toggle the BVH config ... do you think this could help resolve the issue I'm seeing? In particular:
Thanks for any advice you can provide! |
Embree 3 and Embree 4 will behave identical regarding consistency along edges. Please try out enabling the RTC_SCENE_FLAG_ROBUST scene mode if that gives you sufficient quality. If that is not enough please try to enable that ENABLE_WOOP_TEST define described above. Thus should increase quality further. |
Thank you @svenwoop ! It seems both of the implementations I cited use |
The ENABLE_WOOP_TEST is just an experimental feature, this is why it cannot get directly enabled in cmake. You have to patch the code to try this out. Embree is designed for rendering where 100% watertightness is not required. |
The intersection results are occasionally incorrect, even when using the flag
RTC_SCENE_FLAG_ROBUST
. It reports a hit when there are actually no intersection between the ray and the reported triangle, and the tfar returned is some large number that doesn't make sense.An example failure case is shown in the code below. The scene contains one triangle.
Embree returns an
Intersection at t = 12291.2
.In reality, there are no intersection between the ray and the triangle. Also, the distance between the ray origin and any vertices is less than 600, which is significantly different from the returned tfar.
It is very confusing why it returns a hit, and how it computes such a tfar.
I see this kind of errors quite often. From my observation, it tends to happen when the triangle is somewhat skinny. (In the example below, the triangle has edge lengths of around 11.159, 9.721, and 1.438, which is... quite skinny. However, it is still weird that we're getting a false positive hit.)
Could you please help investigate why this is happening and how to fix it? Thanks!
The text was updated successfully, but these errors were encountered: