<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Date: Wed, 21 Dec 2016 14:36:02 +0000<br>
From: doug sanden <<a href="mailto:highaspirations@hotmail.com" target="_blank">highaspirations@hotmail.com</a>><br>
To: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
Subject: Re: [x3d-public] X3D VR<br><br>
Andreas<br>
Q. can/could/should io/stereo mishmash be in a separate config file?<br>
Q. can/could/should the io and stereo special events come from the singleton Browser object?<br></blockquote><div><br></div><div>Let's focus on stereo first. InstantReality decided to follow similar ideas with Engines and Viewareas:</div><div><br></div><div><a href="http://doc.instantreality.org/tutorial/get-your-engine-right/" target="_blank">http://doc.instantreality.org/<wbr>tutorial/get-your-engine-<wbr>right/</a><br></div><div><a href="http://doc.instantreality.org/tutorial/multiple-windows-and-views/" target="_blank">http://doc.instantreality.org/<wbr>tutorial/multiple-windows-and-<wbr>views/</a><br></div><div><br></div><div>The approach allows for very flexible configurations, including CAVEs and clusters and such.</div><div><br></div><div>Consumer VR is more limited, and with the emerging WebVR API standard there is a chance to have unified access to displays and their sensors. There may be similar abstraction layers outside of the web realm or the webVR API could be implemented outside of the web browser as well (as a thin layer on top of each HMD runtime).</div><div><br></div><div>Still, having a place such as config file or an engine node on the same level as the scene node seems attractive if scene content should be separated from rendering control.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-Doug<br>
...<br>
Great topic. I struggled with Android NDK x3dbrowser handling of gyro etc for navigation and found a way to hack and intercept the viewpoint matrix stack, and similar config issues with cardboard viewport distortion configuration -great spaghetti hacking- but need to make it more systematic, configurable and if possible following some standard pattern.<br></blockquote><div><br></div><div>Maybe it makes sense to implement the webVR API for Android ? Chrome with webVR is now available for Android</div><div><a href="https://chromium.googlesource.com/experimental/chromium/src/+/refs/wip/bajones/webvr_1/third_party/WebKit/Source/modules/vr/" target="_blank">https://chromium.googlesource.<wbr>com/experimental/chromium/src/<wbr>+/refs/wip/bajones/webvr_1/<wbr>third_party/WebKit/Source/<wbr>modules/vr/</a></div><div><a href="https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/vr/">https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/vr/</a> </div><div><br></div><div>Not sure if the source here is helpful.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
...<br>
One annoying thing is having to put per-device configurations into the scene file, such as special handling of triggers, matrices etc.<br>
IDEAS:<br>
- hyperscene one level up from scene file<br>
-  .x3dcfg - a separate mini-scene with small set of nodes, inhaled separately by the program<br>
<br>
And the goal of either of those is to convert per-device stereo and input mishmash into some very standard things hidden in the Browser as seen by the scene, so scene files can still be rendered non-stereo with no change to the scene file. Yet still authorable.<br>
For example in conventional x3d, as the user works the mouse to navigate, you don't necessarily get any mouse events coming into the scene - no routing is mandatory to make navigation happen - and the viewpoint 'magically' moves as seen from the scene file. It might let you know where it moved, and allow you to do some moving, but it doesn't require the scene author to intervene, or know which buttons are pressed.<br>
Mind you for a few decades things have been fairly stable hardware-wise on the desktop, with a mouse and keyboard. So the formulas for converting mouse and keyboard to viewpoint navigation -and stereo settings- were baked into the browser.<br>
Now with hardware and stereo permutations fluid and growing in number, it's getting hard for Browser code to hide all that. And some scene authors _do_ want to intercept and play with it.<br></blockquote><div><br></div><div>It would be great to offer some easy VR navigation modes and Leonard had some ideas, I believe. Staring to simulate a 'click' or a selection comes to mind . But there is no standard on how physical controllers are used, or even minimum requirements in terms of buttons, degrees of freedom, haptics, touchpads. So the only solution is to expect scene authors to do their own navigation by giving them access to the controller output. Perhaps protos can then be shared to make this easier for authors.</div><div>InstantReality has IOSensors with lots of available device types:</div><div><a href="http://doc.instantreality.org/tutorial/inputoutput-streams/">http://doc.instantreality.org/tutorial/inputoutput-streams/</a><br></div><div><a href="http://doc.instantreality.org/device/">http://doc.instantreality.org/device/</a><br></div><div>webVR is struggling with the same problem and are trying to come up with a standard at least for mapping buttons to actions, for example. The browser gamepad API is at least a standard to interface with controllers.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
IDEA: Browser fields: instead of new nodes and components for getting io/stereo information into the scene to play, can/could/should they be fields/events on the x3d Browser object? That would keep them Singletons - only one per scene (vs separate node type which could be instanced multiple times - although I think we have a node or two like this already - should be singletons but are allowed to be instanced multiple). And analogous to the desktop Browser managing/hiding all that info.<br>
<br>
But try and imagine all the permutations of your basic scene file you'd need for every permutation of device and stereo setting if its all in the scene file as new nodes.<br></blockquote><div><br></div><div>InstantReality has an 'auto' type for IOSensors which tries to find and use an expected device type given the output fields which are requested. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So the urge to abstract a bit and make more flexible for scene authors.<br></blockquote><div><br></div><div>It may be necessary to define a list of events such as x/y/z/translation,yaw/pitch/roll, buttonABCD states which a standard VR ControllerSensor is expected to output.</div><div><br></div><div>Pressing a designated button, controllers/wands often turn into a pointing device. The Vive typically then shows a ray emanating from the in-scene controller represention. Would a x3d browser be expected to automatically recognize this use of the controller as a pointing device ? Again, I think InstantReality has a way to configure this use (with a 'ray' navigation mode or so).</div><div><br></div><div>This kind of discussion must have happened many times in the past so there may be some consensus on a standard approach to controllers ? Or perhaps each setup used to be unique enough that more ad hoc solutions were viable.</div><div><br></div><div>-Andreas</div></div>
</div></div>