What is the appropriate kernel/epsilon for CSG on inaccurate (float innaccuarcies) meshes?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

What is the appropriate kernel/epsilon for CSG on inaccurate (float innaccuarcies) meshes?

Arthur Silber
Hi,

I haven't found answers using google, so maybe cgal-discuss has some ideas on how I can proceed:

I am using CGAL to compute CSG boolean operations with OFF meshes using mostly the example code using Nef_polyhedron. My input meshes use xyz-float coordinates and I cannot change this, unfortunately.

CSG works great if I can pre-process meshes, i.e. round all points to a certain precision to avoid floating-point inaccuracies that come from my meshes.

However, in some cases, I cannot do this rounding, as that would make things worse. Consider this example:

grafik.png

I want to union the orange mesh with the blue mesh. With floats as coordinates, I can position the orange mesh onto the blue mesh, but whether the red points of the orange mesh are on/inside the blue mesh, depend on the accuracy on the translation math done before and might or might not be true for the given float xyz-values. Rounding point positions might make things worse, as the red points might be extra-far away of the blue surface after rounding than before.

So: Is there a kernel or a way to tell CGAL to use epsilon-distances here? As in "I know my accuracy might work up to 4 digits after comma, but please ignore everything more fine-granular and use epsilon math, as in: consider the red points to be connected with the blue surface even if there might be a distance of 0.00000001"

I'd be really grateful for some ideas.

Thanks a lot!
Arthur

Reply | Threaded
Open this post in threaded view
|

Re: What is the appropriate kernel/epsilon for CSG on inaccurate (float innaccuarcies) meshes?

Sebastien Loriot (GeometryFactory)
I'm afraid there is no magic solution.
I think the cleanest and safest way would be to first identify
faces from A and B that almost overlap and process them so that
the overlap region is part of both meshes. But you are still left
with the epsilon to choose.

In passing let me mention that CGAL also provide an alternative to
Nef much faster that is basically limited to case when the output is
known to be a 2-manifold.

More details here:
https://doc.cgal.org/latest/Polygon_mesh_processing/index.html#Coref_section

Sebastien.


On 10/25/18 8:03 PM, Arthur Silber wrote:

> Hi,
>
> I haven't found answers using google, so maybe cgal-discuss has some
> ideas on how I can proceed:
>
> I am using CGAL to compute CSG boolean operations with OFF meshes using
> mostly the example code using Nef_polyhedron. My input meshes use
> xyz-float coordinates and I cannot change this, unfortunately.
>
> CSG works great if I can pre-process meshes, i.e. round all points to a
> certain precision to avoid floating-point inaccuracies that come from my
> meshes.
>
> However, in some cases, I cannot do this rounding, as that would make
> things worse. Consider this example:
>
> grafik.png
>
> I want to union the orange mesh with the blue mesh. With floats as
> coordinates, I can position the orange mesh onto the blue mesh, but
> whether the red points of the orange mesh are on/inside the blue mesh,
> depend on the accuracy on the translation math done before and might or
> might not be true for the given float xyz-values. Rounding point
> positions might make things worse, as the red points might be extra-far
> away of the blue surface after rounding than before.
>
> So: *Is there a kernel or a way to tell CGAL to use epsilon-distances
> here? As in "I know my accuracy might work up to 4 digits after comma,
> but please ignore everything more fine-granular and use epsilon math, as
> in: consider the red points to be connected with the blue surface even
> if there might be a distance of 0.00000001"*
> *
> *
> I'd be really grateful for some ideas.
>
> Thanks a lot!
> Arthur
>

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


Reply | Threaded
Open this post in threaded view
|

Re: What is the appropriate kernel/epsilon for CSG on inaccurate (float innaccuarcies) meshes?

Arthur Silber
Thanks for your response, Sebastien!

Yep, we ended up doing something similar - manual pre-adjustments before processing the data with CGAL.

Best,

Arthur

On 29.11.2018 11:45:20, Sebastien Loriot (GeometryFactory) <[hidden email]> wrote:

I'm afraid there is no magic solution.
I think the cleanest and safest way would be to first identify
faces from A and B that almost overlap and process them so that
the overlap region is part of both meshes. But you are still left
with the epsilon to choose.

In passing let me mention that CGAL also provide an alternative to
Nef much faster that is basically limited to case when the output is
known to be a 2-manifold.

More details here:
https://doc.cgal.org/latest/Polygon_mesh_processing/index.html#Coref_section

Sebastien.


On 10/25/18 8:03 PM, Arthur Silber wrote:
> Hi,
>
> I haven't found answers using google, so maybe cgal-discuss has some
> ideas on how I can proceed:
>
> I am using CGAL to compute CSG boolean operations with OFF meshes using
> mostly the example code using Nef_polyhedron. My input meshes use
> xyz-float coordinates and I cannot change this, unfortunately.
>
> CSG works great if I can pre-process meshes, i.e. round all points to a
> certain precision to avoid floating-point inaccuracies that come from my
> meshes.
>
> However, in some cases, I cannot do this rounding, as that would make
> things worse. Consider this example:
>
> grafik.png
>
> I want to union the orange mesh with the blue mesh. With floats as
> coordinates, I can position the orange mesh onto the blue mesh, but
> whether the red points of the orange mesh are on/inside the blue mesh,
> depend on the accuracy on the translation math done before and might or
> might not be true for the given float xyz-values. Rounding point
> positions might make things worse, as the red points might be extra-far
> away of the blue surface after rounding than before.
>
> So: *Is there a kernel or a way to tell CGAL to use epsilon-distances
> here? As in "I know my accuracy might work up to 4 digits after comma,
> but please ignore everything more fine-granular and use epsilon math, as
> in: consider the red points to be connected with the blue surface even
> if there might be a distance of 0.00000001"*
> *
> *
> I'd be really grateful for some ideas.
>
> Thanks a lot!
> Arthur
>

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss