[x3d-public] OrthoViewpoint fieldOfView - and display size
Leonard Daly
Leonard.Daly at realism.com
Wed May 23 10:17:33 PDT 2018
I have been watching and reading the comments on camera types and field
of view. It is important for me to understand so I can properly
implement in XSeen. I did a bit of research and found several uses of a
4 (or 8) point viewing region for orthographic projections (8 points
include near and far clipping planes). To help matters I wrote a blog
post on the issues and included example images to illustrate some of the
points - http://realism.com/blog/perspective-vs-orthographic-cameras.
Summary:
1. The X3D perspective camera is well understood and represents
real-world objects (camera lenses, eye, etc).
2. The X3D orthographic camera appears to use standard orthographic
viewing region definitions; however, these are not as well
understood by content creators and developers.
3. X3D adds one final change to the field of view so that the rendered
content fits the display region. This additional parameter
over-specifies the camera system. This over-specification is most
obvious in an orthographic camera.
Note that the post contains links to the 3D test scenes used to create
the images.
Leonard Daly
On 5/23/2018 4:03 AM, Don Brutzman wrote:
> On 5/22/2018 12:48 PM, Andreas Plesch wrote:
>> Hi Don,
>>
>> I can not take any credit for the example, it is all Michalis' .
>
> thanks Andreas.
>
> since you, he, Doug and a few other people are building your own test
> suites, any scenes that you think provide test coverage of common
> interest remain welcome. we can figure out where each might best belong.
>
>> x3dom does not center the example, as it ignores any translation
>> component in the fieldOfView resulting from asymmetry in the
>> parameters around 0,0 .
>>
>> For symmetric fieldOfView values, which may be more typical, browsers
>> probably behave more consistently.
>>
>> I believe the underlying reason for x3dom to just consider width and
>> height (deltas) is that translation is expected by users to occur in
>> the position field, and that therefore additional offsets would be
>> somewhat confusing. Perhaps people started to use (0, 0, width,
>> height) since the parameters are not really defined in the spec.
>>
>> 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.
>
> 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.
>
>> So I would still favor just two parameters (width, height) as
>> fieldOfView if it were not for keeping backwards compatibility. Once
>> 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:
>
> ========================================================
> 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).
>
> 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.
>
> 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.
>
> 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.
>
> So... more work here, but it now looks like we are definitely fixing a
> problem and producing an improved X3Dv4.
>
> Better and better, literally. 8)
>
>> 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.
>>
>> -Andreas
>
> 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)
>
>> 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
--
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Past Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180523/c39463c0/attachment-0001.html>
More information about the x3d-public
mailing list