Whatever happened to the Microsoft LOD node proposal? Adopted? Dropped? Superseded?
What’s current best practice on storing multiple LODs in one glTF asset?
(Use case: Second Life / Open Simulator type metaverses, which are gradually converting over to glTF from COLLADA and proprietary formats.)
Whatever happened to the Microsoft LOD node proposal? Adopted? Dropped? Superseded?
MSFT_lod is not a proposal. It’s a vendor extension that a few Microsoft products are/were using.
There are some discussions of this on GitHub:
What’s current best practice on storing multiple LODs in one glTF asset?
I don’t know if we have one at the moment. There hasn’t been enough progress for standardizing one that I would call best practice. Feel free to add to some of the discussion threads if you want to push things forward.
Adding LODs to glTF ·- right, that’s the MSFT extension. Best summary of that discusssion was “@xissburg My sense is that there’s too many use cases, too different from one another, for easy agreement to emerge on a simple extension… and banging out a more sophisticated one that addresses the majority of use cases is a huge amount of “soft” work –– someone, or some ones, to re-ignite and then lead discussion patiently, over time, in finding and merging common interests and working towards a solution acceptable for most, and tolerated by all.”
Level of Detail (LoD) or Quality of glTF asset – that was associated with Magic Leap, and seems to have died with it.
Progressive glTF: Exploring Ideas · Issue #2270 · KhronosGroup/glTF (github.com)](Progressive glTF: Exploring Ideas · Issue #2270 · KhronosGroup/glTF · GitHub) – more of a research question, on how to make progressive files where you read more and get more detail as you read more file, like progressive image formats. Unreal’s Nanite is sort of like that. But that’s very different from glTF.
What comes out of this is that the problem has at least two main parts - how to put multiple models in one glTF file, and metrics for deciding which to use. The first is straightforward. The second is not very portable, because different systems will have different cost metrics for meshes. All the proposals got stuck on the second problem.
I’d like to have a solution for the first problem, multiple LOD model storage, with metrics left as a a future problem or one to be resolved by the loader.
My understanding is that glTF files can have multiple models in them. That they are all considered “LODs” of the same conceptual model (and therefore should not all be rendered simultaneously) is something your application can work out, perhaps through a simple naming convention.
Ultimately, I’m not sure how you can separate problem 1 from problem 2 in a meaningful, application agnostic way. That is, what does it mean for two models to be “LODs” of the same conceptual model without also including how to distinguish when to render which ones? Which model with a glTF viewer pick to render at any given time?
I’m not sure if this addresses the part of the question you’re after, but one possibility here is to split the data for each mesh into separate .bin files, each of which can be loaded on demand.
npm install --global @gltf-transform/cli
gltf-transform partition input.glb output.gltf --meshes
It’s also possible to do selective loading over a network even when all the data is in a single .glb file, but requires a web server set up to handle HTTP range requests, and possibly some customization of the code you’re using to load the file.
There’s no lack of hacks to do this. But for a good commercial ecosystem, where you create assets in Blender/Maya/etc, sell them through asset stores, buyers buy them and upload them to virtual worlds and games, the LOD representation needs to be standardized. Part of the point of glTF was to get away from shipping around .zip files of assets, with some assembly required before use.
We have struggled with this as well and are about to propose a new extension EE_variant. We have just released a whitepaper detailing our solution and have extended the MSFT work to bridge the gap between LOD and instancing. I am not able to include a link in the forum but can send our white paper with details on how this works. Let me know if you’d like it or look up Griffin Rowell on linkedin and I have a link there.
A formal extension proposal for this would be good. If you’ve published a “whitepaper”, why can’t you publish a link to it here? It’s the right place to discuss this.
I know. The forum will not let me include a link. It gives me an error that links can’t be included when I paste the link here. It’s a bizarre limitation. https go etherealengine com/siggraphwp
Add the punctuation and that will take you to it.
Now we have a Microsoft proposed standard and a Ethereal proposed standard. Would someone from Khronos like to try to bring them together?
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.