[x3d-public] X3D/HTML/DOM integration held November 16th 2016

Wed Nov 30 19:04:52 PST 2016

On Nov 29, 2016 11:23 PM, <x3d-public-
> Message: 1
> Date: Tue, 29 Nov 2016 20:40:44 +0000
> From: doug sanden <highaspirations at hotmail.com>
> To: "x3d-public at web3d.org" <x3d-public at web3d.org>
> Subject: Re: [x3d-public] Minutes of further discussion on
>         X3D/HTML/DOM integration held November 16th 2016
> Message-ID:
>         <
BN6PR14MB1778B012E5FC4A5EACAF2A22B68D0 at BN6PR14MB1778.namprd14.prod.outlook.com
>
>
> Content-Type: text/plain; charset="Windows-1252"
>
> - 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.

The WebVR spec. proposal has a vrpose

https://w3c.github.io/webvr/#interface-vrpose

Navigation is often a combination of pose and controller input. In Google
Earth VR, for example, you use the controller to point a ray at a new
position to which one is then teleported after pressing a button.

> -
> 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'.

I think the DOM integration would mean that the web page as a whole
including x3d and html (and other) content needs to be archived. The
quality of all the involved standards then has a strong impact on the
durability of such archives. There are probably recommendations on the use
of html and DOM for archival purposes.

> 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?

Almost certainly yes, since cobweb allows full styling including
positioning of the webgl canvas it uses as a drawing surface. The browser
can position any other html element including another webgl canvas but also
svg or images on top.

Cobweb, in addition, has full support for x3d layers. X3dom does not since
it is rarely needed.

When this was discussed on the mailing list a while ago, the interesting
point was made that web browsers only allow 8 or perhaps 16 webgl contexts
on the same page while the Layer component usually is implemented using a
single context allowing any number of layers.

> 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.

Or perhaps have multiple Scenes under the same x3d element (in a single
document) and allow viewports for Scenes ?

> 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
>

Andreas

________________________________________
> 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.
>
>
=================================================================================================================
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 29 Nov 2016 23:22:26 -0500
> From: <yottzumm at gmail.com>
> To: Don Brutzman <brutzman at nps.edu>,    X3D Graphics public mailing list
>         <x3d-public at web3d.org>
> Cc: SAVAGE Research Group <savage at nps.edu>
> Subject: Re: [x3d-public] announce: X3D Java Scene Authoring Interface
>         (SAI)open source, initial review release
> Message-ID: <583e5401.6c23ed0a.7d4c5.c495 at mx.google.com>
> Content-Type: text/plain; charset="utf-8"
>
> Waiting for instructions on how to use IS/ISObject/IS statements.  I?m
not sure how to hook them under material, etc.
>
> Thanks,
>
> John
>
> Sent from Mail for Windows 10
>
> From: Don Brutzman
> Sent: Tuesday, November 29, 2016 12:04 PM
> To: X3D Graphics public mailing list
> Cc: SAVAGE Research Group
> Subject: Re: [x3d-public] announce: X3D Java Scene Authoring Interface
(SAI)open source, initial review release
>
> Another significant release has been deployed today:
>
> - Support for prototypes: ProtoDeclare, ProtoInterface/ProtoBody,
ExternProtoDeclare, ProtoInstance.
> - Further validation checks, making it hard for programmers to create a
broken scene graph.
> - Support for X3D, ClassicVRML and VRML97 file export (.x3d .x3dv .wrl)
> - "Principle of least surprise" when null values are encountered from
author (e.g. clear a field, etc.)
> - Further unit tests in example program to confirm proper operation of
correct and incorrect constructs.
> - Internal package refactoring to improve inheritance, leaving exposed
programming API unchanged.
> - Performance looks great, despite complexity am unable to get execution
time above "O seconds" - deserves profiling on large models.
>
> Key links:
>
>
http://www.web3d.org/specifications/java/X3dJavaSceneAuthoringInterface.html
>
>         http://www.web3d.org/specifications/java/examples
>
>         http://www.web3d.org/specifications/java/javadoc
>
> Test reports and improvement suggestions welcome.  Have fun with X3D Java!
>
>
> On 10/21/2016 8:19 AM, Don Brutzman wrote:
> > Second release is out, the X3D Java SAI Library is now in beta.
> >
> > Latest release include autogeneration of concrete classes for field
types.  Quite a tricky business because a number of specification
definitions are contradictory or simply missing, because the published Java
SAI specification was based on X3D v3.0 capabilities.
> >
> > Still in collection mode, but have started a text document listing
specification problems and potential improvements.
> >
> >
http://www.web3d.org/specifications/java/X3dJavaSpecificationChangesAndIssues.txt
> >
> > Active TODO list, more to follow:
> >
> > * In progress. Test concrete field-type classes for SFBool/MFBool
through SFNode/MFNode to support value instantiation, including creation of
type-checked new values from strings. A number of new data types have been
added since X3D version 3.0, extra attention is needed to ensure that new
classes and methods consistently support new specification additions.
Method stubs need to be implemented (typically adapting source code from
the Xj3D implementation).
> > * In progress. Confirm generation of default attribute values and
constructors.
> > * In progress. Continue testing concrete classes for X3D statements,
also confirming that attributes are properly reflected as fields.
> > * In progress. Add support for persistent scene-graph comments and
comment blocks.
> >
> > Initial testing: HelloWorldProgram.java model, online at
> >
> >
http://www.web3d.org/specifications/java/examples/HelloWorldProgram.java
> >
> > The X3D Object Model is looking very solid.  Changes to X3D
specification and schema are automatically integrated in this codebase.
When complete, this will be a big step forward for rigourously maintaining
all X3D specifications, quality assurance tools and Web3D Consortium
resources completely correct and in synch.  I expect it will be especially
helpful when we get to the stage of experimentation with X3D version 4.
> >
> > Scrutiny by Java experts on the class structures and design patterns is
appreciated.  More work to follow on X3D Java SAI Library, of course, but
it looks like all the major building blocks are now in place.  Incremental
implementation improvements and TODO capability addition can now proceed.
> >
> > As ever, all feedback and comments are welcome.  Have fun with X3D Java!
> >
> >
==================================================================================
> > On 6/27/2016 8:03 AM, Don Brutzman wrote:
> >
> > Now available for review: X3D Java Scene Authoring Interface (SAI)
Library.
> >
> >
http://www.web3d.org/x3d/stylesheets/java/X3dJavaSceneAuthoringInterface.html
> >
> > The X3D Java Scene Access Interface (SAI) is a strongly typed Java
library that provides access to a browser and its contained scene graph.
This package contains X3D SAI interfaces that support the X3D
Specifications.
> >
> > Available products include javadoc, source code, build classes and
draft specification annexes.
> >
> >     http://www.web3d.org/x3d/stylesheets/java/javadoc/index.html
> >     http://www.web3d.org/x3d/stylesheets/java/source/org/web3d/x3d/sai
> >     http://www.web3d.org/x3d/stylesheets/java/build/org/web3d/x3d/sai
> >
> >
http://www.web3d.org/x3d/stylesheets/java/draftJavaLanguageBindingAnnexes/Part2/nodeTypeInterfaces.html
> >
http://www.web3d.org/x3d/stylesheets/java/draftJavaLanguageBindingAnnexes/Part2/nodeInterfaces.html
> >
> > Intended uses include
> >
> > * Current: compiling Java source code for an X3D Script node.
> > * Future: support creation of standalone Java applications by providing
a Plain Old Java Object (POJO) implementation for X3D.
> > * Future: serve as a design template for future autogeneration of
similar codebases for ECMAScript, C++/C# and Python.
> >
> > Special thanks to Roy Walmsley for X3D Object Model creation and
ongoing design discussions.  Further notes about API Codebase Production
autogeneration and design considerations appear on the topmost page listed
above.
> >
> > Work continues on matching autogenerated interfaces to the
specification, noting corrections, and testing actual Script code in Java.
> >
> > Comments are always welcome.  Have fun with X3D using Java!
> >
==================================================================================
>
>
> all the best, Don
> --
> Don Brutzman  Naval Postgraduate School, Code USW/Br
brutzman at nps.edu
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
 +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics
http://faculty.nps.edu/brutzman
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161129/73d99cab/attachment.html
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 92, Issue 60
> ******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161130/a14779eb/attachment-0001.html>