Decompose objects into volumes before exporting

[MichaelAtOz]

This issue has change into being about discussing volume decomposition on export, see the comment from @OskarLinde below.

Old:

Either the check is broken or the geometry is...

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[donbright]

i tried to reproduce in linux,
strange, there is no 'Valid:' line at all after i hit f6

[donbright]

Saved backup file: /home/don/.local/share/OpenSCAD/backups/unsaved-backup-XMTJ9713.scad Compiling design (CSG Tree generation)... Rendering Polygon Mesh using CGAL... Geometry Cache hit: cube(size=[10,10,10],center=false); (672 bytes) Geometry Cache insert: group(){cube(size=[10,10,10],center=fals (672 bytes) Geometries in cache: 2 Geometry cache size in bytes: 1344 CGAL Polyhedrons in cache: 0 CGAL cache size in bytes: 0 Total rendering time: 0 hours, 0 minutes, 0 seconds Top level object is a 3D object: Facets: 6 Rendering finished.

note the different number of geometries and the different cache size.

i wonder if its a cache problem? if you clear cache do you get the same thing?
what about restarting a fresh instance?

[MichaelAtOz]

strange, there is no 'Valid:' line at all after i hit f6

It got removed from F6 to save processing, Need to do Design/Check_Validity

OP was after doing other stuff, so there was stuff in the cache.

2014.03.26 Clean run.
Type 'cube(10);' F5

Saved backup file: C:/Users/MeB/Documents/OpenSCAD/backups/unsaved-backup-gqHp2212.scad
Compiling design (CSG Tree generation)...
Compiling design (CSG Products generation)...
Geometries in cache: 1
Geometry cache size in bytes: 672
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Compiling design (CSG Products normalization)...
Normalized CSG tree has 1 elements
CSG generation finished.
Total rendering time: 0 hours, 0 minutes, 0 seconds

F6, then Design/Check_Validity

Saved backup file: C:/Users/MeB/Documents/OpenSCAD/backups/unsaved-backup-gqHp2212.scad
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 2
Geometry cache size in bytes: 1344
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Total rendering time: 0 hours, 0 minutes, 0 seconds
   Top level object is a 3D object:
   Facets:          6
Rendering finished.
   Valid:          no

[donbright]

ahh i didnt realize the output had changed... no more # of faces etc etc. . hrm.
that is quite interesting that we are not valid.

        bool valid = false;
        if (const CGAL_Nef_polyhedron *N = dynamic_cast<const CGAL_Nef_polyhedron *>(this->root_geom.get()))
                valid = N->p3->is_valid();

        PRINTB("   Valid:      %6s", (valid ? "yes" : "no"));

from mainwin.cc

so basically... i think uhm...with Marius new Geometry() system, it turns out that not all objects go through the Nef Polyhedron system. Now, 'valid()' is a function that was part of CGAL's Nef Polyhedron code... if there is no Nef Polyhedron ... then there is no NefPolyhedron.valid() function to call.

So basically all objects that are not Nef Polyhedron will report 'not valid'. At least thats what it looks like from first glance.

[OskarLinde]

@donbright, sorry my fault. The CGAL::Nef_polyhedron_3::is_valid() call could take a very long time on more complex models (up to 75% of the rendering time in some cases), so not running it by default made sense. Seems I missed the non-Nef case.

The thing is, is_valid() is not very interesting to an end user at all. It basically checks the internal consistency of the Nef data structure. As far as I know, the only cases where this should be inconsistent are: bugs in CGAL, incorrect direct Nef manipulation in user-code (not something OpenSCAD does AFAIK), or memory corruption.

I would suggest removing the "check valid" menu option from non-developer builds.

[MichaelAtOz]

I always though the validity=no indicated a non-manifold situation, hence it is very applicable to people wanting to 3D print the object.

[t-paul]

No, the discussion in the pull request #635 came to the conclusion that is_valid() is not very useful. The non-manifold check is something different (is_simple()).

[OskarLinde]

The thing is, Nef polyhedrons are intrinsically guaranteed to be orientable quasi-2-manifolds. Quasi-manifolds in the sense that edges (and vertices) may be shared between two volumes (e.g. cube(); translate([1,1]) cube();), but all surfaces are still closed manifolds. I.e. all points in 3D space can unambiguously be classified as either outside, inside or on the boundary of the object. (Which should be all that is required for e.g. 3D-printing)

What Nef polyhedrons can also contain (but which could basically be prevented by OpenSCAD by utilizing the correct boundary conditions), is infinitely thin "slivers" (i.e. zero volume objects), lines and points.

For exporting to STL/OFF and similar, these things should basically not matter. All Nef polyhedrons are convertible to STLs. OpenSCAD fails ("Object isn't a valid 2-manifold! Modify your design.") due to making the conversion via conversion to a single CGAL::Polyhedron, which require each edge to be part of a proper 2-manifold (i.e. maximally 2 facets must be incident to one edge). There are two simple solutions to that:

1. Instead of taking the path through a CGAL::Polyhedron, just export the facets directly from the Nef polyhedron. For the STL format, this is is not a problem since all vertices are duplicated once per facet anyway. For the OFF format, an importer may assume 2-manifold status of the mesh topology and fail importing.
2. Divide the Nef into a set of proper 2-manifold volumes*. The shared vertices between such volumes are duplicated making sure that the resulting OFF file contains several volumes, each having a valid 2-manifold topology.

It is possible that certain software may fail importing STL/OFFs that contain multiple volumes (or multiple touching volumes). For these cases, we could simply offer the option of exporting the different volumes as separate files. I don't know if this is a real issue or not.

*) I have implemented a simple such method that I could potentially port to OpenSCAD if of use.

[MichaelAtOz]

ahh i didnt realize the output had changed... no more # of faces etc etc. . hrm.

BTW, note those stats are shown for other designs, auto-union it with a sphere(5) for example (a sphere by itself doesn't show them). It then shows as valid too. (yes I know this is explained by above, but such inconsistencies, if kept, will need to be documented)

[kintel]

1. in the comment from @OskarLinde has been implemented. 2. is still interesting. @OskarLinde If you have any code for doing that, in OpenSCAD or stand-alone, I'd be interested.

[kintel]

I'm closing this, as our latest iteration of exporters now use an indexed PolySet implementation, where vertices belonging to different volumes have been duplicated. This works nicely for the Manifold backend. There may still be some corner cases for CGAL, but since this ticket is getting old, it's probably better to open new tickets for current issues.