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

[Roy Walmsley]

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.h
tml#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. 

 

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161129/5bc3805c/attachment.html>