[x3d-public] OrthoViewpoint fieldOfView

[Andreas Plesch]

Thanks for this response. I take it to confirm that my understanding of the
field is largely correct. It took reading source and background on
orthographic projection to arrive at this understanding, so I think there
is room for improvement in the explanation.

I do think the explanation needs to include what each of the four
components is meant to define.

Instead of using 'minimum extent', perhaps something like 'The defined
rectangle is guaranteed to be fully visible' ?

I disagree that using four sides is more intuitive than using width and
height and location, especially when transferring from a regular viewpoint.
But it would be counterproductive to break backward compatibility for such
a change.

-Andreas

On Fri, May 4, 2018, 5:54 PM Michalis Kamburelis <michalis.kambi at gmail.com>
wrote:

> 2018-05-04 22:57 GMT+02:00 Andreas Plesch <andreasplesch at gmail.com>:
> > I think it is intended as an implementation note to suggest the
> > maximum/minimum_x/y need to be recomputed by the browser to fit the
> > display aspect ratio before being used in a projection matrix but I am
> > not sure. I may also be a warning that the fieldOfView parameters need
> > to have the same aspect ratio than the viewport which, however, is
> > typically not known to the scene author in advance. Overall, the note
> > may be more confusing than helpful.
>
> Indeed (as far as I understood and implemented), the
> "OrthoViewpoint.fieldOfView" must be adjusted to match the aspect
> ratio of the window, when being used for projection. The specified
> "OrthoViewpoint.fieldOfView" in X3D file describes only the *minimum*
> view. So the X3D author controls precisely what *must* be visible in
> the window, and leaves up to the renderer to eventually show a little
> more, depending on window aspect ratio.
>
> This is consistent with perspective "Viewpoint.fieldOfView" treatment.
> It also describes a *minimum* angle.
>
> BTW, I just noticed there's a simple bug in this specification text:
> the text about "X3DViewpointNode" also talks about "fieldOfView", "The
> fieldOfView field specifies a preferred minimum viewing angle....".
> Which is incorrect, as "X3DViewpointNode" does not define
> "fieldOfView". Only the "Viewpoint" and "OrthoViewpoint" define
> "fieldOfView" (with different types, but consistent treatment).
>
>
> > There is also the question why the four corners should be provided and
> > not just a width and height, eg. two parameters, more similar to the
> > perspective field of view. In theory, providing the four corners
> > allows for an asymmetric projection, eg. an additional shift away from
> > the center. Since the center is also the center of rotation of examine
> > mode, this option seems exotic and not very useful. In fact, x3dom
> > seems to override any asymmetry and just uses the width and height
> > (deltas) with 0 offset. It looks x_ite allows that, on the other hand,
> > although I did not test. There was perhaps some additional
> > consideration when the field was introduced ? Does anybody recall ?
>
> One can change the center of rotations using the centerOfRotation
> field (available on both OrthoViewpoint and Viewpoint), so it's not
> always zero. In view3dscene/Castle Game Engine, I actually use the
> bounding box center as the default pivot for Examine camera, so
> Examine navigation works "out of the box" for any scene.
>
> From my experience (coding various 2D games using CGE :) ), it is
> useful that a 2D orthographic projection is defined as 4 corners, not
> just width,height. It allows to shift the center, which means that the
> meaning of "OrthoViewpoint.position" is configurable.
>
> E.g.
>
> - with OrthoViewpoint.fieldOfView = (-1, -1, 1, 1), the
> OrthoViewpoint.position determines what is visible precisely at the
> center of the screen.
>
> - with OrthoViewpoint.fieldOfView = (0, 0, 2, 2), the
> OrthoViewpoint.position determines what is visible precisely at the
> bottom-left corner of the screen, for a square window. For panoramic
> window (window.width > window.height), the OrthoViewpoint.position at
> least determines what is visible precisely at the bottom of the
> screen.
>
> All these options are useful, i.e. they allow to "think" about a 2D
> camera easier, in my experience. In some games, I want to place things
> around the center of the screen. In other games, I want to place
> things around the bottom of the screen, e.g. because hero is standing
> at the ground (
> https://store.steampowered.com/app/746750/The_Unholy_Society/
> :) ).
>
> I think that, technically, we could indeed get rid of this (and define
> "OrthoViewpoint.fieldOfView" as only 2 floats, and add any necessary
> shift to "OrthoViewpoint.position"), but it's just easier to think
> when it's 4 values. It's may be also more natural to animate
> "OrthoViewpoint.position" in some cases.
>
> A simple OrthoViewpoint test for CGE is on
>
> https://github.com/castle-engine/demo-models/blob/master/navigation/ortho_viewpoint.x3dv
> .
>
> Regards,
> Michalis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180505/1bebdd60/attachment-0001.html>