[x3d-public] A suggestion for a node supporting VR headsets inX3D

Sun Jul 9 17:00:50 PDT 2017

What Michael says sounds ckay to me.  However, with the way computer develop, we’ll probably need something like an “EmotionCamera” tag in the future that generates emotion events, with direct brain connections and everything. There will again be web and OS support.  Let’s make it easy for the camera to switch from stereo to mono, and from video to still images.

John

Sent from Mail for Windows 10

From: Michael Aratow
Sent: Sunday, July 9, 2017 7:50 PM
To: Leonard Daly; x3d-public at web3d.org
Subject: Re: [x3d-public] A suggestion for a node supporting VR headsets inX3D

I'll echo Leonard's comments about previously developing standards.  Let's not reinvent the wheel.  WebVR, OSVR, OpenXR are all dealing with multiple hardware vendors/configurations and have figured out the reference model and nomenclature to cover all the permutations.  I would suggest getting as much as possible from those initiatives as they are all open and will likely be the defacto standards.

On 7/9/17 10:01 AM, Leonard Daly wrote:
OK. I really think this is a very BAD IDEA. I've tried to explain why below. It's also toned down a lot from my first effort.

Having a separate node that provide for duplicate control for certain scene assets (e.g., cameras) is a mistake. If UserInfo defined a stereo camera and the Viewpoint used an orthographic camera you would get vision disorientation. Stereo vision needs the two view frustas to converge. There is no convergence with orthographic projection.

When viewing a scene in a headset, it is generally accepted that certain features need to remain fixed (e.g., world-up). 

There is already a node for the camera. It should handle all aspects of the camera (perspective, ortho, stereo, etc.). That node is called Viewpoint (there is really no need for OrthoViewpoint). Introducing another, perhaps contradictory means for that would just add confusion.

There is a developing standard for VR on the Web by the W3C. It is called WebVR. It does not control how you present certain information to the user, but how code needs to interact with the browser in order to have the proper VR experience. WebVR also includes some standardization of the various user-interface devices. A misalignment with WebVR would just cause more confusion. More confusion leads to a lower adoption rate.

The spec needs to keep related things together. Viewpoint should be how the scene is presented to the user. It needs to cover all aspects of the camera, camera type, FOV, interpupillary distance. NavigationInfo covers how the user navigates from the current viewing position. Audio node(s) would indicate whether the sound is mono, spatialized, or stereo (plus). 

If a browser wishes to build in a set of user-configurable options (perhaps for disability access or some other reason), then that is fine; but would not be part of the spec.

The discussion of multi-user is irrelevant. Each user has their own copy of the scene (at least for rendering purposes). What one person sees is independent of another in the same scene at the same time. Multi-user support is more for passing high-level information from one viewer to another. Presenting a "birds-eyes" view of a scene in headset mode is not a good idea. Of course it can be done, but the results will be bad and very disturbing (as in cognitive dissonance). (Think of a web page with every word on a blink tag with different rates. That is just beginning to go down the disturbing path.)

Leonard Daly

Hi,

At a recent X3D working group meeting we proposed some possible new nodes to provide support for VR displays within X3D. Here is an extract from the minutes:

• VR
o Stereo viewpoint, which needs two cameras. The X3D specification only allows one camera, e.g. Viewpoint, which is a bindable node. Contrast here the Viewpoint/OrthoViewpoint nodes, which are perspective and orthographic renderings, respectively.
o Input interfaces, possibly from multiple buttons. For example, TouchSensor, may need to be expanded to permit more types of input.
o Audio – is it good enough. There is no left, right ear dependence, i.e. stereo audio.
o Viewpoint switching – alternative methods of animating viewpoint changes are required. For example, Viewpoint node currently has a jump field, but Fade out/Fade in might be needed.

After that meeting Don and I were talking about this, and came up with an alternative suggestion. This was for the following node:

• UserInfo
o Should this be a bindable node, with its own binding stack, so that only one was active at a time? Then, what about multiple users interacting with the same scene?
o It could indicate if the user was needed a stereo rendering, and have attributes for stereo parameters.
o It could indicate if the user required stereo audio, having appropriate attributes.
o It could have attributes relating to FOV – currently in Viewpoint.

This node would not have to be included in a scene. It could be added by the implementation (or modified if present) using SAI techniques. 

The node could be added to the Navigation component, perhaps at support level 2, to fit into the immersive profile.

An example:

• Let’s imagine a garden scene. We would like to be able to render it in stereo, from the perspective of two different users. The first is human. The second is a bird. The saved scene need not have a UserInfo node, and so could be independent of the user. The implementation would then insert the appropriate UserInfo node into the scene at run time, permitting the scene to be rendered with the desired user properties.

What do you think? Good idea? Bad idea?

All comments welcome.

All the best,

Roy

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

-- 
Leonard Daly
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - Creating the Future 

_______________________________________________
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/20170709/33a8a44f/attachment.html>