-
Notifications
You must be signed in to change notification settings - Fork 7
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
Need clarification on "sizes" #5
Comments
For detail: this issue arose from a discussion in the Feb 26th CG telecon - https://www.w3.org/2019/02/26-immersive-web-minutes.html, search for "size". The core issue here is that "sizes" is used in flat image icons to help the UA select an appropriate resource to download - based on how it will render, you can avoid upscaling (by choosing a "big enough" resource) as well as downloading too big or detailed a resource (by choosing one that's "not too big"). Unfortunately, this isn't quite the same as for 3D resources - where we probably want something that is more akin to "level of detail". You'd still want to only d/l a low-poly-count/small-texture model for a low-res display, or far-off LoD, but might want to offer a more detailed model for higher res or closer PoV. |
Our original intent was to use a bounding box computed by asset developer and specify this as a "hint" to UA/platform. There is a LoD extension from MSFT, but that would not be helpful to our case, since various levels are packaged in the same asset. Would something like lod: "high"/"medium"/"small" text work ? We will also explore other and get back here. |
Yeah, something like that, but we'd probably need to give some more direct guidelines as to what that meant in terms of physical-to-user size? |
IIRC from TPAC, we'd discussed both LOD and physical size as information that would influence usage and that it was the specific use case that drove which property would be more important. |
That would an ideal case. If we want to do away with minimal spec changes, it would be best to interpret 'size' attribute and make a decision based on it. If we want both, we would have to introduce new fields in WebApp manifest and new attributes to tag. We prefer not to add additional attributes, but if the immersive-group thinks there is value to it, we are open. @NellWaliczek what do you think ? |
These comments are mostly derived from the presentation during the F2F on June 5. If this is not the correct place to post them, please let me know where I should post. I like the idea of 3D model icons; however, there are a number of issues that need to be address.
|
@DRx3D thanks for the feedback.
Also, what is an alternative to guess-timating quality either on poly count of spatial size ? |
A goal of PBR rendering is to separate the material attributes of a model from the environment that the object is to be presented in. Rather than specifying the environment map as part of the favicon, it should be generated or chosen by the UA to represent the environment that the favicon is being displayed within. The methods used to generate the diffuse irradiance and cube map / environment map for reflections in are described in the lighting-estimation incubation repo. For display within a VR headset, the same algorithms would be performed using the UA's internal scene geometry. For an AR headset, this can be augmented with sensor sampled data and AI algorithms. A successful lighting model would be one that holds up in a future that incorporates real-time global illumination and raytraced reflections as well as current mainstream imaged based lighting techniques. |
In particular, a commonly used method of determining the LOD level decoupled from scaling or distance was described at TPAC. This "screen coverage" method works by determining the maximum FOV covered by the bounding box of the model, as an angle (degrees / radians). This angle is used as the criteria to select the appropriate LOD model. An "LOD Bias" multiplier can be applied to this angle value by the UA or experience that is rendering the model to adjust for varying hardware capabilities and display fidelity. Often this can be done dynamically to target a minimum frame-time for the rendering of the objects. |
Excited that @grorg brought back up spatial favicons today! This "size" issue is the key thing I believe we need to solve before we standardize here. There are two key approaches I've seen us discuss for handling different levels of detail here:
It sounds like Magic Leap's shell currently uses size of the placed model in meters to choose an LOD, and so something more static like approach 1 best fits there (since you don't need any other sizes unless the user can resize the model). Meanwhile, the HoloLens shell uses screen coverage to choose an LOD, does something more dynamic like approach 2 fits best there (since other sizes can be quickly loaded as you move closer). It would be great to hear which of these approaches best matches what @grorg is thinking here! |
FWIW, For this reason, I think it is ok to start with simply mapping icon size to the approximate resulting size of the icon in display pixels (taking scaling into account, etc). It is also ok for the browser to enforce a limit on the data size of the resource, or the rendering complexity - encouraging people to make the best icons they can, as small (in complexity) as they can. |
No description provided.
The text was updated successfully, but these errors were encountered: