<p dir="ltr">> Date: Sat, 7 Jan 2017 21:04:42 +0100<br>
> From: Holger Seelig <<a href="mailto:holger.seelig@yahoo.de">holger.seelig@yahoo.de</a>><br>
> To: <a href="mailto:x3d-public@web3d.org">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</p>
<p dir="ltr">It turns out that x3dom and InstantReality have such a node, called Viewfrustum:</p>
<p dir="ltr"><a href="https://doc.x3dom.org/author/Navigation/Viewfrustum.html">https://doc.x3dom.org/author/Navigation/Viewfrustum.html</a></p>
<p dir="ltr">So this is a pretty strong argument for a new node instead of new fields.</p>
<p dir="ltr">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.</p>
<p dir="ltr">I will try to use Viewfrustum with the x3dom classroom example to gain some experience.</p>
<p dir="ltr">Andreas</p>
<p dir="ltr">><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">roy.walmsley@ntlworld.com</a><br>
> > <mailto:<a href="mailto:roy.walmsley@ntlworld.com">roy.walmsley@ntlworld.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">x3d-public-bounces@web3d.org</a><br>
> >     <mailto:<a href="mailto:x3d-public-bounces@web3d.org">x3d-public-bounces@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">x3d-public@web3d.org</a><br>
> >     <mailto:<a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>>><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>
> > _______________________________________________<br>
> > x3d-public mailing list<br>
> > <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
> > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/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: +49 1577 147 26 11<br>
> E-Mail:   <a href="mailto:holger.seelig@create3000.de">holger.seelig@create3000.de</a><br>
> Web:      <a href="http://titania.create3000.de">http://titania.create3000.de</a><br>
><br>
> Future to the fantasy ? ?<br>
><br>
><br>
><br>
> ------------------------------<br>
><br>
> Subject: Digest Footer<br>
><br>
> _______________________________________________<br>
> x3d-public mailing list<br>
> <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
><br>
><br>
> ------------------------------<br>
><br>
> End of x3d-public Digest, Vol 94, Issue 17<br>
> ******************************************<br>
</p>