<p dir="ltr">On Nov 29, 2016 11:23 PM, <x3d-public-<br>
> Message: 1<br>
> Date: Tue, 29 Nov 2016 20:40:44 +0000<br>
> From: doug sanden <<a href="mailto:highaspirations@hotmail.com">highaspirations@hotmail.com</a>><br>
> To: "<a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>" <<a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>><br>
> Subject: Re: [x3d-public] Minutes of further discussion on<br>
> X3D/HTML/DOM integration held November 16th 2016<br>
> Message-ID:<br>
> <<a href="mailto:BN6PR14MB1778B012E5FC4A5EACAF2A22B68D0@BN6PR14MB1778.namprd14.prod.outlook.com">BN6PR14MB1778B012E5FC4A5EACAF2A22B68D0@BN6PR14MB1778.namprd14.prod.outlook.com</a>><br>
><br>
> Content-Type: text/plain; charset="Windows-1252"<br>
><br>
> - 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.</p>
<p dir="ltr">The WebVR spec. proposal has a vrpose </p>
<p dir="ltr"><a href="https://w3c.github.io/webvr/#interface-vrpose">https://w3c.github.io/webvr/#interface-vrpose</a></p>
<p dir="ltr">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.</p>
<p dir="ltr">> -<br>
> 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.<br>
> Then Archivability == 'automatic, lossless, at least one-way reachability/convertability from v3.3'.</p>
<p dir="ltr">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. <br></p>
<p dir="ltr">> SPEC COMMENT RULES APPLY >>>><br>
><br>
> 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.<br>
><br>
> CSS - Leonard mentioned the Layer component wasn't needed in DOM because could use CSS for HUD<br>
> -- would that also apply to cobweb?</p>
<p dir="ltr">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.</p>
<p dir="ltr">Cobweb, in addition, has full support for x3d layers. X3dom does not since it is rarely needed.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> Native browsers might still like Layer as a way to do HUD<br>
> how I think layer component can be refactored to a higher level:<br>
> <Hyperscene clearColor='0 0 0'><br>
> <Scene DEF='S1' url=''><br>
> </Scene><br>
> <Layer DEF='L1' url=''><br>
> </Layer><br>
> <HyperRoute fromLayer='L1' ... toLayer='S1' ..../><br>
> </Hyperscene><br>
> 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.</p>
<p dir="ltr">Or perhaps have multiple Scenes under the same x3d element (in a single document) and allow viewports for Scenes ?</p>
<p dir="ltr">> 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.<br>
><br>
> <<<< SPEC COMMENT RULES APPLY<br>
></p>
<p dir="ltr">Andreas </p>
<p dir="ltr"> ________________________________________<br>
> From: x3d-public <<a href="mailto:x3d-public-bounces@web3d.org">x3d-public-bounces@web3d.org</a>> on behalf of Roy Walmsley <<a href="mailto:roy.walmsley@ntlworld.com">roy.walmsley@ntlworld.com</a>><br>
> Sent: November 29, 2016 8:26 AM<br>
> To: <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
> Subject: [x3d-public] Minutes of further discussion on X3D/HTML/DOM integration held November 16th 2016<br>
><br>
> Hi all,<br>
><br>
> 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 <a href="http://web3d.org/pipermail/x3d-public_web3d.org/2016-November/005541.html">http://web3d.org/pipermail/x3d-public_web3d.org/2016-November/005541.html</a>.<br>
><br>
> Regards,<br>
><br>
> Roy<br>
> X3D WG co-chair.<br>
><br>
> =================================================================================================================<br>
><br>
> Continued discussion of X3D/HTML/DOM Integration<br>
><br>
> Discussion topics from November 9th open meeting:<br>
><br>
> ? For example, in order to integrate with the DOM/HTML event model what topics do we need to cover?<br>
><br>
> ? 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 (<a href="https://www.w3.org/TR/SVG2/">https://www.w3.org/TR/SVG2/</a>) or XML3D (<a href="http://xml3d.org/xml3d/specification/latest/">http://xml3d.org/xml3d/specification/latest/</a>)?<br>
><br>
> ? What part should CSS play?<br>
><br>
> ? Do we need any additional nodes that might cover VR/AR/MAR/ or specific platform usage such as mobile?<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> With respect to CSS, it is not used much with X3DOM.<br>
><br>
> VR/AR, mobile ? yes, probably need additional nodes. Leonard has suggested some, e.g. for navigation.<br>
><br>
> Andreas modified execution model diagram was reviewed (see <a href="http://web3d.org/mailman/private/x3d_web3d.org/attachments/20161115/bed28a39/attachment-0001.png">http://web3d.org/mailman/private/x3d_web3d.org/attachments/20161115/bed28a39/attachment-0001.png</a>). This has additions to the original diagram in 19775-1 (see <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#f-ConceptualExecutionModel">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#f-ConceptualExecutionModel</a>) for both SAI and DOM events.<br>
><br>
> 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 <a href="http://doc.x3dom.org/author/Networking/Inline.html">http://doc.x3dom.org/author/Networking/Inline.html</a>).<br>
><br>
> Roy noted that in the two examples (see <a href="http://www.web3d.org/member/wiki/x3d-svg-html-dom-integration-example-using-x3dom">http://www.web3d.org/member/wiki/x3d-svg-html-dom-integration-example-using-x3dom</a> and <a href="http://www.web3d.org/member/wiki/x3d-svg-html-dom-integration-example-using-cobweb">http://www.web3d.org/member/wiki/x3d-svg-html-dom-integration-example-using-cobweb</a>) 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.<br>
><br>
> Don has posted that FireFox now provides mobile support, and that both X3DOM and Cobweb render nicely (see <a href="http://web3d.org/pipermail/x3d-public_web3d.org/2016-November/005544.html">http://web3d.org/pipermail/x3d-public_web3d.org/2016-November/005544.html</a>). It was noted, however, that X3DOM has been running on Android for over three years.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> It was noted that other authoring tools, such as game engines, are a completely different. They are not declarative.<br>
><br>
> =================================================================================================================<br>
><br>
><br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 2<br>
> Date: Tue, 29 Nov 2016 23:22:26 -0500<br>
> From: <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>><br>
> To: Don Brutzman <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>>, X3D Graphics public mailing list<br>
> <<a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>><br>
> Cc: SAVAGE Research Group <<a href="mailto:savage@nps.edu">savage@nps.edu</a>><br>
> Subject: Re: [x3d-public] announce: X3D Java Scene Authoring Interface<br>
> (SAI)open source, initial review release<br>
> Message-ID: <<a href="mailto:583e5401.6c23ed0a.7d4c5.c495@mx.google.com">583e5401.6c23ed0a.7d4c5.c495@mx.google.com</a>><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> Waiting for instructions on how to use IS/ISObject/IS statements. I?m not sure how to hook them under material, etc.<br>
><br>
> Thanks,<br>
><br>
> John<br>
><br>
> Sent from Mail for Windows 10<br>
><br>
> From: Don Brutzman<br>
> Sent: Tuesday, November 29, 2016 12:04 PM<br>
> To: X3D Graphics public mailing list<br>
> Cc: SAVAGE Research Group<br>
> Subject: Re: [x3d-public] announce: X3D Java Scene Authoring Interface (SAI)open source, initial review release<br>
><br>
> Another significant release has been deployed today:<br>
><br>
> - Support for prototypes: ProtoDeclare, ProtoInterface/ProtoBody, ExternProtoDeclare, ProtoInstance.<br>
> - Further validation checks, making it hard for programmers to create a broken scene graph.<br>
> - Support for X3D, ClassicVRML and VRML97 file export (.x3d .x3dv .wrl)<br>
> - "Principle of least surprise" when null values are encountered from author (e.g. clear a field, etc.)<br>
> - Further unit tests in example program to confirm proper operation of correct and incorrect constructs.<br>
> - Internal package refactoring to improve inheritance, leaving exposed programming API unchanged.<br>
> - Performance looks great, despite complexity am unable to get execution time above "O seconds" - deserves profiling on large models.<br>
><br>
> Key links:<br>
><br>
> <a href="http://www.web3d.org/specifications/java/X3dJavaSceneAuthoringInterface.html">http://www.web3d.org/specifications/java/X3dJavaSceneAuthoringInterface.html</a><br>
><br>
> <a href="http://www.web3d.org/specifications/java/examples">http://www.web3d.org/specifications/java/examples</a><br>
><br>
> <a href="http://www.web3d.org/specifications/java/javadoc">http://www.web3d.org/specifications/java/javadoc</a><br>
><br>
> Test reports and improvement suggestions welcome. Have fun with X3D Java!<br>
><br>
><br>
> On 10/21/2016 8:19 AM, Don Brutzman wrote:<br>
> > Second release is out, the X3D Java SAI Library is now in beta.<br>
> ><br>
> > 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.<br>
> ><br>
> > Still in collection mode, but have started a text document listing specification problems and potential improvements.<br>
> ><br>
> > <a href="http://www.web3d.org/specifications/java/X3dJavaSpecificationChangesAndIssues.txt">http://www.web3d.org/specifications/java/X3dJavaSpecificationChangesAndIssues.txt</a><br>
> ><br>
> > Active TODO list, more to follow:<br>
> ><br>
> > * 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).<br>
> > * In progress. Confirm generation of default attribute values and constructors.<br>
> > * In progress. Continue testing concrete classes for X3D statements, also confirming that attributes are properly reflected as fields.<br>
> > * In progress. Add support for persistent scene-graph comments and comment blocks.<br>
> ><br>
> > Initial testing: HelloWorldProgram.java model, online at<br>
> ><br>
> > <a href="http://www.web3d.org/specifications/java/examples/HelloWorldProgram.java">http://www.web3d.org/specifications/java/examples/HelloWorldProgram.java</a><br>
> ><br>
> > 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.<br>
> ><br>
> > 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.<br>
> ><br>
> > As ever, all feedback and comments are welcome. Have fun with X3D Java!<br>
> ><br>
> > ==================================================================================<br>
> > On 6/27/2016 8:03 AM, Don Brutzman wrote:<br>
> ><br>
> > Now available for review: X3D Java Scene Authoring Interface (SAI) Library.<br>
> ><br>
> > <a href="http://www.web3d.org/x3d/stylesheets/java/X3dJavaSceneAuthoringInterface.html">http://www.web3d.org/x3d/stylesheets/java/X3dJavaSceneAuthoringInterface.html</a><br>
> ><br>
> > 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.<br>
> ><br>
> > Available products include javadoc, source code, build classes and draft specification annexes.<br>
> ><br>
> > <a href="http://www.web3d.org/x3d/stylesheets/java/javadoc/index.html">http://www.web3d.org/x3d/stylesheets/java/javadoc/index.html</a><br>
> > <a href="http://www.web3d.org/x3d/stylesheets/java/source/org/web3d/x3d/sai">http://www.web3d.org/x3d/stylesheets/java/source/org/web3d/x3d/sai</a><br>
> > <a href="http://www.web3d.org/x3d/stylesheets/java/build/org/web3d/x3d/sai">http://www.web3d.org/x3d/stylesheets/java/build/org/web3d/x3d/sai</a><br>
> ><br>
> > <a href="http://www.web3d.org/x3d/stylesheets/java/draftJavaLanguageBindingAnnexes/Part2/nodeTypeInterfaces.html">http://www.web3d.org/x3d/stylesheets/java/draftJavaLanguageBindingAnnexes/Part2/nodeTypeInterfaces.html</a><br>
> > <a href="http://www.web3d.org/x3d/stylesheets/java/draftJavaLanguageBindingAnnexes/Part2/nodeInterfaces.html">http://www.web3d.org/x3d/stylesheets/java/draftJavaLanguageBindingAnnexes/Part2/nodeInterfaces.html</a><br>
> ><br>
> > Intended uses include<br>
> ><br>
> > * Current: compiling Java source code for an X3D Script node.<br>
> > * Future: support creation of standalone Java applications by providing a Plain Old Java Object (POJO) implementation for X3D.<br>
> > * Future: serve as a design template for future autogeneration of similar codebases for ECMAScript, C++/C# and Python.<br>
> ><br>
> > 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.<br>
> ><br>
> > Work continues on matching autogenerated interfaces to the specification, noting corrections, and testing actual Script code in Java.<br>
> ><br>
> > Comments are always welcome. Have fun with X3D using Java!<br>
> > ==================================================================================<br>
><br>
><br>
> all the best, Don<br>
> --<br>
> Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a><br>
> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<br>
> X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman">http://faculty.nps.edu/brutzman</a><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>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161129/73d99cab/attachment.html">http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161129/73d99cab/attachment.html</a>><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 92, Issue 60<br>
> ******************************************<br>
</p>