Review validity of vnf_validate() error conditions

[amatulic]

Regarding https://github.com/BelfrySCAD/BOSL2/wiki/vnf.scad#module-vnf_validate

Two conditions should be reviewed, and removed if not applicable:

• BIG_FACE warning: This has never been an issue in the years I've been using OpenSCAD, starting with the 2015 version. Before I came across BOSL2, I released several polyhedron-based designs made completely from nonplanar quads (example, example). Not once have I ever encountered a rendering error or CGAL complaint due to a nonplanar face. If it's nonplanar, it gets triangulated for you.
• MULTCONN error: For the example given, with an edge sharing four faces, neither CGAL nor Manifold complains, both render the object.
  • The STL file output simply has 24 triangle faces in it, that's all. When previewing in 3D Builder, it's a valid STL, regardless of whether it was generated by Manifold or CGAL.
  • In both cases, the 3MF file output does cause 3D builder to complain and offer to repair it.

Perhaps that difference between STL and 3MF should be reported to the OpenSCAD repo. I thought 3MF was essentially an extension of STL.

[adrianVmariano]

I don't think you can make a valid object with CGAL that has an edge sharing four faces. Maybe it's possible with manifold?

The big face thing is somewhat confusing. I questioned that, but I think we did have a bug recently where we had to run vnf_triangulate because a large face resulted in a rendering error.

[amatulic]

I tried it with both CGAL and Manifold. It worked in both cases, both exported a valid STL, but neither exported a valid 3MF.

Maybe the big face thing is for non-convex faces? It's never ever been a problem with convex faces.

[adrianVmariano]

Did you have a second shape in your model?

[adrianVmariano]

Unfortunately, I don't remember what the situation was with the big face.

[adrianVmariano]

Rendering Polygon Mesh using CGAL...
ERROR: The given mesh is not closed! Unable to convert to CGAL_Nef_Polyhedron. 
Rendering cancelled.
Geometries in cache: 4
Geometry cache size in bytes: 111348704
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Total rendering time: 0:02:06.971
WARNING: No top level geometry to render 

[adrianVmariano]

v=vnf_join([
           cube(10),
           move([10,10], cube(10))]);

vnf_polyhedron(v);
sphere(4);

[amatulic]

This has no problem with CGAL or Manifold:

include <BOSL2/std.scad>
vnf = linear_sweep(
    union(square(50), square(50,anchor=BACK+RIGHT)), height=50
);
vnf_polyhedron(vnf);

...and exporting the STL gives me the correct shape.

However, for this:

include<BOSL2/std.scad>
v=vnf_join([
    cube(10),
    move([10,10], cube(10))
]);
vnf_polyhedron(v);
sphere(4);

I get an error with CGAL, but Manifold renders it, and creates an STL file that has no errors. It doesn't create an error-free 3MF.

[adrianVmariano]

You never get an error from render when there is only one object because the rendering engine doesn't run. To tell if an object is invalid you always have to have a second object. I think I did see that manifold can handle objects that touch on edges, so that would explain why manifold works, though if the saved output may have errors that's not exactly a success story.

[adrianVmariano]

Is there an action associated with this issue?

[amatulic]

The action is to identify a case where non-triangulated faces are a problem, and if it isn't, then remove that from the validity check.

I tried a concave polyhedron with zero triangles, a highly non-planar face on top, intersected by a cube, and it rendered fine with CGAL and Manifold.

points = [
 [0,0,0], [10,0,0], [10,10,0], [6,10,0], [8,4,0], [2,3,0], [4,10,0], [0,10,0],
 [0,0,6], [10,0,5], [10,10,2], [6,10,5], [8,4,2], [2,3,9], [4,10,5], [0,10,1]
 ];
 faces = [
  [0,1,2,3,4,5,6,7],
  [0,8,9,1], [1,9,10,2], [2,10,11,3], [3,11,12,4],
  [4,12,13,5], [5,13,14,6], [6,14,15,7], [7,15,8,0],
  [15,14,13,12,11,10,9,8]
 ];
 polyhedron(points, faces);
 cube(5,true);

Thre are no triangular faces defined at all in this polyhedron, but they are triangulated for you:

The internal triangulation algorithm appears to be prioritizing shortest distance between vertices, similar to what vnf_tri_array does.