Jump to content
Ultimaker Community of 3D Printing Experts
Sign in to follow this  
bhudson

Precisely overlapping faces fool Cura slicer

Recommended Posts

Here's a very simple STL file; it consists of two cubes that are precisely overlapping. I generated this procedurally (a python script).

Cura with default settings (fix horrible type A) slices this to have one cube filled, and the other cube empty with no top or bottom layer.

The problem seems to be that in the middle of the model, there are two quads in exactly the same place -- bitwise identical -- pointing in opposite directions. The slicer seems to have trouble determining what's in and what's out.

"Keep Open Faces" seems to help a bit, but it's still only generating a shell on the one cube, not both.

Adding "Extensive Stitching" and "Keep Open Faces" seems to get the best results here. However, I'm not just printing two cubes -- that was a small test example related to my big program (imaginary-spaces.com) that procedurally generates buildings. And there are scenes that sometimes I can't get to print properly.

An example that I can't get to print nicely:

https://drive.google.com/a/imaginary-spaces.com/file/d/0B8Xjxc1Q7X_LM0poSUtwQl9NN28/view?usp=sharing

With just Type A, half the walls are empty. Adding "keep open faces" leaves a gash. The gash doesn't close up when I add extensive stitching. With just extensive stitching I get the best result, but still no top on the three windows, and still that weird gash (which is not present in the STL file itself).

My program is outputting chunks of wall, windows, and stairs procedurally, one by one. They land at bitwise identical locations because that's how the math ends up. I am wondering what I could do that would help Cura discover what's in versus out.

 

Share this post


Link to post
Share on other sites

Perhaps I don't understand, and I'm on a tablet right now so can't test it, but two butt-jointed cubes would make an illegal shape if any internal faces remain. That would place the bug in your 3D design software, not in Cura.

 

I'm not blaming anyone, I'm asking how to fix the issue. Surely there's a way to tell Cura "this is a cube, its interior is this way" and "this is another cube, its interior is the other way".

 

Share this post


Link to post
Share on other sites

I looked at your "this busts cura" stl file. The file is perfect except for that one picture frame near the bottom of the stairs. You can tell by doing "xray view" and anything in red means a beam of light in that direction passes through an odd number of walls. This means there is either an extra wall or a missing wall.

Once you fix that, you should be able to uncheck all the fix horrible settings except leave "keep open faces". You need that because your surface normals are messed up. Did you do this in sketchup? Sketchup by default has walls that are gray on one side and white on the other. If you don't want to have to check "keep open faces" you have to make sure only white walls are visible I believe. It's trivial to swap - you select a bunch of gray faces, right click and do "reverse faces" or something like that.

 

Share this post


Link to post
Share on other sites

By the way, some people actually want an air pocket in their model. Maybe they want a cube with a spherical hole in the center and they can drop a marble in the hole when the hole is 3/4 done printing. Who knows. So one should be able to model that and print that. Cura lets you do that. Having "interior" walls confuses things.

 

Share this post


Link to post
Share on other sites

Directly touching faces (100% overlap) currently confuse Cura. As it removes duplicate faces. Which is most likely why your model goes wrong.

If I disable the face removal code (direclt in the engine). I get this result: (with default settings)

ehKlTB2.png

I'll have to check what other side effects will be from not removing duplicate faces. But I'm surprised how much difference this made!

 

Share this post


Link to post
Share on other sites

gr5: I did this in my game, http://imaginary-spaces.com. I generate all the geometry in my code, but it's a bunch of separate objects -- there's windows, stairs, walls, floor, all of them procedurally generated. The normals are correct in all the other software packages I've used (unity, meshmixer, meshlab, blender, ...), so I'm surprised you think they're backwards for Cura -- how do you see that? Also, the picture frame doesn't matter; I took it out and got exactly the same behaviour.

Daid, cool! But that seems to point to a bug: in the cube example, if you remove the four triangles in the middle, you'd get a long rectangular prism with normals all pointing out, and life should be good. So there's apparently some bit of logic that gets confused.

Following this lead, I loaded up this-file-busts-cura (apologies to Guthrie) in blender and removed one of the overlapping quads between the wall and the first window clockwise from the stairs. That let that window print correctly. Other parts were still wrong (unsurprisingly), and the weird gash showed up elsewhere.

Now I'm looking for free software that can post-process an STL file and fix polygons that point opposite each other... anybody hear of some?

 

Share this post


Link to post
Share on other sites

You mean automatic post processing? I'd be surprised if such a thing exists (to clarify: I'm sure that someone is willing to charge money and make grand claims, I just doubt that it'll always work), since no software can know what you intended, it can only see what you did.

3D printing is not like other 3D modelling applications such as the ones you mention. STL is a language - it can be used to describe any shape, whether it could exist in reality or not. But a 3D printer can only print the former.

 

Share this post


Link to post
Share on other sites

Don Milne: The precise problem definition I might write as: you have a bag of triangles in R^3 and a normal for each. For each triangle, find a connected flat region with the normal in one direction, and a connected flat region with the normal in the opposite direction. Find their geometric intersection, delete it. This is a trivial problem, by which I mean, I could imagine sending a fourth-year student to solve this for an independent project and I'd give them an A for effort when they don't quite finish.

Daid's result and the fact that the staircase doesn't cause trouble indicates that it wasn't as bad as solving that full problem: seems that the problem is only if you have a set of triangles on one side that has the same vertices as a set of triangles on the other side (maybe it's just quads?). That's a much easier problem; I'm surprised I couldn't find any free software to solve that. So I spent the afternoon writing it up in my export process.

Removes 28 triangles from my test scene, which is exactly the number I expect (6 wall-window and 1 window-window connections, 4 triangles each), and the following loads exactly as I hoped with default options:

https://drive.google.com/file/d/0B8Xjxc1Q7X_LOFZON0x1STM1bWM/view?usp=sharing

 

Share this post


Link to post
Share on other sites

Daid, cool! But that seems to point to a bug: in the cube example, if you remove the four triangles in the middle, you'd get a long rectangular prism with normals all pointing out, and life should be good. So there's apparently some bit of logic that gets confused.

 

The current code only removes half of the duplicate faces (so it removes till there are no more duplicates).

Previously this was needed on very high resolution models (UM robot for example). But with the code behind it being more rubust, it looks like this is no longer needed.

I'll build a test version today or tomorrow.

 

Share this post


Link to post
Share on other sites

The precise problem definition I might write as: you have a bag of triangles in R^3 and a normal for each. For each triangle, find a connected flat region with the normal in one direction, and a connected flat region with the normal in the opposite direction. Find their geometric intersection, delete it. This is a trivial problem, by which I mean, I could imagine sending a fourth-year student to solve this for an independent project and I'd give them an A for effort when they don't quite finish.

 

Yes, I can see an inexperienced person believing the problem was as simple as that. I take it then that you've never tried anything like this. If you had then you probably wouldn't believe that using terms like "connected", "flat", "opposite" etc served as a precise problem description in a floating point universe - in fact none of those can be mathematically tested using less than infinite numerical precision. And finding 3D intersections itself is an NP complete problem (a variation on nearest neighbour), so hardly trivial. Any student who solved that shouldn't just get an A, they should get a Nobel prize.

Let's set precision aside and look at another issue. How does the software know what the normals mean? (answer: the assumption is that only outside faces are defined, and all normals point outwards, but you already violated that).

What I'm saying boils down to: I'm surprised that Daid is entertaining your suggestion at all. He must know that the old rule applies: garbage in, garbage out, and that nothing he can do will change that fundamentally.

 

Share this post


Link to post
Share on other sites

What I'm saying boils down to: I'm surprised that Daid is entertaining your suggestion at all. He must know that the old rule applies: garbage in, garbage out, and that nothing he can do will change that fundamentally.

 

However, Cura does try to do it's best under these conditions. And, a small patch shows that it can do better.

And, because building new versions is really easy now. You can give this change a spin with the version at:

http://software.ultimaker.com/Cura_closed_beta/

 

Share this post


Link to post
Share on other sites

OBJ is much better, but still has its own problems, e.g. AFAICT it doesn't seem to have a binary option (unlike STL), which encourages applications to output in very low precision ascii floating point. On the other hand at least it references vertices by index rather than repeat them, so at least the model shouldn't fall apart due to precision problems!

I wrote an OBJ parser just a couple of weeks ago for my own 3D viewer, just added colour and transparency support last week in fact, so this is all quite fresh! :)

 

Share this post


Link to post
Share on other sites

If you had then you probably wouldn't believe that using terms like "connected", "flat", "opposite" etc served as a precise problem description in a floating point universe - in fact none of those can be mathematically tested using less than infinite numerical precision.

 

Funny fact, the CuraEngine converts everything to 64bit integers, in microns. To prevent odd rounding problems. After that it merges all vertexes that are within 10 microns, just to close up any imperfections in an otherwise perfect model (but not saved perfect due to rounding errors)

And that's before any magic happens :-)

 

Share this post


Link to post
Share on other sites

point above about model being correct is the first priority, but you can look at meshlab and some of the filters there. i've had some success with that doing a per face quality function and then selection for faces of lower quality, it can find hidden faces. I know this is not actually what your looking for with side by side faces, maybe give it a shot.

 

Share this post


Link to post
Share on other sites

gr5: I did this in my game, http://imaginary-spaces.com. I generate all the geometry in my code, but it's a bunch of separate objects -- there's windows, stairs, walls, floor, all of them procedurally generated. The normals are correct in all the other software packages I've used (unity, meshmixer, meshlab, blender, ...), so I'm surprised you think they're backwards for Cura -- how do you see that? Also, the picture frame doesn't matter; I took it out and got exactly the same behaviour.

 

I didn't see "backwards normals". You didn't mention how you created your STL file at that point in the conversation and a *lot* of people use sketchup - and sketchup is particularly popular among architects and this looked like a building so I just guessed. I have to do that a lot (guess) as many people won't even post pictures.

 

Share this post


Link to post
Share on other sites

.obj is superior in a lot of ways to .stl - distinguishing objects, you can have textures and texturemaps (eg. for colored prints) and so on, but it is proprietory. So you have to license its usage.

 

Really? I wasn't aware of that... and I'm not sure what the basis would be either. As far as I know you can't either copyright or patent a data structure. The only thing you might license from Wavefront is an SDK - which doesn't apply to me as I wrote my own code.

 

Share this post


Link to post
Share on other sites

Funny fact, the CuraEngine converts everything to 64bit integers, in microns. To prevent odd rounding problems. After that it merges all vertexes that are within 10 microns, just to close up any imperfections in an otherwise perfect model (but not saved perfect due to rounding errors)

And that's before any magic happens :smile:

 

Yes, I've investigated similar fixed precision conversion schemes. Of course that is workable for some applications, but it involves making arbitrary decisions as to the rounding direction - and when you have two faces that were defined to be exactly overlapping in the same plane then there just isn't any robust way to choose a z-order, at least not without some really complex fuzzy logic. I assume you also round the normals? So that two adjoining faces can end up with slight different normals which is visible when you shade the faces (at least that's one of the problems I hit when I tried a similar idea).

 

Share this post


Link to post
Share on other sites

Funny fact, the CuraEngine converts everything to 64bit integers, in microns. To prevent odd rounding problems. After that it merges all vertexes that are within 10 microns, just to close up any imperfections in an otherwise perfect model (but not saved perfect due to rounding errors)

And that's before any magic happens :smile:

 

And that answers the question I came back here to ask... 10 microns, thanks!

I've been doing 1/256 meter in-game, which is 1/256 cm when I output at 1:100, or about 40 micron. When I scale that down to .1 scale in Cura to get a quick prototype, I was noticing weird things happen in some cases -- that explains some things.

 

Share this post


Link to post
Share on other sites

the data is ASCII. It would be quite hard for them to track who uses it.

and here is what Wikipedia as to say about it:

 

OBJ (or .OBJ) is a geometry definition file format first developed by Wavefront Technologies for its Advanced Visualizer animation package. The file format is open and has been adopted by other 3D graphics application vendors. For the most part it is a universally accepted format.

Share this post


Link to post
Share on other sites

Proprietary just means it is designed and/or controlled by one company, rather than being an officially recognized standard (e.g. ISO/ANSI/CCITT). The term has nothing to do with licensing.

In any case, as I mentioned before, you can't copyright or patent a data structure, nor have I signed any NDA, nor licensed an SDK. There's nothing civil or criminal which Wavefront can threaten me with. I'm a software developer, formerly freelance (situation very similar to Daid's I recently noticed) so believe me that I make it my business to know the law in this area, at least in parts of the world I operate in.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Our picks

    • "Back To The Future" using Generative Design & Investment Casting
      Designing for light-weight parts is becoming more important, and I’m a firm believer in the need to produce lighter weight, less over-engineered parts for the future. This is for sustainability reasons because we need to be using less raw materials and, in things like transportation, it impacts the energy usage of the product during it’s service life.
        • Like
      • 12 replies
×

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!