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".
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.
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.
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)
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!
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?
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.
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
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.
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.
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/
And of course, the solution with the intersection does not take any form of order into account. It would mean that you get different results if you started at a different location.
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! 
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 :-)
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.
You could simply use the structure of .obj but with a different extention right?
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.
.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.
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).
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.
I'm not aware that use of OBJ needs a license from Wavefront (presumably Autodesk now). Do you have any evidence of that?
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.
no harm done. Who knows. You might be the one right in the end 
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.
ArunC posted a topic in UltiMaker Cura,
.thumb.jpeg.0b7a05eafc09add17b8338efde5852e9.jpeg)
Dustin posted a topic in Firmware,
Recommended Posts
donmilne 2
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.
Link to post
Share on other sites