I think there’s something wrong with the STL export in Rhino 7 for macOS!
I’ve noticed a couple of times already, when exporting STLs for Cura - an open source 3D printing slicer - that it shows an error message (“Something wrong with your model…”), when importing the STL.
No, I constructed the entire geometry with straight curve extrusions and at the end did a simple boolean union! JoinEdge wasn’t used!
Furthermore and as mentioned above, when I remodeled the same geometry in Rhino 6 with practically the exact same workflow, everything worked fine!
I also did a test with ShowEdges before exporting, and nothing out of the ordinary showed up! This and the fact that the geometry was closed and solid, should be indicators that the geometry is fine!!
Maybe it’s not a bug related to the STL export, but there sure seems to be something astray here.
Your little workflow is fine, but do you really expect users to do this for each and every geometry every time? Seems a bit tedious to me, especially since the geometry debugging tools already failed miserably.
I’ve had a few STL exports show up flaky in PrusaSlicer.
For whatever reason those same models when exported as 3MF did not have the issues the STL did. Dunno if Cara supports 3MF, but it’s a lot more recent file format, and has a lot more functionality than STL. Might be worth a shot. I export everything destined for slicing as 3MF any more and haven’t had any odd issues since.
What I have noted (both with STL and 3MF) is models I know are spot on (no manifold edges, or any other typical problem children) show up in PrusaSlicer with the yellow label and some number of issues repaired. This happens with every single object I export out of Rhino (and it can be as simple as a couple cubes.
I haven’t worried about it, as there’s never been a single model that PrusaSlicer couldn’t repair, nor any that after said “repairs” didn’t slice correctly. I don’t believe this to be a rhino issue, I think that PrusaSlicer just finds something to whinge about with every single model it imports and I suspect it wouldn’t matter if the source cad was Rhinio, Autocad, Solidworks or Fusion. Again It’s never prevented me from Slicing and printing.
Being as it shows up on stuff as simple as a couple extruded rects that I know there’s absolutely zero chance they could have non manifold edges, naked edges or any of the other typical bugaboos, I pretty much just ignore it.
One thing I do see a lot with 3MF exports is PrusaSlicer thinking the model units are in imperial when the project file is in mm units,. See that one a lot, and just hit the “no” when it asks if I want the inches converted to MM. No idea why that happens either, and it could either be Rhino or PrusaSlicer or the combination of the two. Doesn’t matter as it’s easy to just ignore on import.
Be curious to see if Cura gives you the same grief on the same model when exported as 3MF.
I don’t know how it got that way, but it is surely the cause of the problem. As @John_Brock said, if you explode and rebuild the edges you will see. The bad surface needs to be remade.
@LewnWorx 3MF is supported in Cura and I’ve used it before. And to answer your question, if my Rhino file is in mm, and I export to 3MF, Cura also displays mm as document units.
@Helvetosaur Yes, I understand what @John_Brock proposed to do. However, that’s not my point!
Why aren’t the supposed non-manifold (or naked edges) showing up in the ShowEdges dialogue and why does Rhino recognize the geometry as solid closed polysurface, given that the geometry was broken by the boolean operation (or MergeAllCoplanarFaces)?
This and the fact that you effectively have to run at least 4 checks, including the one you did, for each and every geometry - including super simple objects like mine - simply blows my mind!
Also it not being an issue in Rhino 6 for practically the same workflow, is weird right?
Thanks for the fixed file, although that wasn’t necessary, since I previously mentioned that I reworked the piece in Rhino 6.
Because there aren’t any non-manifold or open edges in your NURBS object - only ‘bad’ ones. And in this case, since you mention MergeAllCoplanarFaces, I suspect that is the culprit - there are some current bugs related to that if you search the forum.
If you turn on CheckNewObjects, it will tell you immediately when a bad object is created.
Do you have to turn this on every time you open Rhino or does it stay set unless changed? I turned it on with a typed command but can’t find this parameter in Advanced preferences. So I don’t know how to check if it is turned on or not.
If I need to I can set it to run it automatically when opening Rhino. I’d like to try modeling with this turned on for a while and see if it slows me down.
Sorry to hear about the bugs in MergeAllCoplanarFaces. This is one new command I find handy.
MeshRepair and MeshSelfIntersect can be helpful in troubleshooting issues with meshes too. I like to also use Mesh to make the mesh in Rhino to check it out before exporting as Stl. If you have the model before you merged the faces here please post it and I’ll make sure that it’s filed as well for the developers. Something caused this surface to mesh with a self intersection and there are several ways to fix it as you know but it would good to know exactly where it happened. I don’t think it’s a Mac specific thing either.
Thanks but that file already has the same invalid surface in it already before MergeAllCoPlanarFaces. I’m not sure when that issue happened but thought it was from a merging of coplanar faces at one point and the file prior to that was what I was hoping to see for a bug report. The issue with the trimmed edges is so slight it seems that ExtractSrf and then Join again fixes it and the mesh created won’t have the self intersection issue. I’ll keep an eye open for invalid surface creation after a coplanar merge though.
I don’t know what’s different in Rhino 7, but my usual surface modelling workflow that I cultured since Rhino 5, simply doesn’t work anymore.
I always end up with non-manifold, broken geometries and I’m not even doing complex stuff.
Let me describe how I usually model. I tend to start from closed, planar curves that I extrude to get a rough, three-dimensional solid. After that I usually do some boolean operations, if necessary, to refine the geometry, and in the end I apply fillets and chamfers.
The boolean operations seem to be the issue, even for really simple examples. It’s super annoying, since the reliable boolean operations, were one of the best things in Rhino (in my opinion).
I’m giving up on Rhino 7 for now. Fortunately, I haven’t uninstalled Rhino 6 yet.
In order to fix this stuff, we need a repeatable “recipe” to create these bad objects. Would it be at all possible to post an example file with the starting curves/geometry and a step-by-step repeatable procedure of how to get to the bad result? That way the developers can see at what point it goes bad and what to fix.
Hello - in general, Booleans should be more reliable in V7 - so please by all means post examples of any regressions you encounter. So far as I know we have not got reports along these lines until now, so examples would be helpful.
@pascal@Helvetosaur I already posted a file that’s still relevant. The link is above @BrianJ’s last post here. It includes all the steps that I took, except extruding the planar base curves to solids.
