Hi, I’ve been working on yet another script to generate some parts I need for a design but an issue appears after baking the results. I’ve tried different ways of checking the geometry, but I cannot get this extrusion to work as a mesh even though the STEP file looks absolutely fine and Rhino doesn’t report any errors.
Focusing on the round part of this baked object, it looks good in the viewport:
I’ve been wondering if this should be in the Rhino or in Grasshopper subforums, but I would really like to find a way to always get correct output from the GH result and would also like to know if there is a way I can check my geometry from within GH to catch the bug before I go through the hassle of exporting the results and opening it in different software. Is there maybe a rounding error somewhere, or maybe even some type of tolerance issue?
This is by using a STEP file. The reason why I converted into a mesh is because I wanted to troubleshoot if the issue was maybe with the conversion of my slicer from STEP to mesh.
Somehow exporting to STL directly from Rhino either makes my files super big/heavy or it just breaks my meshes:
There must be an issue within the baked data from GH. Or my issue lies in Rhino7, maybe you’re using RH8?
Setting aspect ratio to 0.1 instead of 6 actually seems to fix the issue (but it gives 160 non-manifold edges), but I want to export to STEP and not use STL:
Yes, I do have RH8. But I expect the same result would happen with prior versions.
I’ve found that for 3D printing it’s best to give only STL files made from Closed Breps to the slicer. I’ve never had a problem with these. (Well, almost never.) Meshes seem like black magic to me and although I have used them a few times they have always given me problems in one way or another. (Note that I seldom use GH add-ons.)
An STL file is a non-compressed mesh of the outside surfaces of a piece of geometry. Rhino seems to be quite good at generating valid STL files from closed Breps. It will also generate STL files from other things, but these results have not been nearly as reliable as those made from closed Breps. Fortunately Prusaslicer has a built in STL repair tool that usually works.
I don’t know what a STEP file is so I can’t comment on that. But i can tell you that non-manifold is a problem, and closed Breps exported as STL files don’t have non-manifold components in them. (Closed means it is manifold.) My best suggestion is to try making an STL file and see what happens.
STEP is an increasingly popular file format for 3D printing as it allows the user to modify the object with more ease because you don’t have to edit a mesh but instead get a mathematically defined file. Instead of segments it uses lines, arcs, circles and more.
Look at it like the difference between a pixelated image and a vector file.
I’ve been using STEP for ages because of this enhanced capability.
Also, sorry if I caused any confusion in terms but the only reason why I showed the preview of the mesh in Rhino was to show that my design somehow causes issues when turned into a mesh. An STL is as much as a mesh as a mesh in Rhino. It depends on the export settings how it turns out as you can see in my example above where one changed setting improved the exported STL file by a lot. This sadly doesn’t fix the fact that my STEP file does not turn into a mesh correctly when converted from within the slicing software, leading me to believe there is an inherent issue with the data of the object within Rhino, however Rhino says the object is perfectly fine.
I’ve never ever had issues like this with GH and Rhino before. I’m confused how the STL file I exported from Rhino is non-manifold as it’s a watertight solid object in Rhino itself with 0 issues and the outside is on the correct side of the faces across the object.
First of all thanks for taking the time to diagnose the issue!
Second, I’m sorry for disclosing such a short segment of my GH definition. I tried to keep it as simple as possible.
I’m starting to think that the issue might have been caused by a fillet that I applied on the outline curve before performing a Boundary Surfaces. Looking at your red arrows, this reinforces my assumptions. I got errors with generating the mesh when I use 1.0 for the fillet, and at 0.9 the fillet doesn’t appear to cause issues so far.
I have meanwhile changed some design parameters and it appears the issue is no longer happening, but to prevent future issues I, just like you, would like to find the issue so I know where to look for.
So to help, I have made a new file that contains an additional step: example_2_mount.gh (7.8 KB)
I didn’t have that FilletCorners plugin, so I just bypassed it to focus on the very original curves, baked as polysurface, exported as STL and re-imported over the existing one:
I’m laughing as I write this like a salmon swimming upstream are these curves coming from another software, or imported from a pdf/svg/Illustrator of some sort?
Well, since you’re so curious, I can share some more of the definition. But these are results from Trim with Region.
I’ve been quite ill the past few days so I don’t have my head on straight completely. Weird mind fog. Anyway, I tried to clean it up a bit (I had planned to clean up the document when I’ve recovered).
What I mainly tried to do was draw my entire object with just lines and only extrude it in the end because I’ve been noticing that I too often already extrude things early on and this makes for slow definitions.
Thanks a lot for showing the trick with explode, it’s very useful. Oh, and one trick, you can preview the mesh within Rhino before exporting without having to reimport it! This is how I made the first few screenshots of the mesh.
I have played around with your definition to try using curve booleans instead of Trim with Region, but that did not change the final outcome of the STL mesh
by the way, the “explode thing” looks like working for the version without the filletCorners plugin, but not sure if will also work including those
the wise salmon says the problem is not in your GH file
Years ago (maybe Rhino 5 or 6) I discovered that when I baked a piece of geometry I defined in GH that had fillets in it and then exported that out as an STL file the fillets would sometimes get whacked off into straight line segments - just like Inno showed above. I spent quite a while digging around for a solution to this, and finally came up with the one Kevin mentioned. I ended up writing a short Rhino command button that uses the SplitAtTangents=Yes SplitAtKinks=Yes command. Since I use Rhino only for exporting STL files I have no idea what this Rhno command actually does, or why it was needed only at some times and not others. I haven’t found the need to use it in quite a while now, so I suspect whatever the problem was then it is now fixed in Rhino8.
Marinus - thanks for the info about STEP files. After looking at that I do remember considering them years ago, but I gave up on that because I simply did not need the added capability that file format provides.
My standard procedure is to design something in GH, bake it in Rhino, export the baked geometry as an STL fil, load that STL file into a slicer (I’ve used maybe 5 different ones so far), and then slice and print it.
If that doesn’t work for some reason related to the geometry definition I go back to GH and fix or modify the definition there until it does slice and print OK. I wanted the simplest method I could find for getting from the design process to the final printed result, and that basically eliminated using any other design tweaking options like Blender or MeshMixer or what STEP files allow. For me “simple” means using the fewest pieces of software so as not to get enmeshed in dealing with the vagaries and quirks inherent in different applications.
Hello Kevin, sorry for my late reply. I had fallen ill and didn’t continue working on this issue until today.
Your solution is exactly what I was thinking of when looking at the issue. I was once again faced by a similar issue with a different design and decided to check if your solution would work and it totally did.
The new issue I had was with two faces that didn’t want to be filleted. It took me a while to figure out what the problem was as GH just gave a generic error along the lines of that the fillet couldn’t be created. Then I added your small script and it now totally works for fillets which was very helpful.
To the left was my initial design, and to the right, the result after the fix:
I’m starting to understand the issue now. I’m wondering if my geometry can even be created in GH without the need for this fix. It is related to the fact that I am connecting straight lines and arcs to created rounded caps on a 2D shape and then extruding it. The reason why I want to add the rounded ends in 2D/line mode is because I want to make the script as fast as possible and working with lines is a lot faster than working with solids.
This is only for a personal project, but still a very valuable piece of knowledge, so thanks again!
Edit:
Somehow it is messing up the way I make fillets, so I’ll have to inspect and work on that for a bit
how did you generate these curves? 
like a salmon swimming upstream 
