-
Notifications
You must be signed in to change notification settings - Fork 4
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
Load objects with very large textures #31
Comments
Just jotting down some thoughts and/or complexities that should be worked through when thinking about this story. This is a bit of devil's advocate question, but in what ways could this not be satisfied by user story #11? Presumably one could wrap up a (gigantic) texture map into a GLTF file and serve it in the same way that the previous user story describes, though that would, of course, be non-ideal for a number of reasons. Basically, what I'm getting at is, presumably, the acceptance criteria for this story would include some support in the manifest for providing multiple textures to be used at different points in time (in a Level of Detail kind of way), or potentially supporting image tiling. If that's the case, how would the manifest need to be changed/expanded in order to be able to support these things? How do 2D presentation API manifests change to support 2D image tiling - do they include any explicit support for tiling in the presentation manifest itself? This story also focuses on textures, which is definitely a use case people have. Another use case would be supporting different model complexities in terms of number of polygons. If something like this user story is incorporated into a work package, do we also need a user story for that? And again like above, how should the presentation API manifest be changed to support that? |
I'm basing it on a use case from one of our clients who have these exact requirements. Their tapestry was digitised using an RTI machine built at UWE by Dr Xavi Aure which has produced very large albedo and normal map textures. LODding won't work as when you get to the highest magnification it would still need to load the entire 10k + px textures. I think it makes sense to create a separate user story for LODding. Because they want it presented online, as opposed to a "baked" offline experience, they need something similar to the IIIF image API that dynamically loads only the necessary tiles within the current viewport. @ponchio mentioned Virtual Texturing on our last TSG call. Here's an example of what he means: https://www.youtube.com/watch?v=M6y4glzIwP8 The fact that the normal and albedo maps were generated by an RTI machine is irrelevant - they could have been produced any number of ways, hence my assertion that "it's just textures". |
There will be a creative aspect to the project (e.g. sounds, parallax effects), so we want to be able to use three.js which has the richest ecosystem of tools for creatives using 3D. |
As a Curator at a charity with a large tapestry as one of our main visitor attractions
I want to be able to capture the intricate detail of the tapestry surface and display it in a creative 3D online presentation
So that the public can view/study the tapestry to build engagement/attract visitors.
The text was updated successfully, but these errors were encountered: