[MOAB-dev] OBB ray firing questions

Paul Wilson paul.wilson at wisc.edu
Fri Dec 30 11:32:04 CST 2022


Hi again Tim,

Sorry for the delay…. I’ve put my answers below in red.  Note that the last time I made major changes here was about 6 years ago, so my memory may be foggy.  That said, the changes made at that time were quite substantial!

Paul


From: moab-dev <moab-dev-bounces at mcs.anl.gov> on behalf of Tim Tautges <ttautges at divergent3d.com>
Date: Monday, December 12, 2022 at 18:19
To: moab-dev at mcs.anl.gov <moab-dev at mcs.anl.gov>
Subject: [MOAB-dev] OBB ray firing questions
Hi all,
  I'm attempting to use OrientedBoxTreeTool to do some ray tracing on a shell of triangles. I'm observing two problems:

  *   When I call OBTT::ray_intersect_triangles, the results come back but are not sorted by distance. Is there some reason they're not?

TL;DR: I don’t think there is a reason, but I’m not sure sorting of this was ever promised.

I don’t think we ever promised that they’d be sorted.  This may be something that changed during the major refactor 6 years ago, but I don’t think we actually use this function in our use case.  Instead, we perform similar logic in the RayIntersectSets::leaf() method and rely on the specifics of the provided IntRegCtxt to decide how to treat the intersection.

  *   If I try calling OBTT::ray_intersect_sets, with the variant that does not take an IntRegCtxt argument, the code asserts in RayIntesectsSets::leaf with lastSet == 0, implying that there's some function that should be called before this.

lastSet should be non-zero on entry to RayIntersectSets::leaf() because it must come after RayIntersectSets::visit(), invoked through OBTT::preorder_traverse().  The only way that lastSet does NOT get set, is if the current node contains no sets.  Recall<https://docs.google.com/presentation/d/10m8e6GN8DhLpNHHSOMniZ2pDU9DOAiD0xJF1Zyewzh8/edit#slide=id.g3e33340afa_0_0> that an OBBTree Node is a meshset that contains:

  *   A single volume meshset entity handle
  *   A single surface meshset entity handle
  *   One or more triangle entity handles

The first time that ::visit() is invoked, lastSet should start as 0 and be set to be the meshset entity handle contained in the Node.  If an OBB Tree consisted of only a single node that only contained triangles, then we might see a problem like this.  I’m not sure how that would arise from our normal OBB Tree construction algorithms, but haven’t dug further down that path yet.

Am I using this tool wrongly? Note, for the first bug above, I tried running obb_test on that same file with the offending ray start/direction, and got the same (unsorted) results.

- tim


More information about the moab-dev mailing list