-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Level of Detail (LoD) or Quality of glTF asset #1743
Comments
Have you looked at the Microsoft LOD extension? Does this cover your needs to store the actual LODs? Could you please explain how you would use the quality vectors? From your usecase desciption I would guess that your browser/platform would choose the smaller LOD in case of bookmarks and use the heavier ones in other usecases - or am I missing something? |
The phrase "LOD" might be misleading here — I don't think the W3C question is about storage of the LODs, which would likely be in entirely separate glTF files unlike the Microsoft extension. The difficult question is how choose the metric(s), expressing to the browser the quality of each available glTF file in a way that enables it to choose the appropriate version. The Microsoft extension uses screen coverage as the single metric for their extension. Which really describes the context into which the model will be loaded, as all LODs presumably have the same dimensions. I don't know whether that metric would be right for W3C? Alone, it leaves no room for flexibility based on factors like filesize, network bandwidth, or device GPU performance. But it is similar to HTML |
Ah, thanks @donmccurdy I think we need to make distinction between, at least: At least in our case the @raviramachandra |
@donmccurdy we did look at the MSFT extension. But we could not use it, because all LoDs are embedded in the same asset. Like you mentioned, Browser/Platform will make a choice of asset from a list of assets to use and may only download the appropriate asset. MSFT extension considers only screen coverage, which is similar to an Image asset resolution. It does not consider vertex count, texture sizes which all contribute to "quality". @rsahlin |
@raviramachandra Thanks for the clarififaction Maybe something along the lines of:
What's your thoughts and comments on this? |
I wrote a small program that parses glTF into memory, traverses each scene and collects some metrics:
From this it would be easy to take a decision if the Waterbottle (1 node, 1 primitive, 5 texture channels) or GearboxAssy (118 nodes, 95 primitives, 0 texture channels) is heavy to render on your target platform. Hope this helps! |
@rsahlin Thanks for the info. I am following up this internally in Magic Leap and will respond to your earlier comment. |
@rsahlin I did have a discussion with both internal (within MagicLeap) and W3C community folks. We agree that these metrics provide fair quality assessment of the glTF asset. One factor that Microsoft uses is "screen coverage". This was also suggested by @kearwood in our github issue. As a glTF standard determining the LoD based on the above attributes would be a good start. The web community could use some kind of script (or online tool) to upload an asset and determine this vector of independent metrics. |
Hi @raviramachandra For your usecases I think it could be enough to know how large the render destination is - eg for a given usecase the target screen 'factor' is 0 -> 1 - where 0 is no coverage and 1 is the whole screen. Maybe you would need the screen coverage metric for a usecase where most of the screen is occupied by the model. Personally I would favor a method that assumes worst case - ie the size of the render target is used as screen coverage. |
@rsahlin yes, it makes sense to assume worst case. Also screen coverage will depend on how the platform rendering the asset will scale to it's needs. What would you recommend be the next steps in formalizing this. |
I guess the next steps are: A: Formalizing the metrics used to performance classify a glTF model - eg name a metric, describe what it means and define how it is calculated. B: Take decision if these metrics should be part of glTF as metadata or maybe added as part of 3D commerce metadata (XMP) or configuration - ie where does this feature belong? I think this feature is a configuration parameter that will be used by (mostly) backends to figure out what models to send to clients. |
For W3C purposes, my hunch would be something more like web responsive images and manifest icons. The user agent (client) is provided a list of glTF resources and (external to those resources) certain metrics about each, and chooses a resource as appropriate for the device capabilities, network speed, user preferences, and so on. If that is the case, I believe it's useful to choose good metrics and formally describe them, but not necessarily a requirement to embed them into glTF files. |
@donmccurdy agree, you put it correctly. @rsahlin Part A is of most interest for W3C. Depending on if Part B i.e inclusion of this metric in glTF metadata, we should provide a simple "online tool" for backend implementations to have the ability to get metrics out a given glTF asset, so it can be embedded into HTML tags or App Manifests as mentioned by @donmccurdy . Would you like to take the lead since you are most knowledgeable in this area ? |
Sure @raviramachandra I'll do my best :-) I think the first step would be to figure out which working group of 3D Commerce that this feature would belong to. What do you think of having this as a feature in 3Dcommerce metadata? I also think we need to setup repos for 3Dcommerce (metadata/certification/validation/configuration)
|
@rsahlin agree. Not sure if you have seen. FB has an extension of subset of these defined here
Not sure. I have not been involved there. But I was hoping at the end of this exercise, we publish a clear Guide in glTF repo and also develop a simple Tool (python or Javascript) that will spew out the above metrics. Should I bring this up at Weekly Meetings ? |
Good suggestion - now I'm starting to understand the way forward :-) If I understand the comments correctly we could move forward with a PR - this PR will declare the performance metrics and provide one (or more) tools to calculate these metrics. Yes, I did see the FB extension and it covers similar ground - however I think we need the additional metrics as discussed here. I think it would be good to have a short discussion regarding the way forward in the coming 3D formats call. |
@rsahlin Did we covere this topic on Feb 26 call. Will it get covered next week ? I did not see any notes w/ this issue. I will plan to attend the next call. |
@raviramachandra I put on the agenda but time ran out - hopefully next week :-) |
I have opened up a PR to move forward as agreed: |
Embedding this data into a file would not be very valuable, as it could not be trusted, right? Otherwise, one could upload a model that claims to be small, but is actually complex, possibly resulting in denial of service? |
Did levels of detail ever make it into the glTF spec? The PR mentioned above, #1779 apparently died with Magic Leap. |
W3C immersive-web group is planning to use glTF as an asset for Favicons, WebApp Manifest Icons on XR devices. See this: https://github.com/immersive-web/spatial-favicons/blob/master/explainer.md
To allow Browsers/Platforms to select from multiple glTF icons appropriately to the use case, a quality/LoD metric is needed. There are many questions pertaining to quality of the asset.
This issue is opened to track this effort and derive at this.
The text was updated successfully, but these errors were encountered: