Something I ran into while sketching out some sample code for 2.0: The new magic window structure has the UA providing the projection matrix for magic window canvases based largely on the properties of the canvas itself, the environment, and a small amount of developer supplied scene information. The classic components needed for a simple projection matrix are:
- near/far bounds: VRSession attributes
- aspect ratio: Computed from canvas dimensions
- Horizontal or vertical FoV: Varies
The FoV is a funny one, because ideally we want it to align to several things very precisely to retain the feeling of it being an actual window. In a phone AR scenario it should be precisely matched to the properties of the camera that's providing the video feed (All AR APIs have a way of communicating this.) In the case of an in-VR browser or a device like a ZSpace system you'll want to compute the FoV to match the user's eye positions in relation to the canvas position on screen. (Well, you'll probably be dealing with frusta at that point rather than FoV, but that's besides the point.) And obviously in presentation mode we want to report values that align to the device optics.
However, if you don't have any information about where the user's eyes are in relation to the canvas, and you're not matching to an external data source then we still need to some up with a field of view somehow. And it needs to be consistent across UAs so that carefully aligned content doesn't clip on one device but not on others. The question is: how do we determine that number?
Easiest way to handle this is to roll some dice, declare that to be the default value, and move along. Being slightly more practical we can plop down another attribute next to depthNear/depthFar called defaultVerticalFieldOfView or something similar and call it good. We'd still need our dice roll to come up with a default for the default attribute, but otherwise it just uses whatever the developer sets unless there's a canonical source of FoV. We could also try to get really technical about it and say "Projection matrices should be computed assuming the user's eye is one meter away from the center of the device perpendicularly blah blah blah" and come up with a number based on that, but if we're being honest with ourselves that's not any more useful than a dice roll number and a lot more work.
So the TL;DR is: We probably need a defaultVerticalFieldOfView (or horizontal) on VRSession that describes the Field of View used when computing magic window matrices that don't need to match external data. We also need to collectively agree on what the default value for that attribute should be. If anyone has a more clever/useful idea of how to handle it, or thinks there's a better way of expressing the necessary values than a simple FoV, I'd appreciate hearing it!
Something I ran into while sketching out some sample code for 2.0: The new magic window structure has the UA providing the projection matrix for magic window canvases based largely on the properties of the canvas itself, the environment, and a small amount of developer supplied scene information. The classic components needed for a simple projection matrix are:
The FoV is a funny one, because ideally we want it to align to several things very precisely to retain the feeling of it being an actual window. In a phone AR scenario it should be precisely matched to the properties of the camera that's providing the video feed (All AR APIs have a way of communicating this.) In the case of an in-VR browser or a device like a ZSpace system you'll want to compute the FoV to match the user's eye positions in relation to the canvas position on screen. (Well, you'll probably be dealing with frusta at that point rather than FoV, but that's besides the point.) And obviously in presentation mode we want to report values that align to the device optics.
However, if you don't have any information about where the user's eyes are in relation to the canvas, and you're not matching to an external data source then we still need to some up with a field of view somehow. And it needs to be consistent across UAs so that carefully aligned content doesn't clip on one device but not on others. The question is: how do we determine that number?
Easiest way to handle this is to roll some dice, declare that to be the default value, and move along. Being slightly more practical we can plop down another attribute next to
depthNear/depthFarcalleddefaultVerticalFieldOfViewor something similar and call it good. We'd still need our dice roll to come up with a default for the default attribute, but otherwise it just uses whatever the developer sets unless there's a canonical source of FoV. We could also try to get really technical about it and say "Projection matrices should be computed assuming the user's eye is one meter away from the center of the device perpendicularly blah blah blah" and come up with a number based on that, but if we're being honest with ourselves that's not any more useful than a dice roll number and a lot more work.So the TL;DR is: We probably need a
defaultVerticalFieldOfView(or horizontal) onVRSessionthat describes the Field of View used when computing magic window matrices that don't need to match external data. We also need to collectively agree on what the default value for that attribute should be. If anyone has a more clever/useful idea of how to handle it, or thinks there's a better way of expressing the necessary values than a simple FoV, I'd appreciate hearing it!