is it possible to load a client-side GLB blob into model-viewer?

[rawwerks]

@njiang and i are running into some challenges taking a .glb file that was generated client-side and passing that to model-viewer as a blob.

this post suggests that scene-viewer cannot accept blobs #2884 - but before we go build a bunch of webXR stuff from scratch - i'm curious if someone here (maybe @elalish ?) could help give a definitive answer.

what we are trying to accomplish is:

• the user uploads a .stl file
• there is client-side js code that converts that to a GLTF and packs it to GLB
• (at least for Android devices) - this GLB blob is then passed to model-viewer to be viewed in AR, ideally without ever getting sent to our server

we currently have this working w/ three.js and a USDZ export for iOS AR Quick Look. we are thinking that model-viewer might be the best way to also support Android devices.

[samaneh-kazemi]

Hi @rawwerks, thanks for reaching out. Unfortunately, as you saw in the other discussion #2884, passing GLB blob to src in SceneViewer mode is not supported. This is due to security restrictions in Android. Basically because scene viewer is technically a separate app(though a 1P app), the blob is meaningless outside of Chrome. Quick Look only works because Apple makes an exception for it, but tighter securities are applied in Android even between 1P apps.

[elalish]

For 1), first off, you might not need three.js at all; if you're only configuring materials, that can happen through MV's public API the same way our editor does. If you do need to use three.js, you can either use GLTFExporter and set that blob as our src (we only support glTF/GLB input, not USDZ), or you can hack down into our $scene private symbol, which is a three.js scene and then you can do whatever you want to it. Just be careful to test before upgrading versions, as we don't promise stability in the non-public API.

For 2) I think you're on the right track. MV is there to handle the three.js internals, so if you're doing much of your own they are probably in conflict.

[DanieleMagri]

First of all, thanks for the reply :)

For 2) I had two scenes, and two renderers (the configurator one and the MV one) so I thought I'd do something that turned out to be the right choice: I deleted the animate () function and the renderer of my configurator, leaving only the "backend" (the part that deals with loading the model and changing textures), without displaying the model and the configurator canvas to be clear, and using MV instead to display the model, seems to work well, even the AR now does not give any problems.
In summary:
Three.js changes a texture, calls the GLTFExporter function which changes the value of src by first setting it to null and then linking the blob with the updated model which is then rendered via MV.

For 1) For this configurator I use specific textures saved locally (/assets/textures), would it still be possible to change them using MV's public API?
Last questions:
would it be possible to use a GLB model directly and use it in model-viewer without going through the converter?
i didn't tried quicklook with MV yet, it should automatically convert the model to USDZ right?

[elalish]

Yes to all of these questions. Have a look at these examples for texture swapping: https://modelviewer.dev/examples/scenegraph/#createTexturesExample

The whole point of MV is to use a GLB directly. Our USDZ auto-conversion is detailed here: https://modelviewer.dev/docs/#entrydocs-augmentedreality-attributes-arModes

[DanieleMagri]

Very interesting, I took a look at it, but what if I had a 3D model part that I wanted to change? For example: I have a model of a staircase in glb with different meshes for the handrails integrated in the model, would it be possible through a selection to turn on the selected handrail mesh and turn off the others? (this is the method I currently use on three.js within the configurator)

Any updates?

[elalish]

I'm actually looking at building an API specifically for this right now, but in the meanwhile, yes, you should be able to achieve it by having a separate material for each mesh and making them alternately transparent or not.