Explain AABB offset for planar objects

[manas96]

Hi, I tried adding a triangle intersection routine using the Moller Trumbore algorithm.
I calculate the max and min of each vertice to get an AABB.
Without using the bvh class, this works properly (i.e. triangles are intersected and displayed properly).
My problem is that when I pass in the bvh root, this produces the following weird behavior across invocations of the executable (assume 3 triangles are added to the scene):

• No triangles are rendered.
• Only the first triangle is rendered.
• First two triangles are rendered.

This behavior is non-deterministic.

Could it be that the triangle primitive is a plane and not a 3D object; and the BVH construction scheme in the book is not designed for this? But then again rectangles are also used and they are planes.
I can't figure out where I should be investigating. Any pointers?

[trevordblack]

My initial guess is that you have the triangle in an axis aligned plane. Offset the values of the bvh by 0.001

…

-------- Original Message --------

On Apr 18, 2020, 21:37, Manas Kale wrote: Hi, I tried adding a [triangle intersection](https://github.com/manas96/Raytracer/blob/master/src/triangle.cpp) routine using the Moller Trumbore algorithm. I calculate the max and min of each vertice to get an AABB. Without using the bvh class, this works properly (i.e. triangles are intersected and displayed properly). My problem is that when I pass in the bvh root, this produces the following weird behavior (assume 3 triangles are added to the scene): - No triangles are rendered. - Only the first triangle is rendered. - First two triangles are rendered. This behavior is non-deterministic. Could it be that the triangle primitive is a plane and not a 3D object; and the BVH construction scheme in the book is not designed for this? But then again rectangles are also used and they are planes. I can't figure out where I should be investigating. Any pointers? — You are receiving this because you are subscribed to this thread. Reply to this email directly, [view it on GitHub](#488), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ACNZVKCKRO6PT33TVQRST23RNJ5ZNANCNFSM4MLUHJ3Q).

[manas96]

Cool, that worked!

So that was happening because in the BVH construction we split along any of the 3 axis, and objects with AABplanes were sometimes split along their planes? I'm having a hard time visualizing the problem.

Also, I notice that the same offsetting has been done in the rectangle's bounding box function. Please consider adding some explanation when refactoring it in #292 .

[hollasch]

Thanks Manas & Trevor. I agree that the book needs to add explanation around this issue. I wonder if we can work in a common offsetting function that inflates AABBs in any zero-sized dimension.

I've updated this issue to a work item.

[manas96]

Thank you @hollasch .

• I'm still having a hard time visualizing the problem. Could you/Trevor please help me understand what exactly was the problem?
• If it was a result of the method used to construct the BVH, could you please mention alternative methods that I can explore?

[hollasch]

Too much on my plate to simulate and debug on my own right now, but I'd start looking for places where a zero-volume box presents a problem (doubtful) or more likely, how boxes are compared against splitting planes. For example, if the comparison operators are > and/or <, then I'd expect to see this problem. Operators for inclusion should be like > or <.

That said, there's nothing that requires spatial partitioning to be precise; as a scheme with a small slop will have almost the same efficiency — for a complex scene, the vast majority of geometry is well outside any particular cell.

[hollasch]

Ok, perhaps inspection is sufficient. Here's something to try — look at box_compare() in bvh.h. In the return statement, replace < with <=, remove any slop you've added to your box calculation, and let me know if that works. This would be a much better fix than adding slop in strategic places.

[hollasch]

Hmmm. I've tried several scenes from The Next Week after removing the slop in xy_rect::bounding_box and using BVH, and can't find a failure.

@manas96 — it's up to you to verify whether this is a fix or not.

[manas96]

I added <= in the boxCompare() method after removing slop from my triangle BB, but it didn't work. I haven't implemented rectangles yet, trying to work on a mesh class instead. I'll update here when I implement rectangles.
Thanks, I appreciate your time.

[hollasch]

Thanks for testing. Are you creating boxes around each triangle? Seems like the overhead would clobber any theoretical speedup.

[hollasch]

Hmmm. Don't know what finger-fumble closed this. Reopened.

[manas96]

You mean boxes around each triangle in the mesh class? Haven't got around to doing that yet (am stuck on implementing a memory-efficient mesh solution), but I'm going to create a BB for the whole mesh and then subdivide that.
For testing, I just rendered a few individual triangles.

[hollasch]

Ah, I see. So the issue you encountered was when an entire mesh was coplanar and lay on an integral boundary. But yes, I believe that all bounding boxes should have non-zero sizes for all dimensions.

We still need to document this criteria in our AABB text.