On 5/28/2022 9:16 PM, Daniel Harvey wrote:

Kind of.

Hollows count too.

If you have nothing, that's one volume - the universe.
If you have a sphere, that's two volumes - the sphere, and the rest of
the universe.
If you have two non-touching spheres, that's three volumes - sphere A,
sphere B, and the rest of the universe.
If you have one hollow sphere, that's three volumes - the shell of the
sphere, the inside of the sphere, and the rest of the universe.
If you have a hollow sphere with another sphere inside it, that's four
volumes - the shell of the outer sphere, the hollow space, the inner
sphere, and the rest of the universe.

Does that make sense now?

Thanks for the explanation Jordan.
Maybe you can help shed some light on this issue I am having and the
strange volume behavior...
I am trying make a model of something that is essentially a tube (ie a
hollow cylinder) with a lattice structure inside the tube.
I wrote a module that can create a lattice (using long, thin "cube"s) , and
did the following test
difference() {
cylinder(d=33,h=23,$fn=120); // bigger shorter cylinder
difference() {
translate([0,0,-1]) cylinder(d=30,h=25,$fn=120); // smaller taller
cylinder, offset to pierce the above
cubicXLattice(); // sized bigger than either
}
}
The rendered result has 5 volumes, despite the render of the tube having 2
(its surface and the universe). I then cut into it by subtracting a cube
from it, and the result had 10 volumes. Is there any way to interpret this
other than that the lattice is flawed somehow - that it somehow isn't one
volume (despite being made up simply of many intersecting cubes, and
despite the render of the lattice alone reporting 2 volumes)?

[image: Messages Image(1412952642).png]
[image: Messages Image(3806480974).png]

On Sat, May 28, 2022 at 10:22 PM Jordan Brown openscad@jordan.maileater.net
wrote:

On 5/28/2022 9:45 PM, Daniel Harvey wrote:

Absent the full model source I can't experiment, but I have a guess or two.

Guess #1:  where the lattice touches the shell, there may in some cases
be small enclosed voids.

Guess #2:  in corner cases where you chop the lattice off, there might
be small orphaned objects.

Guess #3:  Computational imprecision (e.g. the fact that cylinders are
really polygonal, or that floating point values are not precise) might
be throwing a wrench into the works.

The A-(B-C) structure that you've used is somewhat hard to reason about
when the objects are not simple.  I assume that you're doing it at least
partially to cut the lattice into a cylinder.

You might try instead something like

id = 9;
od = 10;
overlap = 0.2;
h = 10;

difference() {
    cylinder(h=h, d=od);
    cylinder(h=h*3, d=id, center=true);
}
intersection() {
    lattice();
    cylinder(h=h, d=id + overlap);
}

which makes a tube of the specified height with the specified inside and
outside diameters, and then cuts a lattice to the right height and a
little bigger than the ID so that it will cleanly overlap with the tube.

But also:  other than curiosity, why do you care?

Thanks again Jordan. I suspect that the issue is your Guess #3 (the
floating point issue), because this may relate to what has led me down this
line of investigation in the first place.

But first, here's a link to the lattice code if you have time to take a
look: https://www.dropbox.com/s/mmftzhsp938foo5/Lattice.scad?dl=0

The back-story is that I am designing some bicycle frame parts to have 3D
printed from titanium using DMLS and then welded into a frame (in
preference to a machined part). The company that will do the printing
ordinarily works with STP files, and then has a workflow that involves
taking a solid design, introducing wall thickness and structural / internal
support in SolidWorks (eg braces inside tubes), and then adding external
sacrificial structural support to stop the part pulling off the build plate.

But I am more experienced working from an openscad / source-code approach
than trying to design in a GUI, especially when trying to create and
control complex shapes. And before I understood the company's workflow, I
had already created my designs. One of the main components of the designs
are bent tubes that may transition in their cross-sectional shape: each
cross section is part of a "rounded off rectangle" family (encompasses
regular circles). To do this I am creating the points and faces of a
polyhedron via iteration and recursion - the hollow cylinder in the example
is a simple representation of the more complex concept, but demonstrates
some of the same issues. Ultimately, I am trying to reproduce the company's
workflow on the models myself - make them hollow, add internal structure to
make them stronger, etc - given that they cannot perform their regular
workflow on an STL file that openscad produces. I also like the idea of
being able to follow and control the project / design through all phases
myself.

The real problem I am having relates to saving the final models as STL
files, and then trying to reread / import said STL back into openscad and
do further manipulations.
The renders for each of the 3 parts I am making take a couple hours to
complete. To spot check my work, particularly with regards to
cross-sections, wall thicknesses, and lattice interactions, I am
subtracting away carefully positioned / oriented cubes from the final
models in order to cut into the model and make sure things are as they
should be.

In each part, I encounter no CGAL issues at all if I render the
difference() { part_model(); cutting_cube(); } in one operation. Sometimes
the number of volumes is not 2, but otherwise they appear to be entirely
valid. I see no warnings about mesh closures or anything else. And I seem
to be able to difference() the models with any other objects in any
location without issue, which to me is a sign that things with the model
are OK.

But repeating this task of cutting into the models, multiple times, by
doing full renders is time-consuming, so I decided to try doing the
checking operations by: difference() {import(part_model.stl);
cutting_cube(); }.
For the larger/more complex two out of three parts, CGAL finds faults with
the imported STL object, and that has left me with an uneasy feeling about
them that I have been trying to investigate and resolve.The oddity of the
volume number made me pursue this line of investigation, but it might be a
red-herring.

The lattice code I linked to above provides a good example of the problems
I am having. I believe that if you run it, it will create a valid object
with two volumes - a tube supported by an internal lattice. But, at least
in my case, if you save it to an STL, and then import it, and subtract a
cube from it, it will give CGAL errors about CGAL_Nef_Polyhedron.

The CGAL errors from the STL imports have been really troublesome to
investigate. I have played games where I slowly build up the parts from a
simple starting state - take out the lattice, other complex details, make
them no longer hollow...then add these things back in. By doing this I will
get an STL that I can import and modify - and think I am onto something -
but then I will add a detail, run into a CGAL error, and back up to the
prior state that had worked and find that it suddenly no longer does (ie I
try to recreate the previously successful model and save a new STL, and the
new STL will cause CGAL errors after import and modify that the old did
not).

The bottom line here is that I am unsure whether these problems I am having
with the STL import should be cause for concern with the models themselves,
or are just a result of minor floating point issues that stem from
re-reading of a file (rather than using a value stored in memory that is
consistent with the original creation of said file).

No doubt the fact that each polyhedron has 60 steps along its length, and
120 segments around it, is contributing to these issues... not to mention
the large lattice. But I obviously don't want to see facets in the parts
that are made, and want a fine lattice to provide uniform structure.

Would greatly appreciate your further insight. Photos of the rendered parts
attached also.

[image: Messages Image(1539228526).png]
[image: Messages Image(2485843806).png]

On Sat, May 28, 2022 at 11:02 PM Jordan Brown openscad@jordan.maileater.net
wrote:

I have not examined your situation closely, but if you get a CGAL error on
import of an STL, it means the STL was bad when you saved it.  It is
possible to have an invalid model and CGAL "doesn't notice".  I don't know
exactly the circumstances of this.  But I have created a polyhedron that
was bad and added a cube to the model and it still works in CGAL and then I
put the cube somewhere else and it fails.

On Sun, May 29, 2022 at 1:25 PM Daniel Harvey dwaharvey@gmail.com wrote:

If you save an STL from OpenSCAd and load it back it will often have errors
because of the truncation to float causing close vertices to collapse. To
make valid STLs you have to ensure vertices are never too close and that
can be almost impossible when two curves intersect in 3D.

On Sun, 29 May 2022 at 18:34, Adrian Mariano avm4@cornell.edu wrote:

Try rotating the block of mesh 45degrees. i.e. rotate([45,0,0]) . when
the resultant stl is imported, it then passes validation OK.

On 29/05/2022 18:24, Daniel Harvey wrote:

Rotating the mesh in the lattice code about the z axis didn't do anything
for me (stl still invalid after saving and importing). I didn't try
rotating about the x-axis because it would have made it the wrong
shape/size for the purpose (filling the cylinder).

Is the consensus that with a complex model with lots of detail that one
shouldn't be surprised if the STL is invalid for import and further
operations within openscad? That as long as I can do operations within the
render that there is likely nothing wrong per se?

On Sun, May 29, 2022 at 1:13 PM Raymond West raywest@raywest.com wrote:

Hi,

rotating around the z axis still leaves the vertical lines of the mesh
// to the cylinder walls. rotating around the x or y makes nothing //. I
didn't fill the cylinder when I rotated the mesh, I just wanted to prove
the point. You could make the mesh volume bigger and rotate. Possibly
try it without rotating, but with only the vertical parts in the centre.
I think, as others mentioned, the rounding errors moves the lines to
interfere with others. i tried something quick in meshlab, to correct
the stl. There were errors, but I know little about meshlab -- it takes
no prisoners - i.e. no undo, so I gave up and tried the angled mesh
approach. I'm not sure if the mesh will add much strength anyway, maybe
a thick wall would weigh no more and be as strong.

In my version of openscad - one of the nightly builds - I can validate
the object. You could possibly isolate the problem, by constructing the
mesh differently - e.g. no vertical struts, see if it fails, then only
vertical struts, etc. As it is, it takers far to long to render, so try
it with a smaller section, and experiment with different lattice
construction. The object is valid as rendered, but not valid when loaded
in from the saved stl. which would suggest rounding errors as others
stated.

If you don't want to make the mesh bigger, than maybe rotate it just a
few degrees. This however, is for your test piece, could be different
for you more fancy shapes.

On 30/05/2022 18:18, Daniel Harvey wrote: