[x3d-public] supporting VIEWALL capabilities for users, authors, browsers - Mantis 1194

[Don Brutzman]

VIEWALL functionality has been around form many years, but it is not a current part of the X3D v3.3 specification.

Am hoping that we might regularize its use, since VIEWALL can be very valuable when "lost in space" viewing problems occur.  Certainly end users and browsers can benefit from documenting best practices.  Scene authors might also benefit if we can make VIEWALL a triggerable NavigationInfo behavior for cool animation or user assistance.

Attached please find discussion that has been migrated (with permission) from X3D Working Group mailing list, along with a current copy of issue 1194 Web3D Consortium Mantis Issue Tracker.

All of us working and learning together is powerful.  All feedback and comment welcome as efforts continue to improve the X3D user experience in X3D version 4.


http://www.web3d.org/member-only/mantis/view.php?id=1194
=============================================================
Subject: "VIEWALL" needs to be a required navigation behavior

A common failure mode for end users is to have no viewpoint, or incorrect viewpoints, inside a large X3D model. Such a situation means that there is no way to tell if the scene is empty, or the browser is broken, or what else might be going on.

This pathology is becoming more prevalent as CAD and 3D printing models are created more frequently, especially with varying units.

VIEWALL thus needs to be available as a navigation option (and also recovery mode) for users.

A number of X3D browsers have already implemented this functionality, which therefore appears to be well understood.

Suggest adding:

"VIEWALL" zooms back to show all geometry in a scene, either from the current location or from the default viewpoint location.

=============================================================

One example VIEWALL algorithm for X3D browser:

a. compute bounding box and center for entire current scene.
b. stay at current location, re-orient view to look at that center.
c. move out (or in) along that vector until bounding box is within view frustum.
d. (Dick's variation) if objects are very small, might need to move in further, or draw the bounding box, or something.

Not a goal: strictly specifying such an algorithm to allow compatible browser innovations, since different approaches might be appropriate depending on user/scene context.

=============================================================

On 1/26/2018 12:30 AM, Don Brutzman wrote:
> On 1/25/2018 12:42 PM, Roy Walmsley wrote:
>> Hi,
>>
>> I have been giving further thought to the discussion we had at yesterday’s X3D WG meeting about VIEWALL as a proposed new Navigation type.
> 
> Thanks for excellent discussion and thoughtful email analysis.
> 
> This discussion is much more appropriate on x3d-public list since it involves broad usability and implementation and authoring issues, all at one time.  Can we please move it there?  Feel free to push "as is" prior to next round of replies.  Might also do well to attach pdf of current issue following any edits you want to make.
> 
> * Mantis issue 1194 – 19775-1, 23.4.4 NavigationInfo - VIEWALL should be a required navigation behaviour
> 
> Reference: http://www.web3d.org/member-only/mantis/view.php?id=1194
> 
>> Short summary: I’m opposed as proposed, but recommend adding to Annex G.
> 
> X3D 19775 Abstract Spec,  Annex G Recommended navigation behaviours (informative)
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/behaviours.html#SelectFromMulitpleViewpoints
> 
> "This annex describes basic X3D scene navigation recommended practice." and
> "Features that imply interactivity are fundamental in X3D."
> 
> The mantis proposal is seeking a general improvement, not a specific path, so figuring out the best appropriate resolution is certainly welcome.  Let us all first seek to understand please.  Interestingly, for good navigation practices and common patterns of interaction/usage like this, truly excellent capabilities are only really possible when pursued as a group endeavor.
> 
> Of related note:  Annex G is not referred to by NavigationInfo section and likely should be.
> 
>> Long reasoning:
>>
>>  1. Looking first at the semantics of a Navigation mode I conclude it is a continuous state, where the browser user has the freedom, as permitted by the file author, to move the viewpoint through or around the scene.
> 
> Yes we should be clear on whether it occurs once or continuously.  Given that multiple VIEWALL algorithms are possible, even within a single browser depending on context, continuous operation is difficult to define.  The user ceding continuous control to the browser is also inconsistent with our interaction model.
> 
> Likely better is to define that this NavigationInfo type:
> a. can enable user-interface buttons,
> b. is a one-shot behavior upon activation.  Then reverts to prior active type in the bound NavigationInfo, or else binds/unbinds if no other type is defined in the NavigationInfo node.
> 
>>  2. Looking second at the semantics of Viewpoint node I conclude it is a predefined position that can be user selected. On selection it tells the browser to move to a specific state. The user is then free to navigate away from this state, or not.
> 
> Not clear what you mean here - will assume this is Leonard's point that an author can predefine a "see everything" Viewpoint beforehand.
> 
> That is certainly an excellent option and already available.  However certain dynamic content can not be computed in advance, and VIEWALL button response is typically context dependent.
> 
> As the original issue tries to point out, the need is clearly established by various recurring "lost in space" pathologies and also the commonplace (but not universal) offering of such navigation by browsers.
> 
> The use cases listed in the mantis issue might be further extended by considering value of this mode when viewing scenes in HMD devices for VR/AR/MAR applications.  (... and certainly continuous VIEWALL of dynamic scenes is not good for such displays since that might easily trigger simulation sickness.)
> 
>>  3. What is our intended usage of VIEWALL? Is it the former, or the latter?
> 
> a. Offering reasonably consistent VIEWALL functionality to end users in all browsers, for all scenes where such a navigation type makes sense (i.e. incompatible with "NONE").
> b. Given value to end users, also offer activation of this animation capability to scene authors as well so that it can be an optional part of designing the user experience.
> 
>>  4. It is definitely not the former.
>>  5. It is also not the latter.
> 
> Unsure of your context... hopefully the points above are helpful in elaborating the posted issue.
> 
>> It is not intended to be predefined, although, of course, a scene author could always provide a “VIEWALL” viewpoint.
> 
> I don't agree that an author can "always" define a VIEWALL viewpoint... since dynamic content getting loaded/removed at run time may preclude /a priori/ definition.
> 
>> Rather, the use case is for a dynamic calculation of this  viewpoint.
> 
> Yes, as an animated navigation option both for users and also for scene designers.
> 
>>  6. Therefore, this should be a browser capability.
> 
> Yes, and therefore defined in X3D Abstract Specification.
> 
>> Recommended navigation behaviours, including Viewpoint selection, is covered in Annex G. A “VIEWALL” capability should be part of the browser interface, and covered in Annex G (informative) Recommended navigation behaviours.
> 
> Agreed that is an excellent place in spec to elaborate these kinds of rationales and practices.  Terse functional description should also be listed under 23.4.4 NavigationInfo with other type values.
> 
>> Thanks for reading. Comments welcome.
>>
>> All the best,
>>
>> Roy
> 
> Thanks Roy.  Hopefully this functionality is now better described.  Further reactions will be valuable.
> 
> I expect this is one of several navigation types that have evolved over the years which we will all want to capture so that advantages are available and repeatable among browsers, users and scene authors.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ViewallMantis1194_ 28JAN2018.pdf
Type: application/pdf
Size: 188284 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180128/22802ab1/attachment-0001.pdf>