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