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.
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.
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.
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.
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.
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.
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.
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.
download them from the ShapeDiver Geometry Backend (directly accessing the Geometry Backend API, or using the SDK).
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.
