Can we conclude a leaf node is fully inside the object if indicator function evaluations on its faces come out above the iso-value?

[lopeLH]

Hi, I have been plotting the nodes of the octree and have some questions, which I hope might be relevant for the whole community.

First, I noted that adjacent nodes seem to have depths differing by at most one level. One can see this, for instance, looking at some slice of the octree along the Z axis after running on the classic Stanford bunny (just inlining a detail, full view here)

Is this expected / guaranteed by the algorithm implementation? If so, that brings me to a second question. Lets assume that for some leaf octant we evaluate the indicator function on a 3x3 grid over each of its faces. If the indicator comes out as being above the iso-value for all those evaluations, can we assume the whole octant to be inside of the object? In other words, can we assume the indicator function will evaluate to values above that iso-value when evaluated anywhere inside this leaf octant? Intuitively I would say so, but I struggle to find hard evidence for it.

Going back to the 2D illustration, the question would boil down to whether a case like this is possible or not:

where again we can see the octree structure, the red circles represent evaluations of the indicator function which yield a value above the iso-value, and the black dashed line represent the iso-surface where the indicator function crosses the iso-value.

Thanks in advance,

[mkazhdan]

In answer to your first question, the implementation does make some restrictions on the topology of the octree. (See Section 3.2, "The hierarchical solver is made more efficient..." in https://www.cs.jhu.edu/~misha/MyPapers/CGF18.pdf.) This is not a requirement for iso-surface extraction, but is needed to make the multigrid solver have linear (rather than log-linear) complexity. I believe that the condition implies that there cannot be more than a one-level difference between face-adjacent leaf nodes.

The answer to your second question is "yes" but it is caveated. This is true when using first-order B-splines (which is the default for the reconstruction code) because only nodes/functions supported on the face are supported on the face. And, since the value in the interior of the face is given by a convex combination of values at the corners, the fact that the values at the corners are all on one side of the iso-value ensures that their convex combination will be as well.

[lopeLH]

If I understand correctly, the B-spline degree in question is the one passed as first argument to the LevelSetExtractor::Extract member function, which is used to initialize the internal indicator function evaluators. Is that correct? Also, I take that this value is specified at the higher level with the DefaultFEMDegree constant, right?

Thanks a lot for your answer.

[mkazhdan]

That's correct. Though its use in the extraction code needs to be consistent with its use in the reconstruction code. If you do not have the "FAST_COMPILE" flag enabled, you can set it through the command line parameter using "--degree".

[lopeLH]

Perfect. That solves all my questions. Closing the issue. Thanks again for the help. Much appreciated.