Redefines camera to pose#144
Conversation
|
|
||
| <div w-nodev> | ||
|
|
||
| <p>The position, rotation, and scale of a model element's contents are controlled through the |
There was a problem hiding this comment.
I think this should be strengthened with MUST, SHOULD, etc
|
|
||
| <ol> | ||
|
|
||
| <li><p>Determine the <code data-x="dom-model-boundingboxextents">boundingBoxExtents</code>, <var>extents</var>, of the resource and store it in the relevant attribute.</p></li> |
There was a problem hiding this comment.
This should be rewritten as an algorithm. You can see how to do that in the WebXR spec.
There was a problem hiding this comment.
This boundingBox computation is happening below the level of the UA in our implementation - does that still make it a candidate for definition within the scope of this document?
There was a problem hiding this comment.
@fantasai provided guidance on an appropriate level of detail about the bounding box. I'm hoping that anyone leveraging an underlying 3D engine will simply be able to call this, rather than having to write their own in-place.
There was a problem hiding this comment.
@cabanier Do you think the algorithm needs to be spelled out here, or is it something we can expect to leverage in an underlying system?
There was a problem hiding this comment.
yes it should. It doesn't matter where the code runs.
Add some MUSTs and a SHOULD to reflect a stronger stance on correct functioning
Adds a definition of the bounding box (which can be further clarified when we get to animation etc)
Added a plausible bounding box calculation algorithm
|
Okay, I've added an AABB calculation - @cabanier LMK if it needs more detail! |
Removed links to issue 41 and 42, which this PR is supposed to resolve.
4 participants
Updates the section relating to camera and orientation to reflect the discussion of leveraging the
DOMMatrixobject as anentityTransformover the model, per discussions in the CG.Fixes #42
Fixes #41
Preview | Diff