Seems to be working here… I copied the script above, I just changed the file path to my desktop to test, but it did export the object with no complaints and I re-imported it and it was correct…
Hi, this is true, the export works. However, the arguments such as _Refine etc. don’t work for me. I only require a very coarse mesh to be exported with very low required space for storage.
When I put the commands into the command line manually there are no _DetailedOptions. So I am wondering if there are any more options to export. @pascal Do you might know if I can control these options?
Use the -dash version of the command to get the command line options. After browsing and choosing the file name and .stl format, you get this:
After Enter, you get this (make sure UseSimpleDialog=No):
And if you click on DetailedOptions, you get this:
And, if you click on AdvancedOptions, you get all this:
All the command line options are mostly useful for scripting the command.
Otherwise, simply use the normal Export command (no dash) and use the settings dialog:
Hi, thanks for looking into it. I think then this is probably a feature of Rhino 7, because at my machine it goes like this:
But with a combination of changing the angle, aspect ratio, distance, density, grid and maxedgelength I could decrease the required storage space a lot as well. So let’s consider the case closed.
Thanks for your help! BR, Jelle
That is why I asked for the version of Rhino you were using in my first response to you…
Here are the proper command line settings/sequencing for V6 (and V5):
def GetSTLSettings(ang,ar,dist,grid,den,maxL=0,minL=.0001):
#Changed in V6 - UseSimpleParameters response *inverted*
e_str = "_ExportFileAs=_Binary "
e_str+= "_ExportUnfinishedObjects=_Yes "
e_str+= "_UseSimpleDialog=_No "
e_str+= "_UseSimpleParameters=_{} ".format("Yes" if rs.ExeVersion()==6 else "No")
e_str+= "_Enter _DetailedOptions "
e_str+= "_JaggedSeams=_No "
e_str+= "_PackTextures=_No "
e_str+= "_Refine=_Yes "
e_str+= "_SimplePlane=_Yes "
e_str+= "_AdvancedOptions "
e_str+= "_Angle={} ".format(ang)
e_str+= "_AspectRatio={} ".format(ar)
e_str+= "_Distance={} ".format(dist)
e_str+= "_Density={} ".format(den)
e_str+= "_Grid={} ".format(grid)
e_str+= "_MaxEdgeLength={} ".format(maxL)
e_str+= "_MinEdgeLength={} ".format(minL)
e_str+= "_Enter _Enter"
return e_str
As you can see, these settings were changed from V5 to V6 and again from V6 to V7… 
Perfect! This indeed works. In the post where I shared my script I mentioned that I was working in Rhino6. Interesting that they changed what they considered ‘simple parameters’. Thanks @Helvetosaur
OK, sorry, I missed that… 
No worries! Thanks for your help, well appreciated.
Hi @Helvetosaur, I am using Rhino 7 and I want to export a batch of layers into separate files while maintaining layer names.
All the attached scripts which I found are not working for me. Exported names do not match layer names. I used a separate script to make the object name the same as the layer name.
I am getting only sequential naming based on the Rhino3D file name and not layer or object names. I have 214 surfaces, please let me know if you know how I can get this to work.
BatchExportSTLByObjWFixedSettingsPlus.py (1.9 KB)
BatchExportSTLByLayerDefault.py (890 Bytes)
BatchExportSTLByObjectwName.py (4.4 KB)
BatchExportSTLByObjWFixedSettings.py (1.8 KB)
BatchExport3dmByObjectPlusNames.py (1.7 KB)
True. Basically because nobody ever asked that the files be named after the layer names. I will look at what I can cook up. It’s a little tricky because sublayers of different parent layers can have the same name - so I will probably have to name the files with the full layer path.
So you have 214 different layers each with one object?
1 Like
@Helvetosaur it is actually working. I used a script to transfer the layer name to object name however, the problem was that the names included double colon marks (::). Once these were removed it worked perfectly.
I had a lot of layers and sublayers. I kind of understood that these scripts do not work on sublayers so I saved the file in iges format to get everything in layers instead of having layers and sublayers. Once I opened the iges file as a 3dm file again then I got the main layer name and the sublayer name in the same name separated by a double colon (::), something like, layername::sublayername. All I had to do is remove all double colon marks from all layer names before transferring the layer names to object names.
BatchExportSTLByObjectwName.py (4.4 KB)
LayerNameToObjectName.py (205 Bytes)
This one will automatically remove the :: and replace it with another separator for naming the objects. By default, it substitutes an underscore, _ you can edit the script in a text editor and replace the underscore with anything else you want.
(Edit this line) sep="_"
LayerNameToObject2.py (570 Bytes)
1 Like
That’s amazing. Thank you very much!
hi @Helvetosaur, all,
This is great work! I’ve been watching this thread with a lot of interest since we use a very old batch exporter from @phcreates written circa 2003 
Batch exporting is one of those things that we do a lot, and we are just used to dealing with the hassles it creates with our current half-broken tools, because it’s easier and faster than not using such tools, but in this case it’s been now almost 20 years doing these same workarounds, so I figure it’s time that I explain them and see if anyone has a more modern idea of how to solve this workflow problem that happens at least 2 -3 times a week in our team.
Maybe you Mitch have some suggestions. Or you Peter have some newer versions of this? or @pascal Pascal has some ideas?
So I’ll explain…
What we like about Peter’s old script:
-
it was an export-by-layers approach. Since our files are organized by layers, this made a lot of sense. Also sometimes we do have multiple bodies that we want to export together as a single file, so exporting-by-object defeats this purpose.
-
It allows us to pick with layers we want to export, and which ones to omit, export by layers is great, but we have reference, junk-drawer, template… layers that we do not want to include in our exports. Example:
-
Only mesh items will be exported as mesh format, instead of meshing at export.
This is very important because we cannot trust RHino’s meshing to be able to create an on-the-fly meshed object at export. So we always premesh, and examine the meshes in flat shaded view to make sure it’s acceptable. Rhino is very unruly and very happy to ignore its own settings, so we sometimes have to explote/extract surfaces, split by isocurve, try other mesh settings for specific parts, etc. before we can have acceptable meshes.
What we don’t like about Peter’s old script:
-
It requires to type a prefix at export, so instead of taking just the layer names you need to at least type an extra character and you end up with X_latername.xyz (prefix + undescore + layername+ filetype suffix). In this case I had to type X, otherwise the script will not continue:
-
It also inherits the parent layer name, so we end up with parentlatername::layername.xyz in which case the export script will fail, so I have to move all layers outside parent layers before I run the export batch. So I end up with something like this:
In summary:
It would be great to have a batch export script that:
- Allows you to choose a file format from a list for us would be Step, Iges, pdf, ai, dxf, fbx. Having a list to enable/disable formats would be nice too.
- Export by layer, with the following options:
2A. Rename object names (or unnamed parts) as layer names (important for other apps) but undo such renaming after the export
2B. include/exclude parent layer name
2C. include/exclude non-mesh objects for mesh filetypes
2D. extra credit: include mesh thickness (as meshed pipes) for curves (important to export visible wireframes)
2E. extra credit: option to choose using layer/object/material colors - creates a list of what was exported, something that can be a .csv to paste into excel with all the file names, what’s in each one (number/ type of objects), etc… or maybe this is better dealt with @phcreates’s BOM tools?
Thanks for listening,
Gustavo
1 Like
I don’t have an updated version that answers any of your wishes. Actually, I don’t know if I even have that script anymore.
1 Like
Hey Gustavo,
Most of this stuff is do-able of course, some of it is relatively simple, others do involve some work and lots of coding. Let me go through your list point-by-point.
-
Choice of file format: easy enough to choose one with a dialog as you showed. Simply, for each file format, there are different export options that need to be chosen or hard-coded. Some of the file formats require quite a few options/settings and for example dwg/dxf export schemes are still not directly exposed to scripting. So making this kind of all-in-one script ends up being long and complicated with a chain of choices for the user to go through (especially with all of the rest of the options you want below). My preference has always been for a series of simpler one type/use scripts that one can use with a set of aliases or toolbar buttons.
-
(A) Renaming objects is not a problem - undoing them isn’t too hard either as long as you keep track of the objects that have been renamed, the risk is simply less robustness if something fails somewhere in the middle and the undo isn’t executed.
(B-E) All options possible, again, simply more options to go through and check. Your chain of command options is getting pretty long already. (B) could be a problem if you have same-named sublayers and you choose to exclude the parent layer name. For (D) I’m not sure if access to the curve piping meshes has been exposed to scripting - if not it’s more complicated because the meshes would need to be extracted via a the Rhino command and then deleted again after. -
Also possible certainly, again, just more complexity added to the mix.
Anyway, to roll all of your options into an all-in-one script would be IMO a time-consuming endeavor, and I’m not convinced that the resulting complexity of use would be very comfortable in the end.
Hi Mitch, this is super helpful feedback. Let’s think about how to best structure this to be the most robust approach and most helpful for everyone.
- For starter, I think a master script project could be useful to then spit out separate scrips for each file format, or smaller clusters for only a handful of file formats. Would that help?
For export options: does it make sense taking the last used setting for that file format? And if you want a new setting you would first manually export a dummy file with the settings you want and then re-run the scrip to use those settings. Would that work?
2A-B. I’m rethinking the auto renaming part, because you are right, it could create complications. Maybe including a namesfromlayers script to run first separately for those who do want to first match object names to layer names. I do have that script from Pascal in my pC, I’ll post it later. The only limitation of Pascal’s script is that in only takes the layer name, completely ignoring parent layer’s name. In some cases we do want “parent-layernane_layername” we can bug Pascal about that feature. This will give the user granular control and when/how to rename parts based on layers.
2C. I’m thinking of favoring Peter’s old approach: only meshed objects will be exported as meshed file formats. This also simplifies scripting, allows for manual check and to have more granular control of mesh setting for objects that require very different meshing settings.
2D. Same logic as 2C. This makes more sense to do manually so user can see what will be exported as pipes. How it looks, how heavy it is, which ones omit, etc.
2E. I need to do more testing here to find out where color information matters.
- A simple list of filenames.xyz makes more sense. For more documentation Peter’s BOM tools is the way to go.
Does this make more sense?
Best,
G