MakerBot Print is our newest print-prepration software, which supports native CAD files and STL assemblies,
allows you to interact with all your printers via the Cloud, and many other exciting new features.
I can import an stl file, render it and export it.
Which, by itself, is completely useless.
As soon as i apply a difference operation to the imported stl, it refuses to render.
I can get an f5 preview but as soon as i try and get an f6 render, the stl vanishes and I get this message:
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: pe_prev->is_border() || !internal::Plane_constructor::get_plane(pe_prev->facet(),pe_prev->facet()->plane()).is_degenerate() File: /opt/mxe/usr/i686-w64-mingw32.static/include/CGAL/Nef_3/polyhedron_3_to_nef_3.h Line: 251
I used to be able difference imported stls.
I usually run the latest development version of openscad.
Thought that might be it, but having downgraded to the 2015 current recommended version. I get exactly the same thing.,
The complexity of the imported stl doesn't seem to make any difference.
Anybody got any ideas ? It's really bloody annoying.
The idea of learning a wysiwig cad program fills me with dread, but this is bloody ridiculous.
Without knowing what STL file, and without knowing what you were doing with it, very hard to say. Means either the STL or your project is broken, usually. Bug is possible but all the times it's happened to me, been a bad STL.
And "bad STL" usually means orphaned polygons, non-manifold objects, overlapping polygons, etc, etc. Could be a million things. If the object is simple enough, you could import it into Blender and go hunting for defects.
CA, what version are you running. Ijust did a simple import of an stl and a difference with a cylinder. Worked fine. I am using Windows 10, OpenSCAD version 2019.01-RC3
windows 7 - I'll run windos 10 on one of my machines only as an absolute neccessity when 7 dies in about 10 years time :-)
I've tried different versions of openscad - as I stated. Why does nobody read all of a post ?
Well, if I just stated it worked for me, without stating the environment it worked in, that would be a useless piece of information for you. Good Luck
This happens occasionally, especially if the stl is broken somehow. Sometimes I've succeeded fixing things by running the stl through Meshmixer inspector or MS 3DBuilder (it asks to fix the stl if there are errors). However, many times the problem seems to be what you do to the file, for example using difference to remove stuff might break the render and it seems that if the resulting object has some really tiny geometries after the operations, it will break. Tuning the placement and sizes of the removed geometries might help,
Also you could try flushing the caches before the render, I remember getting at least one part rendered with that trick, but it might have been different problem that time.
CA, I was able to import an STL and make a hole in the center with a difference operation.
Note that I an using Windows 10, openSCAD version 2019.01-RC3
Here is the console output:
Copyright (C) 2009-2019 The OpenSCAD Developers
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
Loaded design 'C:/Users/mark/Documents/OpenSCAD/testSTL.scad'.
Compiling design (CSG Tree generation)...
Compiling design (CSG Products generation)...
Geometries in cache: 2
Geometry cache size in bytes: 331216
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Compiling design (CSG Products normalization)...
Compiling highlights (1 CSG Trees)...
Normalized CSG tree has 2 elements
Compile and preview finished.
Total rendering time: 0 hours, 0 minutes, 1 seconds
Parsing design (AST generation)...
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 3
Geometry cache size in bytes: 332808
CGAL Polyhedrons in cache: 1
CGAL cache size in bytes: 3065552
Total rendering time: 0 hours, 0 minutes, 3 seconds
Top level object is a 3D object:
You did try to only import it, to render it and to write an STL. If that works, maybe that exported STL will work?
If not, you can try as PGraaff says, or import it into slic3r check it by slicing it and export it to STL. Works 9 out of 10 times for me. Meshmixer has also a great repair tool.
Sorry, I can't really offer any advice but my thing here: https://www.thingiverse.com/thing:3529157 relies on importing an stl and taking away the stl as difference. Can confirm it works in that model. Hopefully you can use it to diagnose your problem. Best of luck!
Sometimes it helps to load an STL into the 3D builder of WIN 10 and to store it. The 3D builder can repair STL-files and it's handy to place objects at 0,0,0 or what you want. Imported STLs sometimes are somewhere in the 3D room.
don't use windows 10 - just too many issues with too many things.
I can get round most of them - but, yeuuchhh, why bother when windows 7 is so much better.
I will add I can't import the image as a dxf files either. Even with drag and drop. openscad generates the link but nothing appears on screen.
Oh yeah, this is not the first imported stl I've had issues with. Tried importing a bunch of skulls last week. Again, all appeared to work until you used them in a difference operation - then it either crashed or just plain didn't work. All files have been checked, all work well on the f5 preview. All tested stl files slice in various slicers without any issues.
Just wondering if cgal (which appears to be the program that actually renders models) could be somehow corrupted. I have definitely successfully done difference operations on imported stl's in the past.
The current imported file is a jpg I extruded and cropped in flashprint.
Like I said I can import and render it without modification.
I'm just wondering if I've tried to re-import the file that openscad rendered itself. Pretty sure I save it in a different folder, so I'll try importing it back into openscad next.
If openscad has problems with an stl file that it rendered itself - then there's a problem somewhere. But don't think I've tried that yet.
Like I said I have tried converting the original jpg to a dxf - but that just say's it's imported and then does nothing. Might have to load gimp and try through that. I just used an online convertor. So no clue what sort of dxf file it generated.
Cheers for attempts to help :-)
It cannot be said often enough:
The STL you use must be absolutely error-free, no holes noinside-out triangles, no degenerated faces etc.
"If openscad has problems with an stl file that it rendered itself - then there's a problem somewhere ..."
Nope. If there is no manipulation of the mesh needed, OpenSCAD simply writes the STL as it is (with the errors). OpenSCAD didn't repair!
well after running it through the fix stl options in various slicers - none of which made any difference. I loaded it into tinkercad, exported it - without doing anything - back to my computer, and it now works :-)
So yes Bernd, it was something in the file that tinkercad somehow changed, but nothing else did. weird.
So I now have a method to make working imported stl files, if no idea why it works :-)
For me, this has been a thing that happens with some models. They can appear perfectly fine in every other tool, but they won't import and interact with OpenSCAD. What can sometimes fix some models is to import them into OpenSCAD then intersect them with a cube that fully encloses the STL model. An OpenSCAD export from that produces an STL that's functionally identical to the original but seems to work with OpenSCAD. It bugs me that I don't know why this can work, but I still rely on it.
Slicers can generally swallow problems. OpenSCAD is not a slicer, it does everything the hard way, and needs perfect geometry.
These problems usually aren't very mysterious. Open a problem-child STL in blender and I usually find one or more of the following:
And the finer the model, the more likely this is, since the precision of an STL file is not infinite. Subdivide too far and points will start to occupy the same place.
I had run the file through the fixing options in fashprint and simplify3d - both said there was nothing wrong with it. Also exported from simplify3d in bin and ascii formats.
The interesting thing is that the stl file that tinkercad exported was half the size of the same file I'd imported.
So I don't think it's necessarily geometriy issues with stl files that openscad dislikes, there does seem to be a variety of types of 'stl' files. Some of which it just doesn't get along with.
But I can recommend the 'import, export' fix with tinkercad. Quick, simple and seems to produce an openscad friendly .stl file.
Obviously only tried the 2 extruded images so far (making keyfobs in the shape of animals) I'll have a go with the skulls I was fighting a couple weeks back. Ended up modelling one from scratch that, actually came out really well. But they're much more complex files that openscad would happily preview but not render.
"Fixer programs", not being psychic, only fix a few kinds of problems. The worst ( and most common ) kinds of problems are spots where the mesh is ambiguous.
How are overlapping triangles fixed, for example? By moving them -- but moving them where? A computer program doesn't know where they're supposed to belong and might do something awkward instead, like deleting one then filling the hole.
Degenerate triangles are even more ambiguous - little spots of divide-by-zero which act like holes but are actually triangles squashed all the way down to lines. The computer can't tell if they're overlapping something else, or what direction they're facing. Properly fixing them means altering the surrounding mesh and completely redoing that entire group of faces to avoid that situation - or, in short, possessing human abilities to know what the object is intended to look like and the ability to plan ahead.
Occasionally mesh simplification can solve it. Sometimes it makes it worse. Simplifying doesn't make the geometry better, after all, just bigger and bigger until the problem triangles aren't ambiguous any more.
Hmm maybe Tinkercard simplifies the mesh somehow? Meshmixer also has mesh simplification functions, might be worth a try also...
pretty sure that's what's happening. I will add that none oif the stl's I've had issues with in openscad, had any problems picked up by any other program. But the exported file from tinkercad is consistently at least half the size of the original. Looks fine, and works great in openscad - so I don't appear to be losing anything worth keeping :-)
Tinkercad exports binary STL files. These are much smaller than the ASCII STL files that OpenSCAD creates for the same model.