[x3d-public] OrthoViewpoint fieldOfView - and display size

Andreas Plesch andreasplesch at gmail.com
Wed May 23 05:43:01 PDT 2018


Hi Don,

On Wed, May 23, 2018 at 7:03 AM, Don Brutzman <brutzman at nps.edu> wrote:
>> ...
>> Centering is also something which does not occur with the regular
>> Viewpoint fieldOfView value.
>
> aha, am beginning to understand a bit better.  i too had wondered about
> semantics that seem a bit overloaded - the position and orientation fields
> define a specific direction to look at, but the 4-tuple fieldOfView (if
> off-centered) indicates a different direction (towards the center of the 4
> corners).
>
> that seems to be a contradiction, and thus an inconsistency in the
> specification that needs to be fixed.

It is a bit confusing, although what happens is that position and
fieldOfView get combined.

> if we all agree that specification cannot be corrected solely by adding
> further explanatory prose, then we indeed have a problem that must be fixed
> by changing the field signature of OrthoViewpoint fieldOfView.

Explaining the four parameters as min x/y, max x/y in the correct
order would be the minimum correction which achieves perhaps
sufficient certainty.

>> So I would still favor just two parameters (width, height) as
>> fieldOfView if it were not for keeping backwards compatibility. One
>> could also argue that it is easy to just always use symmetric values.
>
> First let's figure out how to define correctness, then addressing backwards
> compatibility follows.
>
> Any 4-tuple for the fieldOfView window is similarly problematic:  defining 4
> coreners is equivalent to defining (width, height) and an X-Y lookat offset.
>
> If we indeed agree that a 4-tuple for FOV window cannot work, and since the
> Viewpoint/GeoViewPoint fieldOfView fields are 1-tuples, then we should avoid
> overloading inconsistent semantics on the fieldOfView field and change its
> name.  Existing definition:

Yes, this is the question. Michalis had a use case where the 4 tuple
seemed advantageous. So an immediate test would if this use case could
as easily use width/height plus position.

> ========================================================
> 23.4.6 Viewpoint
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/navigation.html#Viewpoint
> [...]
> The fieldOfView field specifies a preferred minimum viewing angle from this
> viewpoint in angle base units. A small field of view roughly corresponds to
> a telephoto lens; a large field of view roughly corresponds to a wide-angle
> lens. The field of view shall be greater than zero and smaller than π. The
> value of fieldOfView represents the minimum viewing angle in any direction
> axis perpendicular to the view.
>
> A browser with a rectangular viewing projection has the following
> relationship:
>
>     display width    tan(FOVhorizontal/2)
>     -------------- = -------------------
>     display height   tan(FOVvertical/2)
>
> where the smaller of display width or display height determines which angle
> equals the fieldOfView (the larger angle is computed using the relationship
> described above). The larger angle shall not exceed π and may force the
> smaller angle to be less than fieldOfView in order to sustain the aspect
> ratio.
> ========================================================
>
> It is not necessary (or possible) to preserve strict backwards compatibility
> if a field is incorrectly specified.  We can define a suggested conversion
> algorithm (convert X3Dv3 4-tuple corners to X3Dv4 by computing 2-tuple
> width, height).

Width, height are just differences between min max values. The
position is derived from the center (average x and y), probably taking
into account the viewpoints direction.

The 1 tuple fov of viewpoint brings up that it would be possible to
also just have a single dimension for orthoviewpoint which is
guaranteed to fit in the display (typically the height). The other
dimension is derived from the actual display aspect ratio (as in
viewpoint).

>
> Nice side effect of such a correction would be that newfound consistency of
> existing fieldOfView field can be adjusted to become part of
> X3DViewpointNode abstract interface.  This improves the Unified Object
> Model.

That would be the1 tuple for both case ?

>
> 23.3.1 X3DViewpointNode
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/navigation.html#X3DViewpointNode
>
> Doubling back to an earlier theme in this thread: we should next look at how
> display-size functionality of this 2-tuple field is defined in OpenGl, HTML5
> and SVG, then redefine (with a different name) and provide well-defined
> semantics for X3Dv4.

SVG: The viewBox attribute for the SVG element and for view elements
is the exact analog:

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. Other values distort or cut off.

HTML5: Not sure how to transport the idea of a viewpoint but I think
the idea is to consider the browser window as a viewport. Fitting
content into the window (exclusively?) works inside out,eg. the
content self-scales. It can do so by using relative size, as
percentages to the size of the browser window.

> Additional due diligence: we should similarly look at whether it is possible
> to define or determine overall display dimensions, to assist authors trying
> to adjust (Geo)Viewpoint fieldOfView precisely.

This is already possible in a web browser environment.
canvas.clientWidth/Height can be queried to get dimensions in pixels.
Since the X3D element has the 3d canvas element attached to it, it
would be most natural to add clientWidth/Height, and page position to
the X3D element.
In terms of SAI, it would become an additional SAI Browser service
read only property.

>
>> Another example should probably test default values, and another one
>> position/translation component combos. The NIST Conformance scenes are
>> really well designed and are good templates.
>>
>> Let's what viewpoint features are tested, for inspiration.

Most NIST tests are about proper scene graph integration and would not
need to be replicated for Orthoviewpoint since a reasonable assumption
is that an implementation would behave the same for both kinds of
viewpoints in this regard.

There is a test for default values, and for non-standard fov values.

> Sounds great.  The Design Printing Scanning group has added a number of
> scenes to test consistency with ISO STEP models.  We should be willing to
> follow the outstanding example of NIST and extend the ConformanceNIST
> Examples Archive to provide broader coverage, rather than treating it as an
> unmodifiable shrine...  8)

One might even say the official examples archive and especially the
conformance tests define the defacto standard.

Circling back to interactive zooming capability, I think it would be
important to clarify either that zooming by user gestures is not
possible with Orthoviewpoints (since the projection does not support
it directly), or if it is deemed an important capability how browsers
may allow for it, or restrict it (navigation mode).

Although currently not widely supported, I tend to think that users
want to zoom in interactively and not just by jumping to different
Orthoviewpoints.

-Andreas

>> On Tue, May 22, 2018 at 3:21 PM, Don Brutzman <brutzman at nps.edu> wrote:
>>>
>>> There are also inconsistent display results when testing the baseline
>>> scene's default view on different X3D browsers.  Some are centered, some
>>> are
>>> not.
>>>
>>> We have no scenes in the X3D Examples to test OrthoViewpoint.  That
>>> probably
>>> is a contributor to inconsistency problems.
>>>
>>> Wondering if we might add one or more scenes designed for conformance
>>> testing, to encourage consistency.
>>>
>>> The logical location, and design patterns for success, can be found in
>>> the
>>> NIST Conformance Suite examples.  More work but higher potential value.
>>> Exemplar:
>>>
>>>          X3D Example Archives: Conformance Nist, Bindable Nodes,
>>> Viewpoint
>>>
>>>
>>> http://www.web3d.org/x3d/content/examples/ConformanceNist/BindableNodes/Viewpoint
>>>
>>> Anyone interested in tackling this?
>>>
>>> Thanks for sharing your current example Andreas.
>>>
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <!DOCTYPE X3D PUBLIC "ISO//Web3D//DTD X3D 3.3//EN"
>>> "http://www.web3d.org/specifications/x3d-3.3.dtd">
>>> <X3D profile='Full' version='3.3'
>>> xmlns:xsd='http://www.w3.org/2001/XMLSchema-instance'
>>>
>>> xsd:noNamespaceSchemaLocation='http://www.web3d.org/specifications/x3d-3.3.xsd'>
>>>    <Scene>
>>>      <OrthoViewpoint fieldOfView='-1 -1 4 4' description='default' />
>>>      <!--
>>>      # since Box centers are between (0, 0 - 3, 3), and Box sizes are (2,
>>> 2,
>>> 2),
>>>      # so below field of view should force the browser to *exactly* align
>>>      # window borders so they match Boxes borders (in the shorter axis,
>>>      # usually vertical; in the other axis you will see slightly more)
>>>      -->
>>>      <OrthoViewpoint fieldOfView='-1 -2 4 5' description='taller' />
>>>      <Shape DEF='S'>
>>>        <Appearance>
>>>          <Material diffuseColor='1 1 0' />
>>>        </Appearance>
>>>        <Box />
>>>      </Shape>
>>>      <Transform translation='3 0 0'>
>>>        <Shape USE='S' />
>>>      </Transform>
>>>      <Transform translation='0 3 0'>
>>>        <Shape USE='S' />
>>>      </Transform>
>>>      <Transform translation='3 3 0'>
>>>        <Shape USE='S' />
>>>      </Transform>
>>>      <Transform translation='0 0 -3'>
>>>        <Shape USE='S' />
>>>      </Transform>
>>>      <Transform translation='3 0 -3'>
>>>        <Shape USE='S' />
>>>      </Transform>
>>>      <Transform translation='0 3 -3'>
>>>        <Shape USE='S' />
>>>      </Transform>
>>>      <Transform translation='3 3 -3'>
>>>        <Shape USE='S' />
>>>      </Transform>
>>>    </Scene>
>>> </X3D>
>>>
>>>
>>>
>>>
>>> On 5/20/2018 1:48 PM, Andreas Plesch wrote:
>>>>
>>>>
>>>> On Mon, May 7, 2018 at 2:49 PM, Andreas Plesch <andreasplesch at gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>> ..
>>>>> 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.
>>>>
>>>>
>>>>
>>>> Using as a test for navigation along the viewing direction:
>>>>
>>>>
>>>>
>>>> https://github.com/castle-engine/demo-models/blob/master/navigation/ortho_viewpoint.x3dv
>>>>
>>>>
>>>> https://raw.githubusercontent.com/andreasplesch/Library/master/Tests/Components/Navigation/ortho_viewpoint.x3d
>>>>
>>>> no zooming when navigating along viewing direction:
>>>>
>>>> - x_ite
>>>> - view3dscene
>>>> - InstantPlayer
>>>> - freeWRL
>>>> - octaga
>>>> - h3dviewer
>>>>
>>>> zooming:
>>>>
>>>> - x3dom
>>>>
>>>> na:
>>>>
>>>> - BSContact
>>>>
>>>> The majority of browsers applies the orthographic projection such that
>>>> only the fieldOfView controls the 'zoom' level and the distance of the
>>>> viewpoint to any object is irrelevant. This is strict and a bit
>>>> counter-intuitive but probably does not need any clarification in the
>>>> prose.
>>>>
>>>> -Andreas
>>>
>>>
>>>
>>>
>>> all the best, Don
>>> --
>>> Don Brutzman  Naval Postgraduate School, Code USW/Br
>>> brutzman at nps.edu
>>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
>>> +1.831.656.2149
>>> X3D graphics, virtual worlds, navy robotics
>>> http://faculty.nps.edu/brutzman
>>>
>>
>>
>>
>
>
> all the best, Don
> --
> Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
>



-- 
Andreas Plesch
Waltham, MA 02453



More information about the x3d-public mailing list