So, I just initialized a BLAS with a list of 9 AABBs, each with size = 0.5. I always reportIntersectionKHR in the intersection shader, and in the closest-hit shader I output gl_PrimitiveID on the screen.
Now, I increase the size of the AABBs to 0.8.
As shown in the image, two of my AABBs are merged together, and they share the same gl_PrimitiveID. If I move the second AABB a little bit, the two boxes get separated.
Now, I do understand that the Vulkan Specification states that “In the case of AABB geometries, implementations may increase their size in an acceleration structure in order to mitigate precision issues. This may result in false positive intersections being reported to the application.”
However, I do expect to receive accurate gl_PrimitiveID information in the intersection shader so that I can use that to index into my list of custom geometries and perform intersection tests.
Are there any workarounds to avoid this issue?
I ran into the same “issue” and had to do my own ray / AABB intersection test to eliminate false positives
This tutorial on “implicit” objects helps in doing that : vk_raytracing_tutorial_KHR/intersection.png at master · nvpro-samples/vk_raytracing_tutorial_KHR · GitHub
See :
The DirectX Raytracing (DXR) Functional Spec is more explicit about AABB handling:
“Implementations may replace the AABBs provided as input to an acceleration structure build with more or fewer AABBs (or other representation), with the only guarantee that the locations in space enclosed by the input AABBs are included in the acceleration structure.”
See DirectX Raytracing (DXR) Functional Spec | DirectX-Specs
Thanks for your response! Although it’s reasonable that some AABBs will be larger in size, when I put in an array of 9 AABBs, I do expect to see 9 primitives in the scene with 9 distinct gl_PrimitiveID.
If the implementation is just going to merge some AABBs together, what would happen is that the intersection shader for some AABBs will be called with a gl_PrimitiveID inconsistent with what it actually is. I wouldn’t be able to do custom ray / AABB intersection test if I don’t even know which AABB it is.
1 Like
Turns out the merged primitive is still there. The driver just calls the intersection shader twice for the same merged AABB with different gl_PrimitiveID.
This behavior needs to be in the Vulkan Specs. The Vulkan Specs did mention that the AABBs could be bigger, but it didn’t mention that the primitive can be merged and the intersection shader would be called twice.
1 Like
Hi! I think that this is what is happening to me too. Does anybody knows how I can avoid this issue? Cheers.
