<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">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 -
<a class="moz-txt-link-freetext" href="http://realism.com/blog/perspective-vs-orthographic-cameras">http://realism.com/blog/perspective-vs-orthographic-cameras</a>.<br>
<br>
Summary:<br>
<ol>
<li>The X3D perspective camera is well understood and represents
real-world objects (camera lenses, eye, etc). </li>
<li>The X3D orthographic camera appears to use standard
orthographic viewing region definitions; however, these are
not as well understood by content creators and developers.</li>
<li>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.</li>
</ol>
<p><br>
</p>
<p>Note that the post contains links to the 3D test scenes used to
create the images.</p>
<p><br>
</p>
<p>Leonard Daly<br>
</p>
<br>
<br>
<br>
<br>
On 5/23/2018 4:03 AM, Don Brutzman wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3e2b0c9c-9c35-27e8-4bcf-f3d295d13aae@nps.edu">On
5/22/2018 12:48 PM, Andreas Plesch wrote:
<br>
<blockquote type="cite">Hi Don,
<br>
<br>
I can not take any credit for the example, it is all Michalis' .
<br>
</blockquote>
<br>
thanks Andreas.
<br>
<br>
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.
<br>
<br>
<blockquote type="cite">x3dom does not center the example, as it
ignores any translation
<br>
component in the fieldOfView resulting from asymmetry in the
<br>
parameters around 0,0 .
<br>
<br>
For symmetric fieldOfView values, which may be more typical,
browsers
<br>
probably behave more consistently.
<br>
<br>
I believe the underlying reason for x3dom to just consider width
and
<br>
height (deltas) is that translation is expected by users to
occur in
<br>
the position field, and that therefore additional offsets would
be
<br>
somewhat confusing. Perhaps people started to use (0, 0, width,
<br>
height) since the parameters are not really defined in the spec.
<br>
<br>
Centering is also something which does not occur with the
regular
<br>
Viewpoint fieldOfView value.
<br>
</blockquote>
<br>
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).
<br>
<br>
that seems to be a contradiction, and thus an inconsistency in the
specification that needs to be fixed.
<br>
<br>
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.
<br>
<br>
<blockquote type="cite">So I would still favor just two parameters
(width, height) as
<br>
fieldOfView if it were not for keeping backwards compatibility.
Once
<br>
could also argue that it is easy to just always use symmetric
values.
<br>
</blockquote>
<br>
First let's figure out how to define correctness, then addressing
backwards compatibility follows.
<br>
<br>
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.
<br>
<br>
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:
<br>
<br>
========================================================
<br>
23.4.6 Viewpoint
<br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/navigation.html#Viewpoint">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/navigation.html#Viewpoint</a>
<br>
[...]
<br>
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.
<br>
<br>
A browser with a rectangular viewing projection has the following
relationship:
<br>
<br>
display width tan(FOVhorizontal/2)
<br>
-------------- = -------------------
<br>
display height tan(FOVvertical/2)
<br>
<br>
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.
<br>
========================================================
<br>
<br>
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).
<br>
<br>
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.
<br>
<br>
23.3.1 X3DViewpointNode
<br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/navigation.html#X3DViewpointNode">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/navigation.html#X3DViewpointNode</a>
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
So... more work here, but it now looks like we are definitely
fixing a problem and producing an improved X3Dv4.
<br>
<br>
Better and better, literally. 8)
<br>
<br>
<blockquote type="cite">Another example should probably test
default values, and another one
<br>
position/translation component combos. The NIST Conformance
scenes are
<br>
really well designed and are good templates.
<br>
<br>
Let's what viewpoint features are tested, for inspiration.
<br>
<br>
-Andreas
<br>
</blockquote>
<br>
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)
<br>
<br>
<blockquote type="cite">On Tue, May 22, 2018 at 3:21 PM, Don
Brutzman <a class="moz-txt-link-rfc2396E" href="mailto:brutzman@nps.edu"><brutzman@nps.edu></a> wrote:
<br>
<blockquote type="cite">There are also inconsistent display
results when testing the baseline
<br>
scene's default view on different X3D browsers. Some are
centered, some are
<br>
not.
<br>
<br>
We have no scenes in the X3D Examples to test OrthoViewpoint.
That probably
<br>
is a contributor to inconsistency problems.
<br>
<br>
Wondering if we might add one or more scenes designed for
conformance
<br>
testing, to encourage consistency.
<br>
<br>
The logical location, and design patterns for success, can be
found in the
<br>
NIST Conformance Suite examples. More work but higher
potential value.
<br>
Exemplar:
<br>
<br>
X3D Example Archives: Conformance Nist, Bindable
Nodes, Viewpoint
<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/x3d/content/examples/ConformanceNist/BindableNodes/Viewpoint">http://www.web3d.org/x3d/content/examples/ConformanceNist/BindableNodes/Viewpoint</a>
<br>
<br>
Anyone interested in tackling this?
<br>
<br>
Thanks for sharing your current example Andreas.
<br>
<br>
<br>
<?xml version="1.0" encoding="UTF-8"?>
<br>
<!DOCTYPE X3D PUBLIC "ISO//Web3D//DTD X3D 3.3//EN"
<br>
<a class="moz-txt-link-rfc2396E" href="http://www.web3d.org/specifications/x3d-3.3.dtd">"http://www.web3d.org/specifications/x3d-3.3.dtd"</a>>
<br>
<X3D profile='Full' version='3.3'
<br>
xmlns:xsd='<a class="moz-txt-link-freetext" href="http://www.w3.org/2001/XMLSchema-instance">http://www.w3.org/2001/XMLSchema-instance</a>'
<br>
xsd:noNamespaceSchemaLocation='<a class="moz-txt-link-freetext" href="http://www.web3d.org/specifications/x3d-3.3.xsd">http://www.web3d.org/specifications/x3d-3.3.xsd</a>'>
<br>
<Scene>
<br>
<OrthoViewpoint fieldOfView='-1 -1 4 4'
description='default' />
<br>
<!--
<br>
# since Box centers are between (0, 0 - 3, 3), and Box
sizes are (2, 2,
<br>
2),
<br>
# so below field of view should force the browser to
*exactly* align
<br>
# window borders so they match Boxes borders (in the
shorter axis,
<br>
# usually vertical; in the other axis you will see
slightly more)
<br>
-->
<br>
<OrthoViewpoint fieldOfView='-1 -2 4 5'
description='taller' />
<br>
<Shape DEF='S'>
<br>
<Appearance>
<br>
<Material diffuseColor='1 1 0' />
<br>
</Appearance>
<br>
<Box />
<br>
</Shape>
<br>
<Transform translation='3 0 0'>
<br>
<Shape USE='S' />
<br>
</Transform>
<br>
<Transform translation='0 3 0'>
<br>
<Shape USE='S' />
<br>
</Transform>
<br>
<Transform translation='3 3 0'>
<br>
<Shape USE='S' />
<br>
</Transform>
<br>
<Transform translation='0 0 -3'>
<br>
<Shape USE='S' />
<br>
</Transform>
<br>
<Transform translation='3 0 -3'>
<br>
<Shape USE='S' />
<br>
</Transform>
<br>
<Transform translation='0 3 -3'>
<br>
<Shape USE='S' />
<br>
</Transform>
<br>
<Transform translation='3 3 -3'>
<br>
<Shape USE='S' />
<br>
</Transform>
<br>
</Scene>
<br>
</X3D>
<br>
<br>
<br>
<br>
<br>
On 5/20/2018 1:48 PM, Andreas Plesch wrote:
<br>
<blockquote type="cite">
<br>
On Mon, May 7, 2018 at 2:49 PM, Andreas Plesch
<a class="moz-txt-link-rfc2396E" href="mailto:andreasplesch@gmail.com"><andreasplesch@gmail.com></a>
<br>
wrote:
<br>
<blockquote type="cite">
<br>
On Mon, May 7, 2018 at 1:28 AM, Don Brutzman
<a class="moz-txt-link-rfc2396E" href="mailto:brutzman@nps.edu"><brutzman@nps.edu></a> wrote:
<br>
<blockquote type="cite">
<br>
Thanks for multiple helpful postings on this topic.
Offhand I'm not
<br>
remembering special rationale involved. Good question
for CAD experts
<br>
where
<br>
OrthoViewpoint view is more commonly used.
<br>
</blockquote>
<br>
<br>
..
<br>
Another aspect which I am not quite clear about is
navigation from a
<br>
Orthoviewpoint, along the viewing direction. Strictly
speaking,
<br>
orthographic projection would mean no zooming during such
navigation.
<br>
The zoom is only defined by the fieldOfView. However, the
user
<br>
expectation would be zooming during such navigation which
then leads
<br>
to some interaction between location and field of view. I
should test
<br>
how browsers behave but any insight would be much
appreciated.
<br>
</blockquote>
<br>
<br>
Using as a test for navigation along the viewing direction:
<br>
<br>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/castle-engine/demo-models/blob/master/navigation/ortho_viewpoint.x3dv">https://github.com/castle-engine/demo-models/blob/master/navigation/ortho_viewpoint.x3dv</a>
<br>
<br>
<a class="moz-txt-link-freetext" href="https://raw.githubusercontent.com/andreasplesch/Library/master/Tests/Components/Navigation/ortho_viewpoint.x3d">https://raw.githubusercontent.com/andreasplesch/Library/master/Tests/Components/Navigation/ortho_viewpoint.x3d</a>
<br>
<br>
no zooming when navigating along viewing direction:
<br>
<br>
- x_ite
<br>
- view3dscene
<br>
- InstantPlayer
<br>
- freeWRL
<br>
- octaga
<br>
- h3dviewer
<br>
<br>
zooming:
<br>
<br>
- x3dom
<br>
<br>
na:
<br>
<br>
- BSContact
<br>
<br>
The majority of browsers applies the orthographic projection
such that
<br>
only the fieldOfView controls the 'zoom' level and the
distance of the
<br>
viewpoint to any object is irrelevant. This is strict and a
bit
<br>
counter-intuitive but probably does not need any
clarification in the
<br>
prose.
<br>
<br>
-Andreas
<br>
</blockquote>
<br>
<br>
<br>
all the best, Don
<br>
--
<br>
Don Brutzman Naval Postgraduate School, Code USW/Br
<a class="moz-txt-link-abbreviated" href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>
<br>
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
+1.831.656.2149
<br>
X3D graphics, virtual worlds, navy robotics
<a class="moz-txt-link-freetext" href="http://faculty.nps.edu/brutzman">http://faculty.nps.edu/brutzman</a>
<br>
<br>
</blockquote>
<br>
<br>
<br>
</blockquote>
<br>
<br>
all the best, Don
<br>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Past Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>