[x3d-public] OrthoViewpoint fieldOfView - and display size

[Leonard Daly]

Andreas et al,

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.

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.


Leonard Daly


> 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.
> 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.
>
>> X3D Tooltip:
>> http://www.web3d.org/x3d/content/X3dTooltips.html#OrthoViewpoint.fieldOfView
>> =========================================
>> [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.
> 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.
>
>> 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.
> 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.
>
>> 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.
> The web CSS transform function comes to mind:
>
> https://developer.mozilla.org/en-US/docs/Web/CSS/transform
>
> 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:
>
> 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.
>
>> Am finding a number of OrthoViewpoint issues already in Mantis when
>> searching, but none seem particularly relevant to this point.
>> http://www.web3d.org/member-only/mantis/search.php?project_id=4&search=OrthoViewpoint
>>
>> 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.
>> http://www.web3d.org/member-only/mantis/search.php?project_id=4&search=screen
> 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.
>
>> 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
>> http://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/servRef.html#BrowserServices
>>
>> 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."
>>
>> 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 "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.
> 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.
>
>> 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.
> Let's see what can come out this,
>
> -Andreas
>

-- 
*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/20180509/a4d8a42f/attachment-0001.html>