Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v0.43.0 breaks viewing of *.glb files #297

Closed
qqmyers opened this issue Aug 8, 2024 · 4 comments
Closed

v0.43.0 breaks viewing of *.glb files #297

qqmyers opened this issue Aug 8, 2024 · 4 comments

Comments

@qqmyers
Copy link

qqmyers commented Aug 8, 2024

I've just been working to display glb files such as https://dataverse.harvard.edu/file.xhtml?fileId=6931827 within Dataverse.

We're generating HTML like
<voyager-explorer resourceroot="https://3d-api.si.edu/resources/" root="http://ourhost.org/api/v1/access/datafile/" model="ClunyCapital06.glb"> </voyager-explorer>

and then loading the voyager-explorer.min.js script.

Using https://3d-api.si.edu/resources/js/v0.42.1/voyager-explorer.min.js (and several earlier versions), this works.
With https://3d-api.si.edu/resources/js/v0.43.0/voyager-explorer.min.js, we see the following error in the display:

image and nothing displays.

I'm not familiar enough with the format or the Voyager app to help debug this further, but I can point to other glb examples that fail the same way and can probably get answers about how these files were created if that helps. (Am I just using the root/model attributes incorrectly?)

I've also confirmed that we see the same problem using a static HTML file with just voyager-explorer element above followed by <script src="https://3d-api.si.edu/resources/js/v0.43.0/voyager-explorer.min.js"></script>

Thanks for any help and apologies if this is an issue on our end and not a bug.

Also FWIW, we found that the glb file was being loaded via

"Accept": url.endsWith(".html")?"text/html":"text/plain"
and our code was originally responding with a 406 because the mimetype is model/gltf-binary and not text/plain as was being requested. (It was the same in v0.42.1, so I assume it's not related, and we've worked around it, but I mention it in case it means we're not loading the file correctly)).

@gjcope
Copy link
Collaborator

gjcope commented Aug 12, 2024

Hi @qqmyers , thanks for the bug report and awesome to hear about the inclusion in Dataverse!

This is definitely a bug on our side introduced by an unnoticed type change. It's been fixed in 160a19f and will be included in the next release. As a temporary fix, you can manually set the quality parameter (ex: quality="High") to achieve the same thing.

FWIW I believe the model-only loading mechanism is not often used with Voyager as most of the viewer's value comes from content in the Voyager scene file compared to other lower-overhead viewers. Are you planning to support Voyager scenes in Dataverse as well? That would be super cool - happy to start another thread on the that topic if it would be helpful.

@qqmyers
Copy link
Author

qqmyers commented Aug 12, 2024

@gjcope - thanks for the fix and work-around! I've just added it so we can use 0.43.0.

As for supporting scene files - in general we follow the Dataverse users and I'm not sure how many datasets with scene files there are so far. I did look into the technical aspects. One challenge for us is that we don't support accessing files by their original path/name (even relative path). We also support having per-file access restrictions and embargoes and direct access to files on S3 stores using signed URLs. All of that means that somewhere we'd have to manage changing the scene file's references to our download URLs, handle error conditions where someone has restricted/embargoed a file needed by the scene file, etc. Not impossible, but more work that just pointing Voyager at the glb file.

@gjcope
Copy link
Collaborator

gjcope commented Aug 12, 2024

@qqmyers Got it. That makes sense, we went through something similar integrating Voyager with our repository system. If it does become a need for your users, happy to engage our developer who worked through those issues on our end as well.

@gjcope
Copy link
Collaborator

gjcope commented Aug 29, 2024

This has been addressed in the v0.44.0 release.

@gjcope gjcope closed this as completed Aug 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants