Specify the view on model contents

[zachernuk]

At TPAC we discussed the necessity to point the view into a <model> element at specific locations within it, e.g. to focus on specific features of a car.

We also agreed that for both reasons of complexity for the author and compatibility across platforms, that supplying view information like a 4x4 projection matrix were not appropriate. Instead, to follow something closer to the style indicated with the existing proposed JS syntax, i.e setCamera({pitch:10, yaw:10, scale:1}).

My suggestion is to specify an {x,y,z} object as an optional origin or pivot parameter on that setCamera call:

myShelf.setCamera( { 
  pitch:0, 
  yaw:20, 
  scale:1, 
  pivot: {x:0, y:1, z:0}
} );

and in fact for the other parameters to be made optional as well, with the presumption that no supplied value implies to retain the same one.

[zachernuk]

/agenda

[cabanier]

Can you explain what shelf represents? Are you defining a new API on the model element?

[zachernuk]

aha - no! I have been using a 3D model of a shelf / shelf configurator as a sample for doing this (and the IBL example), so I was naming the hypothetical model based on what it is doing. I've updated the name to be myShelf to reflect that it's a user object rather than an API name.

[DR-xR]

Are the units for rotation in radians or degrees? I suspect from the provided values that it is degrees, but JS deals with radians. There is the potential issue of using one unit for the API and a different one for the HTML because it is more convenient for the user and environment.

It is also necessary to define the origin (up & forward) and location. Location is necessary because how far you look up (for example) depends on how far away from the object you are looking at. If that is included in pivot, then I am confused. If that is to be the location of the camera (relative to the local origin), then why not use location.

[zachernuk]

After a lot of exploration I think it would be better to pursue a metaphor where the root element (possibly even denoted as model.rootElement) exposes the transform it's using.

This avoids the notion of a "camera" as an obligatory feature at all, which would help clarify its function in spatial/stereoscopic environments.

And while I think we can and should pursue a V1 specification (and implementation) that doesn't reach into a scene graph, exposing the root node will give us a reasonable pattern to follow once we have the appetite to do so.

/facetoface

[zachernuk]

/tpac

[zachernuk]

from discussions at TPAC I think the DOMMatrix-based transformation seems adequate - we could try to investigate XRRigidTransform but I do suspect it has more information in it than we actually want.

Another thing we get out of using DOMMatrix is that we could aim to specify the (entity|view|model)transform within CSS, which opens the door to styling and transitions, and leveraging CSS animation on the properties. I find that very exciting. @toji, is there anything that we'd be missing out on from DOMMatrix?

[toji]

I don't think so. Though to be a bit pedantic: XRRigidTransform is actually more limited than DOMMatrix in terms of the transforms that it can represent.

The reason it was discussed at all is because there was some concern about supporting skew, which DOMMatrix allows and XRRigidTransform would avoid. However XRRigidTransform also doesn't allow for scale, which seems fairly important for this use case. As such even though we'll need to figure out how to handle skew it does seem like DOMMatrix is the better option here. (In addition to the CSS capabilities mentioned.)

[zachernuk]

/agenda
Do we want to codify that this happens both with DOMMatrix and in CSS? It's not essential to do both, but it does mean things like transition-duration and CSS Animations have a way to being used.