Use the PackageManager with pre-release checked, and search for glTF-BinExporter.
Usage
File Export plugin. Just select glb or gltf.
Also exposes a single command glTFBinExport that exports the selected objects to a .gltf and .glb.
For how to use the resulting glb file see e.g. ThreeJS GLTFLoader Example
NOTE: The DracoCompression extension is required, if exporting with DracoCompression.
Geometry
Geometry can optionally be compressed with DracoCompression.
Materials
Physcially based MetalRoughness materials are copied into the resulting .glb. Normal materials are converted in a best-effort way.
Textures
Textures from the material are included into the exported file.
Known Limitations
Lights.
Cameras.
Animations.
Releases
We’ll keep posting here with updates for new releases, so subscribe to this topic.
Since you are building for V7, I would highly recommend dropping the rhi/macrhi distribution method and go with the package manager. It is a much better way to distribute.
Honestly didn’t try meshes yet. My hacky approach was just to steal the render mesh and export that for Breps. Meshes should be easy to add though. I think I might have some free time over the weekend!
@aske I have not been able yet to import any of the glb files created by your plug-in into Blender 2.91. For the two exports I tried the add-on tells me that parsing failed.
Thanks for reporting!
I only export DracoCompressed geo for now (didn’t have bandwidth to fix two different codepaths) Is it possible that Blender is just not able to import that? It’s only listed under export as far as I can tell.
I published a new version that supports Meshes. Instead of using the RenderMesh like other geometry, it should take your mesh directly and pipe it through DracoCompression.
In your example I see the UV map is incorrectly exported. How is it mapped? I tried a sphere that got correctly exported with the latest version at least.
I was using surface mapping when I got the result above. I change it to spherical mapping and the texture works better. I’m getting pinching at the top in Google Model Viewer that I don’t see in Rhino. What would need to happen for Bump Maps to export to GLB?
I was using surface mapping when I got the result above. I change it to spherical mapping and the texture works better.
Never looked at UV mapping in Rhino, so I would need to dive into that to solve it. Maybe need to bake a UV map on the fly. I think I would down prioritize this: users could work around it, by converting it to Mesh with an explicit plain old UV map. Do you think that would be acceptable?
What would need to happen for Bump Maps to export to GLB?
I need to figure out what types of bump/normal/parallax/other maps Rhino supports, and how they map to GLB (I think GLB just uses Normal maps?). Shouldn’t be too hard though. Bump -> normal is easy, normal -> normal as well.
You’ll get similar pinching if you use ExtractRenderMesh and then show that instead of the sphere surface with spherical mapping. The Rendered mode is able to do per-pixel mapping, whereas with the mesh with (essentially baked) UV coordinates you can’t. Higher density mesh will yield nicer results, but there’ll always be some pinching - at the cost of increased memory usage.
@Joshua_Kennedy has been at it again! This time mostly internals changed to make everything more robust by switching from my hand-written brittle gltf solution, to using a generator based on the schema directly from KhronosGroup (creators of the gltf spec). This means some validation errors that were present before are now gone, improving portability of the resulting files.
Released as 1.6.0.0.
Please let me know if you encounter any errors.
