Using Rhino's exporters in a headless way

Is there a possibility in Rhino 8 to use Rhino’s export plugins in a headless way? So far, this hasn’t been possible in Rhino 7. Therefore, at ShapeDiver, we are using the following approach when exporting files:

  • bake objects to the Rhino document
  • call the export command in command line mode (-_Export)

This works, but passing export options on the command line is a pain. For example, the new glTF exporter does not allow passing any options when running in command line mode. The options dialog which is available in interactive mode obviously can’t be used for automating exports. Could you add the glTF export options in a service release?

@stevebaer we talked about this before, please let me know whether there are any plans to support headless export.

Rhino 8 has a slew of new import and export option classes for this. Here’s a brief article on the subject.

3 Likes

Wow, this is amazing @stevebaer !

@stevebaer Thank you for pointing us to these new import and export option classes, they will help us significantly improve the File I/O components of ShapeDiver in the future.

We are currently evaluating the best way forward on our side. I made a first pass regarding the export formats we already support in our plugin, and the ones we want to add support for. This leads me to a few questions, related to the following steps we want to take:

1) Make sure our current method will work without breaking changes in Rhino 8.

This seems to be the case except for a small change we noticed: in Rhino 7, calling -Export for the dxf/dwg file formats triggered an additional command line option:

This additional option disappeared in Rhino 8. In practice, this is not crucial since we call the - AcadSchemes command first, which allows to set the current scheme, and this scheme is used by the -Export command in Rhino 8. Still, I thought it was worth mentioning as a potential breaking change on your side.

As a result, I made an exhaustive review of all command line options for the formats we support, and I did not find other such breaking changes.

2) Quickly add support for some new formats without having to refactor our whole code

We would in particular like to add support for glTF. As Alex mentioned above, the traditional command line options of the -Export command are not available for this format. Therefore my question is: can we expect this behaviour to come in Rhino 8, for glTF but also for any other format newly supported in this version?

We understand this might be a decision to only implement export option classes for new formats, but in that case, knowing McNeel’s position in that regard would help us to adapt our expectations.

Note that, at the moment, the export option classes do not seem to exist for glTF anyway, which means we do not have any way to support this format. It might be a smaller task on your side to implement the command line options than the new classes.

3) Refactor our code to make use of the new export option classes

Naturally, this is our ultimate goal, and the one we are excited about. However, a pass on the formats we currently support seems to indicate that those classes are not reliably implemented yet for all options that are available in Rhino. Here is a list of some elements that (unless I missed them) are not exposed through the new classes yet:

  • None of the 3mf export options
  • For the skp file format, the CullUnnecessaryVertices and MinimumFaceCount options (available when calling Export and -Export)
  • As mentioned in the point above, the glTF options

I do not have the bandwidth to do an exhaustive review of all formats supported by Rhino, but I expect some other formats lack exposure through the new option classes.

I guess my main question is whether this is on your radar as future patches? And in a purely selfish, ShapeDiver-specific context, if there is no concrete timeline regarding the completion of this feature: could tasks be filed for the specific examples I listed above so we can get started on a significant but crucial code refactoring on our side?

I apologize for this lengthy report! We deeply appreciate your support on those topics, it truly helps improve our product.

1 Like

Hi Mathieu,
We’ll get some bugtrack issues put together for this and get started on implementations right away. @Alain is going to start looking into this and should may have some feedback in the next few days.

1 Like

Hi Mathieu,

Having all relevant File IO plug-ins support Code-Driven File IO is our goal but it seems that exports that don’t support scripting well should be the first candidates.

Here are a few issues I logged as a start

Can you successfully export the 3mf formats with scripting?

1 Like

Thank you for the support about these topics! Indeed, 3mf exports work using the command line options, they are just missing from the code-drive file IO classes.