Not Slicing correct

[S3D-Alex]

This...actually...is the first time I think the question has been asked.....and I would also be very interested in an answer.

Simplify3D currently honors the STL specification. The Separate Connected Surfaces tool is not really intended to be used as a mesh repair option but admittedly it does work well quite often for scenarios like this.

I seem to have to run every file through Netfab in order to print in S3D. Even simple ones. Perhaps it is the program I am using to create parts (Sketchup) or the program that converts to .stl. ????

I took a look at the original file that was posted and it seemed like using the "Remove duplicate triangles" option allowed this to slice fine. It is tough to know what series of events caused the errant STL file but it looks like the top portion was duplicated causing the section to be non-manifold. Non-manifold triangles will not slice. I included a screenshot below showing the duplicated section.

[dkightley]

Simplify3D currently honors the STL specification. The Separate Connected Surfaces tool is not really intended to be used as a mesh repair option but admittedly it does work well quite often for scenarios like this.

Alex.....

The question I was referring to is illustrated in this post:
viewtopic.php?f=9&t=3096&p=13417&hilit= ... ces#p13417

And the question is...Why does every other slicer manage to treat interlaced meshes within the same file correctly...and S3D end up with the printed parts "broken" into two or more parts that usually fall apart..UNLESS you use the Separate Connected Surfaces option to force the meshes into separate files...and then S3D slices the separated parts as if they were one????

This is probably one of the most frequent issues that many users get.....and it was, for some, a show stopper until the Separate Connected Surfaces option was introduced...which allowed previously "S3D unprintable" parts to be printed. And its not a solution, but a "fudge"!!

[S3D-Alex]

Simplify3D currently honors the STL specification. The Separate Connected Surfaces tool is not really intended to be used as a mesh repair option but admittedly it does work well quite often for scenarios like this.

Alex.....

The question I was referring to is illustrated in this post:
viewtopic.php?f=9&t=3096&p=13417&hilit= ... ces#p13417

And the question is...Why does every other slicer manage to treat interlaced meshes within the same file correctly...and S3D end up with the printed parts "broken" into two or more parts that usually fall apart..UNLESS you use the Separate Connected Surfaces option to force the meshes into separate files...and then S3D slices the separated parts as if they were one????

This is probably one of the most frequent issues that many users get.....and it was, for some, a show stopper until the Separate Connected Surfaces option was introduced...which allowed previously "S3D unprintable" parts to be printed. And its not a solution, but a "fudge"!!

The thread you link to is a slightly different manifestation of this mesh issue so I will cover these separately below:

The original issue here occurs because there are duplicate triangles making up that upper geometry of the part. For that section every triangle is duplicated and lays on one another with opposing normals. They basically cancel each other out and this results in the shape not existing.

The thread you link to shows two cubes intersecting without being properly merged in a CAD program. This results in a void in these intersecting areas as the normals are again conflicting with one another. The normal tells the slicer what is the inside of the model and what is supposed to be the outside which is why you see these sections seemingly just not slice. They are indicated as being empty space by the model so that is how the slicer interprets it.

These issues both lead back to a core concept. An STL file in the world of 3D printing is simply a way to communicate with the slicer. There is a right and wrong way to make an STL. Simplify3D currently assumes the STL it is interpreting was created correctly.