<p dir="ltr">Yves,</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Andreas <br></p>
<p dir="ltr">On Jan 8, 2017 11:38 AM, "Yves Piguet" <<a href="mailto:yves.piguet@gmail.com">yves.piguet@gmail.com</a>> wrote:<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">andreasplesch@gmail.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">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<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">https://doc.x3dom.org/author/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">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>
> ><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>
></p>