<div dir="ltr"><p dir="ltr">Sounds like a plan as it will be critical to interface well with the WebVR API as an important emerging standard for consumer VR hardware.</p>
<p dir="ltr">First, a link to the WebVR standard:</p>
<p dir="ltr"><a href="https://w3c.github.io/webvr/" target="_blank">https://w3c.github.io/webvr/</a><br>
latest:<a href="https://rawgit.com/w3c/webvr/master/index.html" target="_blank"> https://rawgit.com/w3c/webvr/<wbr>master/index.html</a> (development)</p>
<p dir="ltr">Going through every parameter in the webvr standard will be a lengthy process, so let's better get started.</p>
<p dir="ltr">Note, that right in the introduction the focus is directed at interfaces to VR hardware.</p>
<p dir="ltr">X3D though device independant has a fair amount of assumptions on hardware capabilities used to render and interact with the scenegraph. For example, pointing devices and keyboards and opengl/inventor based rendering are implied to be available.</p><p dir="ltr">> Regarding configuration information, here is another way of considering our many existing capabilities together with new opportunities.</p><p dir="ltr">></p><p dir="ltr">> a. Perform a diff of functionality between WebVR API and X3D scene graph.</p><p dir="ltr">
> - What is in WebVR needed for HMDs that isn't supported in X3D?<br>
> - probably also helpful to list everything found in common already.<br></p>
<p dir="ltr">First:<a href="https://w3c.github.io/webvr/#interface-vrdisplay" target="_blank"> https://w3c.github.io/webvr/#<wbr>interface-vrdisplay</a></p>
<p dir="ltr">General points: x3d does not have a concept of a display, eg. the exact method of displaying is left to the x3d browser. The scene does not have a way to infer display parameters other than browser.options which a browser may provide. In addition to display parameters, vrDisplay also includes navigation parameters, the pose. x3d has a concept of navigation, so there are intersections.</p>
<p dir="ltr">readonly attribute boolean isConnected: could be used by a browser implementation to indicate to the user that HMD is available. If x3d has guidelines on browser UI, it should include a list of available display devices. Probably best left to the discretion of the browser.</p>
<p dir="ltr">readonly attribute boolean isPresenting: the browser should use this attribute to indicate that a device is currently in use. On a web page this could be a message on the monitor, replacing the scene rendering. Should be also available to the scene, to allow dynamic adjustment of scene content/viewpoint use when HMD is used. MetadataBoolean vrDisplayisPresenting .</p>
<p dir="ltr">readonly attribute VRDisplayCapabilities capabilities: detail for each property later. Most capabilities potentially useful for a scene, eg. should be in Metadata. If a capability is not available, the browser should not attempt to substitute for the missing capability. Should be shown in a browser UI.</p>
<p dir="ltr">readonly attribute VRStageParameters? stageParameters: detail for each property later. Concerns both viewing and interaction. Browser needs sittingToStandingTrafo, scene could use sizes of stage to add visual stage representation to scene, so in Metadata.</p>
<p dir="ltr">VREyeParameters getEyeParameters(VREye whichEye): renderWidth/Height for browser rendering, and browser UI . fov and offset deprecated . Resolution useful for scene as Metadata, also more generally for any kind of display.</p>
<p dir="ltr">boolean getFrameData(VRFrameData frameData): VRFramedata have projection/view matrices and pose. Viewpoint discussion applies. Browser uses these data to navigate by updating viewpoint on top of other navigation mode dependent navigation. Useful also for scene but expensive since Metadata would need to be updated every frame. Detail later but x3d needs to use the provided data.</p>
<p dir="ltr">[NewObject] VRPose getPose(): deprecated in favour of FrameData</p>
<p dir="ltr">void resetPose(): designate a key press to call resetPose when HMD isPresenting, similar to key presses to cycle viewpoints ? InputField MetadataBoolean vrDisplayResetPose to trigger reset ?</p>
<p dir="ltr">attribute double depthNear; gets used to determine provided projection matrix, should be set to viewpoint's zNear by browser, so no new field required</p>
<p dir="ltr">attribute double depthFar; same</p>
<p dir="ltr">unsigned long requestAnimationFrame(<wbr>FrameRequestCallback callback); browser implementation detail</p>
<p dir="ltr">void cancelAnimationFrame(unsigned long handle); browser implementation detail</p>
<p dir="ltr">Promise<void> requestPresent(sequence<<wbr>VRLayerInit> layers); layer has source to be displayed, currently only 1 layer allowed, no new nodes .</p>
<p dir="ltr">Promise<void> exitPresent(); used by browser to stop displaying on HMD, Scene can use isPresenting above to react.</p>
<p dir="ltr">sequence<VRLayer> getLayers(); </p>
<p dir="ltr">void submitFrame(); browser uses this to indicate that a frame is ready to be displayed in the HMD. WebVR will then display it.</p><p><br></p><p>Summary: VrDisplay node could have these Metadata:</p><p>isPresenting</p><p>capabilities.hasFeatureX</p><p>stageParametersSizes</p><p>left/rightRenderWidth/Height</p><p>resetPose</p><p><br></p>
<p dir="ltr">Next VRLayer and VRDisplay capabilities.</p>
<p>-Andreas</p>
<p dir="ltr">><br>
> b. Characterize and define those parameters, divide and conquer:<br>
> - what information is specific to hardware devices for viewing,<br>
> - what information is specific to hardware devices for interaction,<br>
> - what information is specific to user anatomy: spacing between eyes, etc.<br>
> - what information might be considered scene specific, i.e. varying by scene usage?<br>
> - what information might be considered a user preference?<br>
><br>
> c. Preparing for initial experimentation and evaluation, what are use cases for common use?<br>
> - the MAR Reference Model (update briefing in Seoul next week) has done a lot on that.<br>
><br>
> d. Good assumption: X3D viewing navigation and interaction models are device neutral already. Rephrase: authors can create scenes for users that can be used immediately and effectively over a wide range of devices already, no further customization needed.<br>
><br>
> e. Looking over all the WebVR/HMD diffs with existing X3D:<br>
> - likely this is mostly information that can be expressed as parameters.<br>
> - just like on this discussion thread, people will want to try different approaches with nodes/fields/scripts<br>
> - the information set of parameters could be captured in a Prototype, perhaps embedding a Script<br>
> - the information set of parameters could be captured in a MetadataSet collection<br>
> - this enables different players to implement in their own way using shared X3D content<br>
><br>
> Hope this helps explain a potential path for further cooperative exploration. There are lots of alternatives.<br>
><br>
> I will be requesting permission to share MAR Reference Model more widely in our consortium/community, it will likely complement WebVR nicely.<br>
><br>
> We can discuss for a bit on today's X3D working group teleconference, if you or anyone wants. Probably should be a monthly focus topic, dialog often clarifies email ideas nicely.<br>
><br>
> v/r Don<br>
><br>
><br>
> On 1/10/2017 7:42 PM, Andreas Plesch wrote:<br>
</p>
<blockquote><p dir="ltr">>><br>
</p>
</blockquote>
<p dir="ltr">>> On Jan 8, 2017 5:45 PM, "Don Brutzman" <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a> <mailto:<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>>> wrote:<br>
</p>
<blockquote><p dir="ltr">>>><br>
</p>
</blockquote>
<p dir="ltr">>>><br>
>>> Another option: can we define HMD parameters separately from existing Viewpoint and NavigationInfo nodes, so that existing scenes (with many many viewpoints already defined) might be viewable without modification.<br>
>><br>
>><br>
>> Ok, while sofar the node/field proposals were made from a practical standpoint taking into account existing or feasible implementations, let's turn it around and see what should ideally be available from a scene authoring perspective.<br>
>><br>
>> Let's imagine there is a browser and it has built-in options to display an existing scene in a selected HMD taking advantage of stereo immersion and head tracking/body tracking.<br>
>><br>
>> Let's also assume the scene is designed for both desktop and HMD experience. This is probably harder than it sounds but scenes designed for WALK mode with a single viewpoint or careful transitions between viewpoints, on a human scale, should be a good start.<br>
>><br>
>> The browser can figure out optimal rendering resolution, and use the HMD provided projection and view matrixes for navigation relative to the bound viewpoint.<br>
>><br>
>> All this does not seem to need scene specific information (?). This is why we had previously discussed a browser configuration file or Engine node above/next to the scene level.<br>
>><br>
>> Now, it turns out that currently the easiest way to add such functionality to the x3dom browser is to preprocess the scene (via 'injection') to use additional nodes (the RenderedTexture node). When getting out of HMD mode, these additional nodes can be removed again.<br>
>><br>
>> For other browsers (such as cobweb) it may be advantageous to preprocess the scene in a different way, requiring other, specialized nodes (Viewfrustum).<br>
>><br>
>> This is just one way to add functionality to a x3d browser and currently the most available one. It is also modular as nodes can be used for other purposes.<br>
>><br>
</p>
<blockquote><p dir="ltr">>>> Perhaps an HMD node, rather than HMD mode? That is, a separate node that complements NavigationInfo?<br>
</p>
</blockquote>
<p dir="ltr">>><br>
>><br>
</p>
<blockquote><p dir="ltr">>>> The VRML and X3D specifications have done an excellent job in being device neutral (as well as quite supportive of most devices) when defining user viewing and interaction already. It will be good to keep building on that device independence, which incidentally lets you create large shared environments where users have multiple diverse devices interacting.<br>
</p>
</blockquote>
<p dir="ltr">>>><br>
>>> WebVR might provide an excellent first pass for the parameters that might be needed for HMDs.<br>
>><br>
>><br>
>> WebVR inspired parameters supplied by/provided to a HMD node could be:<br>
>><br>
>> isPresenting: SFBool, currently in use, scene may want to adapt to immersion experience in some way<br>
>><br>
>> Stage: some HMDs have a certain, limited area in which a user can be tracked and be expected to stay inside. This could be useful information for a scene. Includes size, location.<br>
>><br>
>> Enabled: a scene may want to strictly disable display on a HMD<br>
>><br>
>> DeviceID: a scene may want to know a name for the device to reflect<br>
>><br>
>> Capabilities: resolution: a scene may want to adapt (hi res textures)<br>
>><br>
>> resetPose: make current location/orientation the reference.<br>
>><br>
</p>
<blockquote><p dir="ltr">>>><br>
</p>
</blockquote>
<p dir="ltr">>>> Presumably most of fields are metadata for devices to use, which is in keeping with scenes that can be utilized by many devices.<br>
>><br>
>><br>
>> Hmm, as evidenced above, I tend to think about the reverse, eg. fields which can be utilized by scenes. So I am probably missing something.<br>
>><br>
</p>
<blockquote><p dir="ltr">>>> So if we can agree on parameters then a simple MetadataSet node (or prototype) for HMD might be sufficient to start performing some experimentation in developmental versions of players.<br>
</p>
</blockquote>
<p dir="ltr">>>><br>
>>> Wondering if such metadata is oriented towards several categories at once:<br>
>><br>
>><br>
>> (a) device specific,<br>
>> all above<br>
>><br>
>> (b) scene specific,<br>
>><br>
>> I cannot think of anything, eg. imagine how a scene could modify the behaviour of a HMD. At this point HMDs only have a single mode. In the future, a HMD may switch between VR, AR, MR and a scene request an expected mode ?<br>
>><br>
>> If we start to also consider controllers, this might be the place where a scene configures usage of controller buttons and axes.<br>
>><br>
>> and (c) user specific (which can also be saved as preferences).<br>
>><br>
>> lastPose: pose before exiting HMD mode<br>
>> resumePose: return to last pose upon entering<br>
>> ...<br>
>><br>
>> I am still unsure if I grasped the idea behind using a MetadataSet node as a conduit between scene and HMD.<br>
>><br>
>> Andreas<br>
>><br>
>> This might help re-use and portability.<br>
</p>
<blockquote><p dir="ltr">>>><br>
</p>
</blockquote>
<p dir="ltr">>>><br>
>>><br>
>>> On 1/8/2017 12:40 PM, Andreas Plesch wrote:<br>
</p>
<blockquote><p dir="ltr">>>>><br>
</p>
</blockquote>
<p dir="ltr">>>>><br>
>>>> Yves,<br>
>>>><br>
>>>> thanks for your input. While seeing a Viewfrustum node as a generalization is convincing, there is a practical difference in how it would be used. Rather than specifying an initial viewpoint from which user navigation starts/is relative to, the matrices would be used directly for navigation. Not sure what the implications of this difference are.<br>
>>>><br>
>>>> Another option is to define another navigation mode, 'HMD', which would take HMD output (the matrixes) and apply it to the current viewpoint. If the viewpoint is a stereo viewpoint left and right matrixes would be supplied. Additional navigation from controllers would still need to be possible. What device 'HMD' refers to could be defined by a new NavigationInfo field 'hmd' MFString = "''AUTO' 'VIVE' ... " in case of multiple connected devices.<br>
>>>><br>
>>>> Andreas<br>
>>>><br>
>>>> On Jan 8, 2017 11:38 AM, "Yves Piguet" <<a href="mailto:yves.piguet@gmail.com" target="_blank">yves.piguet@gmail.com</a> <mailto:<a href="mailto:yves.piguet@gmail.com" target="_blank">yves.piguet@gmail.com</a>> <mailto:<a href="mailto:yves.piguet@gmail.com" target="_blank">yves.piguet@gmail.com</a> <mailto:<a href="mailto:yves.piguet@gmail.com" target="_blank">yves.piguet@gmail.com</a>><wbr>>> wrote:<br>
</p>
<blockquote><p dir="ltr">>>>>><br>
</p>
</blockquote>
<p dir="ltr">>>>>><br>
>>>>><br>
>>>>> I'd also prefer a new node. Another reason is the existence of OrthoViewpoint: a viewpoint where you specify an arbitrary projection matrix is a generalization of both Viewpoint and OrthoViewpoint, so it should logically be a sibling which also implements the X3DViewpointNode abstract node. Now an extension for stereoscopic views, where you still have a single viewer position which defines viewer-related sensor events, LOD, Billboard etc. and a single node traversal for rendering with two projection matrices, seems fine.<br>
>>>>><br>
>>>>> Yves<br>
>>>>><br>
>>>>><br>
>>>>> > On 8 Jan 2017, at 15:29, Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a> <mailto:<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.<wbr>com</a>> <mailto:<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.<wbr>com</a> <mailto:<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.<wbr>com</a>>>> wrote:<br>
>>>>> ><br>
>>>>> > > Date: Sat, 7 Jan 2017 21:04:42 +0100<br>
>>>>> > > From: Holger Seelig <<a href="mailto:holger.seelig@yahoo.de" target="_blank">holger.seelig@yahoo.de</a> <mailto:<a href="mailto:holger.seelig@yahoo.de" target="_blank">holger.seelig@yahoo.de</a><wbr>> <mailto:<a href="mailto:holger.seelig@yahoo.de" target="_blank">holger.seelig@yahoo.de</a> <mailto:<a href="mailto:holger.seelig@yahoo.de" target="_blank">holger.seelig@yahoo.de</a><wbr>>>><br>
>>>>> > ><a href="mailto:To%3Ax3d-public@web3d.org" target="_blank"> To:x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>>><br>
>>>>> > > Subject: Re: [x3d-public] X3D VR<br>
>>>>> > ><br>
>>>>> > ><br>
>>>>> > > I think instead of defining a new field to the existing viewpoints, it<br>
>>>>> > > should be considered that for that purpose and new viewpoint node could<br>
>>>>> > > be appropriate. A node called something like ?MatrixViewpoint?. This<br>
>>>>> > > node could have two fields matrix and projectionMatrix. The matrix field<br>
>>>>> > > would store the transformation matrix with orientation and position<br>
>>>>> > > values. The projectionMatrix field would store the projection matrix.<br>
>>>>> > > This viewpoint would be an all purpose viewpoint. The main idea is if<br>
>>>>> > > one is able to define an ?viewMatrix? field as Andreas proposes he is<br>
>>>>> > > able to handle a node like MatrixViewpoint with its matrix fields.<br>
>>>>> > > Defining a new node has the advantages to left the existing viewpoints<br>
>>>>> > > untouched and to handle this behavior in a new node.<br>
>>>>> > ><br>
>>>>> > > Holger<br>
>>>>> ><br>
>>>>> > It turns out that x3dom and InstantReality have such a node, called Viewfrustum:<br>
>>>>> ><br>
>>>>> ><a href="https://doc.x3dom.org/author/Navigation/Viewfrustum.html" target="_blank">https://doc.x3dom.org/author/<wbr>Navigation/Viewfrustum.html</a> <<a href="https://doc.x3dom.org/author/Navigation/Viewfrustum.html" target="_blank">https://doc.x3dom.org/author/<wbr>Navigation/Viewfrustum.html</a>><br>
>>>>> ><br>
>>>>> > So this is a pretty strong argument for a new node instead of new fields.<br>
>>>>> ><br>
>>>>> > New fields have the advantage that they should make it easier to adapt existing scenes. I think default values could be such that they guarantee full backward compatibility.<br>
>>>>> ><br>
>>>>> > I will try to use Viewfrustum with the x3dom classroom example to gain some experience.<br>
>>>>> ><br>
>>>>> > Andreas<br>
>>>>> ><br>
>>>>> > ><br>
>>>>> > > Am 07.01.2017 um 18:07 schrieb Andreas Plesch:<br>
>>>>> > > > Hi,<br>
>>>>> > > ><br>
>>>>> > > > back from the holiday season, here are proposals for new fields for<br>
>>>>> > > > Viewpoint.<br>
>>>>> > > ><br>
>>>>> > > > I do not have an x3dom implementation but the idea is to add two<br>
>>>>> > > > Matrix4d fields:<br>
>>>>> > > ><br>
>>>>> > > > projectionMatrix :<br>
>>>>> > > ><br>
>>>>> > > > default: NULL<br>
>>>>> > > ><br>
>>>>> > > > purpose: allow control of the view projection from 3d to 2d by such a<br>
>>>>> > > > matrix from sources such HMD drivers. The projection matrix controls fov<br>
>>>>> > > ><br>
>>>>> > > > The projectionMatrix should be used as is by the browser if not NULL. If<br>
>>>>> > > > NULL, a projection matrix shall be contructed from viewpoint fields.<br>
>>>>> > > ><br>
>>>>> > > ><br>
>>>>> > > > viewMatrix:<br>
>>>>> > > ><br>
>>>>> > > > default: unit matrix<br>
>>>>> > > ><br>
>>>>> > > > purpose: allow control of the viewer orientation and location by such a<br>
>>>>> > > > matrix from sources such as HMD drivers.<br>
>>>>> > > ><br>
>>>>> > > > The viewMatrix V shall be combined with the matrix M derived from the<br>
>>>>> > > > location/ orientation fields by M * V for rendering use.<br>
>>>>> > > ><br>
>>>>> > > > This means that if V is used in a scene exclusively the location fields<br>
>>>>> > > > needs to be reset to 0 0 0 from its default by the scene.<br>
>>>>> > > ><br>
>>>>> > > > Typical use would be as sinks of routes from (new) ProjectionSensor or<br>
>>>>> > > > VRDevice node fields.<br>
>>>>> > > ><br>
>>>>> > > > A VRDevice delivers both matrixes for each eye. A scene can then set up<br>
>>>>> > > > a viewpoint for each eye, and use Layers to show them side by side.<br>
>>>>> > > ><br>
>>>>> > > > In terms of efficiency, this would seem to require repeated traversals<br>
>>>>> > > > of the scene unless both Layers can be recognized to show the same scene<br>
>>>>> > > > content.<br>
>>>>> > > ><br>
>>>>> > > > A more convenient and integrated alternative would be to introduce a<br>
>>>>> > > > stereo SFBool field and have left and right variants of the matrix<br>
>>>>> > > > fields ( and perhaps also left and right variants of the location,<br>
>>>>> > > > orientation, fov, zfar, znear fields).<br>
>>>>> > > ><br>
>>>>> > > > stereo = false would ignore all left and right fields.<br>
>>>>> > > > stereo = true would use the left/right fields and render them side by side.<br>
>>>>> > > ><br>
>>>>> > > > Since in this case there is a guaranty that views for each eye use the<br>
>>>>> > > > same scene content, only one traversal should be needed to render both eyes.<br>
>>>>> > > ><br>
>>>>> > > > The idea would be switching mono to stereo and back only requires<br>
>>>>> > > > toggling the stereo field. Navigation may have a similar switch to and<br>
>>>>> > > > from mouse/keyboard modes ?<br>
>>>>> > > ><br>
>>>>> > > > Implementation in x3dom of viewMatrix and projectionMatrix may be rather<br>
>>>>> > > > straightforward. I do not see large obstacles (famous last words ...).<br>
>>>>> > > > Implementation in cobweb of viewMatrix and projectionMatrix may be also<br>
>>>>> > > > straightforward but I am less sure.<br>
>>>>> > > ><br>
>>>>> > > > Without layers in x3dom then one could put two scene side by side on the<br>
>>>>> > > > web page, use external js to feed the matrix fields, and then also use<br>
>>>>> > > > external js to grab the frames from both scene canvases, combine them<br>
>>>>> > > > into a single frame on another canvas, and use that finally as a source<br>
>>>>> > > > for the HMD display. (This sounds slow).<br>
>>>>> > > > In cobweb, it should not be hard to set up a scene with a layer for each<br>
>>>>> > > > eye.<br>
>>>>> > > ><br>
>>>>> > > > Implementation of stereo, left and rightView/ProjectionMatrix in x3dom<br>
>>>>> > > > is harder since it needs changes to the rendering code which is a bit<br>
>>>>> > > > unstructured. The first approach would be for stereo=true to go through<br>
>>>>> > > > the rendering twice with the rendering surfaces appropriately set somehow.<br>
>>>>> > > ><br>
>>>>> > > > -Andreas<br>
>>>>> > > ><br>
>>>>> > > > On Dec 21, 2016 6:00 AM, "Roy Walmsley" <<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.com</a> <mailto:<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.<wbr>com</a>> <mailto:<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.<wbr>com</a> <mailto:<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.<wbr>com</a>>><br>
>>>>> > > > <mailto:<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.<wbr>com</a> <mailto:<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.<wbr>com</a>> <mailto:<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.<wbr>com</a> <mailto:<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.<wbr>com</a>>>>> wrote:<br>
>>>>> > > ><br>
>>>>> > > > Hi Andreas,____<br>
>>>>> > > ><br>
>>>>> > > > __ __<br>
>>>>> > > ><br>
>>>>> > > > That?s great to see what you have been doing here. Would you like<br>
>>>>> > > > to take your node suggestions one step further and propose the<br>
>>>>> > > > fields that might be specified for each node?____<br>
>>>>> > > ><br>
>>>>> > > > __ __<br>
>>>>> > > ><br>
>>>>> > > > What we could do then is, in the new year, is to host an open<br>
>>>>> > > > discussion on WebVR and X3D. Contributions from any other readers<br>
>>>>> > > > are welcome, and could lead to a lively discussion on this topic.____<br>
>>>>> > > ><br>
>>>>> > > > __ __<br>
>>>>> > > ><br>
>>>>> > > > Thank you for the suggestions,____<br>
>>>>> > > ><br>
>>>>> > > > __ __<br>
>>>>> > > ><br>
>>>>> > > > All the best,____<br>
>>>>> > > ><br>
>>>>> > > > __ __<br>
>>>>> > > ><br>
>>>>> > > > Roy____<br>
>>>>> > > ><br>
>>>>> > > > __ __<br>
>>>>> > > ><br>
>>>>> > > > *From:*x3d-public [mailto:<a href="mailto:x3d-public-bounces@web3d.org" target="_blank">x3d-public-bounces@<wbr>web3d.org</a> <mailto:<a href="mailto:x3d-public-bounces@web3d.org" target="_blank">x3d-public-bounces@<wbr>web3d.org</a>> <mailto:<a href="mailto:x3d-public-bounces@web3d.org" target="_blank">x3d-public-bounces@<wbr>web3d.org</a> <mailto:<a href="mailto:x3d-public-bounces@web3d.org" target="_blank">x3d-public-bounces@<wbr>web3d.org</a>>><br>
>>>>> > > > <mailto:<a href="mailto:x3d-public-bounces@web3d.org" target="_blank">x3d-public-bounces@<wbr>web3d.org</a> <mailto:<a href="mailto:x3d-public-bounces@web3d.org" target="_blank">x3d-public-bounces@<wbr>web3d.org</a>> <mailto:<a href="mailto:x3d-public-bounces@web3d.org" target="_blank">x3d-public-bounces@<wbr>web3d.org</a> <mailto:<a href="mailto:x3d-public-bounces@web3d.org" target="_blank">x3d-public-bounces@<wbr>web3d.org</a>>>>] *On Behalf Of *Andreas Plesch<br>
>>>>> > > > *Sent:* 21 December 2016 05:51<br>
>>>>> > > > *To:* X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>>><br>
>>>>> > > > <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>>><wbr>>><br>
>>>>> > > > *Subject:* [x3d-public] X3D VR____<br>
>>>>> > > ><br>
>>>>> > > > __ __<br>
>>>>> > > ><br>
>>>>> > > > Hi____<br>
>>>>> > > ><br>
>>>>> > > > Working with x3dom and WebVR I am exploring what additions to X3D<br>
>>>>> > > > would be necessary or useful to effectively use current VR hardware<br>
>>>>> > > > such as the Rift, Vive, Gear, or Cardboard.____<br>
>>>>> > > ><br>
>>>>> > > > The proposed RenderedTexture node is currently used in x3dom with<br>
>>>>> > > > special stereo modes to generate left and right views from a single<br>
>>>>> > > > viewpoint in a single GL context.____<br>
>>>>> > > ><br>
>>>>> > > > A Layer for each left and right view could also be used with two<br>
>>>>> > > > coordinated but separate viewpoints. This would be Cobweb's pattern.____<br>
>>>>> > > ><br>
>>>>> > > > Since the HMD and its own runtime know best the internal optical<br>
>>>>> > > > characteristics of the display, the preferred interface at least in<br>
>>>>> > > > WebVR are view and projection matrixes directly usable by consumers<br>
>>>>> > > > for 3d graphics generation, and not position, orientation and fov.<br>
>>>>> > > > This leads to a new requirement for X3D to accept these raw matrixes<br>
>>>>> > > > as input.____<br>
>>>>> > > ><br>
>>>>> > > > Since x3dom uses RenderedTexture for VR, I added there additional<br>
>>>>> > > > special stereo modes which directly receive these matrixes from the<br>
>>>>> > > > HMD to be used for rendering at each frame. This in effect<br>
>>>>> > > > accomplishes a first, head and body based, level of navigation. In<br>
>>>>> > > > my first tests (on github) it works well and should be robust across<br>
>>>>> > > > devices. This approach does require some standard API to the HMD<br>
>>>>> > > > such as WebVR.____<br>
>>>>> > > ><br>
>>>>> > > > Another possibility is to add view and projection matrix fields<br>
>>>>> > > > input fields to viewpoints which can be continually updated. One<br>
>>>>> > > > could convolve the view matrix with position/orientation fields, or<br>
>>>>> > > > optionally completely ignore them.____<br>
>>>>> > > ><br>
>>>>> > > > One then could use external SAI to keep updating or perhaps<br>
>>>>> > > > introduce an environment ProjectionSensor. It would relay these<br>
>>>>> > > > matrix events from an HMD runtime to then be routed to the<br>
>>>>> > > > viewpoints.____<br>
>>>>> > > ><br>
>>>>> > > > A second level of navigation is accomplished with handheld<br>
>>>>> > > > controllers. Until some standard gestures evolve, it will be<br>
>>>>> > > > necessary to expect custom per scene navigation. X3d should have a<br>
>>>>> > > > way to sense buttons and axes velocities of such controllers so<br>
>>>>> > > > these are then available to manipulate the view in some way.<br>
>>>>> > > > InstantReality has a general IOSensor to that effect. On the web the<br>
>>>>> > > > GamePad API is a standard which would need to be used.____<br>
>>>>> > > ><br>
>>>>> > > > Summary: RenderedTexture with stereo modes, matrix fields for<br>
>>>>> > > > viewpoints, a ProjectionSensor, and a ControllerSensor would all be<br>
>>>>> > > > candidates for x3d VR support.____<br>
>>>>> > > ><br>
>>>>> > > > Thanks for reading, any thoughts welcome,____<br>
>>>>> > > ><br>
>>>>> > > > Andreas ____<br>
>>>>> > > ><br>
>>>>> > > ><br>
>>>>> > > ><br>
>>>>> > > ><br>
>>>>> > > > ______________________________<wbr>_________________<br>
>>>>> > > > x3d-public mailing list<br>
>>>>> > > ><a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>>><br>
>>>>> > > ><a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a> <<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a>><br>
>>>>> > > ><br>
>>>>> > ><br>
>>>>> > ><br>
>>>>> > > --<br>
>>>>> > > Holger Seelig<br>
>>>>> > > Mediengestalter Digital ? Digital Media Designer<br>
>>>>> > ><br>
>>>>> > > Scheffelstra?e 31a<br>
>>>>> > > 04277 Leipzig<br>
>>>>> > > Germany<br>
>>>>> > ><br>
>>>>> > > Cellular:<a href="tel:%2B49%201577%20147%2026%2011" target="_blank">+49 1577 147 26 11</a> <tel:+49%201577%201472611><br>
>>>>> > > E-Mail: <a href="mailto:holger.seelig@create3000.de" target="_blank">holger.seelig@create3000.de</a> <mailto:<a href="mailto:holger.seelig@create3000.de" target="_blank">holger.seelig@<wbr>create3000.de</a>> <mailto:<a href="mailto:holger.seelig@create3000.de" target="_blank">holger.seelig@<wbr>create3000.de</a> <mailto:<a href="mailto:holger.seelig@create3000.de" target="_blank">holger.seelig@<wbr>create3000.de</a>>><br>
>>>>> > > Web: <a href="http://titania.create3000.de" target="_blank">http://titania.create3000.de</a> <<a href="http://titania.create3000.de" target="_blank">http://titania.create3000.de</a>><br>
>>>>> > ><br>
>>>>> > > Future to the fantasy ? ?<br>
>>>>> > ><br>
>>>>> > ><br>
>>>>> > ><br>
>>>>> > > ------------------------------<br>
>>>>> > ><br>
>>>>> > > Subject: Digest Footer<br>
>>>>> > ><br>
>>>>> > > ______________________________<wbr>_________________<br>
>>>>> > > x3d-public mailing list<br>
>>>>> > ><a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>>><br>
>>>>> > ><a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a> <<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a>><br>
>>>>> > ><br>
>>>>> > ><br>
>>>>> > > ------------------------------<br>
>>>>> > ><br>
>>>>> > > End of x3d-public Digest, Vol 94, Issue 17<br>
>>>>> > > ******************************<wbr>************<br>
>>>>> ><br>
>>>>> > ______________________________<wbr>_________________<br>
>>>>> > x3d-public mailing list<br>
>>>>> ><a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>>><br>
>>>>> ><a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a> <<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a>><br>
>>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> ______________________________<wbr>_________________<br>
>>>> x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">>>>> x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">>>>> http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a> <<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a>><br>
>>>><br>
>>><br>
>>><br>
>>> all the best, Don<br>
>>> --<br>
>>> Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a> <mailto:<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>><br>
>>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA <a href="tel:%2B1.831.656.2149" target="_blank">+1.831.656.2149</a> <tel:(831)%20656-2149><br>
>>> X3D graphics, virtual worlds, navy roboticshttp://<a href="http://faculty.nps.edu/brutzman" target="_blank">faculty.nps.<wbr>edu/brutzman</a> <<a href="http://faculty.nps.edu/brutzman" target="_blank">http://faculty.nps.edu/<wbr>brutzman</a>><br>
>><br>
>><br>
><br>
><br>
> all the best, Don<br>
<font color="#888888">> -- </font><br>
<font color="#888888">> Don Brutzman Naval Postgraduate School, Code USW/Br </font><a href="mailto:brutzman@nps.edu" target="_blank"><font color="#888888">brutzman@nps.edu</font></a><br>
<font color="#888888">> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA </font><a href="tel:%2B1.831.656.2149" target="_blank"><font color="#888888">+1.831.656.2149</font></a><br>
<font color="#888888">> X3D graphics, virtual worlds, navy robotics</font><a href="http://faculty.nps.edu/brutzman" target="_blank"><font color="#888888"> http://faculty.nps.edu/<wbr>brutzman</font></a><br><br><br></p>
<p dir="ltr">-- <br>
Andreas Plesch<br>
39 Barbara Rd.<br>
Waltham, MA 02453</p>
</div>