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

John Carlson yottzumm at gmail.com
Wed Jan 31 09:37:35 PST 2018


So it seems like VIEWALL supports non-geographical requirements, such as VR editing.  When the scene is significantly edited. Is the intent of VIEWALL to support X3D 4.1+?  We can also provide a overall map of the scene that the user can click on to move to content, similar to a 2D view on many games.  I think if we don’t provide an overall map, then the user will still be lost if the content is widely dispersed.

Thanks,

John

Sent from Mail for Windows 10

From: Don Brutzman
Sent: Wednesday, January 31, 2018 12:18 PM
To: X3D Graphics public mailing list
Subject: Re: [x3d-public] supporting VIEWALL capabilities for users, authors,browsers - Mantis 1194

[Forwarded with permission: prior comments by Leonard on X3D Working Group list.]

On 1/26/2018 7:43 AM, Leonard Daly wrote:
> It appears to me that there is a concern for having a standard mechanism for users to "recover" their view of the entire scene AND we will make the assumption that the content author cannot or will not create a existing-style viewpoint for such a purpose.
> 
> As Roy pointed out Viewpoints & NavigationInfo nodes are bound. Having a ViewAll navigational mode on the stack could make things quite messy at times and lead to unexpected behavior. Some of the counter arguments (as outlined by Don below) would make this type of Viewpoint a one-shot bind/unbind operation. This is counter to what has been done in the past -- any change like this would need to be carefully documented.
> 
> There are other issues about orientation of the look - where in the scene universe is the user looking at and how is the user oriented relative to their previous orientation, that need to be resolved.
> 
> I do not like this idea because the content developer does not have control over what the potential viewpoints are. In fact the content developer may intentionally pre-load content into the scene, but out of sight of the viewer that should not be visible until the appropriate time/event is reached.
> 
> To me this feature seems much more like a developer's aid. In that case, we could expect a higher level of ability in working with navigation and scene management. I suggest that the API be extended by methods to compute and return a position and orientation that can be fed to a Transform or Viewpoint node. This would be an obvious one-time happening (though the content developer might choose to put it in a loop to have it continuously updated) and not require a significant change in concept to NavigationInfo (or Viewpoint). If there was concern about this feature being programmatic, a new set of developers nodes could be specified that provide the computational and event functionality.
> 
> Leonard Daly

Regarding a priori definition of a global Viewpoint by authors: it certainly remains an excellent authoring practice and possible now for most scenes.  However, it is simply not possible for scenes with significant content that is dynamically added/subtracted from a scene.

Thanks for those comments.  They led to improvements in the growing rationale that an existing useful capability might go beyond current ad hoc implementations to become a well-defined recommended practice, suitable for providing consistent benefits to users, authors, and browser implementers.


On 1/28/2018 6:10 PM, Don Brutzman wrote:
> 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


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

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180131/02552984/attachment-0001.html>


More information about the x3d-public mailing list