<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Andreas et al,<br>
<br>
I know this is a few days late. I want to withdraw my earlier
statement about the coordinates being fractional size of the total
scene. My new thinking (and this is without developing examples or
checking the code) is that the coordinates are world-units. All 4
values define the viewing window -- anything outside that region
is not rendered. Zoom-in is reducing the size of the viewing
window; zoom-out is increasing the size of the viewing window.
Moving a fixed-size viewing window is the same as scrolling though
the scene. This 4-vector is equivalent to a look direction and
field-of-view in determining the center and extent of the viewing
window. <br>
<br>
In practical applications, the viewing window needs to be adjusted
for the size of the physical display (or display region in the
page/application). I do not know why the decision was made to use
the 4-tuple. Perhaps it was thought to be easier for the developer
to determine the viewing window size values.<br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
</div>
<blockquote type="cite"
cite="mid:CAKdk67uk5wQUtzF+TfDzBTdHtWY7Y=M6uqUgG2ZC_ZPNGVeCcA@mail.gmail.com">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
It is also useful for exact map views, for scenes which use UTM
directly. Perhaps there could be a GeoOrthoviewpoint node for scenes
with geoCoordinates as well.
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.
</pre>
<blockquote type="cite">
<pre wrap="">X3D Tooltip:
<a class="moz-txt-link-freetext" href="http://www.web3d.org/x3d/content/X3dTooltips.html#OrthoViewpoint.fieldOfView">http://www.web3d.org/x3d/content/X3dTooltips.html#OrthoViewpoint.fieldOfView</a>
=========================================
[fieldOfView accessType inputOutput, type MFFloat CDATA "-1 -1, 1 1"]
Minimum and maximum extents of view in units of local coordinate system.
Small field of view roughly corresponds to a telephoto lens, large field of
view roughly corresponds to a wide-angle lens.
Warning: minimum corner must remain less than maximum corner.
Hint: rectangular display width/height = (maxX-minX) / (maxY-minY)
=========================================
If someone wants to collate everything posted regarding OrthoViewpoint
fieldOfView into a proposed specification-text prose change, am happy to use
that to establish a Mantis entry that tracks this issue. Important to list
options and tradeoffs when doing so.
</pre>
</blockquote>
<pre wrap="">
Let me try to come up with prose to circulate here before submitting
specification comment.
My main initial concern was clarification of the existing prose which
comes down to explaining each parameter of the 4-tuple. This could be
concise.
</pre>
<blockquote type="cite">
<pre wrap="">
As far as going from a 4-tuple to a 2-tuple for fieldOfView, and considering
default values, and considering fractional or unit based, there is no better
time to pursue such a change than when going to X3D v4 which indeed allows
such modifications - when justifiable.
</pre>
</blockquote>
<pre wrap="">
These are functional changes for which I am not sure there is enough
support to justify breaking backward compatibility. Although I do
think that width and height would have better ergonomics.
</pre>
<blockquote type="cite">
<pre wrap="">May I suggest that someone look into SVG and HTML to see if there is some
potential benefit to changing our representation to better match with an
existing Web design pattern. X3D authoring would remain really awkward if a
broader norm exists and our norm is different (or difficult to map) for no
good reason.
</pre>
</blockquote>
<pre wrap="">
The web CSS transform function comes to mind:
<a class="moz-txt-link-freetext" href="https://developer.mozilla.org/en-US/docs/Web/CSS/transform">https://developer.mozilla.org/en-US/docs/Web/CSS/transform</a>
It lets you scale and shift a HTML element, probably including the svg
element and the webgl canvas element.
SVG has a viewBox attribute for the SVG element and for view elements:
<a class="moz-txt-link-freetext" href="https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/viewBox">https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/viewBox</a>
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:
<a class="moz-txt-link-freetext" href="https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/preserveAspectRatio">https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/preserveAspectRatio</a>
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.
</pre>
<blockquote type="cite">
<pre wrap="">
Am finding a number of OrthoViewpoint issues already in Mantis when
searching, but none seem particularly relevant to this point.
<a class="moz-txt-link-freetext" href="http://www.web3d.org/member-only/mantis/search.php?project_id=4&search=OrthoViewpoint">http://www.web3d.org/member-only/mantis/search.php?project_id=4&search=OrthoViewpoint</a>
Of course having fieldOfView values that are fractional to screen size
actually begs the point somewhat if screen size remains unknown...
Rechecked mantis, not finding any issues relevant to screen size.
<a class="moz-txt-link-freetext" href="http://www.web3d.org/member-only/mantis/search.php?project_id=4&search=screen">http://www.web3d.org/member-only/mantis/search.php?project_id=4&search=screen</a>
</pre>
</blockquote>
<pre wrap="">
Another idea would be to indicate a fraction of the _scene_ size
(perpendicular to the viewing direction), with default values
providing a way to guarantee that the full (100%) scene is shown.
</pre>
<blockquote type="cite">
<pre wrap="">Am thinking that being able to determine display screen size at run time
ought to be part of SAI for authors, and just rechecked, but am not finding
it. The Browser services list is lengthy but doesn't have that:
6.3 Browser services
<a class="moz-txt-link-freetext" href="http://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/servRef.html#BrowserServices">http://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/servRef.html#BrowserServices</a>
Related: a number of years back I started exposing Browser functionality in
a "Scene" prototype, trying to expose SAI functionality that otherwise
required scripting to expose in a scene. It includes several "wish list"
parameters including pixelHeight and pixelWidth. Incomplete/imperfect
trial:
- Basic X3D Examples Archive, development, Scene Node Prototype
"Expose functionality of Browser class in Java/ECMAscript annexes of VRML
97 specification. Consider promotion to a native node in X3D/VRML 200x
scenes.<a class="moz-txt-link-rfc2396E" href="http://www.web3d.org/x3d/content/examples/Basic/development/SceneNodePrototypeIndex.htmlIfrequentlyseeHTMLortablet/phoneappexamplesthatrequireknowledgeofscreensizetoproperlyfunctionfromauserperspective.Alwaysleftwithimpression">"
http://www.web3d.org/x3d/content/examples/Basic/development/SceneNodePrototypeIndex.html
I frequently see HTML or tablet/phone app examples that require knowledge of
screen size to properly function from a user perspective. Always left with
impression "</a>X3D needs those parameters from browser" or X3D scenes cannot be
similarly effective. Historically, past browser-builder companies could
never seem to agree on resolution (or even need) to handle the issue, and so
this remains a gap... am guessing that this definciency is why
OrthoViewpoint.fieldOfView is weakly specified.
</pre>
</blockquote>
<pre wrap="">
Yes, for HTML this is called 'responsive' design, eg. dynamically
adjusting layout and style for specific media and screen sizes. Use of
CSS alone can often accomplish this goal (since selectors can query
media sizes). For example, one could start to hide elements for small
screens (display: none). For web integrated X3D browsers and SAI like
code for those, it is already easy to query the current size of the
display area (canvas) and then act accordingly.
One could imagine adaptive scenes which provide different levels of
complexity in the content based on screen size.
Practically, in X3D it may mean routing from a Scene.pixelWidth field
to a Switch node (preferably without scripting in between, perhaps
using a Sequencer).
You can ask x3dom how large 1px at the current far clipping distance
is, which I think was useful.
</pre>
<blockquote type="cite">
<pre wrap="">
So, suggestion: let's fix both OrthoViewpoint.fieldOfView and Browser screen
size together, consistently, if possible. Aligning well with HTML or SVG or
current practice in apps will simplify X3D authoring and integration.
Am also happy to dedicate X3D Working Group teleconference discussion time
if that can help. This is an excellent opportunity for progress, thanks for
considering the possibilities.
</pre>
</blockquote>
<pre wrap="">
Let's see what can come out this,
-Andreas
</pre>
</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>