I’m not sure what that might be. Let me ask a few questions. It sounds like you’re using instancing for the small cubes? The cubes are using OptiX triangles, or a custom intersection program? How are you propagating a ray after a hit? When any-hit is disabled, you are relaunching the ray with another optixLaunch() call? What is the general ratio of missing hits to rays cast that you’re seeing, is it a small number of missing hits, or are most rays seeing this? How are the small cubes arranged - are they randomly placed, or arranged into a regular grid? Are the small cubes all exactly the same size? Do you have a scale value set in your instance transform that is different from uniform identity (1,1,1)? How repeatable are the missing cubes - is it the same set regardless of the rays; will very similar rays (neighboring pixels and/or neighboring subpixel rays) experience the same missing cubes, or see a completely different set?
Here are a few stupid ideas of mine and things to double-check, maybe shooting these down will help us narrow in on the real cause.
If there are any indexing errors in allocating, setting, or passing the instance transforms, that could leave some of them uninitialized, which would result in them not getting traced. And of course, double-check and verify that the number of instances and the buffer sizes passed to the BVH builder is correct, etc.
If the number of spurious misses is low, maybe the problem is numeric precision - rays striking the edge between two cubes and missing the front face. OptiX tries to guarantee that triangles that have shared edges in a mesh are watertight, but there is no way to guarantee this for separate instances, especially if the scale values in the transform are non-identity; floating point precision will cause errors that allow rays to escape.
Some things you might try:
- Copy your instance transform buffer to the host and inspect it for NaNs, Infs, or other unexpected, uninitialized, or bad data.
- Turn down the number of sub-cubes until the problem goes away, or becomes easy to debug.
- If the set of missing cubes is repeatable, try peeling away layers of the big cube mass until you can see the missing cubes.
- Try sending multiple rays per pixel with varying amounts of jitter to check whether they experience the exact same hits & misses.
- Check whether using any-hit vs relaunching gives you the same set of unexpected misses.
- Save out the data for one ray and it’s hits, and visualize it in a separate program to see if any patterns become obvious. (Personally, I like adding code in my OptiX launch params & programs that will limit printf output to the clicked pixel, and then print OBJ format data and open it in Blender… super easy!)
I’m taking stabs in the dark, just hoping to make a suggesting that might help debugging, but apologies in advance if these are unrelated or lead to wasting time. The other option, of course, is to create a minimal reproducer code sample you can share.