Add library project

[visose]

Hi, I am planning to use this project as a dependency to a Rhino plugin. The readme mentions it can be used by developers in this way.
The project seems to work great, the only issue is that it's structured only as a Rhino plugin. It would be great if you could separate it into two projects, a library and a Rhino plugin. The library can then be used by other Rhino plugins directly without having to make changes to this project.

For the time being, I've created a fork with this additional library project, making as few changes as possible. You can have a look here:
https://github.com/visose/glTF-Bin/tree/library
If done properly, it would be better to restructure the folders and move the code files around, rather than reference them as I've done here.

[jrz371]

Hi,

I'm guessing you're trying to export geometry that doesn't exist in the document. For that I'd create a new document with RhinoDoc.Create, add those objects, and then export with the .gltf/.glb file extension with RhinoDoc.Export. While it would require the glTF-BinExporter plugin to be installed with that copy of Rhino it saves the headache of dancing around with another library project. Since this is MIT licensed you can distribute it with your own plugin. I think the wording in the README is a bit misleading and should be changed. While that may have been the original intention it has diverged a bit. I'm in the process of trying to get this plugin into Rhino 8 as well. Hopefully in the same release time frame Rhino will support passing a dictionary with export options to the Export function. This way you can programmatically decide options for how to export the file.

Let me know if this helps

[visose]

Hi @jrz371, no, in our plugin we are generating a .glb byte array from existing selected geometry, which never gets saved into a file on disk. The Rhino command saves a file, but we tweaked the calling code a bit to retrieve a memory stream. Also, as you mention, we created a separate class to pass the parameters, as the existing one is too tightly coupled with the plugin's settings.

I don't think an additional project, clean of Rhino plugin and command specific code, would add much overhead, and might help structure the project a bit better, but ofcourse it's your decision if you opt for this.

[jrz371]

I still think this is a few extra steps of work since you could export to a temporary file and read back in the byte array from disk. You can also use Rhino.PlugIns.PlugIn.LoadPlugIn to ensure glTF-BinExporter is loaded, Rhino.PlugIns.PlugIn.Find to get the export plugin and Rhino.PlugIns.PlugIn.Settings to poke the various export settings glTF-BinExporter uses before calling RhinoDoc.Export. This way you can manipulate the plugin without needing to reference it. I just double checked that all the export settings are all cached in the settings dictionary. If I'm missing one I'd be happy to fix that. I'm not certain we'll ever be hosting a stable SDK for the plugin.

[visose]

I'm not certain we'll ever be hosting a stable SDK for the plugin.

No worries, for the time being we will continue to use our fork.

[jrz371]

If you don't mind sharing, what's your use case? I'd like to add a note to our YouTrack issue about accessing export settings from Rhino

[visose]

The plugin has a panel where the UI is created by web technologies (using a webview control). It includes a three.js viewer where we preview Rhino geometry (that's why ideally we want to send the geometry in-memory, without access to disk).