[x3d-public] OrthoViewpoint fieldOfView - and display size

[Andreas Plesch]

On Mon, May 7, 2018 at 1:28 AM, Don Brutzman <brutzman at nps.edu> wrote:
> Thanks for multiple helpful postings on this topic.  Offhand I'm not
> remembering special rationale involved.  Good question for CAD experts where
> OrthoViewpoint view is more commonly used.

It is also useful for exact map views, for scenes which use UTM
directly. Perhaps there could be a GeoOrthoviewpoint node for scenes
with geoCoordinates as well.

Another aspect which I am not quite clear about is navigation from a
Orthoviewpoint, along the viewing direction. Strictly speaking,
orthographic projection would mean no zooming during such navigation.
The zoom is only defined by the fieldOfView. However, the user
expectation would be zooming during such navigation which then leads
to some interaction between location and field of view. I should test
how browsers behave but any insight would be much appreciated.

> X3D Tooltip:
> http://www.web3d.org/x3d/content/X3dTooltips.html#OrthoViewpoint.fieldOfView
> =========================================
> [fieldOfView accessType inputOutput, type MFFloat CDATA "-1 -1, 1 1"]
> Minimum and maximum extents of view in units of local coordinate system.
> Small field of view roughly corresponds to a telephoto lens, large field of
> view roughly corresponds to a wide-angle lens.
> Warning: minimum corner must remain less than maximum corner.
> Hint: rectangular display width/height = (maxX-minX) / (maxY-minY)
> =========================================
>
> If someone wants to collate everything posted regarding OrthoViewpoint
> fieldOfView into a proposed specification-text prose change, am happy to use
> that to establish a Mantis entry that tracks this issue.  Important to list
> options and tradeoffs when doing so.

Let me try to come up with prose to circulate here before submitting
specification comment.

My main initial concern was clarification of the existing prose which
comes down to explaining each parameter of the 4-tuple. This could be
concise.

>
> As far as going from a 4-tuple to a 2-tuple for fieldOfView, and considering
> default values, and considering fractional or unit based, there is no better
> time to pursue such a change than when going to X3D v4 which indeed allows
> such modifications - when justifiable.

These are functional changes for which I am not sure there is enough
support to justify breaking backward compatibility. Although I do
think that width and height would have better ergonomics.

> May I suggest that someone look into SVG and HTML to see if there is some
> potential benefit to changing our representation to better match with an
> existing Web design pattern.  X3D authoring would remain really awkward if a
> broader norm exists and our norm is different (or difficult to map) for no
> good reason.

The web CSS transform function comes to mind:

https://developer.mozilla.org/en-US/docs/Web/CSS/transform

It lets you scale and shift a HTML element, probably including the svg
element and the webgl canvas element.

SVG has a viewBox attribute for the SVG element and for view elements:

https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/viewBox

It lets you define what is effectively the field of view for different
views.  It is defined in terms of min-x, min-y, width and height.

There is also a related preserveAspectRatio attribute:

https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/preserveAspectRatio

It defines if and how aspect ratio should be preserved. A 'meet' value
of this attribute would correspond to the minimum range requirement of
Orthoviewpoint.

>
> Am finding a number of OrthoViewpoint issues already in Mantis when
> searching, but none seem particularly relevant to this point.
> http://www.web3d.org/member-only/mantis/search.php?project_id=4&search=OrthoViewpoint
>
> Of course having fieldOfView values that are fractional to screen size
> actually begs the point somewhat if screen size remains unknown...
> Rechecked mantis, not finding any issues relevant to screen size.
> http://www.web3d.org/member-only/mantis/search.php?project_id=4&search=screen

Another idea would be to indicate a fraction of the _scene_ size
(perpendicular to the viewing direction), with default values
providing a way to guarantee that the full (100%) scene is shown.

> Am thinking that being able to determine display screen size at run time
> ought to be part of SAI for authors, and just rechecked, but am not finding
> it.  The Browser services list is lengthy but doesn't have that:
>
> 6.3 Browser services
> http://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/servRef.html#BrowserServices
>
> Related: a number of years back I started exposing Browser functionality in
> a "Scene" prototype, trying to expose SAI functionality that otherwise
> required scripting to expose in a scene.  It includes several "wish list"
> parameters including pixelHeight and pixelWidth.  Incomplete/imperfect
> trial:
>
> - Basic X3D Examples Archive, development, Scene Node Prototype
>   "Expose functionality of Browser class in Java/ECMAscript annexes of VRML
> 97 specification. Consider promotion to a native node in X3D/VRML 200x
> scenes."
>
> http://www.web3d.org/x3d/content/examples/Basic/development/SceneNodePrototypeIndex.html
>
> I frequently see HTML or tablet/phone app examples that require knowledge of
> screen size to properly function from a user perspective.  Always left with
> impression "X3D needs those parameters from browser" or X3D scenes cannot be
> similarly effective.  Historically, past browser-builder companies could
> never seem to agree on resolution (or even need) to handle the issue, and so
> this remains a gap...  am guessing that this definciency is why
> OrthoViewpoint.fieldOfView is weakly specified.

Yes, for HTML this is called 'responsive' design, eg. dynamically
adjusting layout and style for specific media and screen sizes. Use of
CSS alone can often accomplish this goal (since selectors can query
media sizes). For example, one could start to hide elements for small
screens (display: none). For web integrated X3D browsers and SAI like
code for those, it is already easy to query the current size of the
display area (canvas) and then act accordingly.

One could imagine adaptive scenes which provide different levels of
complexity in the content based on screen size.

Practically, in X3D it may mean routing from a Scene.pixelWidth field
to a Switch node (preferably without scripting in between, perhaps
using a Sequencer).

You can ask x3dom how large 1px at the current far clipping distance
is, which I think was useful.

>
> So, suggestion: let's fix both OrthoViewpoint.fieldOfView and Browser screen
> size together, consistently, if possible.  Aligning well with HTML or SVG or
> current practice in apps will simplify X3D authoring and integration.
>
> Am also happy to dedicate X3D Working Group teleconference discussion time
> if that can help.  This is an excellent opportunity for progress, thanks for
> considering the possibilities.

Let's see what can come out this,

-Andreas