[x3d-public] OrthoViewpoint fieldOfView - and display size
Andreas Plesch
andreasplesch at gmail.com
Wed May 23 09:14:47 PDT 2018
A quick follow-up:
On Wed, May 23, 2018 at 8:43 AM, Andreas Plesch <andreasplesch at gmail.com> wrote:
...
>>
>> 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.
>
> 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.
https://raw.githubusercontent.com/andreasplesch/Library/master/Tests/Components/Navigation/ortho_viewpoint_pos.x3d
is a modified version of the example which uses position and a
symmetric fov. It seems to work as intended in view3dscene, x_ite and
x3dom.
But other use cases may have different requirements.
-Andreas
For quick testing:
x3dom: http://andreasplesch.github.io/Library/Viewer/x3dom.html
x_cite: http://andreasplesch.github.io/Library/Viewer/
Both: http://andreasplesch.github.io/Library/Viewer/x3dweb.html
>
>> ========================================================
>> 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
--
Andreas Plesch
Waltham, MA 02453
More information about the x3d-public
mailing list