Model (and page) Scale?

[zachernuk]

We've established that entityTransform being managed by a DOMMatrix is a reasonable way to work on transforming the appearance of a model, but there's a mapping that we need establish between the real-world dimensions that are inside 3D models and the pixel- or point-based scale of a web page.

CSS dimensions technically do have cm (and inches, if you must) but we need to look at the perceptual appropriateness of leaning on them, based on where browsers with a more complicated relationship with scale end up. (both Quest and visionOS, through various user operations, can end up with very different perceptual scale to the logical "points" or "pixels" recorded for a window)

This isn't to get spatially-correct dimensions for any particular context, as the window metrics should be the main determinant for this - but I wanted to check in on what is a reasonable place to put some scale factor.

/agenda

[zachernuk]

Looking at this with a demo I think we should use the heuristic of 1cm CSS = ~1cm world, understand there's going to be variability with environments with a dynamic scale, and then expect to encode 1cm CSS == 1cm world if/when we establish a context with a spatially consistent container (rather than, say, a perceptually consistent container/window based on degrees of arc)

[zachernuk]

It's probably important to clarify that there are three reference frames we need to think about and resolve:

• Model-world scale, in cm/inches/etc
• Window-world scale, primarily in pt/CSS pixels, but also referring to cm and in etc.
• Real-world scale, in cm/cubits/furlongs/etc

My proposal is that we make a hard link between model-world scales and window-world scales, so a model containing a 10x10cm object, set in a <model> with dimensions of 10x10cm, with an identity scale applied, will fully occupy the viewport.

This actually isn't close to the perceptual size of the viewport today. The mapping we use on the web to cm/in/etc is set at 72 dpi, and in practice many devices and monitors look closer to 110-200 dpi.

Relating this back to real-world dimensions is tricky - but on a 16" MacBook Pro this mapping is roughly correct only at the 2nd of 5 settings - next to "Larger text."

This is a recommendation that's independent of Real-world scales, and is actually grounding the model-scale as quite a bit larger than it currently is (in our experimental, feature-flagged presentation, based on default scales and distances. So it goes.)

This still doesn't resolve any consistency between window-world and real-world, which is effectively an OS/design decision - but

1. That mapping is likely to be different between devices/versions/etc, and
2. It can vary based on custom distance or OS settings, so there's no way to index too closely to that.

The initial Auto-fit and orbit-fit should function the same anyway, but what the numbers for scale mean - i.e. what the identity looks like, and values that are absolutely-derived. Ultimately we need to settle on some frame of reference, and the fact that both model contents and CSS have some notion of centimeters, it's probably safest that we bind those together.

[AdaRoseCannon]

Note css size are all relative to the number of CSS pixels where there are 96 CSS pixels per inch so this should work irrespective of pixel density or actual physical size of the document window.

[m-blix]

This generally seems to make sense, establishing a 1:1 correspondence of CSS unit to model unit.

[mkeblx]

On the call we generally agreed that this should be specified, and that 1 cm model scale should equal 1 CSS cm.

<model style="width: 1cm; height: 1cm">
   <source src="1cm-box.glb">
</model>

<!-- model.entityTransform scale => 1 -->

Figuring out a perceptual real-world scale portal was discussed and would be useful in some scenarios, but may come with some user privacy issues that needs more consideration.