Chronological Thread 

< Chronological >      < Thread >

---

Hi Brig,

Responses inline:

On Fri, May 20, 2016 at 3:22 PM, Brig Bagley <brig@sci.utah.edu> wrote:
> A couple of high level answers now that I'm thinking...
>
> Snapping and warping in the GUI was assumed to always be enabled for element
> quality reasons. The GUI check mark is merely a progress indicator stating
> that a particular step is complete.
>

That's correct. Snapping and warping is really the key to tetrahedral
mesh quality. But, it can and does sacrifice geometric features in
exchange for angles. Disabling it is expected to produce bad angles,
but good features. In this case, I'm not trying to build a mesh, but
rather just extract the features.

> The GUI and CLI both have a structured vs. unstructured (adaptive) options.
> But at first glance, structured still looks pretty adaptive to me. I'm not
> versed enough to know what parameters deep in the code prevent the adaptive
> calls.

Depends on what you mean by adaptive. There are two levels: (1)
volumetric adaptation away from the surface (via an octree) and (2)
surface adaptation (to use large triangles in flatter regions of the
interface surface). By switching the "Cleaving tool" mode from
"Adaptive" to "Regular", I think this disabled both. I wasn't
entirely sure how to just disable (2), since (1) shouldn't affect the
resolution near features.

>
> As far as interpolation goes, I do think it's a very coarse linear guess. I
> don't think there is any robust root finding.

"Coarse" isn't quite how I understand it. Jonathan had worked on a
kind of "truncated" interpolation scheme in the triple/quadruple
computation that effectively ignores the materials that are not
maximal on the vertices of each tet. See "computeTripleForFace()" and
"computeQuadrupleForTet()". These both solve simple linear system,
but they should be robust. I do not think it's a precision error.
Still, I was a bit surprised to see it's behavior though, which seemed
worse than I anticipated (perhaps simply because I'm calling the code
wrong). It could also just be that we're linearizing non-linear
functions, and that this is the best we can do.

Perhaps there's a novel way to reconstruct something smoother by
fitting these curves with something like a b-spline?


>
> Regards,
>
> Brig Bagley
> Research Software Engineer
> SCI Institute, University of Utah
> WEB 3616
> brig@sci.utah.edu
> 801.613.7718
>
>
> On 5/20/2016 1:06 PM, Joshua Levine wrote:
>>
>> Hi,
>>
>> I tried out Cleaver2 to do this based on a question from a few of the
>> CGAL guys (Andreas Fabri, Laurent Rineau). They want to compute
>> triple curves and quadruple points from image data (presumably, to
>> bake this into CGAL's feature detection for meshing). I suggested
>> they try out Cleaver.
>>
>>
>> The bummer is, they tried it out and are getting results like this:
>>
>>
>> https://raw.githubusercontent.com/SCIInstitute/Cleaver2/master/src/gui/Resources/surface.png
>>
>> Because (I believe) of a couple of things:
>>
>> (1) the default settings for Cleaver are to use adaptive surface meshing
>> (2) snapping and warping is enabled.
>> (3) the interpolation
>>
>> (Note that with (2), there is supposedly a checkbox to disable
>> snapsAndWarps(), but it seems like this was never implemented? It was
>> greyed out for me and I couldn't even select it. This might be a bug
>> on OSX though).
>>
>>
>> My approach:
>>
>> I grabbed the source code and recompiled after manually disabled
>> snapsAndWarps(), and I switched to uniform grids instead. I was able
>> to do better, but there is still some puckering near the interface
>> curves that persists even if you up the resolution of uniform
>> background grid (see attached screenshot at 2x resolution for the
>> spheres).
>>
>> I suspect that ultimately this has to do with our scheme for
>> interpolation and truncation of the linear functions. I'm curious on
>> the state of development for this and if anyone is actively working on
>> extracting these features. It would be handy to add some features
>> where someone could just output a set of polycurves (e.g. a VTK .vtp
>> file) with the 1-skeleton of the interface.
>>
>> I also noticed there's a topologicalCleaving() mode (line 6864 of
>> CleaverMesher.cpp). Is this exposed through the UI?
>>
>>
>> Thanks!
>> Josh
>
>

---

• [Cleaver] Best way to extract triple and quadruples using Cleaver2?, Joshua Levine, 05/20/2016
  • Message not available
    • Re: [Cleaver] Best way to extract triple and quadruples using Cleaver2?, Joshua Levine, 05/20/2016

---

Archive powered by MHonArc 2.6.18.