Shapediver: Export glTF in Grasshopper?

I am just playing around with loading and transforming external geometry directly in the Shapediver viewer as outlined here:

it mentions the Geometry needs to be exported as .glb files using the functionality that comes with the Shapediver plugin:

My question now: it doesn’t seem to be possible to export as .glb using the shapediver export component. That seems odd, since I am assuming that the mesh in the viewer is already in that format anyways.

Is there any way to export a .glb using Grasshopper locally? We cannot manually export each geometry, but want to integrate it in our automation. I guess it might be possible with RhinoScript to execute something that happens in Rhino.

To me it would make sense to have the exporter in Shapediver itself, so that you can use Shapediver to export geometry in a way that can then be loaded in the viewer.

No, exporting GLB files is not currently possible with ShapeDiver Export component.

@seltzdesign for now you could grab the glbs directly from the API. The coming update includes functionality for

  • exporting glTF directly from the display component (right click)
  • exporting glTF using a Rhino export plugin

thanks for getting back. Is it documented somewhere how to do this?

Also I noticed that this page: https://support.shapediver.com/hc/en-us/articles/360023743572-Component-Display-External-Geometry is not quite up to date. It was last edited 2 years ago and S3 doesn’t allow CORS rules written in XML any longer - only in json. Also the embedded shapediver viewer to test a file does not show up.

I uploaded the example file again to Shapediver and I tried to set up everything according to your suggestions, but not getting it to load the file I put in a S3 bucket.

Can you spot a mistake here:

also the metadata on the file is set correctly (automatically):

these were my export settings of the mesh:

Not sufficiently for external usage for now, but you could review network traffic in the browser console and figure it out from there.

The way how CORS works certainly has not changed since then :wink:

Many thanks for the hint, fixed.

What’s the browser console error message(s) shown? Please provide a link to your test environment that allows to reproduce the problem.

The CORS settings are not shown.

Alright, you exported a glTF v2. Please provide your test environment for reproduction of the problem.

I am not saying that the way it works has changed, just that if you are using the normal S3 console on the web, it MUST be in json format, so why not show it in that format, since that also works for using the SDK or Rest API.

https://app.shapediver.com/m/load-external-geometry-v1-0

The error it shows is:

It is showing the CORS settings right at the bottom of the image:

We are going to update it once we revisit this documentation page, many thanks for your hint!

Hmm but this is not a CORS error. You only need to configure CORS if assets get fetched directly from an origin of your own, the requests that are failing here are requests to our geometry backend.

Could you post a minimal version of your model that produces this error?

Strangely though, it works if I use the S3 assett from your example (the business man) as the URL. As soon as I provide my own, I get this 500 server error.

I already posted it above, but here it is again: https://app.shapediver.com/m/load-external-geometry-v1-0

Just now I saw that the business man example uses the format .glb, while I am trying to use the .gltf format. Is there a difference? Can I use both?

Oh, now we are getting closer. You are providing a URL using the s3 scheme: s3://modismo-3dfiles/make-words-matter.gltf
That can’t work, because our servers are not allowed to access your S3 bucket. Even if you make all of your bucket public that won’t work. You need to use a public https url, e.g. something like https://modismo-3dfiles.s3.amazonaws.com/make-words-matter.gltf

Go to your AWS S3 console to get a public https URL for your file and give it a try. Then please post it here.

That’s odd. It makes sense, except that in your own example you are using this for you model URL: s3://shapediverexternalgeometry/People/BusinessMan.glb

So you only allow shapediver to access your own S3 bucket, but not anyone else’s? I think that leads to confusion (and this topic is already confusing enough, as seen here: ShapeDiver external geometry and countless similar threads).

What would be great would be that you can actually just upload some geometry in the shapediver app, just like you upload a grasshopper file. Than it get’s put on your S3 and already has everything set correctly and it just shows you the correct URL. That would mean we don’t all have to set this up which is rather complex even for people familiar with web stuff. What do you think of that for a future feature?

Did you create this example from a model which we provide as an example? If so then there is a mistake. The file url in this example should be a https url as well: https://shapediverexternalgeometry.s3.amazonaws.com/People/BusinessMan.glb
I will make sure this example gets fixed.

It would technically not be a good idea for us to use the S3 API for accessing assets on an S3 bucket not owned by us. It would be possible, but would be a really bad design choice. As an example, it would require you to grant S3 API access for our AWS account, etc, certainly not something we want to get into. Therefore you simply provide a publicly accessible https url to your gltf or glb or texture asset. As I explained above, an example model provided by us is not supposed to contain s3 scheme urls.

This feature is already on our list and it will be there eventually. I know you might think that we have been saying this for lots of features, but great things take time, and I think you are going to like what’s coming in the next weeks/months.

1 Like

Slowly making progress here and I can now load a file and also change the file in the viewer. I keep getting this error though when I load: https://modismo-3dfiles.s3.eu-central-1.amazonaws.com/dontworrybehappy.glb

Have you seen this before?

What are the exact recommended settings for the Shapediver GLTF exporter from Rhino?

I just gave it a try here, and it worked using your glb: https://app.shapediver.com/m/external-gltf-2-0-1
Attached please find the GH model.
external_geometry.ghx (99.9 KB)

Yeah, strange I don’t get the error message there. Anyways, now I have another issue:

I am trying now with a bit more high-res mesh and it has some strange artifacts that are not there in Rhino:

You can see that some faces have their normals flipped. In Rhino all normals are correct:

Since you cannot import a Shapediver exported .gltf file back to Rhino or open it in the 3D viewer:

image

I can’t really check what is at fault, but it’s definitely not loading it correctly.

Here is the mesh: https://modismo-3dfiles.s3.eu-central-1.amazonaws.com/cantknockthehustle_highres.gltf

Any ideas?

Oh, wait, wasn’t there some limit on how many vertices a mesh can have in the Shapediver viewer? I bet it downsamples the Mesh somewhere and that’s where the errors happen.

Yup, answered my own question here. I reduced the mesh to 65.000 vertices and then it looks just fine:

Yep meshes with more than 2^16-1 = 65535 vertices will get downsampled. Easy way to avoid this: Split it into several meshes! Should be easily possible in your case.

1 Like

Okay, we gave that a go and I could find where it sends the .gltf back and download it from the URL:

Now the only problem with that are:

a) we don’t know what API call to use to get this URL

b) the gLTF file that it downloads seems to be a legacy V1 file format, which cannot be opened in any of the gLTF viewers. I could get it to work in that Shapediver viewer that can load .gltf files but not in any of the other viewers out there. If I export from Rhino I also have to choose glTF2 as the version so that the files can be loaded in other viewers.

What is the reason that the Shapediver viewer uses the old legacy format?

c) I assume there is no way to get the .gltf file using the backend API, since it presumably doesn’t send any meshes

Ideally we want to get the output of Shapediver as say a .gltf file and then display it in a different viewer where you can do transformations and material updates without any callback to a server. We have played with the transformExternalGeometry stuff, but in the end it still needs to call back to the server and takes several seconds to do the transformation, even though threeJS and similar can do transformations in basically real time. Same with the material changes. If I want to change a color or material it takes several seconds to update, even though again a threeJS viewer can do this pretty much instantly.

Will there be any updates in that area with the new plugin and app? If so we will wait for the update first.

@seltzdesign in the meanwhile we have rolled out updates which make it possible to

Please uninstall your currently installed version of the ShapeDiver Plugin, and then install the latest version using Rhino’s package manager. Note that the latest version is not yet available for Rhino on Mac.

You might also want to check out the capabilities of our new viewer, which allows you to do all of this (and more).