[x3d-public] Minutes of further discussion on X3D/HTML/DOM integration held November 16th 2016

[doug sanden]

- VR/AR nodes -  I could use them in freewrl -a native browser that runs on mobile ie android, uwp, and uses sensors like gyro for navigation already, but would be great to have web3d standard nodes for bringing mobile platform sensor/camera data into the scenegraph.
-
Didn't see a mention of archivability. If it could be shown/proven that you can translate/export/publish/compile v3.3 scenes to a DOM / more general inclusive format, that might solve archivability because then scenes can be authored and stored in v3.3 formats for archival, and converted on-demand. Then any DOM altered formats become publishing formats, and v3.3 series remains the only archival format needed.
Then Archivability ==  'automatic, lossless, at least one-way reachability/convertability from v3.3'.   

SPEC COMMENT RULES APPLY >>>>

Or from a v4 that refactors out a few  native-only things like Layer to make it easier for native and html to co-exist with the same node specs.

 CSS - Leonard mentioned the Layer component wasn't needed in DOM because could use CSS for HUD
-- would that also apply to cobweb?

Native browsers might still like Layer as a way to do HUD
how I think layer component can be refactored to a higher level:
<Hyperscene clearColor='0 0 0'>
<Scene DEF='S1' url=''>
</Scene>
<Layer DEF='L1' url=''>
</Layer>
<HyperRoute fromLayer='L1' ... toLayer='S1' ..../>
</Hyperscene>
Then somehow the hyperscene in DOM could be different, using CSS for HUD. Then scene format can stay the same for native and cobweb, and Layers just in native. Layers then becomes a native substitute for CSS, and not tangled with the Scene file, so the scene file works on native and cobweb.

When implementing Layers I found it was almost like re-implementing scene - separate binding stacks - and at the time I thought it should be up one level even with Scene anyway.

<<<< SPEC COMMENT RULES APPLY

________________________________________
From: x3d-public <x3d-public-bounces at web3d.org> on behalf of Roy Walmsley <roy.walmsley at ntlworld.com>
Sent: November 29, 2016 8:26 AM
To: x3d-public at web3d.org
Subject: [x3d-public] Minutes of further discussion on X3D/HTML/DOM integration held November 16th 2016

Hi all,

Following the open meeting held on November 9th further discussion of the same topic continued during the X3D WG meeting held on November 16th. The minutes of this second discussion are reproduced below. The minutes of the first discussion can be found at http://web3d.org/pipermail/x3d-public_web3d.org/2016-November/005541.html.

Regards,

Roy
X3D WG co-chair.

=================================================================================================================

Continued discussion of X3D/HTML/DOM Integration

Discussion topics from November 9th open meeting:

·         For example, in order to integrate with the DOM/HTML event model what topics do we need to cover?

·         Do we need DOM/HTML element interface definitions, and what form should these take? Should these be of a similar nature to those in SVG 2 (https://www.w3.org/TR/SVG2/) or XML3D (http://xml3d.org/xml3d/specification/latest/)?

·         What part should CSS play?

·         Do we need any additional nodes that might cover VR/AR/MAR/ or specific platform usage such as mobile?

It was stated that X3DOM is a big step to standardization. Andreas felt that the X3D scene graph and event system should be preserved as much as possible, perhaps utilizing a small interface layer to enable integration. Industry commonly used web workflow and Javascript ideas should apply. Having Cobweb is good too. It is powerful to have two implementations, and appreciation was expressed to Andreas that he has been working on both, and in particular providing additional code for HTML integration with Cobweb.

It was agreed that SVG is a good model to think about,  with all SVG elements having DOM definitions. However, since SVG has a smaller set of capabilities than X3D, is it realistic to follow the same path? It would be a big and rigorous effort.

With respect to CSS, it is not used much with X3DOM.

VR/AR, mobile – yes, probably need additional nodes. Leonard has suggested some, e.g. for navigation.

Andreas modified execution model diagram was reviewed (see http://web3d.org/mailman/private/x3d_web3d.org/attachments/20161115/bed28a39/attachment-0001.png). This has additions to the original diagram in 19775-1 (see http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#f-ConceptualExecutionModel) for both SAI and DOM events.

Some discussion of DEF/USE versus id ensued. Andreas suggested that perhaps don’t have to equate them. Simply use DEF/USE for X3D ROUTES, and id for HTML. Both X3DOM and Cobweb allow both and treat them both independently, although X3DOM has an option for the Inline node called ‘mapDEFToID’ to link them that is not enabled by default (see http://doc.x3dom.org/author/Networking/Inline.html).

Roy noted that in the two examples (see http://www.web3d.org/member/wiki/x3d-svg-html-dom-integration-example-using-x3dom and http://www.web3d.org/member/wiki/x3d-svg-html-dom-integration-example-using-cobweb) showing X3D integration into HTML, the content is essentially identical. In the Cobweb example, the bridge code generated by Andreas for Cobweb was included. However, it was noted that there were significant differences in the performance of the two implementations, particularly with respect to event management. The TouchSensor node is not implemented in X3DOM. Instead, authors are expected to use HTML event methods. On the other hand, Cobweb has no support for HTML interaction capability, such as OnClick.

Don has posted that FireFox now provides mobile support, and that both X3DOM and Cobweb render nicely (see http://web3d.org/pipermail/x3d-public_web3d.org/2016-November/005544.html). It was noted,  however, that X3DOM has been  running on Android for over three years.

The use of page up and page down to move between viewpoints was commented on, but it was noted that there are no keys on mobile hardware. It was suggested that buttons could be added to change viewpoints. Some examples do that. For VR it was noted that navigation needs to be much more flexible. Andreas commented that  he has looked at some headsets, using the X3DOM classroom example, and noted that newer headsets come with controllers for the hands.

The possibility of extending X3D to make a VR profile was discussed. X3DOM outputs to VR in an ad hoc manner using RenderToTexture to get each eye rendering. In comparison, WebVR has to interoperate with global VR standards. There is recognition of connected hardware within a web page. One mode of navigation in VR is to look around while moving.

A-Frame was commented on. It was usually seen with full screen examples. It uses an entity/component model, and can be thought of as being built on three.js. Usage involves imperative coding.

Next steps for standards development were summarized. Differences between X3D and Cobweb were highlighted. Cobweb allows usage of SAI methods, X3DOM doesn’t. X3DOM allows modification via DOM methods. Cobweb does not support global events. X3DOM has an ‘OnOutputChange’ event type, that listens to any output event from any node.

It was noted that other authoring tools, such as game engines, are a completely different. They are not declarative.

=================================================================================================================