-
Notifications
You must be signed in to change notification settings - Fork 12
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
Is media= enough for LOD handling? (or do we need srcset?) #49
Comments
potentially, yes... do they?
That would be great! Another thing to consider would be if |
@marcoscaceres GLTF has at least one extension |
The proposal for KHR_mesh_variants would get us pretty close to LOD handling, too. That said — LODs are a very specific technical solution to a broader problem. Whether file formats adopt them or not, a Consider glTF extensions for compression — e.g. Draco, Meshopt, Basis — that either complement or exceed traditional HTTP transport compression like gzip and brotli for 3D content. Compression technology will improve over time, and browser support for existing and future extensions will vary. See WebKit/explainers#75 for more discussion here. glTF headers identify when a particular extension is "optional" or "required" when loading an asset, and the user agent should ideally download compressed 3D scenes if possible. While I don't know whether USD has a similar concept of extensions, I imagine similar complications might apply to running different versions of the USD Runtime in different browsers, or to different subsets of the broader USD format being supported in different browsers. tl;dr — there are a lot of criteria affecting which asset a browser should load. If |
I agree. At least, I'd like to exhaust |
Just to be clear, LOD handling might still be done dynamically by the format itself. This would be more for model selection based on, for example, |
LOD should be left up to the UA. |
MSFT_lod is certainly not a holistic approach to adjusting a model for every target device. It is a more specific optimization technique generally used for swapping particular objects within the scene for higher-detail versions as the camera gets closer to those objects, often used alongside other responsive performance techniques in games. Per #49 (comment), there are many reasons a model might be "costly". It may have be a large file requiring too much bandwidth, or an expensive material requiring too much GPU compute, or contain large textures requiring too much GPU VRAM, or have too many draw calls for the available CPU and graphics APIs. I do not think it is likely that fallbacks for all scenarios can/will be expressed and included within a single file, in any format. We probably need to allow the developer to provide options, and to express the differences between them somehow. |
One thing I've been considering is how LOD handling should be handled on the web. Could we leverage
<source srcset
to define LOD swapping?An example:
The idea here would be that when the model is rendered at 200px or less in the viewport that the model from url
assets/example_200.usdz
would be rendered. Just to be clear I'm not talking about elementsinnerWidth
but rather the render resolution of the model itself calculated from a bounding sphere.It could be assumed that the lowest quality model is the one that would be rendered at the lowest resolution.
Arguing against this idea it could be argued that the 3D Model Format itself should define this functionality.
I've created a demo using canvas/webgl that has similar functionality that I can share at some point if it's helpful.
The text was updated successfully, but these errors were encountered: