glTF-BinExport

hi @Joshua_Kennedy,

I also see the same problem with the .glft export I get this on the three.js/editor:

When I load a .3dm with PBR materials my meshes show up ok (besides all rotated 90 on X), but then all the PBR textures are missing, only base color is available:

I’ll send you both the .3dm file with materials + the .gltf for your review.

Best,

Gustavo

Naive guess, just to rule it out: try to go to the material and set the “Side” option to “DOUBLE”


More likely is probably a Alpha/Depth test/write setting gone wrong.

@Joshua_Kennedy thanks, I just sent my file over

Hi @aske, Thanks for the suggestion. I just checked and they are all set to front, and in theory that should work since the normals in Rhino are correct (?).

Setting them to double does not fix the issue. A lot of materials are also set as ‘transparent’ for some reason. Even unchecking that transparency box is not fixing completely.

This exporter is not working well with PBR materials, not sure if that’s even the intent of this tool. Tiling doesn’t work either. Or maybe this is only meant to export geometry with basic colors?

Thanks,

G

I didn’t get a notification about a file from you. Did you forget to include my email in the upload page?

Thanks, I have them and I’ll take a look. The material conversion can definitely be improved in the exporter. The next version already has several fixes and improvements in this regard. It is worth noting that while Rhino and glTF have very similar PBR material definitions they don’t line up perfectly.

Hi @Joshua,

Thanks for the explanation. And for pointing out this limitation. I want to share a POV and see what you all think:

I think the goal is that Rhino is not a ‘destructive tool’ in a PBR/glTF workflow, but rather a constructive tool.

What I mean, is that I should be able to open any glTF file and see it in Rhino displayed just as if I was looking at it in a web browser. Or if we are having things nicer in the Rhino viewport (always welcome) we should at least be able to see a ‘Web Preview’. Just like 2D drawings have a ‘Print Preview’

Reasons why I think this is important:

  1. We want to develop the look of a model in my Rhino viewport, but the sharing will NOT be in Rhino, but on a glTF-compatible platform.

  2. We want to open an existing glTF file, edit geometry, and resave it as a glTF, undestructively.

IMO these are the goals your team should be chasing, otherwise, I do not understand why we even have PBR in Rhino when it’s slower on the viewport than non-PBR and also slower to render inside Rhino using Cycles than non-PBR. I always thought that PBR has One Job: Universal compatibility. Right?

Thanks,

Gustavo

PS: In general this in-and-out/non-destructive nature of imports and export is something that McNeel has been ignoring for too long and should be taking a lot more seriously. Not only in PBR/glTF, but also in all file types imports/exports.

I think it’s absolutely terrible that I cannot open a well-structured .STEP assembly, modify one part with the awesome modeling tools in Rhino and yet not be able to export the same .STEP assembly structure intact with my geometric change.

Same for pdf, Ai, FBX, etc.

A very healthy goal for Rhino V8 should be to stop being destructive in their imports/exports.

3 Likes

I agree with you that roundtripping data in and out of Rhino with other formats can be improved. I think there is some misconception though about Rhino being “destructive.” You have to understand that Rhinoceros isn’t modifying the FBX/glTF/etc. file directly when you import it. Instead it converts the entire file to a format Rhinoceros can understand (the Rhino document [3dm]). Then when the export occurs it’s converting the entire Rhino document back to FBX/glTF/etc. There’s no link to the original imported file that can just be updated. A loose analogy is using Google Translate to go from English to something else and then back to English again. There’s bound to be some imperfections. Trying to get these imports and exports to match up as closely as possible is of course the goal. I readily admit the glTF exporter needs and improvement and I’m quite thankful for yours and others feedback.

PBR isn’t a standard but rather a set of techniques and ideas. The techniques create quite compelling results and as a consequence have been adopted widely. Because it’s not a hardline standard implementations vary, but since they all derive from the same foundational work they’re quite similar. This means interoperability is much closer than with other material definitions but may not be exact. glTF and Rhino are very similar but there are gaps. For example, glTF has no support for subsurface scattering either natively or through extensions. As a result I have nowhere to put that part of the material definition. There is some unavoidable loss.

I’ve kind of gone off the rails from glTF here but I understand where you’re coming from. I’d suggest making another thread about round tripping data with other file formats. It’d be very useful to have specific examples in specific formats about what changes and what you expect to be preserved. That way necessary changes or additions can be made.

1 Like

Although I agree with the needs and I keep my eye on Rhino glTF capabilities, glTF format has at least two problems when it comes to using it as an input for further modifications. - probably you experienced both of them.

  1. Only triangular mesh faces.
  2. Non-merged vertices / Discontinued UVs. (I hope I use the right terminology)
    glTF export has twice the vertices it should - Blender Stack Exchange

I had some hopes for this format and now I relocated them on the USD format as a modern exchange format.

A post was split to a new topic: Roundtripping in Rhino

For some reason the dialog has stopped popping up at all now and files are being saved with no content. I’m not sure why the behaviour has changed, but I can’t get it saving at all now from GH? Rhino export still works as it should.

My apologies - just realised it was due to the simple reason that the layer was turned off !

Did you ever get this working for Grasshopper? I’m looking to export a folder of geometries to gltf as a batch export.

1 Like

Hello!
Any news on the importer?
Thanks!

1 Like
1 Like

I met a problem Exporter File is so big !!!
only simple geometric objects in the file and texture (JPG file 58 MB)
original 3dm file is 59MB
Exporter glb File size to 254 MB
This is a problem File to BIG

Hi @kenichi_Lin
JPG are uncompressed in glTF, so the actual footprint of your massive texture is ~250MB. You’ll need to downsample it to get the file size down, AFAIK.
HTH, Jakob

Sorry to revive an old forum.
But for Rhino 7 on Mac, is this still the best way to export GLTF?
Or is this deprecated in favour of some other method?
thanks,
R

Hello,

I want to express my appreciation for the plugin. I’m currently facing a challenge as I need to install it on a PC that is not connected to the internet due to company policy. It would be extremely beneficial if you could kindly provide the plugin as a .gha file or offer instructions on how to install it from the files downloaded from GitHub for offline installation.

Thank you.
Amara

Hello!

Amazing work, thank you for that.
I have a .gltf file that includes some name => mesh mapping, like this:

nodes:[
   {
      "name": "2535",
      "mesh": 115
  },
  {
      "name": "2426",
      "mesh": 116
  },
  {
      "name": "3607",
      "mesh": 117
  },
  {
      "name": "4934",
      "mesh": 118
  }
]

When I import it into Rhino, the names are not translated to RhinoObject name / user string, so it’s not possible to identify an object by its name.

It looks like the name field from a Node is not assigned to a corresponding Mesh, so we lose it. :slight_smile:

Made a PR with a quick solution: Overwrite a mesh name with a node name by DanielSBoba · Pull Request #84 · Stykka/glTF-Bin · GitHub


This is may rendered model when I try to export this to .glb format & open it on online 3D viewer it look dark as attached in images