Has anyone experienced errors when exporting STLs directly from Grasshopper.
it’s been happening since the previous service release Candidate. I currently have this release installed on Windows 11 PC:
I’m seeing the error with both the TT-Toolbox 2 STL export Component as well as a custom C# component I’ve been using for a few years now. See attached GH file for simple test workflow
Surprisingly, everything is working fine on my Mac, which is running RHino 8 SR8.23
Thanks for the ref. However, in my current workflow, I would like to avoid baking anything in Rhino as I am importing different Rhino files and sometimes exporting multiple STL files at once using a trigger.
You don’t need to bake any objects to Rhino. This Bake input for Object Save acts solely as an output switch. You can simultaneously export multiple different STL files by properly organizing the output object names, paths, and the objects data structure.
I tested it, but every time the name of the file changes, it actually bakes inside Rhino. Or if I trigger it with a button (which is what I usually use), it also bakes inside Rhino, which would make the file too heavy.
Is there a way to install a previous release of Rhino? Everything was working fine for this STL export with SR23.
So weird. I just tried it on mine and it’s exporting all right but it is still baking the meshes inside Rhino. Not sure what’s happening there.
After doing some digging, and debugging into the component that kept crashing, it seems like the cuprit was CreateHeadless(). After removing that part and re-writing it to avoid headless document creation, it seems like it works now and it’s fast. For anyone interested here is the GH file including the updated C# script.
Yes, I think that is also the way to do it. Use Datatree grafting to create and export multiple blocks to export to multiple file locations if necessary.
Agreed! For simple tasks, the native component is perfect. I developed the custom one because I’m running automated iterations with a sort of counter cycling through design options, where exports need to trigger programmatically based on each iteration’s parameters. But you’re right - for straightforward exports, native is the way to go.
