-
Notifications
You must be signed in to change notification settings - Fork 31
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
Comments
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. |
@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. |
@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. |
This has been addressed in the v0.44.0 release. |
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:
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
dpo-voyager/source/client/io/FileReader.ts
Line 63 in ebbda0b
The text was updated successfully, but these errors were encountered: