Easy lithopanes with Simplify3D

[Tim]

The hole-filling bad behavior in S3D seems to be quite common.

I found a similar error in a (standard flat) lithophane I created, in which S3D drew a boundary around an area and then filled a boundary inside of that that was supposed to be unfilled. I think it uses some sort of flood-fill algorithm to identify internal and external areas in each slice, but clearly it's buggy.

So I sent the factory file to S3D and told them they had an error. Predictably, they came back with a response that my mesh was non-manifold. It was trivially non-manifold, and I was sure that that was not the problem. Whatever happened to "the customer is always right"? Obviously it is not a familiar concept in the closed-source software world. Anyway, they had a marginally valid point, so I rewrote the lithophane program to make sure it was manifold. Sure enough, the manifold version has the same slicing errors. So I sent it back to S3D and will see what they have to say about it.

In the meantime, my first version of the correctly-manifold lithophane generator generated output in the Wavefront .obj file format. I read up on the format on Wikipedia, and noting that a facet in Wavefront can have more than three vertices, I had corrected my non-manifold error by splitting one side of the offending triangle into a lot of segments, making a big polygon out of it, since that was allowed by the format specification. When I read this into S3D, it turned the multi-point polygon into a triangle, discarding everything after the first three points! So S3D does not read Wavefront .obj files correctly. I sent them that factory file too, for good measure. I also checked the same file by reading it into Wings3D, which correctly parsed it, so I know I have the .obj format correct. It's S3D that's at fault (again).

Toby---if you have a slicer and a toolpath generator, you have a business! Treat customers like real people, and you could probably put S3D out of business in a few months.

[Toby]

Oh, that's right... I remember now S3D doesn't like anything more than 4 sided-polygons in an .obj file. Not a problem to decompose convex polygons into triangles before writing the obj file, but the non-convex case isn't trivial. Which is probably why they don't do it for you. iirc, Netfabb is ok with reading them and when they output the same model in obj format they turn it all into triangles for you.

[Toby]

Toby---if you have a slicer and a toolpath generator, you have a business! Treat customers like real people, and you could probably put S3D out of business in a few months.

Too much for me to take on at the moment. But the field is wide open, imo. The current crop of slicers leave a lot of room for improvement.

[ednisley]

It was trivially non-manifold, and I was sure that that was not the problem.

Well, things obvious to humans generally aren't all that easy to describe mathematically and whenever I'm positive it's not my problem, it is. [grin]

Fixing a non-manifold object requires deciding which parts are correct, then adjusting the rest to match. This is absolutely non-trivial, particularly when you expect it to work all the time, without human intervention.

For example, I recently kibitzed with a guy on his very first model. He really, really, really wanted to use Sketchup, although I pointed out that it's really, really, really easy to build crappy, non-manifold, un-sliceable models. So he built his model, which was basically a rectangular box with a separate cover, and both had their largest inside surface "backwards": the surface normal was reversed, so both planes were oriented in the same direction and less than 1 mm apart. Classic Sketchup blunder; everybody does it.

All the slicers & mesh fixers came to the same conclusion: it looked like he intended to remove that big rectangle entirely and just misaligned it, so they chopped both planes out of the model, fixed up the holes, and left four walls standing.

Of course, that's not what he meant, but it's a perfectly reasonable assumption under the circumstances.

Rule of thumb: never ask algorithms to fix your mistakes. It won't end happily...

[Tim]

Hello Ed,

Well, this particular case was generated from code that I wrote myself, and I have been doing geometric computer algorithms for about 30 years, including appropriately related things like tesselation of non-convex polygons. So I was actually being careful to keep the object perfectly manifold. For the border edge, though, I have what is basically a simple rectangle with the side facing the lithophane image being divided into many short segments. If I draw the border as a simple rectangle (actually two triangles, but the principle is the same) with the edge facing the image being a single line, the single line of the border matches up perfectly with all the line segments running up the side of the image. In some sense it is correct to call this manifold, but I can see that a slicer may not want to see a line running through vertices like that.

At any rate, the non-manifold edge was on a convex polygon, so it was fairly simple just to go ahead and break that line up into the same number of segments as the matching edge, and then turn it into a triangle fan. At which point S3D agreed that it was perfectly manifold but screwed up the slicing in exactly the same way, so my intuition was right in this case: S3D was properly handling the non-manifold edge. But, yeah, you have to be pedantic, especially if you're submitting a bug report. If you give the developer a pretext, they'll take it.

[jsc]

I've had manifold objects with slicing artifacts in S3D. I'm pretty sure it happens when a vertex elsewhere ends up very near a slicing plane, and some floating point instability decides the outside is now the inside for that layer.

S3D certainly has its share of bugs, but no slicer is free of them.

[Tim]

Hello Toby,

I have updated the model that I made of the world globe. Although the previous one was claimed to be manifold by S3D, after I made some edits to the C code, it was no longer manifold, in such a way that I'm not sure why it was supposedly manifold before (basically, it's a roundoff error in the result sin(x) between x = 0 and x = 2*pi, presumably because in floating-point, 0 is exactly 0 but 2*pi is not exactly 2*pi). The edits I made to the C code were to support the Wavefront .obj format, so I'm including that output, too. I am totally swayed by your argument about the superiority of the .obj format vs. the .stl format.

http://opencircuitdesign.com/~tim/archi ... obe.stl.gz

http://opencircuitdesign.com/~tim/archi ... obe.obj.gz

Here's an interesting fact: When I slice this model in S3D, if I include support structures, S3D goes into an infinite loop and I have to kill the process. If I don't include support structures, then it finishes the slicing, but has the same kind of hole-filling errors as I got for the flat lithophane (except these are globe-filling errors, and are probably very detrimental to the print). Also, its toolpaths gobble up 8GB of memory very quickly and gets bogged down in page swapping. Slic3r, on the other hand, slices the model correctly. It is predictably much slower, but it is error-free and has a low memory overhead.

[Toby]

I tried the new lithoglobe and it sliced in S3D, with or without supports. The support case took a couple of minutes but I couldn't see any of the hole-filling errors. The non-support case was clean also.

I've attached the .fff file I was using in case you want to try it. I assume you're using v2.1 (not v2.0.1)?

Note: this .fff file is just what S3D happens to load with on this pc. I wouldn't trust it for printing anything. I think it started life as part of .factory file I was test printing for someone else to see if I could reproduce an artifact he was getting with his settings.

On the S3D memory usage: yeah, it's extreme. And the leak is very annoying. They really should clean up after themselves better. I have to regularly exit S3D and restart it just to keep my laptops memory usage within bounds

[Tim]

Hey Toby,

Interesting. Your .fff file really works. I changed a few key parameters and it still worked, but there must be something else different about that setup and the one I was using that's the key to making S3D go off into la-la land. One major difference I saw was that the extrusion width was set manually to 0.35, while I had mine set to auto, which was setting itself to 0.4. But every time I change parameters to test whether or not it works, if it works, then it fills up my memory and it takes a bit of work to get my computer back to normal. So I haven't tried too many settings changes, yet, including the extrusion width. I'll give that a try tomorrow.

But I think the last setting I used would work decently for a PLA print. Of course, it's filling the whole globe with support structures and says it will be a 17 hour print, so I'm not quite ready for that. . . Nobody ever said that 3D printing a globe would be easy.

[Toby]

Strange. That .fff file really was random. It's not my settings at all. I'll have to try to slice the globe on my usual settings, which sets the extrusion width to automatic. But now I'm afraid to given your experience...