Fixes InOutOctree samping on surface boundary by kennyweiss · Pull Request #1909 · llnl/axom

kennyweiss · 2026-07-09T01:19:18Z

Summary

This PR is a bugfix with some minor refactoring
It fixes the InOutOctree for samples on (or very close to) the surface boundary, which was previously inconsistent about whether such points are considered inside or outside the surface.
- By convention, we consider these points to be inside the contained volume, and this is consistent with our winding number treatment
- In addition to fixing the tests, I added some regression tests for this, and compared the results to those of the winding number for 2D points on the unit square and 3D points on the unit cube
- This also make our sample-based shaping results for inout-based sampling and winding-based sampling more consistent on the "heroic roses" dataset, so I updated the REGEX check on our regression test
I also added a runtime switch to output debug/visualization files of the generated octrees, and wired those through the containment_driver and shaping_driver examples
Misc: I slightly refactored the containment_driver and InOutOctree to replace SFINAE w/ if constexpr, and to use a variant for the 2D and 3D octrees, since we can only have one of these within the containment driver application
Resolves Improve handling of points on surface for InOutOctree #611
Companion PR to axom_data repository: Update containment regression baselines after bugfix for points on/near surface axom_data#39

kennyweiss · 2026-07-09T01:20:03Z

+
+  // First, handle the case where the query point lies on (or within the vertex welding tolerance of)
+  // one of the block's segments. Such points are 'within' the surface by convention,
+  // but the ray-orientation test below is degenerate for them.
+  for(int i = 0; i < numSegments; ++i)
+  {
+    if(primal::squared_distance(queryPt, m_meshWrapper.cellPositions(segmentSet[i])) <=
+       m_vertexWeldThresholdSquared)
+    {
+      return true;
+    }
+  }


This is the 2D bugfix

kennyweiss · 2026-07-09T01:20:33Z

+  // First, handle the case where the query point lies on (or within the vertex welding tolerance of)
+  // one of the block's triangles. Such points are 'within' the surface by convention,
+  // but the ray-orientation test below is degenerate for them.
+  for(int i = 0; i < numTris; ++i)
+  {
+    if(primal::squared_distance(queryPt, m_meshWrapper.cellPositions(triSet[i])) <=
+       m_vertexWeldThresholdSquared)
+    {
+      return true;
+    }
+  }


This is the 3D bugfix

By convention, such points should be categorized as "Inside".

By conention, such points should be categorized as "Inside".

... and exposes this as an option in the quest containment and shaping examples. This was previously exposed through a compile-time ifdef.

…3D cases

…tOctree After our bugfix, the volume for the "black" material increased from 36,595 to 36,662.53, which better matches the computed volume from the winding-based approach (36,653.78). The difference between the two is now 8.74 (~0.024%).

The 2D and 3D functions were sufficiently different that I kept them separate, so this is mostly cosmetic

…cific InOutOctree::withinGrayBlock*D implementation This was vestigial from the earlier SFINAE formulation.

Also addresses PR suggestions about comments in new tests.

This ensures that we are using the same on-surface check in the octree and its comparison tests.

This file was last updated before our move to C++17, so I took this opportunity to update the file a bit. There are no functional changes in this commit.

kennyweiss added this to the FY26 August release milestone Jul 9, 2026

kennyweiss requested review from Arlie-Capps, BradWhitlock, adayton1, bmhan12, jcs15c, publixsubfan, rhornung67 and white238 July 9, 2026 01:19

kennyweiss self-assigned this Jul 9, 2026

kennyweiss added bug Something isn't working Quest Issues related to Axom's 'quest' component maintenance Issues related to code maintenance labels Jul 9, 2026

kennyweiss commented Jul 9, 2026

View reviewed changes