[x3d-public] OrthoViewpoint fieldOfView - and display size
Don Brutzman
brutzman at nps.edu
Wed May 23 04:03:27 PDT 2018
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
--
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
More information about the x3d-public
mailing list