https://www.web3d.org/wiki/api.php?action=feedcontributions&user=Webmaster&feedformat=atomWeb3D.org - User contributions [en]2024-03-28T22:43:51ZUser contributionsMediaWiki 1.25.1https://www.web3d.org/wiki/index.php?title=Xj3D_Evolution&diff=9804Xj3D Evolution2020-01-27T23:21:33Z<p>Webmaster: Minor TEST text change to test removal of security restrictions</p>
<hr />
<div>[[File:Xj3Dlogo-275.png|right]]<br />
<br />
Xj3D is an open-source Java implementation for X3D graphics. Xj3D is used to demonstrate many capabilities for specification development and supports a variety of valuable projects.<br />
<br />
Announcement: NPS has ported the full Xj3D codebase and history to the [http://sourceforge.net/projects/xj3d Sourceforge Xj3D] site. This page describes the how that transition from the original [http://xj3d.org xj3d.org] site took place.<br />
<br />
== Discussion and consensus building ==<br />
<br />
We are using [mailto:source@web3d.org?subject=Xj3D%20Evolution source@web3d.org] mailing list <br />
to work out these possibilities and build stakeholder consensus.<br />
([http://web3d.org/mailman/listinfo/source_web3d.org subscribe], [http://web3d.org/mailman/private/source_web3d.org/ archive])<br />
<br />
Consensus summary points<br />
* Basic strategy: we are evolving by re-versioning, not re-naming Xj3D<br />
* We will simply mirror the current xj3d.org repository, as version 2.0, and maintain full backwards compatibility by integrating any forthcoming changes there<br />
<br />
== Transition Goals and Timeline ==<br />
<br />
Long-term stability, improvement and development of the Xj3D code base are shared goals. This page records ideas for potential improvement. These are familiar topics and lots of excellent work continues. <br />
<br />
It was straightforward for interested stakeholders to discuss and agree on next steps.<br />
* Following extensive comments from Xj3D source community and X3D working group from our teleconference on 30 June 2014, work to mirror Xj3D on SourceForge began during the week of 7 July 2014.<br />
* We achieved the goal to have everything transitioned, stabilized, announced and ready for new contributions at the [http://www.web3d2014.org Web3D 2014 Conference] and [http://www.siggraph.org SIGGRAPH 2014 Conference] in Vancouver Canada.<br />
* The NPS branch and original Yumetech trunk were successfully swapped in May 2015.<br />
* Additional variants of Xj3D have been integrated within the new trunk, sometimes saving alternates as branches for archival purposes.<br />
* Primary development is on the trunk with JOGAMP/JOGL/JOAL fully updated.<br />
<br />
== Source Code Hosting Transferred ==<br />
<br />
The Xj3D code was moved to a stable public open-source repository in order to enable greater participation and development. This approach also gained more visibility among programmers who might want to contribute.<br />
* [http://www.xj3d.org xj3d.org] has hosted the source for many years but development has been intermittent and somewhat less than fully open.<br />
* [https://savage.nps.edu/Savage/developers.html#Xj3D NPS branch of Xj3D] was used for experimental development. Proven changes and unit tests are integrated back into the Xj3D trunk when stable.<br />
<br />
'''Direction''': mirroring the full xj3d.org site on [https://sourceforge.net/projects/xj3d SourceForge Xj3D project] is the group's best approach to meet group goals for unveiling and evangelizing Xj3D community opportunities at Web3D 2014 Conference and SIGGRAPH 2014.<br />
<br />
'''Results''': The codebase has been re-established at [http://sourceforge.net/projects/xj3d Xj3D Sourceforge project]<br />
* [http://sourceforge.net/p/xj3d/code/HEAD/tree Xj3D Sourceforge codebase] without change (and with total prior code history) was made publicly available 8 August 2014<br />
* Initial build tests satisfactory for both NPS branch and original Yumetech trunk.<br />
<br />
Decision rationale follows for choice of source archive site.<br />
<br />
=== SourceForge ===<br />
<br />
* The current xj3d.org code is in subversion, this can be migrated completely<br />
* Web3D already has numerous assets checked into the [https://sourceforge.net/projects/x3d Sourceforge X3D project], it is available<br />
* Sourceforge also has related projects for [https://sourceforge.net/projects/jgeom jgeom] and [https://sourceforge.net/projects/open-dis open-dis]<br />
* Multiple participants have experience with using and administering the Sourceforge site<br />
* Instead of using the Web3D X3D project, can Web3D instead create a new and separate Sourceforge project for Xj3D to keep things a bit simpler?<br />
* Can the new site maintain a side-by-side mirror of Xj3D.org and an refactored trunk, so that all updates are reliably accessible?<br />
* Can the new site keep a new trunk adjacent but separate so that new developers can get started quickly?<br />
* There is a lot of merit to using a version-control system that is familiar, especially as we try to integrate other Xj3D variants and prepare for SIGGRAPH milestones.<br />
<br />
=== GitHub ===<br />
<br />
* GitHub includes the X3DOM project and a few other X3D-related projects.<br />
* We have reserved an [https://github.com/x3d X3D Xj3D] project site on GitHub as a placeholder. This might be useful for cross-links and future evolution.<br />
* The [https://github.com/pricing github pricing policy] does not cost money to operate an open-source organizational repository.<br />
* We are looking at migration of subversion to git.. appears possible but somewhat involved.<br />
* If we do migrate to GitHub, that will likely complicate the re-integration of other existing subversion-based exports of Xj3D.<br />
<br />
=== Maven ===<br />
<br />
* [http://maven.apache.org Apache Maven] can encourage a variety of build possibilities and paired support between multiple projects, especially for Java. Who has some experience, or wants to experiment, with adding it?<br />
<br />
== Web3D.org Website ==<br />
Several project builds are maintained on external repositories but their corresponding websites are automatically built and updated on [http://www.web3d.org web3d.org]<br />
<br />
=== Web3D summary page ===<br />
<br />
* TODO: have ''www.web3d.org/xj3d'' (or somesuch) provide an official summary page for Xj3D community on new web3d.org website<br />
* TODO: find and cleanup or move other wiki pages for Xj3D - somewhat gated by difficulties with web3d.org wiki.<br />
<br />
=== Mailing list considerations ===<br />
<br />
Web3D Consortium maintains the mailing list archives.<br />
* Discussion list ''[http://web3d.org/mailman/listinfo/source_web3d.org source@web3D.org]'' seems to be a misnomer, perhaps it should be restarted as ''xj3d@web3d.org''<br />
* This list is also used for discussions on the SourceForge [https://sourceforge.net/projects/jgeom/?source=directory jgeom] project, so perhaps the current name is actually OK<br />
* Commits list ''[http://web3d.org/mailman/listinfo/source_web3d.org source_x3d_cvs@web3d.org]'' and commits account ''[http://web3d.org/mailman/listinfo/source_web3d.org cvs-user@xj3d.org]'' are also mis-named since subversion is used<br />
<br />
Another alternative option:<br />
* Move all discussion and reporting lists to the sourceforge repository in order to maximize community productivity. In that case, the prior email lists are simply closed and kept archived, which also reduces the web3d.org administrative burden.<br />
<br />
Resolution: we maintained stability with the ''[http://web3d.org/mailman/listinfo/source_web3d.org source@web3D.org]'' list.<br />
<br />
== TODO: Opportunities and upcoming tasks ==<br />
<br />
=== Merge orphaned Xj3D codebases ===<br />
<br />
Separate projects have made excellent improvements to Xj3D over the years, but were never re-integrated into the master code base. We hope to capture, merge and test these improvements in version control, and then issue a series of new releases.<br />
* NPS has maintained an [https://savage.nps.edu/Savage/developers.html#Xj3D Xj3D branch] that is used in multiple tools: X3D-Edit, example archives image generation, AUV Workbench, Viskit<br />
* [http://www.web3d.org/case-studies/structure-and-form-analysis-system-safas/e-learning-and-e-design Structure And Form Analysis System (SAFAS)], Nicholas Polys, Virginia Tech (VT) <br />
* [http://www.partdb.com PartDB Inc.], Hyokwang Lee, Don Brutzman and Terry Norbraten<br />
* [http://www.aniviza.com/svn/listing.php Aniviza modifications for NASA WorldWind] by Rick Goldberg<br />
* [https://github.com/Norkart/NK-VirtualGlobe Norkart/NK-VirtualGlobe], Rune Aasgaard<br />
* Others?<br />
<br />
Please [mailto:source@web3d.org,brutzman@nps.edu,tdnorbra@nps.edu?subject=Xj3D%20inquiry contact us] if you have source code to integrate into the Xj3D project.<br />
<br />
=== Xj3D issue tracking ===<br />
<br />
Currently two bugzilla sites are in existence. They need to be merged and become active.<br />
* [http://bugzilla.xj3d.org bugzilla.xj3d.org] (master)<br />
* [https://www.movesinstitute.org/bugzilla/buglist.cgi?quicksearch=xj3d NPS bugzilla] <br />
<br />
TODO: for maximum reliability over long term, we need to migrate to the SourceForge tickets tracker. Past bugs and issues can be transcribed as appropriate to maintain historical rationales.<br />
<br />
=== Xj3D website improvements ===<br />
<br />
The orginal [http://www.xj3d.org Xj3D website] is moderately complete but woefully out of date. <br />
<br />
TODO website migration: <br />
* Confirm that website pages and documentation are checked into version control<br />
* Automate website updates by synchronizing with version control<br />
* Offer ways for people to contribute bug reports, issues, improvements<br />
<br />
=== Programming problems ===<br />
<br />
Several areas of Xj3D implementation are problematic. Dedicated attention and teamwork may help.<br />
* Better run-time exception reporting (most log entries are completely obscure)<br />
* Confirm updated jogl rendering is working, especially z-buffer and aliasing<br />
* Extrusion node support for orientation field (overall passes 7 of 10 tests)<br />
* Image rendering timing can miss colors/textures and hangs on numerous examples<br />
* Compressed binary encoding hangs on numerous examples, but the apparent list of exception errors seems short<br />
* Ensure that we are keeping current with [http://jogamp.org JOGAMP] (formerly java.net JOGL, includes JOAL JOCL etc.) and the [http://aviatrix3d.j3d.org Aviatrix3D] render layer ([https://github.com/j3d/aviatrix3d github]), administered by Justin Couch<br />
* FontStyle implementation is incorrect. See example [http://www.web3d.org/x3d/content/examples/ConformanceNist/Appearance/FontStyle/_pages/page01.html FontStyle/default]<br />
<br />
Other project efforts are always welcome.<br />
* [https://savage.nps.edu/X3D-Edit X3D-Edit] update report<br />
* Automatic creation of viewpoint images for all scenes in the [http://www.web3d.org/x3d/content/examples/X3dResources.html#Examples X3D Examples] archives<br />
<br />
All inputs and contributions are welcome. Have fun with Xj3D!</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=Xj3D_Evolution&diff=9803Xj3D Evolution2020-01-27T23:17:32Z<p>Webmaster: </p>
<hr />
<div>[[File:Xj3Dlogo-275.png|right]]<br />
<br />
TEST: Check for error on save.<br />
<br />
Xj3D is an open-source Java implementation for X3D graphics. Xj3D is used to demonstrate many capabilities for specification development and supports a variety of valuable projects.<br />
<br />
Announcement: NPS has ported the full Xj3D codebase and history to the [http://sourceforge.net/projects/xj3d Sourceforge Xj3D] site. This page describes the how that transition from the original [http://xj3d.org xj3d.org] site took place.<br />
<br />
== Discussion and consensus building ==<br />
<br />
We are using [mailto:source@web3d.org?subject=Xj3D%20Evolution source@web3d.org] mailing list <br />
to work out these possibilities and build stakeholder consensus.<br />
([http://web3d.org/mailman/listinfo/source_web3d.org subscribe], [http://web3d.org/mailman/private/source_web3d.org/ archive])<br />
<br />
Consensus summary points<br />
* Basic strategy: we are evolving by re-versioning, not re-naming Xj3D<br />
* We will simply mirror the current xj3d.org repository, as version 2.0, and maintain full backwards compatibility by integrating any forthcoming changes there<br />
<br />
== Transition Goals and Timeline ==<br />
<br />
Long-term stability, improvement and development of the Xj3D code base are shared goals. This page records ideas for potential improvement. These are familiar topics and lots of excellent work continues. <br />
<br />
It was straightforward for interested stakeholders to discuss and agree on next steps.<br />
* Following extensive comments from Xj3D source community and X3D working group from our teleconference on 30 June 2014, work to mirror Xj3D on SourceForge began during the week of 7 July 2014.<br />
* We achieved the goal to have everything transitioned, stabilized, announced and ready for new contributions at the [http://www.web3d2014.org Web3D 2014 Conference] and [http://www.siggraph.org SIGGRAPH 2014 Conference] in Vancouver Canada.<br />
* The NPS branch and original Yumetech trunk were successfully swapped in May 2015.<br />
* Additional variants of Xj3D have been integrated within the new trunk, sometimes saving alternates as branches for archival purposes.<br />
* Primary development is on the trunk with JOGAMP/JOGL/JOAL fully updated.<br />
<br />
== Source Code Hosting Transferred ==<br />
<br />
The Xj3D code was moved to a stable public open-source repository in order to enable greater participation and development. This approach also gained more visibility among programmers who might want to contribute.<br />
* [http://www.xj3d.org xj3d.org] has hosted the source for many years but development has been intermittent and somewhat less than fully open.<br />
* [https://savage.nps.edu/Savage/developers.html#Xj3D NPS branch of Xj3D] was used for experimental development. Proven changes and unit tests are integrated back into the Xj3D trunk when stable.<br />
<br />
'''Direction''': mirroring the full xj3d.org site on [https://sourceforge.net/projects/xj3d SourceForge Xj3D project] is the group's best approach to meet group goals for unveiling and evangelizing Xj3D community opportunities at Web3D 2014 Conference and SIGGRAPH 2014.<br />
<br />
'''Results''': The codebase has been re-established at [http://sourceforge.net/projects/xj3d Xj3D Sourceforge project]<br />
* [http://sourceforge.net/p/xj3d/code/HEAD/tree Xj3D Sourceforge codebase] without change (and with total prior code history) was made publicly available 8 August 2014<br />
* Initial build tests satisfactory for both NPS branch and original Yumetech trunk.<br />
<br />
Decision rationale follows for choice of source archive site.<br />
<br />
=== SourceForge ===<br />
<br />
* The current xj3d.org code is in subversion, this can be migrated completely<br />
* Web3D already has numerous assets checked into the [https://sourceforge.net/projects/x3d Sourceforge X3D project], it is available<br />
* Sourceforge also has related projects for [https://sourceforge.net/projects/jgeom jgeom] and [https://sourceforge.net/projects/open-dis open-dis]<br />
* Multiple participants have experience with using and administering the Sourceforge site<br />
* Instead of using the Web3D X3D project, can Web3D instead create a new and separate Sourceforge project for Xj3D to keep things a bit simpler?<br />
* Can the new site maintain a side-by-side mirror of Xj3D.org and an refactored trunk, so that all updates are reliably accessible?<br />
* Can the new site keep a new trunk adjacent but separate so that new developers can get started quickly?<br />
* There is a lot of merit to using a version-control system that is familiar, especially as we try to integrate other Xj3D variants and prepare for SIGGRAPH milestones.<br />
<br />
=== GitHub ===<br />
<br />
* GitHub includes the X3DOM project and a few other X3D-related projects.<br />
* We have reserved an [https://github.com/x3d X3D Xj3D] project site on GitHub as a placeholder. This might be useful for cross-links and future evolution.<br />
* The [https://github.com/pricing github pricing policy] does not cost money to operate an open-source organizational repository.<br />
* We are looking at migration of subversion to git.. appears possible but somewhat involved.<br />
* If we do migrate to GitHub, that will likely complicate the re-integration of other existing subversion-based exports of Xj3D.<br />
<br />
=== Maven ===<br />
<br />
* [http://maven.apache.org Apache Maven] can encourage a variety of build possibilities and paired support between multiple projects, especially for Java. Who has some experience, or wants to experiment, with adding it?<br />
<br />
== Web3D.org Website ==<br />
Several project builds are maintained on external repositories but their corresponding websites are automatically built and updated on [http://www.web3d.org web3d.org]<br />
<br />
=== Web3D summary page ===<br />
<br />
* TODO: have ''www.web3d.org/xj3d'' (or somesuch) provide an official summary page for Xj3D community on new web3d.org website<br />
* TODO: find and cleanup or move other wiki pages for Xj3D - somewhat gated by difficulties with web3d.org wiki.<br />
<br />
=== Mailing list considerations ===<br />
<br />
Web3D Consortium maintains the mailing list archives.<br />
* Discussion list ''[http://web3d.org/mailman/listinfo/source_web3d.org source@web3D.org]'' seems to be a misnomer, perhaps it should be restarted as ''xj3d@web3d.org''<br />
* This list is also used for discussions on the SourceForge [https://sourceforge.net/projects/jgeom/?source=directory jgeom] project, so perhaps the current name is actually OK<br />
* Commits list ''[http://web3d.org/mailman/listinfo/source_web3d.org source_x3d_cvs@web3d.org]'' and commits account ''[http://web3d.org/mailman/listinfo/source_web3d.org cvs-user@xj3d.org]'' are also mis-named since subversion is used<br />
<br />
Another alternative option:<br />
* Move all discussion and reporting lists to the sourceforge repository in order to maximize community productivity. In that case, the prior email lists are simply closed and kept archived, which also reduces the web3d.org administrative burden.<br />
<br />
Resolution: we maintained stability with the ''[http://web3d.org/mailman/listinfo/source_web3d.org source@web3D.org]'' list.<br />
<br />
== TODO: Opportunities and upcoming tasks ==<br />
<br />
=== Merge orphaned Xj3D codebases ===<br />
<br />
Separate projects have made excellent improvements to Xj3D over the years, but were never re-integrated into the master code base. We hope to capture, merge and test these improvements in version control, and then issue a series of new releases.<br />
* NPS has maintained an [https://savage.nps.edu/Savage/developers.html#Xj3D Xj3D branch] that is used in multiple tools: X3D-Edit, example archives image generation, AUV Workbench, Viskit<br />
* [http://www.web3d.org/case-studies/structure-and-form-analysis-system-safas/e-learning-and-e-design Structure And Form Analysis System (SAFAS)], Nicholas Polys, Virginia Tech (VT) <br />
* [http://www.partdb.com PartDB Inc.], Hyokwang Lee, Don Brutzman and Terry Norbraten<br />
* [http://www.aniviza.com/svn/listing.php Aniviza modifications for NASA WorldWind] by Rick Goldberg<br />
* [https://github.com/Norkart/NK-VirtualGlobe Norkart/NK-VirtualGlobe], Rune Aasgaard<br />
* Others?<br />
<br />
Please [mailto:source@web3d.org,brutzman@nps.edu,tdnorbra@nps.edu?subject=Xj3D%20inquiry contact us] if you have source code to integrate into the Xj3D project.<br />
<br />
=== Xj3D issue tracking ===<br />
<br />
Currently two bugzilla sites are in existence. They need to be merged and become active.<br />
* [http://bugzilla.xj3d.org bugzilla.xj3d.org] (master)<br />
* [https://www.movesinstitute.org/bugzilla/buglist.cgi?quicksearch=xj3d NPS bugzilla] <br />
<br />
TODO: for maximum reliability over long term, we need to migrate to the SourceForge tickets tracker. Past bugs and issues can be transcribed as appropriate to maintain historical rationales.<br />
<br />
=== Xj3D website improvements ===<br />
<br />
The orginal [http://www.xj3d.org Xj3D website] is moderately complete but woefully out of date. <br />
<br />
TODO website migration: <br />
* Confirm that website pages and documentation are checked into version control<br />
* Automate website updates by synchronizing with version control<br />
* Offer ways for people to contribute bug reports, issues, improvements<br />
<br />
=== Programming problems ===<br />
<br />
Several areas of Xj3D implementation are problematic. Dedicated attention and teamwork may help.<br />
* Better run-time exception reporting (most log entries are completely obscure)<br />
* Confirm updated jogl rendering is working, especially z-buffer and aliasing<br />
* Extrusion node support for orientation field (overall passes 7 of 10 tests)<br />
* Image rendering timing can miss colors/textures and hangs on numerous examples<br />
* Compressed binary encoding hangs on numerous examples, but the apparent list of exception errors seems short<br />
* Ensure that we are keeping current with [http://jogamp.org JOGAMP] (formerly java.net JOGL, includes JOAL JOCL etc.) and the [http://aviatrix3d.j3d.org Aviatrix3D] render layer ([https://github.com/j3d/aviatrix3d github]), administered by Justin Couch<br />
* FontStyle implementation is incorrect. See example [http://www.web3d.org/x3d/content/examples/ConformanceNist/Appearance/FontStyle/_pages/page01.html FontStyle/default]<br />
<br />
Other project efforts are always welcome.<br />
* [https://savage.nps.edu/X3D-Edit X3D-Edit] update report<br />
* Automatic creation of viewpoint images for all scenes in the [http://www.web3d.org/x3d/content/examples/X3dResources.html#Examples X3D Examples] archives<br />
<br />
All inputs and contributions are welcome. Have fun with Xj3D!</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_version_4.0_Development&diff=9746X3D version 4.0 Development2019-02-28T19:26:35Z<p>Webmaster: Reverted edits by Webmaster (talk) to last revision by Brutzman</p>
<hr />
<div>[http://www.web3d.org/x3d4 X3D Version 4] is a major upgrade to the Extensible 3D (X3D) Graphics International Standard that aligns with the HTML5 Recommendation. This is major work in progress, expected to include several future versions. This effort is driven by the X3D Graphics Working Group with regular community outreach.<br />
<br />
==Genesis and Strategic Overview==<br />
<br />
Web3D Consortium working groups currently define specification goals and requirements. Working group efforts are often the focus for defining and testing new X3D components.<br />
<br />
We publicly review these goals annually during [http://web3dconference.org/ Web3D Conference] and [http://www.siggraph.org/attend/annual-conferences SIGGRAPH] Birds of a Feather (BOF) meetings ([http://www.web3d.org/event/siggraph-2016-conference-colocated-web3d-2016-anaheim-california SIGGRAPH 2016], upcoming SIGGRAPH 2017).<br />
<br />
Suggestions, development and discussion via the [http://web3d.org/mailman/listinfo/x3d-public_web3d.org x3d-public mailing list] is ongoing.<br />
<br />
X3D version 3.4 Development efforts were evolutionary improvements to the widely proven X3D Graphics architecture. Consortium members decided to skip version 3.4 and go straight to version 4.0, prior goals and requirements have all been merged here.<br />
<br />
The [http://www.web3d.org/wiki/index.php?title=X3D_version_4.0_Development#Candidate_Capabilities Candidate Capabilities] list shows that a lot of interesting capabilities have been proposed and are under way for X3D version 4. However, topics on this list are not guaranteed to be completed! Rather these are all works in progress.<br />
<br />
Activity and approval proceeds based on technical contributions and Web3D Consortium Member priorities. Please consider [http://web3d.org/membership/join joining Web3D Consortium] to help advance 3D graphics on the Web.These X3D version 4.0 Development efforts are considering potentially major additions to the baseline X3D architecture.<br />
<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_HTML5 HTML5], [http://www.w3.org/community/declarative3d/ Declarative 3D], CSS, [http://www.x3dom.org X3DOM] (see [http://web3d.org/wiki/images/f/f2/X3DOM_4_WebGL_audience_10_2013.pdf Summary slides (Oct 2013)]), and [http://titania.create3000.de/cobweb/ Cobweb]<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_Augmented_Reality Mixed and Augmented Reality (MAR)] (renamed from Augmented Reality Continuum (ARC)<br />
* Relaxing prior design constraints can enable a broader new basis for X3D integration<br />
* Normalizing interaction semantics with HTML5 can further open up X3D for the vast majority of Web authors<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered. X3D Futures planning is primarily a Web3D Consortium member-only activity, with community input.<br />
<br />
== Legacy Issues ==<br />
<br />
We plan to confirm the existence of complete capabilities for X3D v3.3 prior to final approval of X3D version 4.<br />
<br />
* Full support for all existing X3D v3.3 components:<br />
** At least two compatible implementations (including at least one in open source) plus repeatable example scenes<br />
** Layer, ParticleSystems, RigidBodyPhysics, Shaders, TODO others<br />
** TransformSensor node: [http://doc.instantreality.org/documentation/nodetype/TransformSensor/ IGD] and [http://www.parallelgraphics.com/developer/products/cortona/extensions/transformsensor/ old Cortona]<br />
** Note that it is not a requirement that all features and capabilities in X3D V3.3 are included in V4.0<br />
<br />
* Is it necessary for Layout component to be deprecated or improved?<br />
* Are there other features or capabilities that should not or are not able to move into V4.0?<br />
<br />
== Candidate Capabilities ==<br />
<br />
Each of the following possibilities for X3D version 4 have been discussed by the various X3D working groups during meetings and on mailing lists.<br />
Each potential capability is considered to be a feasible (and in most cases, straightforward) addition to the existing X3D version 3.3 architecture.<br />
<br />
*'''Appearance'''<br />
**'''Images''': recommended formats for imagery and video (.gif .bmp .flv .exr .hdr etc.) - details below:<br />
***'''GIF''': [http://www.w3.org/Graphics/GIF/spec-gif89a.txt "Graphics Interchange Format, Version 89a"], W3C. 31 July 1990.<br />
***'''BMP''': [https://en.wikipedia.org/wiki/BMP_file_format BMP]. Note: Originally developed by Microsoft for OS/2 and Windows.<br />
***'''FLV''': <span style="text-decoration: line-through;">[http://download.macromedia.com/f4v/video_file_format_spec_v10_1.pdf FLV and F4V] usage has been deprecated by browser manufacturers.</span><br />
***'''EXR''': [http://www.openexr.com/openexrfilelayout.pdf EXR file layout], developed as OpenEXR by Industrial light and magic (ILM). This requires HDR (see below).<br />
***'''Khronos Texture Format (KTX)''': Khronos [https://www.khronos.org/opengles/sdk/tools/KTX KTX File Format]<br />
***'''QR codes''': [http://en.wikipedia.org/wiki/QR_code QR codes], while useful in Mixed Augmented Reality (MAR) applications, are a content representation and not a file format.<br />
***'''attributes''': width_changed, height_changed, aspectRatio_changed with accessType outputOnly<br />
**'''SVG''': Possible use of SVG for image generation on the fly. Images could be static or dynamic. See [https://www.w3.org/Graphics/ W3C Graphics on the web].<br />
**'''Materials''': advanced parameters<br />
**'''HDR''': Improvements in both materials and rendering for high definition rendering (HDR) technological advances.<br />
**[[X3D Multitexture | Multitexture]]: review for correctness, completeness and conformance of rendering example scenes<br />
**'''Rendering''': bump maps, [http://doc.instantreality.org/tutorial/dynamic-shadows/ shadows], edge smoothing, gamma correction, Non-Photorealistic Rendering (NPR)<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/shaders.html Shaders]: improved support and better interoperability, library of examples; [http://doc.instantreality.org/documentation/nodetype/CommonSurfaceShader/ CommonSurfaceShader?]<br />
**'''Texturing''': [http://en.wikipedia.org/wiki/Texture_atlas Texture atlas], [http://en.wikipedia.org/wiki/Projective_texture_mapping projective texture mapping (PTM)], [http://www.xj3d.org/extensions/render_texture.html RenderedTexture node] for multipass rendering - 2D texture version of GeneratedCubeMapTexture, first proposed by Xj3D and also implemented in X3DOM and InstantReality, useful for all kinds of NPR, shadows, mirrors, etc. Also review 8-bit vs 24-bit texture application differences - see https://castle-engine.sourceforge.io/x3d_multi_texturing.php#section_default_texture_mode.<br />
**'''Chroma key''' for TextureProperties node to support special transparent background.<br />
*'''Audio and video''': alignment with [https://www.w3.org/2011/audio W3C Audio Working Group], especially for [https://webaudio.github.io/web-audio-api Web Audio API] and [https://webaudio.github.io/web-midi-api Web Midi API].<br />
**''Considerations.'' Adding royalty-free formats, streamability, [http://web3d.org/pipermail/x3d-public_web3d.org/2013-December/002681.html disabling attenuation], 3D aural spatialization using reflection from simple geometry (such as [http://gamma.cs.unc.edu/Sound/RESound RESOUND]).<br />
**''Point paper.'' [http://www.web3d.org/specifications/X3Dv4StrategiesToImproveSoundComponent.pdf Strategies to Improve X3D v4 Sound Component] for 3D sound model and audio rendering<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/computer-aided-design-cad Computer Aided Design (CAD)]''' Interactive Profile, to include:<br />
**[http://www.web3d.org/wiki/index.php/X3D_v4.0_CAD_Improvements X3D v4.0 CAD Improvements] with 3D printing + 3D scanning included<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/CADInterchange.html CADInterchange profile] plus FillProperties/LineProperties, primitive/Geometry2D nodes, Extrusion, NURBS, ClipPlane<br />
**Part selection/animation, 3D printing, [http://www.web3d.org/realtime-3d/news/3d-graphics-compress-call-contributions Compressed Binary Encoding (CBE)], possibly [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html annotations component]<br />
** Building Information Models (BIM), Architecture Engineering Construction (AEC), Physical Sensors<br />
*'''[http://www.ecma-international.org/publications/standards/Ecma-262.htm ECMAScript]''' (Javascript) specification revision compatibility with [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html ECMAScript encoding]; possibly add C# or Python support. Note that minor changes in the current X3D Script node might be needed to enable full integration into HTML/DOM.<br />
*'''Events'''<br />
** Review X3D event interoperability with other event models, such as Document Object Model (DOM) Recommendations<br />
** Add capability for Event logging and playback so that deterministic replay is possible for demonstrations and debugging<br />
*'''Generalized input/output interface support'''<br />
** Possibly [http://www.cs.unc.edu/Research/vrpn/index.html Virtual Reality Peripheral Network (VRPN)], gesture recognition (such as [http://en.wikipedia.org/wiki/Kinect KINECT], [http://www.leapmotion.com LEAP]), etc.<br />
** Support for arbitrary sensors and user interaction devices<br />
* '''Geometry'''<br />
** PointSet point size, PointProperties (pointsprites), and associated Normal vectors; Octrees<br />
** 3D Extruded Text<br />
** Support for [http://en.wikipedia.org/wiki/Web_typography Web typography] using [http://www.w3.org/TR/WOFF Web Open Fonts Format (WOFF)]<br />
** Progressive meshes (suitable for both compression and streaming)<br />
** Support for direct loading of compressed [https://x3dom.org/src Shape Resource Container (SRC)] and [https://www.x3dom.org/examples/externalshape-with-gltf-binary-glb ExternalShape] from Fraunhofer<br />
** Direct loading of other geometry meshes such as [https://en.wikipedia.org/wiki/STL_(file_format) STL] and [https://en.wikipedia.org/wiki/PLY_(file_format) PLY]<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/x3d-earth Geospatial X3D]''' component<br />
** [http://www.igraphics.com/Standards/EnhancedGeospatialComponent_2007_10_30/Part01/X3D.html Enhanced Geospatial Component - spatial reference frame (SRF)] and [http://www.opengeospatial.org/standards/kml KML] support, [http://www.opengeospatial.org/projects/initiatives/3dpie OGC 3D Portrayal], [http://web3d.org/pipermail/x3d-public_web3d.org/2010-December/001187.html GpsSensor], [http://openlayers.org OpenLayer] mashups<br />
** GeoSet collection of adjacent GeoElevationGrid nodes to enable proper computation of normals for edge boundaries of adjacent grids<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/h-anim Humanoid Animation (H-Anim)]''' anatomical correctness for skeleton and skinning, motion capture (mocap) and playback, interchangeable avatars, animation for hands feet and faces<br />
* '''Interoperability''': include ''class'' attribute for all nodes to all encodings<br />
* '''[http://www.json.org JSON]''': JavaScript Object Notation as an X3D encoding ([http://web3d.org/pipermail/x3d-public_web3d.org/2014-July/thread.html#2854 assessment thread]), relation to [http://www.khronos.org/gltf GlTF], streaming considerations<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/medx3d Medical working group]''' ImageTextureAtlas plus capabilities including recent Community Improvements to the Volume Component (Aberlaiz et al 2018 [https://dl.acm.org/citation.cfm?id=3075945], and MPR)<br />
** [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html Annotations component] and metadata usage<br />
** Archival 3D medical records, potential emphasis on [http://en.wikipedia.org/wiki/Traumatic_brain_injury Traumatic brain injury (TBI)] volume visualization<br />
** Haptics component for force feedback; [http://www.w3.org/TR/vibration W3C Vibrations API] for tactile feedback<br />
** Soft-body physics component to complement rigid-body physics component<br />
* '''Mobile Profile.''' TODO - needed? Calling out a reduced palette for mobile devices remains interesting, but might instead remain a browser-optional optimization.<br />
* '''[http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#Nodereference Metadata]''': support for embedding information useful for applications utilizing X3D<br />
** Enumerated types: better access, typing, naming, and validation than using MetadataSet/MetadataString combinations<br />
* '''Mixed and Augmented Reality (MAR)''': follow ISO MAR Reference Model, integrate multiple capabilities with devices situated in real world<br />
*'''Networking''': consider [http://www.web3d.org/x3d/content/examples/Basic/Networking NetworkSensor] and event-passing issues, streaming using [http://www.json.org JSON], server-side 3D topics<br />
*'''Security and privacy''':<br />
** Include X3D Networking Component Level 4 support for https in Immersive, Interactive and other commonly used profiles<br />
** Review X3D specifications to ensure that Security Considerations are fully documented throughout in every component<br />
** [http://www.w3.org/standards/xml/security XML Security] provides best-available encryption, digital signature (authentication)<br />
** [http://www.w3.org/standards/webdesign/privacy Web Privacy]: examine X3D compatibility with Do Not Track, P3P, POWDER<br />
*'''Viewing and navigation''': [http://www.web3d.org/x3d/content/examples/Basic/development/CameraExamplesIndex.html cinematic camera control], alternative navigation types (such as PAN, [http://www.x3dom.org/?p=3536 TURNTABLE] etc.), [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/behaviours.html Recommended navigation behaviours] review, and old MatrixTransform node (esp. useful for CAD, VR/AR etc., implemented in X3DOM and InstantReality)<br />
*'''Virtual Reality (VR)''': requirements definition needed includes viewing with stereo devices, interocular distance, frame-rate requirements, comparison (and potential profile) for [https://webvr.info WebVR] capabilities, physiological considerations, health and safety, relation with Mixed Augmented Reality (MAR), etc.<br />
<br />
All suggestions and recommendations are welcome. Component improvements and additions are approved by Web3D Consortium members.<br />
<br />
* TODO: Which experimental nodes are ready? Candidates include [http://doc.instantreality.org Fraunhofer], X3DOM, Cobweb, other members and working groups?<br />
* TODO: articulate Big Data and Cloud, server-side visualization, related issues.<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered.<br />
<br />
== Backwards and Forwards Compatibility ==<br />
<br />
A major benefit of using the X3D standard is full backwards compatibility with prior VRML97 and X3D content.<br />
Thanks to careful design and insistence on implementation/evaluation, the X3D International Standard has maintained both steady growth and interoperability ever since Virtual Reality Modeling Language (VRML) in 1997. This track record of stability and innovation is among the best in the 3D graphics industry.<br />
<br />
Our goal is to maximize, but not necessarily require, backwards compatibility in version 4.0 with the version 3.x specifications<br />
* A great majority of X3D nodes and features are likely achievable without change<br />
* Some X3D features may require import/export conversion for compatibility (event model reconciliation, ROUTEs and sensors perhaps)<br />
* A few features might be refactored, deprecated or obsoleted (none yet identified)<br />
* Name deconfliction: HTML Script versus embedded X3D Script<br />
<br />
The comprehensive forward compatibility of VRML97 and X3D with later-developed X3D versions shows that careful anticipatory design is achievable.<br />
<br />
X3D version 4.0 Development efforts are currently focused on HTML5, Declarative 3D, X3DOM, and Cobweb with many more issues under consideration.<br />
* Discussion of [[Importing and adding nodes in HTML]]<br />
<br />
X3D Version 4.1 is focused on Mixed and Augmented Reality (MAR) capabilities, which may also require architectural changes. Some new technologies may get pushed from 4.0 to 4.1 (or back again) after careful consideration by the respective working groups.<br />
<br />
Related specification support and changes<br />
*As with all other X3D components, all work is defined in the abstract specification has corresponding file encodings (.x3d .x3dv .x3db) and language bindings (ECMAScript and Java). <br />
*Compatibility concerns include evolutionary efforts to upgrade the X3D Compressed Binary Encoding (CBE), as described in the [http://www.web3d.org/realtime-3d/working-groups/x3d/compressed-binary/x3d-compressed-binary-encoding-call-contributions X3D Compressed Binary Encoding Call For Contributions].<br />
*ECMAScript (JavaScript) support in X3D needs to be upgraded to the new standard for that rapidly improving programming language.<br />
**[http://standards.iso.org/ittf/PubliclyAvailableStandards/c055755_ISO_IEC_16262_2011(E).zip ISO/IEC 16262:2011 Information technology — ECMAScript language specification] (.zip download)<br />
**Downloadable from [http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html ISO Publicly Available Standards] site without charge<br />
**This relates to [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html 19777-1 Part 2, X3D Scene Access Interface (SAI) language bindings for EcmaScript]<br />
<br />
== Architectural Considerations ==<br />
<br />
This section will synopsize significant differences between X3D version 4 and X3D version 3 that may require structural changes in tools and scenes. Special attention is needed to minimize incompatibilities with legacy software and content.<br />
<br />
Much depends on the target environment. X3D V3.x presumes a controlled environment that interacts with the rest of the (computing) world through a well defined API (called SAI). When X3D is running in the browser (as in fully integrated with the DOM), the DOM defines a portion of the environment in which X3D must operate. For that environment it will be necessary to make changes to X3D so that it is compatible with the DOM.<br />
<br />
== Open Questions ==<br />
<br />
* Are MAR abstract design and X3D AR proposals sufficiently mature to enable integration with HTML5/Declarative 3D/X3DOM/Cobweb issues?<br />
* Are the previously X3D Layer/Layering components compatible with HTML5 overlay model? Are they still needed, perhaps for multiscreen or CAVE support?<br />
* Mashup and interoperability support: is anything else needed for broader use with the Web? YouTube etc.<br />
<br />
== Related Work==<br />
<br />
Much careful planning is involved, we are working to ensure that X3D version 4 can be coherently advanced in combination with a [http://www.web3d.org/specifications/X3dSpecificationRelationships.png coordinated set of steadily evolving ISO/IEC standards].<br />
*'''X3D Efficient Binary Encoding (EBE).''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings. See also SRC format (Web3D 2014)and ExternalGeometry node in InstantPlayer and X3DOM<br />
*'''X3D JavaScript Object Notation (JSON) Encoding.''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings.<br />
*'''X3D version 4.0 (HTML5/X3D DOM)'''. This work is proceeding in parallel. X3D version 4 support is expected.<br />
*'''X3D version 4.1 (Mixed and Augmented Reality)'''. Nodes and capabilities in this arena will build on v4.0 and HTML5. Experimentation, evolution and evaluation occurs throughout.<br />
** '''[[Essential Elements of X3D]]''' collects elements that are essential to X3D<br />
<br />
Technologies and activities that relate to X3D version 4 are: <br />
* [https://webvr.info/ '''WebVR'''] "bringing virtual reality to the web" - standardize the interface to VR displays and controllers <br />
* [https://www.w3.org/community/decwebvr/ '''W3C's Declarative WebVR Community Group'''] formed to developed a declarative 3D standard for WebVR<br />
* [https://threejs.org/ '''three.js'''], a JavaScript library<br />
* [https://aframe.io/ '''A-Frame'''] "a web framework for building virtual reality experiences"<br />
* [http://xml3d.org/ '''XML3D'''] " seamless integration of 3D content into HTML pages"<br />
<br />
== Schedule ==<br />
<br />
'''ISO Considerations'''<br />
* Deciding readiness for ISO New Work Item Proposal (NWIP): we need Committee Draft (CD) specification prose for each planned capability.<br />
* Web3D Consortium is not locked into an annual schedule, ISO handling is flexible.<br />
* Once the NWIP is approved, ISO rules for schedule and review are established.<br />
<br />
'''Execution goals'''<br />
* Review progress during monthly calls, Web3D Conference, and SIGGRAPH Conference.<br />
* We are continuing a monthly review schedule for submissions so that we can build out X3D version 4 one component at a time.<br />
* We are planning to have a 1-year deadline for completion of CD specification prose, rather than wait until all possible version 4 work is ready.<br />
* Web3D Consortium members and public review when a final draft specification is ready to proceed to ISO.<br />
* Any new components not meeting Web3D deadlines might be a candidate for deferral to V4.1. Or considered not ready.<br />
<br />
'''Progress'''<br />
<br />
* Active development of X3D, X3DOM and Cobweb content is tracking HTML 5 capabilities now<br />
* We participate and contribute to the W3C Community Group for [http://www.w3.org/community/declarative3d Declarative 3D]</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_version_4.0_Development&diff=9745X3D version 4.0 Development2019-02-28T19:26:11Z<p>Webmaster: Test of Save capability</p>
<hr />
<div>[http://www.web3d.org/x3d4 X3D Version 4] is a major upgrade to the Extensible 3D (X3D) Graphics International Standard that aligns with the HTML5 Recommendation. This is major work in progress, expected to include several future versions. This effort is driven by the X3D Graphics Working Group with regular community outreach.<br />
..Minor Page Edit..<br />
<br />
==Genesis and Strategic Overview==<br />
<br />
Web3D Consortium working groups currently define specification goals and requirements. Working group efforts are often the focus for defining and testing new X3D components.<br />
<br />
We publicly review these goals annually during [http://web3dconference.org/ Web3D Conference] and [http://www.siggraph.org/attend/annual-conferences SIGGRAPH] Birds of a Feather (BOF) meetings ([http://www.web3d.org/event/siggraph-2016-conference-colocated-web3d-2016-anaheim-california SIGGRAPH 2016], upcoming SIGGRAPH 2017).<br />
<br />
Suggestions, development and discussion via the [http://web3d.org/mailman/listinfo/x3d-public_web3d.org x3d-public mailing list] is ongoing.<br />
<br />
X3D version 3.4 Development efforts were evolutionary improvements to the widely proven X3D Graphics architecture. Consortium members decided to skip version 3.4 and go straight to version 4.0, prior goals and requirements have all been merged here.<br />
<br />
The [http://www.web3d.org/wiki/index.php?title=X3D_version_4.0_Development#Candidate_Capabilities Candidate Capabilities] list shows that a lot of interesting capabilities have been proposed and are under way for X3D version 4. However, topics on this list are not guaranteed to be completed! Rather these are all works in progress.<br />
<br />
Activity and approval proceeds based on technical contributions and Web3D Consortium Member priorities. Please consider [http://web3d.org/membership/join joining Web3D Consortium] to help advance 3D graphics on the Web.These X3D version 4.0 Development efforts are considering potentially major additions to the baseline X3D architecture.<br />
<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_HTML5 HTML5], [http://www.w3.org/community/declarative3d/ Declarative 3D], CSS, [http://www.x3dom.org X3DOM] (see [http://web3d.org/wiki/images/f/f2/X3DOM_4_WebGL_audience_10_2013.pdf Summary slides (Oct 2013)]), and [http://titania.create3000.de/cobweb/ Cobweb]<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_Augmented_Reality Mixed and Augmented Reality (MAR)] (renamed from Augmented Reality Continuum (ARC)<br />
* Relaxing prior design constraints can enable a broader new basis for X3D integration<br />
* Normalizing interaction semantics with HTML5 can further open up X3D for the vast majority of Web authors<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered. X3D Futures planning is primarily a Web3D Consortium member-only activity, with community input.<br />
<br />
== Legacy Issues ==<br />
<br />
We plan to confirm the existence of complete capabilities for X3D v3.3 prior to final approval of X3D version 4.<br />
<br />
* Full support for all existing X3D v3.3 components:<br />
** At least two compatible implementations (including at least one in open source) plus repeatable example scenes<br />
** Layer, ParticleSystems, RigidBodyPhysics, Shaders, TODO others<br />
** TransformSensor node: [http://doc.instantreality.org/documentation/nodetype/TransformSensor/ IGD] and [http://www.parallelgraphics.com/developer/products/cortona/extensions/transformsensor/ old Cortona]<br />
** Note that it is not a requirement that all features and capabilities in X3D V3.3 are included in V4.0<br />
<br />
* Is it necessary for Layout component to be deprecated or improved?<br />
* Are there other features or capabilities that should not or are not able to move into V4.0?<br />
<br />
== Candidate Capabilities ==<br />
<br />
Each of the following possibilities for X3D version 4 have been discussed by the various X3D working groups during meetings and on mailing lists.<br />
Each potential capability is considered to be a feasible (and in most cases, straightforward) addition to the existing X3D version 3.3 architecture.<br />
<br />
*'''Appearance'''<br />
**'''Images''': recommended formats for imagery and video (.gif .bmp .flv .exr .hdr etc.) - details below:<br />
***'''GIF''': [http://www.w3.org/Graphics/GIF/spec-gif89a.txt "Graphics Interchange Format, Version 89a"], W3C. 31 July 1990.<br />
***'''BMP''': [https://en.wikipedia.org/wiki/BMP_file_format BMP]. Note: Originally developed by Microsoft for OS/2 and Windows.<br />
***'''FLV''': <span style="text-decoration: line-through;">[http://download.macromedia.com/f4v/video_file_format_spec_v10_1.pdf FLV and F4V] usage has been deprecated by browser manufacturers.</span><br />
***'''EXR''': [http://www.openexr.com/openexrfilelayout.pdf EXR file layout], developed as OpenEXR by Industrial light and magic (ILM). This requires HDR (see below).<br />
***'''Khronos Texture Format (KTX)''': Khronos [https://www.khronos.org/opengles/sdk/tools/KTX KTX File Format]<br />
***'''QR codes''': [http://en.wikipedia.org/wiki/QR_code QR codes], while useful in Mixed Augmented Reality (MAR) applications, are a content representation and not a file format.<br />
***'''attributes''': width_changed, height_changed, aspectRatio_changed with accessType outputOnly<br />
**'''SVG''': Possible use of SVG for image generation on the fly. Images could be static or dynamic. See [https://www.w3.org/Graphics/ W3C Graphics on the web].<br />
**'''Materials''': advanced parameters<br />
**'''HDR''': Improvements in both materials and rendering for high definition rendering (HDR) technological advances.<br />
**[[X3D Multitexture | Multitexture]]: review for correctness, completeness and conformance of rendering example scenes<br />
**'''Rendering''': bump maps, [http://doc.instantreality.org/tutorial/dynamic-shadows/ shadows], edge smoothing, gamma correction, Non-Photorealistic Rendering (NPR)<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/shaders.html Shaders]: improved support and better interoperability, library of examples; [http://doc.instantreality.org/documentation/nodetype/CommonSurfaceShader/ CommonSurfaceShader?]<br />
**'''Texturing''': [http://en.wikipedia.org/wiki/Texture_atlas Texture atlas], [http://en.wikipedia.org/wiki/Projective_texture_mapping projective texture mapping (PTM)], [http://www.xj3d.org/extensions/render_texture.html RenderedTexture node] for multipass rendering - 2D texture version of GeneratedCubeMapTexture, first proposed by Xj3D and also implemented in X3DOM and InstantReality, useful for all kinds of NPR, shadows, mirrors, etc. Also review 8-bit vs 24-bit texture application differences - see https://castle-engine.sourceforge.io/x3d_multi_texturing.php#section_default_texture_mode.<br />
**'''Chroma key''' for TextureProperties node to support special transparent background.<br />
*'''Audio and video''': alignment with [https://www.w3.org/2011/audio W3C Audio Working Group], especially for [https://webaudio.github.io/web-audio-api Web Audio API] and [https://webaudio.github.io/web-midi-api Web Midi API].<br />
**''Considerations.'' Adding royalty-free formats, streamability, [http://web3d.org/pipermail/x3d-public_web3d.org/2013-December/002681.html disabling attenuation], 3D aural spatialization using reflection from simple geometry (such as [http://gamma.cs.unc.edu/Sound/RESound RESOUND]).<br />
**''Point paper.'' [http://www.web3d.org/specifications/X3Dv4StrategiesToImproveSoundComponent.pdf Strategies to Improve X3D v4 Sound Component] for 3D sound model and audio rendering<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/computer-aided-design-cad Computer Aided Design (CAD)]''' Interactive Profile, to include:<br />
**[http://www.web3d.org/wiki/index.php/X3D_v4.0_CAD_Improvements X3D v4.0 CAD Improvements] with 3D printing + 3D scanning included<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/CADInterchange.html CADInterchange profile] plus FillProperties/LineProperties, primitive/Geometry2D nodes, Extrusion, NURBS, ClipPlane<br />
**Part selection/animation, 3D printing, [http://www.web3d.org/realtime-3d/news/3d-graphics-compress-call-contributions Compressed Binary Encoding (CBE)], possibly [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html annotations component]<br />
** Building Information Models (BIM), Architecture Engineering Construction (AEC), Physical Sensors<br />
*'''[http://www.ecma-international.org/publications/standards/Ecma-262.htm ECMAScript]''' (Javascript) specification revision compatibility with [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html ECMAScript encoding]; possibly add C# or Python support. Note that minor changes in the current X3D Script node might be needed to enable full integration into HTML/DOM.<br />
*'''Events'''<br />
** Review X3D event interoperability with other event models, such as Document Object Model (DOM) Recommendations<br />
** Add capability for Event logging and playback so that deterministic replay is possible for demonstrations and debugging<br />
*'''Generalized input/output interface support'''<br />
** Possibly [http://www.cs.unc.edu/Research/vrpn/index.html Virtual Reality Peripheral Network (VRPN)], gesture recognition (such as [http://en.wikipedia.org/wiki/Kinect KINECT], [http://www.leapmotion.com LEAP]), etc.<br />
** Support for arbitrary sensors and user interaction devices<br />
* '''Geometry'''<br />
** PointSet point size, PointProperties (pointsprites), and associated Normal vectors; Octrees<br />
** 3D Extruded Text<br />
** Support for [http://en.wikipedia.org/wiki/Web_typography Web typography] using [http://www.w3.org/TR/WOFF Web Open Fonts Format (WOFF)]<br />
** Progressive meshes (suitable for both compression and streaming)<br />
** Support for direct loading of compressed [https://x3dom.org/src Shape Resource Container (SRC)] and [https://www.x3dom.org/examples/externalshape-with-gltf-binary-glb ExternalShape] from Fraunhofer<br />
** Direct loading of other geometry meshes such as [https://en.wikipedia.org/wiki/STL_(file_format) STL] and [https://en.wikipedia.org/wiki/PLY_(file_format) PLY]<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/x3d-earth Geospatial X3D]''' component<br />
** [http://www.igraphics.com/Standards/EnhancedGeospatialComponent_2007_10_30/Part01/X3D.html Enhanced Geospatial Component - spatial reference frame (SRF)] and [http://www.opengeospatial.org/standards/kml KML] support, [http://www.opengeospatial.org/projects/initiatives/3dpie OGC 3D Portrayal], [http://web3d.org/pipermail/x3d-public_web3d.org/2010-December/001187.html GpsSensor], [http://openlayers.org OpenLayer] mashups<br />
** GeoSet collection of adjacent GeoElevationGrid nodes to enable proper computation of normals for edge boundaries of adjacent grids<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/h-anim Humanoid Animation (H-Anim)]''' anatomical correctness for skeleton and skinning, motion capture (mocap) and playback, interchangeable avatars, animation for hands feet and faces<br />
* '''Interoperability''': include ''class'' attribute for all nodes to all encodings<br />
* '''[http://www.json.org JSON]''': JavaScript Object Notation as an X3D encoding ([http://web3d.org/pipermail/x3d-public_web3d.org/2014-July/thread.html#2854 assessment thread]), relation to [http://www.khronos.org/gltf GlTF], streaming considerations<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/medx3d Medical working group]''' ImageTextureAtlas plus capabilities including recent Community Improvements to the Volume Component (Aberlaiz et al 2018 [https://dl.acm.org/citation.cfm?id=3075945], and MPR)<br />
** [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html Annotations component] and metadata usage<br />
** Archival 3D medical records, potential emphasis on [http://en.wikipedia.org/wiki/Traumatic_brain_injury Traumatic brain injury (TBI)] volume visualization<br />
** Haptics component for force feedback; [http://www.w3.org/TR/vibration W3C Vibrations API] for tactile feedback<br />
** Soft-body physics component to complement rigid-body physics component<br />
* '''Mobile Profile.''' TODO - needed? Calling out a reduced palette for mobile devices remains interesting, but might instead remain a browser-optional optimization.<br />
* '''[http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#Nodereference Metadata]''': support for embedding information useful for applications utilizing X3D<br />
** Enumerated types: better access, typing, naming, and validation than using MetadataSet/MetadataString combinations<br />
* '''Mixed and Augmented Reality (MAR)''': follow ISO MAR Reference Model, integrate multiple capabilities with devices situated in real world<br />
*'''Networking''': consider [http://www.web3d.org/x3d/content/examples/Basic/Networking NetworkSensor] and event-passing issues, streaming using [http://www.json.org JSON], server-side 3D topics<br />
*'''Security and privacy''':<br />
** Include X3D Networking Component Level 4 support for https in Immersive, Interactive and other commonly used profiles<br />
** Review X3D specifications to ensure that Security Considerations are fully documented throughout in every component<br />
** [http://www.w3.org/standards/xml/security XML Security] provides best-available encryption, digital signature (authentication)<br />
** [http://www.w3.org/standards/webdesign/privacy Web Privacy]: examine X3D compatibility with Do Not Track, P3P, POWDER<br />
*'''Viewing and navigation''': [http://www.web3d.org/x3d/content/examples/Basic/development/CameraExamplesIndex.html cinematic camera control], alternative navigation types (such as PAN, [http://www.x3dom.org/?p=3536 TURNTABLE] etc.), [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/behaviours.html Recommended navigation behaviours] review, and old MatrixTransform node (esp. useful for CAD, VR/AR etc., implemented in X3DOM and InstantReality)<br />
*'''Virtual Reality (VR)''': requirements definition needed includes viewing with stereo devices, interocular distance, frame-rate requirements, comparison (and potential profile) for [https://webvr.info WebVR] capabilities, physiological considerations, health and safety, relation with Mixed Augmented Reality (MAR), etc.<br />
<br />
All suggestions and recommendations are welcome. Component improvements and additions are approved by Web3D Consortium members.<br />
<br />
* TODO: Which experimental nodes are ready? Candidates include [http://doc.instantreality.org Fraunhofer], X3DOM, Cobweb, other members and working groups?<br />
* TODO: articulate Big Data and Cloud, server-side visualization, related issues.<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered.<br />
<br />
== Backwards and Forwards Compatibility ==<br />
<br />
A major benefit of using the X3D standard is full backwards compatibility with prior VRML97 and X3D content.<br />
Thanks to careful design and insistence on implementation/evaluation, the X3D International Standard has maintained both steady growth and interoperability ever since Virtual Reality Modeling Language (VRML) in 1997. This track record of stability and innovation is among the best in the 3D graphics industry.<br />
<br />
Our goal is to maximize, but not necessarily require, backwards compatibility in version 4.0 with the version 3.x specifications<br />
* A great majority of X3D nodes and features are likely achievable without change<br />
* Some X3D features may require import/export conversion for compatibility (event model reconciliation, ROUTEs and sensors perhaps)<br />
* A few features might be refactored, deprecated or obsoleted (none yet identified)<br />
* Name deconfliction: HTML Script versus embedded X3D Script<br />
<br />
The comprehensive forward compatibility of VRML97 and X3D with later-developed X3D versions shows that careful anticipatory design is achievable.<br />
<br />
X3D version 4.0 Development efforts are currently focused on HTML5, Declarative 3D, X3DOM, and Cobweb with many more issues under consideration.<br />
* Discussion of [[Importing and adding nodes in HTML]]<br />
<br />
X3D Version 4.1 is focused on Mixed and Augmented Reality (MAR) capabilities, which may also require architectural changes. Some new technologies may get pushed from 4.0 to 4.1 (or back again) after careful consideration by the respective working groups.<br />
<br />
Related specification support and changes<br />
*As with all other X3D components, all work is defined in the abstract specification has corresponding file encodings (.x3d .x3dv .x3db) and language bindings (ECMAScript and Java). <br />
*Compatibility concerns include evolutionary efforts to upgrade the X3D Compressed Binary Encoding (CBE), as described in the [http://www.web3d.org/realtime-3d/working-groups/x3d/compressed-binary/x3d-compressed-binary-encoding-call-contributions X3D Compressed Binary Encoding Call For Contributions].<br />
*ECMAScript (JavaScript) support in X3D needs to be upgraded to the new standard for that rapidly improving programming language.<br />
**[http://standards.iso.org/ittf/PubliclyAvailableStandards/c055755_ISO_IEC_16262_2011(E).zip ISO/IEC 16262:2011 Information technology — ECMAScript language specification] (.zip download)<br />
**Downloadable from [http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html ISO Publicly Available Standards] site without charge<br />
**This relates to [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html 19777-1 Part 2, X3D Scene Access Interface (SAI) language bindings for EcmaScript]<br />
<br />
== Architectural Considerations ==<br />
<br />
This section will synopsize significant differences between X3D version 4 and X3D version 3 that may require structural changes in tools and scenes. Special attention is needed to minimize incompatibilities with legacy software and content.<br />
<br />
Much depends on the target environment. X3D V3.x presumes a controlled environment that interacts with the rest of the (computing) world through a well defined API (called SAI). When X3D is running in the browser (as in fully integrated with the DOM), the DOM defines a portion of the environment in which X3D must operate. For that environment it will be necessary to make changes to X3D so that it is compatible with the DOM.<br />
<br />
== Open Questions ==<br />
<br />
* Are MAR abstract design and X3D AR proposals sufficiently mature to enable integration with HTML5/Declarative 3D/X3DOM/Cobweb issues?<br />
* Are the previously X3D Layer/Layering components compatible with HTML5 overlay model? Are they still needed, perhaps for multiscreen or CAVE support?<br />
* Mashup and interoperability support: is anything else needed for broader use with the Web? YouTube etc.<br />
<br />
== Related Work==<br />
<br />
Much careful planning is involved, we are working to ensure that X3D version 4 can be coherently advanced in combination with a [http://www.web3d.org/specifications/X3dSpecificationRelationships.png coordinated set of steadily evolving ISO/IEC standards].<br />
*'''X3D Efficient Binary Encoding (EBE).''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings. See also SRC format (Web3D 2014)and ExternalGeometry node in InstantPlayer and X3DOM<br />
*'''X3D JavaScript Object Notation (JSON) Encoding.''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings.<br />
*'''X3D version 4.0 (HTML5/X3D DOM)'''. This work is proceeding in parallel. X3D version 4 support is expected.<br />
*'''X3D version 4.1 (Mixed and Augmented Reality)'''. Nodes and capabilities in this arena will build on v4.0 and HTML5. Experimentation, evolution and evaluation occurs throughout.<br />
** '''[[Essential Elements of X3D]]''' collects elements that are essential to X3D<br />
<br />
Technologies and activities that relate to X3D version 4 are: <br />
* [https://webvr.info/ '''WebVR'''] "bringing virtual reality to the web" - standardize the interface to VR displays and controllers <br />
* [https://www.w3.org/community/decwebvr/ '''W3C's Declarative WebVR Community Group'''] formed to developed a declarative 3D standard for WebVR<br />
* [https://threejs.org/ '''three.js'''], a JavaScript library<br />
* [https://aframe.io/ '''A-Frame'''] "a web framework for building virtual reality experiences"<br />
* [http://xml3d.org/ '''XML3D'''] " seamless integration of 3D content into HTML pages"<br />
<br />
== Schedule ==<br />
<br />
'''ISO Considerations'''<br />
* Deciding readiness for ISO New Work Item Proposal (NWIP): we need Committee Draft (CD) specification prose for each planned capability.<br />
* Web3D Consortium is not locked into an annual schedule, ISO handling is flexible.<br />
* Once the NWIP is approved, ISO rules for schedule and review are established.<br />
<br />
'''Execution goals'''<br />
* Review progress during monthly calls, Web3D Conference, and SIGGRAPH Conference.<br />
* We are continuing a monthly review schedule for submissions so that we can build out X3D version 4 one component at a time.<br />
* We are planning to have a 1-year deadline for completion of CD specification prose, rather than wait until all possible version 4 work is ready.<br />
* Web3D Consortium members and public review when a final draft specification is ready to proceed to ISO.<br />
* Any new components not meeting Web3D deadlines might be a candidate for deferral to V4.1. Or considered not ready.<br />
<br />
'''Progress'''<br />
<br />
* Active development of X3D, X3DOM and Cobweb content is tracking HTML 5 capabilities now<br />
* We participate and contribute to the W3C Community Group for [http://www.w3.org/community/declarative3d Declarative 3D]</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_V4_HTML_Integration_Requirements&diff=9634X3D V4 HTML Integration Requirements2017-08-23T14:38:38Z<p>Webmaster: /* Scripting Examples */ Added examples</p>
<hr />
<div><br />
== Objectives and Strategy ==<br />
<br />
The objective for this page is to describe particular issues and details for close integration of X3D capabilities in HTML5/DOM pages. We are working towards identification of consensus points open issues.<br />
<br />
This work is part of a broad strategy for X3D version 4.<br />
<br />
# [http://www.web3d.org/strategy Web3D Standards Strategy] emphasizes a "fundamental objective is to enable the open publishing of interactive 3D graphics models on the Web, enabling real-time 3D communication. We carefully improve and evolve our Recommended Standards while maintaining long-term archival stability."<br />
# [http://www.web3d.org/x3d4 X3D V4] describes the design strategy of X3D v4.0 for HTML5/DOM integration, and X3D v4.1 Mixed Augmented Reality (MAR). "Next-generation evolution + revolution is combined with archival compatibility of existing legacy content." <br />
# [http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development X3D V4 Development] describes Genesis and Strategic Overview, Legacy Issues, Candidate Capabilities, Backwards and Forwards Compatibility, Architectural Considerations, Open Questions, and Related Work.<br />
<br />
== Boundary conditions ==<br />
<br />
# This is just for X3D running in a web browser and integrated with HTML. This could be expressed as <x3d> ... </x3d> can be treated as a document fragment in the body of an HTML document. If there is X3D outside of this limitation, these requirements may or may not apply.<br />
# Changes to X3D Abstract Specification? I had not gone as far as indicating which changes needed to go where. Obviously new nodes would need to be in the Abstract specification. But even before going there it is necessary to determine what environments X3D will operate in. My limitations are only for a web browser environment. Environments beside that one are not a concern of the requirements I stated. If there are to be other environments than those differences and similarities would need to be worked out.<br />
# Defining an HTML5 Encoding, and perhaps a corresponding HTML5 Profile<br />
<br />
== Notes ==<br />
<br />
# Some of these requirements may overlap by varying amounts. It was easier to specify them this way then trying to make a complete and non-overlapping set. I'm not going to even claim that this is a complete set, but it is a beginning.<br />
# For those that want XHTML, then convert all references to HTML to XHTML and make the appropriate syntax changes. The differences between HTML and XHTML in the appearance of the elements and attributes is that XHTML is strict. This amounts to closing elements, elements and attributes are lower case, mandatory elements and attributes, different MIME type (text/html vs. application/xml or applications/xhtml+xml), and quoted attributes -- see https://www.w3schools.com/html/html_xhtml.asp for details. The WhatWG has a pretty good documentation page on the differences at https://wiki.whatwg.org/wiki/HTML_vs._XHTML.<br />
<br />
== Decisions taken ==<br />
<br />
At the X3D Working Group meeting held 19th July 2017 the following decisions were made:<br />
# The HTML standard to be normatively referenced should be the current W3C HTML recommendation, found at https://www.w3.org/TR/html/. As of the meeting date this is HTML 5.1, dated 1 November 2016.<br />
# As a consequence the DOM specification normatively referenced by the HTML specification can be found at https://www.w3.org/TR/DOM/. This is the W3C recommendation for DOM4, dated 19 November 2015.<br />
# All X3D nodes and statements are defined in the X3D abstract specification. Each encoding shall specify the mapping of each node and statement in the X3D abstract specification to the respective encoding form.<br />
# Each X3D element needs a corresponding DOM interface definition. The form of this is still to be decided.<br />
# X3D element DOM interface definitions will use the same IDL as HTML, namely WebIDL Level 1 defined at https://www.w3.org/TR/WebIDL-1/.<br />
<br />
== Candidate Requirements ==<br />
<br />
=== Looks "like" HTML ===<br />
: Elements (nodes in X3D-speak) shall be case independent<br />
: Attributes (fields in X3D-speak) shall be case independent<br />
: X3D nodes shall not have name conflicts with any HTML-defined elements<br />
:: I believe the HTML5 Custom Elements spec requires a prefix-name format for element names. While allowing lowercase should we also allow 'x3d-transform' format alternative names?<br />
:: In that case, each node would be aliased with a HTML5 Custom Element compatible name.<br />
: All X3D nodes shall support all HTML Global Attributes https://www.w3schools.com/tags/ref_standardattributes.asp<br />
:: Is this equivalent to requiring that X3D nodes need to derive from HTMLElement as defined in the DOM?<br />
: All X3D fields with the same name as HTML attributes shall behave as the HTML element<br />
: TBD: Not all style attributes apply to X3D nodes & fields<br />
<br />
==== Candidate interface definitions for X3DElement ====<br />
Start with the assumption that all X3D elements inherit a common interface, named X3DElement. Two candidate interface definitions are as follows:<br />
<br />
'''Candidate A'''<br />
<br />
interface X3DElement : HTMLElement { } ;<br />
<br />
Using the definition of HTMLElement from the W3C HTML specification, this can be expanded to:<br />
<br />
interface X3DElement : [https://www.w3.org/TR/dom/#interface-element Element] {<br />
// metadata attributes<br />
attribute DOMString [https://html.spec.whatwg.org/multipage/dom.html#dom-title title];<br />
attribute DOMString [https://html.spec.whatwg.org/multipage/dom.html#dom-lang lang];<br />
attribute boolean [https://html.spec.whatwg.org/multipage/dom.html#dom-translate translate];<br />
attribute DOMString [https://html.spec.whatwg.org/multipage/dom.html#dom-dir dir];<br />
[[https://heycam.github.io/webidl/#SameObject SameObject]] readonly attribute [https://www.w3.org/TR/html/infrastructure.html#domstringmap-domstringmap DOMStringMap] [https://html.spec.whatwg.org/multipage/dom.html#dom-dataset dataset];<br />
<br />
// user interaction<br />
attribute boolean [https://html.spec.whatwg.org/multipage/embedded-content.html#dom-texttrack-hidden hidden];<br />
void [https://html.spec.whatwg.org/multipage/interaction.html#dom-click click]();<br />
attribute long [https://html.spec.whatwg.org/multipage/interaction.html#dom-tabindex tabIndex];<br />
void [https://html.spec.whatwg.org/multipage/interaction.html#dom-focus focus]();<br />
void [https://html.spec.whatwg.org/multipage/interaction.html#dom-blur blur]();<br />
attribute DOMString [https://www.w3.org/TR/html/editing.html#dom-htmlelement-accesskey accessKey];<br />
attribute boolean [https://www.w3.org/TR/html/editing.html#dom-htmlelement-draggable draggable];<br />
[[https://heycam.github.io/webidl/#PutForwards PutForwards]=[https://dom.spec.whatwg.org/#dom-domtokenlist-value value]] readonly attribute [https://dom.spec.whatwg.org/#domtokenlist DOMTokenList] [https://www.w3.org/TR/html/editing.html#dom-htmlelement-dropzone dropzone];<br />
attribute [https://www.w3.org/TR/html/interactive-elements.html#htmlmenuelement-htmlmenuelement HTMLMenuElement]? [https://www.w3.org/TR/html/interactive-elements.html#dom-htmlelement-contextmenu contextMenu];<br />
attribute boolean [https://html.spec.whatwg.org/multipage/interaction.html#dom-spellcheck spellcheck];<br />
void [https://html.spec.whatwg.org/multipage/interaction.html#dom-forcespellcheck forceSpellCheck]();<br />
};<br />
<br />
X3DElement implements [https://www.w3.org/TR/html/webappapis.html#globaleventhandlers-globaleventhandlers GlobalEventHandlers];<br />
<br />
X3DElement implements [https://www.w3.org/TR/html/webappapis.html#documentandelementeventhandlers-documentandelementeventhandlers DocumentAndElementEventHandlers];<br />
<br />
X3DElement implements [https://www.w3.org/TR/html/editing.html#elementcontenteditable-elementcontenteditable ElementContentEditable];<br />
<br />
'''Candidate B'''<br />
<br />
Take the SVGElement interface, substituting X3D for all occurrences of SVG.<br />
Note: The original names have been retained in order to include the hyperlinks.<br />
<br />
interface SVGElement : [https://www.w3.org/TR/2014/WD-dom-20140204/#element Element] {<br />
<br />
[SameObject] readonly attribute [https://www.w3.org/TR/SVG2/types.html#InterfaceSVGAnimatedString SVGAnimatedString] [https://www.w3.org/TR/SVG2/types.html#__svg__SVGElement__className className];<br />
[SameObject] readonly attribute [https://www.w3.org/TR/2014/CR-html5-20140204/infrastructure.html#domstringmap DOMStringMap] [https://www.w3.org/TR/SVG2/types.html#__svg__SVGElement__dataset dataset];<br />
readonly attribute [https://www.w3.org/TR/SVG2/struct.html#InterfaceSVGSVGElement SVGSVGElement]? [https://www.w3.org/TR/SVG2/types.html#__svg__SVGElement__ownerSVGElement ownerSVGElement];<br />
readonly attribute [https://www.w3.org/TR/SVG2/types.html#InterfaceSVGElement SVGElement]? [https://www.w3.org/TR/SVG2/types.html#__svg__SVGElement__viewportElement viewportElement];<br />
attribute long [https://www.w3.org/TR/SVG2/types.html#__svg__SVGElement__tabIndex tabIndex];<br />
void [https://www.w3.org/TR/SVG2/types.html#__svg__SVGElement__focus focus]();<br />
void [https://www.w3.org/TR/SVG2/types.html#__svg__SVGElement__blur blur]();<br />
};<br />
<br />
[https://www.w3.org/TR/SVG2/types.html#InterfaceSVGElement SVGElement] implements [https://www.w3.org/TR/2014/CR-html5-20140204/webappapis.html#globaleventhandlers GlobalEventHandlers];<br />
<br />
[https://www.w3.org/TR/SVG2/types.html#InterfaceSVGElement SVGElement] implements [https://www.w3.org/TR/SVG2/struct.html#InterfaceSVGElementInstance SVGElementInstance];<br />
<br />
=== HTML encodings ===<br />
: HTML5 has two encodings, not one. Each consistently maps to DOM. The WG developing corresponding functionality and syntax that supports both encodings will add tremendous value to everyone.<br />
:: HTML5 Recommendation section 8. The HTML syntax https://www.w3.org/TR/html5/syntax.html#syntax<br />
:: HTML5 Recommendation section 9. The XHTML syntax https://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax<br />
: The differences between HTML and XHTML in the appearance of the elements and attributes is that XHTML is strict. This amounts to closing elements, elements and attributes are lower case, mandatory elements and attributes, different MIME type (text/html vs. application/xml or applications/xhtml+xml), and quoted attributes -- see https://www.w3schools.com/html/html_xhtml.asp for details. The WhatWG has a pretty good documentation page on the differences at https://wiki.whatwg.org/wiki/HTML_vs._XHTML. There are differences in scripting. Most of the differences are obvious extensions from XHTML being an XML document. The W3C HTML5 specification (https://www.w3.org/TR/html5/introduction.html#html-vs-xhtml) is consistent with the above comments. All of the formalities aside, from my observations there is very little use of the XHTML document type for regular web pages.<br />
<br />
=== Functions "like" HTML ===<br />
: All nodes shall be fully integrated with the DOM [This may need to change if certain nodes need to remain hidden from the DOM. For example, the manner which X3DOM implements Inline.]<br />
: The scene graph does not need to be DOM (or a portion of it).<br />
:: X3DOM keeps a separate scene graph from the DOM. The rendering occurs from the scene graph. Changes to the DOM cause changes to the scene graph and vice versa.<br />
: Changes to the DOM shall be reflected in the scene graph<br />
: Changes to the scene graph shall be reflected in the DOM<br />
:: Using the DOM to maintain and reflect state is often considered slow. Could this be optional? Changes to the scene graph cause events which can be listened to if required. (This is why cobweb-dom does not reflect back interpolator output to the DOM at this point)<br />
:: Perhaps it is better to set all current fields that are initialized to be (generally) non-updated. If you want to see a particular value, you need to listen to the appropriate event. Certain events would cause the initialized fields to be updated. I know that this is not written well.<br />
: Events are handled as HTML events<br />
: DOM is the external (i.e., from the web page) API to the scene graph<br />
:: X3dom does it that way. One could add that this external API could be implemented using the SAI thereby guaranteeing X3D event flow determinism<br />
:: Would it be possible to implement the SAI over DOM? I am concerned about having more than one fundamental API. It will cause confusion and errors.<br />
Note: The notes on Cobweb DOM by Andreas Plesch should be noted. See https://github.com/andreasplesch/cobweb_dom<br />
<br />
=== Other HTML related ===<br />
: X3D scenes can pass events to/from the DOM and ROUTE events within the scene graph.<br />
: HTML elements, SVG elements and css blocks can be interspersed with X3D elements.<br />
: HTML Script, SVG Script and X3D Script elements are unique and distinguishable.<br />
:: I still have not heard a good reason to have X3D scripts. They cannot have the same element name so legacy X3D files cannot run. At that point using HTML JavaScript for all processing appears to be the right thing to do. I see it as very important to content developers not to have multiple flavors of JavaScript running.<br />
: String-based DOM events correlate with strongly typed X3D events by defined correspondences<br />
:: Multiple candidate approaches can be listed and compared<br />
:: The events I am referring to are those that cross between X3D and HTML or any other non-X3D environment (e.g., display, orientation, etc.).<br />
<br />
=== X3D shall support the evolving web standards for flat-3D (WebGL), VR (WebVR) and AR ===<br />
<br />
=== Existing features & functionality ===<br />
: Perform the following tasks with the requirements that is be conflict with the above<br />
:: Conduct a review of all existing features (nodes) to determine if any should be deprecated in V4<br />
:: Conduct a review of all existing functionality (run-time) to determine if any should be deprecated or changed in V4<br />
: Include all features and functionality that passes the above reviews<br />
<br />
=== Additional features to be added ===<br />
: Deformable-skin joint based animation<br />
: Support for multiple geometry formats, including OBJ, glTF<br />
:: Leonard has a pretty good understanding about binary glTF support in x3dom. There are issues posted under the X3DOM project at GitHub, but resolution of those issues will take quite a bit of work.<br />
: Increased Material support with a standard library of pre-defined shaders<br />
:: Three.js has good shaders including for PBR. But again quite a bit of work. Not sure if Fraunhofer is that engaged since there may be commercialization interest.<br />
:: Including programmable shaders in declarative language and not providing predefined operations seems like a poor choice. This is an attempt to start to rectify it.<br />
: Mechanism to navigate a scene without a pointing device<br />
: Mechanism to touch or select objects without a pointing device<br />
:: Or with wand or controller.<br />
: Review other 3D/VR display technologies (XML3D, A-Frame, GLAM, etc.) to determine if there are features that should be included<br />
:: The three.js examples are also inspiring. Postprocessing of the rendered frame in another shader stage comes to mind. There are probably many more modern graphics methods which need some support. Ambient occlusion ssao? Motion blur? Distance defocus?<br />
<br />
== Issues ==<br />
What encodings are needed? For example, do we need an HTML encoding. Or an XHTML encoding. Or can we simply reference the XML encoding, with modifications as appropriate, if required?<br />
<br />
== Existing implementation designs ==<br />
<br />
There are currently two implementations that enable X3D to be integrated into HTML web pages. These are:<br />
: X3DOM - Developed by Fraunhofer - see https://www.x3dom.org/. Version is 1.7.2 at the time of writing.<br />
: Cobweb - Developed by Holger Seelig - see http://titania.create3000.de/cobweb/. Version is 3.2 at the time of writing.<br />
:: See also the Cobweb DOM developed by Andreas Plesch - see https://github.com/andreasplesch/cobweb_dom<br />
<br />
The remainder of this section will consider some of the design patterns of these two implementations<br />
<br />
=== Commonalities ===<br />
<br />
: Both Cobweb/Cobweb DOM and X3DOM support the embedding of X3D scenes directly into the HTML. Both implementations also support referencing an external X3D file.<br />
<br />
: Both X3DOM and Cobweb/Cobweb DOM have a parallel dual-node setup. That is, they have both a DOM document fragment that integrates directly with the remainder of the HTML in the web page, and an internal X3D scene graph. The two sets of nodes are synchronized, so that changes in either one are reflected into the other. The DOM document fragment permits all the usual HTML/DOM interactions. The X3D scene graph permits the regular X3D interactions. In Cobweb, the synchronization functionality for the X3D scene graph is faithful to the scene access interface (SAI).<br />
<br />
: Both Cobweb/Cobweb DOM and X3DOM use the HTML canvas tag for rendering the scene. Each implementation will automatically incorporate the canvas tag into the DOM document fragment.<br />
<br />
: Both X3DOM and Cobweb/Cobweb DOM support both the X3D "DEF" attribute and the HTML "id" attribute. Cobweb maintains these in the appropriate document fragment, with no mapping from one to the other. While X3DOM supports both "DEF" and "id", it also provides some mapping between them. All "id" attributes are automatically mapped to "DEF" attributes if no "DEF" attribute is defined. The reverse mapping is only optionally allowed for Inline scenes, where the Inline node has an additional attribute "mapDEFToID" defined.<br />
<br />
: With embedded X3D scenes both X3DOM and Cobweb/Cobweb DOM incorporate all nodes into the DOM. This can be verified by inspection of the HTML web page when loaded into a browser.<br />
<br />
=== Differences === <br />
<br />
: In order for the X3D tag to faithfully follow the standard and not include extra attributes Cobweb has an additional X3DCanvas tag that is used as a parent to the X3D tag. This X3DCanvas tag has all the additional properties that might be required for integrating an X3D scene into a web page. In contrast, X3DOM simply adds additional properties to the X3D tag.<br />
<br />
: Cobweb supports both prototypes and scripts. X3DOM supports neither. In order to recognize the difference between an HTML script element and an X3D script element the X3D script element in the Cobweb implementation has been given an additional attribute named "type" that is analogous to the HTML script tag attribute "type". For X3D scripts, the value for this attribute should be "application/x-vrmlscript".<br />
:: As a consequence of the current X3DOM implementation not supporting prototypes and scripts it cannot support the "Immersive" or "Full" profiles. ''TODO: Find out if variables and functions from X3D Script nodes can be accessed in other HTML scripts.''<br />
<br />
: Cobweb/Cobweb DOM runs the X3D scenegraph portion of the scene using the standard X3D event models. Output events are translated into custom DOM events. ''TODO: Find out what X3DOM does.''<br />
<br />
: Cobweb/Cobweb DOM is designed to be a faithful implementation of the X3D standard. X3DOM, however, has significant differences from the standard. ''TODO: Enumerate these differences.''<br />
<br />
: X3DOM only permits the external referencing of XML encoded X3D files. Cobweb can externally reference both XML and Classic VRML encoded X3D files.<br />
<br />
{| class="wikitable"<br />
|+Comparison of implementations<br />
!style="text-align:left;"|Description<br />
!X3DOM<br />
!Cobweb<br />
!Cobweb/DOM<br />
|-<br />
|Embedding X3D<br />
|Supported<br />
|Supported<br />
|Supported<br />
|-<br />
|Referencing external X3D<br />
|Supported<br />
|Supported<br />
|Supported<br />
|}<br />
<br />
== General comments ==<br />
<br />
Generally, the vrml spec. was written before the advent of powerful GPUs (massively parallel super computers) where it now can be faster to repeat the same fragment shader operation for each pixel (perhaps a million times) rather than update data between cpu and gpu once. Not sure what the consequences exactly are other than being shader friendly in some way.<br />
<br />
Deformable skin from joint animation calculations are typically carried out on the GPU. Too much for serial processors. I'm sure there are other items.<br />
<br />
=== HTML empty tag closing ===<br />
<br />
In general web browsers are not very good at recognizing self-closing empty tags. For example:<br />
<pre><br />
&lt;Material diffuseColor='1 1 1' /&gt;<br />
&lt;ImageTexture url='"MyImage.jpg"' /&gt;<br />
</pre><br />
will be incorrectly interpreted, with ImageTexture being loaded as a child, and not a sibling, of Material. Instead, these must be written as:<br />
<pre><br />
&lt;Material diffuseColor='1 1 1'&gt;&lt;/Material&gt;<br />
&lt;ImageTexture url='"MyImage.jpg"'&gt;&lt;/ImageTexture&gt;<br />
</pre><br />
NOTE: It must be remembered that all X3D nodes can contain children, if only a metdata node. Therefore, they are not empty elements by design.<br />
<br />
=== MFString quoting ===<br />
<br />
In accordance with the standards MFString fields should have double quotes, as illustrated in the examples above. While X3DOM will be tolerant of single quote usage, Cobweb will not.<br />
<br />
=== DEF/USE in HTML ===<br />
<br />
'''(Comment by Leonard)'''<br />
The original purpose (and still used in this manner) of the 'USE' attribute is to indicate that another node should also appear in place of the node declaring 'USE'. In fact the specification states (4.4.3 - http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#DEFL_USESemantics) that "the same node is inserted into the scene graph a second time, resulting in the node having multiple parents".<br />
<br />
This requirement is not allowed in DOM (see https://www.w3.org/TR/dom/#concept-node-tree for the standard, https://www.w3.org/wiki/Traversing_the_DOM#Nodes for the explanation). A DOM element is allowed to have at most one parent. It is possible to create a (deep) copy of the node and insert it into the tree. That gives a structure like:<br />
<br />
<pre><br />
B - C - D<br />
/ <br />
A <br />
\ <br />
E - CC - DD<br />
</pre><br />
<br />
Where A is the parent of this (sub-)tree, B is the node that start one branch (e.g., Transform). C is the 'DEF'ed node with a child of D. E is a separate child of A (e.g., a different Transform) CC is the 'USE' version of C. Since HTML does not allow multiple parents ('B' and 'E'), a copy of 'C' needs to be made. This needs to be a deep copy (all children) as no node can have more than one parent.<br />
<br />
'''(Comment by Andreas)'''<br />
It may be also instructive to determine how x3dom currently deals with DEF/USE. My recollection is that DOM elements with a USE attribute have just one parent (they have to) but are mapped to x3dom nodes (in javascript memory) which have the DEF parent (through a map).<br />
<br />
cobweb_dom is initially loading nodes including USE nodes with the SAI importDocument(DomNode) function (http://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#t-FunctionsBrowserObject). USE nodes added later to the DOM are parsed into the x3d graph using cobwebs parser which I think takes care of parenting to the x3d DEF node.<br />
<br />
A-frame has an assets systems which allows reuse of components in multiple entities. I suspect A-frame avoids copying and would reference the same asset multiple times. This is possible because A-frame also has a parallel scene graph (the THREE graph) which exists in memory apart from the DOM.<br />
<br />
Another angle is the shadow DOM but I am not sure if that applies since I suspect that it also does not allow multiple parents.<br />
<br />
I think SVG has DEF/USE as well. SVG then must define some exceptions (?).<br />
<br />
Overall, it looks like it may be necessary to rely on more than the DOM alone for DEF/USE functionality.<br />
<br />
'''(Comment by Leonard)'''<br />
I have looked through the code and have not yet been able to find the specific lines that deal with 'USE'. X3DOM does deal with 'USE' as can be seen in the example at https://examples.x3dom.org/example/x3dom_defUse.xhtml. View-source shows that it is used in the second 'Shape'. I suspect that the second 'Shape' is removed from the DOM but kept in the scene graph. <br />
<br />
This particular method breaks (2 - not all X3D nodes are in the DOM). I believe Andreas describes Cobweb as doing essentially the same thing.<br />
<br />
''cobweb_dom is initally loading nodes including USE nodes with the SAI importDocument(DomNode) function (http://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#t-FunctionsBrowserObject) . USE nodes added later to the DOM are parsed into the x3d graph using cobwebs parser which I think takes care of parenting to the x3d DEF node.''<br />
<br />
A-frame has an assets systems which allows reuse of components in multiple entities. I suspect A-frame avoids copying and would reference the same asset multiple times. This is possible because A-frame also has a parallel scene graph (the THREE graph) which exists in memory apart from the DOM.<br />
<br />
I have looked at the asset system in A-Frame, but not in sufficient depth to determine whether <br />
1) It uses the data as a single copy inserted into the DOM in the asset statement with the uses not appearing in the DOM<br />
2) It copies the information from the asset definition to the node that uses it<br />
3) It uses the asset-defined information by reference<br />
<br />
If the asset system does not expand nodes in the DOM when it is used, then it could very easily work like CSS by supplying a common definition that other nodes just refer to (#3 above).<br />
<br />
''Another angle is the shadow DOM but I am not sure if that applies since I suspect that it also does not allow multiple parents.''<br />
<br />
Shadow DOM is (sort-of) like regular DOM. You are right about not allowing multiple parents. It allows you to expose elements to the (page) renderer without them being directly visible in the DOM. Since the scene graph is roughly parallel to the DOM, adding another DOM seems to me to be increasing the complexity without necessarily solving the problem. <br />
<br />
Even though it is 6 years old, this article provides a good basic description of Shadow DOM - https://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/<br />
<br />
''I think SVG has DEF/USE as well. SVG then must define some exceptions (?).''<br />
<br />
Not being an SVG expert, I had to look this up. I found this Stack Overflow questions: https://stackoverflow.com/questions/19246232/svg-reuse-a-line-node-with-def-and-use<br />
<br />
It describes that the 'use' attribute does a deep clone and inserted into the generated tree. Unfortunately, the answer did not provide a reference, but it does look like it is quoting something important.<br />
<br />
''Overall, it looks like it may be necessary to rely on more than the DOM alone for DEF/USE functionality.''<br />
<br />
Offering another possibility. Unreal (and I think Unity) create a class for each object. If something is "copied", then it is sub-classed from the original class. Changes to the parent propagate to all subclasses; however, a sub-class can override any property (which would then propagate to sub-sub-classes). I think that means in "X3D"-speak, the "DEF" node defines the master class. Any node that "USE"s it would create a subclass. A USE node could also redefine fields for that subclass, and even make itself available for subclassing by using a DEF statement. This would look something like:<br />
<br />
<Transform DEF='Master' translation='1 2 3' rotation='0 1 0 0' scale='1 1 1'>...</Transform><br />
<br />
<Transform USE='Master'>...</Transform> <!-- strict subclass of Master --><br />
<Transform USE='Master' DEF='Alpha' rotation='1 0 0 1.57'>...</Transform> <!-- subclass of Master with a change of rotation --><br />
<Transform USE='Master' DEF='Beta' rotation='0 0 1 1.57'>...</Transform> <!-- different subclass of Master with a change of rotation --><br />
<Transform USE='alpha' scale='2 2 2'>...</Transform> <!-- subclass of Alpha with a change of scale --><br />
<br />
'''(Comment by Andreas)'''<br />
The second shape is still in the DOM. But I am not sure what happens if its USE attribute is modified.<br />
<br />
https://github.com/x3dom/x3dom/search?utf8=✓&q=defmap&type=<br />
<br />
shows how DEF is implemented.<br />
<br />
The svg spec. needs a lot of language to deal with def/use:<br />
<br />
https://www.w3.org/TR/SVG/struct.html#Head<br />
<br />
https://www.w3.org/TR/SVG/struct.html#UseElement<br />
<br />
An excerpt:<br />
"The effect of a ‘use’ element is as if the contents of the referenced element were deeply cloned into a separate non-exposed DOM tree which had the ‘use’ element as its parent and all of the ‘use’ element's ancestors as its higher-level ancestors. Because the cloned DOM tree is non-exposed, the SVG Document Object Model (DOM) only contains the ‘use’ element and its attributes. The SVG DOM does not show the referenced element's contents as children of ‘use’ element."<br />
<br />
Mostly use seems understood as referencing def but the actual representation then needs to be a deep and unexposed copy.<br />
<br />
Svg also allows reusing a modified use for subclassing, judging from the spec. . I have never tried this.<br />
<br />
Could be cool. There may be a chance to make this a backwards compatible addition to x3d ?<br />
<br />
Trying to come up with a practical use case. Cars. Blue Cars. Blue cars with lights on.<br />
<br />
'''(Comment by Leonard)'''<br />
Examples where you might wish to sub-class an object. You have one master car wheel. The ones on the other side need to have their geometry inverted, but not their rotation characteristics. The ones in front turn, the ones in back don't. Going around corners cause the tires to rotate at different speeds.<br />
<br />
Another one is trees. They may all be the same, but they will bend differently depending on how the wind blows through the forest.<br />
<br />
The people who build Unreal environments do this all time. I can ask a couple of illustrated examples if that would help.<br />
<br />
<br />
=== Scripting ===<br />
<br />
* See https://www.w3.org/TR/SVG/script.html<br />
* See the example in 18.2 The 'script' element at https://www.w3.org/TR/SVG/script.html#ScriptElement<br />
* See the DOM interface definition for SVGScriptElement at https://www.w3.org/TR/SVG/script.html#InterfaceSVGScriptElement<br />
<!-- <br />
DO NOT REMOVE THIS COMMENT<br />
Note that there is something in the text from the third bullet below to the <br />
end of the text prior to the comment that triggers a security error in Apache (SQL injection). <br />
This section MUST be the last in the list.<br />
DO NOT REMOVE THIS COMMENT<br />
--><br />
<br />
==== Scripting Examples ====<br />
<br />
''This section added because of a structural reason in the parent that prevents additional items from being added there''<br />
<br />
ECMAScript is very powerful and allows dynamic changes to code at run-time. This section illustrates some features that are regularly used in advanced HTML/JavaScript programming<br />
<br />
X3D Script function called 'foo'<br />
HTML script function called 'bar'<br />
<br />
In the body of bar, I should be able to redefine 'foo'. It is (in a <br />
fully integrated system) available as window.foo. Similarly for inside <br />
of 'foo' to change 'bar'.<br />
<br />
<nowiki><br />
function bar(event, time) {<br />
window.foo = bar; // I would (perhaps) settle for <br />
window.x3d.foo = bar;<br />
}</nowiki><br />
<br />
and<br />
<br />
<nowiki><br />
X3D-Script ...> <!-- X3D Script node --><br />
function foo (event, time) {<br />
window.bar = foo;<br />
}<br />
</script></nowiki><br />
<br />
I should be able to construct an object with 'foo' as a method. E.g.,<br />
<br />
<nowiki><br />
var globalVar = {};<br />
globalVar.x3d = foo;<br />
<br />
// should call the X3D script passing it a reference to the current <br />
value of 'event' and 'time'.<br />
globalVar.x3d(event, time);</nowiki><br />
<br />
<br />
Inside 'foo' I should be able to access any DOM element to get it's <br />
current state or even establish an event listener.<br />
<br />
=== OBJ file format ===<br />
<br />
I applaud the idea of multiple geometry formats, as we need interoperability, and glTF is a nice standard.<br />
<br />
But I would remove OBJ from the list, or be careful what parts of the OBJ are necessary to be supported.<br />
* The OBJ is an old format. It doesn't have many features nice for modern rendering (like a specification of shading suitable for modern GPUs). And it does have some features that are unhandy, and were probably really useful only by the initial Wavefront OBJ implementation (trace_obj).<br />
* The OBJ specification is not officially maintained by anyone, I think. It's not updated. The creators of it, and the original software implementing it, are closed now. (https://en.wikipedia.org/wiki/Wavefront_Technologies , https://en.wikipedia.org/wiki/The_Advanced_Visualizer ). No-one since then has taken the effort to update the OBJ specification in any way, as far as I know.<br />
* Although it has a specification http://www.martinreddy.net/gfx/3d/OBJ.spec, most implementations treat it more like a "de-facto" standard, implementing different subsets of the format, whatever seems useful. There are features in OBJ format that are widely supported (vertexes with normals, tex coords), and there are features not supported by any existing implementation (I have not seen yet an implementation that supports Bezier patches defined in OBJ files; or one that supports d_interp or trace_obj).<br />
<br />
Bottom line: While OBJ is a popular format, I would either discourage from using it (we made X3D for a reason iii it's really better on all accounts), or at least specify only a precise subset of OBJ features required to be supported.<br />
<br />
A very informative link to Wikipedia description of OBJ: https://en.wikipedia.org/wiki/Wavefront_.obj_file<br />
<br />
I included OBJ because it is a very popular format for the exchange of geometry and normal information. I have only seen it with triangles. I am in complete agreement with Michalis about limiting it's scope.<br />
For example, SVG also has a script node that seems to operate just fine in combination with HTML.</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_V4_HTML_Integration_Requirements&diff=9633X3D V4 HTML Integration Requirements2017-08-23T14:30:23Z<p>Webmaster: Added subsection on Scripting Examples</p>
<hr />
<div><br />
== Objectives and Strategy ==<br />
<br />
The objective for this page is to describe particular issues and details for close integration of X3D capabilities in HTML5/DOM pages. We are working towards identification of consensus points open issues.<br />
<br />
This work is part of a broad strategy for X3D version 4.<br />
<br />
# [http://www.web3d.org/strategy Web3D Standards Strategy] emphasizes a "fundamental objective is to enable the open publishing of interactive 3D graphics models on the Web, enabling real-time 3D communication. We carefully improve and evolve our Recommended Standards while maintaining long-term archival stability."<br />
# [http://www.web3d.org/x3d4 X3D V4] describes the design strategy of X3D v4.0 for HTML5/DOM integration, and X3D v4.1 Mixed Augmented Reality (MAR). "Next-generation evolution + revolution is combined with archival compatibility of existing legacy content." <br />
# [http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development X3D V4 Development] describes Genesis and Strategic Overview, Legacy Issues, Candidate Capabilities, Backwards and Forwards Compatibility, Architectural Considerations, Open Questions, and Related Work.<br />
<br />
== Boundary conditions ==<br />
<br />
# This is just for X3D running in a web browser and integrated with HTML. This could be expressed as <x3d> ... </x3d> can be treated as a document fragment in the body of an HTML document. If there is X3D outside of this limitation, these requirements may or may not apply.<br />
# Changes to X3D Abstract Specification? I had not gone as far as indicating which changes needed to go where. Obviously new nodes would need to be in the Abstract specification. But even before going there it is necessary to determine what environments X3D will operate in. My limitations are only for a web browser environment. Environments beside that one are not a concern of the requirements I stated. If there are to be other environments than those differences and similarities would need to be worked out.<br />
# Defining an HTML5 Encoding, and perhaps a corresponding HTML5 Profile<br />
<br />
== Notes ==<br />
<br />
# Some of these requirements may overlap by varying amounts. It was easier to specify them this way then trying to make a complete and non-overlapping set. I'm not going to even claim that this is a complete set, but it is a beginning.<br />
# For those that want XHTML, then convert all references to HTML to XHTML and make the appropriate syntax changes. The differences between HTML and XHTML in the appearance of the elements and attributes is that XHTML is strict. This amounts to closing elements, elements and attributes are lower case, mandatory elements and attributes, different MIME type (text/html vs. application/xml or applications/xhtml+xml), and quoted attributes -- see https://www.w3schools.com/html/html_xhtml.asp for details. The WhatWG has a pretty good documentation page on the differences at https://wiki.whatwg.org/wiki/HTML_vs._XHTML.<br />
<br />
== Decisions taken ==<br />
<br />
At the X3D Working Group meeting held 19th July 2017 the following decisions were made:<br />
# The HTML standard to be normatively referenced should be the current W3C HTML recommendation, found at https://www.w3.org/TR/html/. As of the meeting date this is HTML 5.1, dated 1 November 2016.<br />
# As a consequence the DOM specification normatively referenced by the HTML specification can be found at https://www.w3.org/TR/DOM/. This is the W3C recommendation for DOM4, dated 19 November 2015.<br />
# All X3D nodes and statements are defined in the X3D abstract specification. Each encoding shall specify the mapping of each node and statement in the X3D abstract specification to the respective encoding form.<br />
# Each X3D element needs a corresponding DOM interface definition. The form of this is still to be decided.<br />
# X3D element DOM interface definitions will use the same IDL as HTML, namely WebIDL Level 1 defined at https://www.w3.org/TR/WebIDL-1/.<br />
<br />
== Candidate Requirements ==<br />
<br />
=== Looks "like" HTML ===<br />
: Elements (nodes in X3D-speak) shall be case independent<br />
: Attributes (fields in X3D-speak) shall be case independent<br />
: X3D nodes shall not have name conflicts with any HTML-defined elements<br />
:: I believe the HTML5 Custom Elements spec requires a prefix-name format for element names. While allowing lowercase should we also allow 'x3d-transform' format alternative names?<br />
:: In that case, each node would be aliased with a HTML5 Custom Element compatible name.<br />
: All X3D nodes shall support all HTML Global Attributes https://www.w3schools.com/tags/ref_standardattributes.asp<br />
:: Is this equivalent to requiring that X3D nodes need to derive from HTMLElement as defined in the DOM?<br />
: All X3D fields with the same name as HTML attributes shall behave as the HTML element<br />
: TBD: Not all style attributes apply to X3D nodes & fields<br />
<br />
==== Candidate interface definitions for X3DElement ====<br />
Start with the assumption that all X3D elements inherit a common interface, named X3DElement. Two candidate interface definitions are as follows:<br />
<br />
'''Candidate A'''<br />
<br />
interface X3DElement : HTMLElement { } ;<br />
<br />
Using the definition of HTMLElement from the W3C HTML specification, this can be expanded to:<br />
<br />
interface X3DElement : [https://www.w3.org/TR/dom/#interface-element Element] {<br />
// metadata attributes<br />
attribute DOMString [https://html.spec.whatwg.org/multipage/dom.html#dom-title title];<br />
attribute DOMString [https://html.spec.whatwg.org/multipage/dom.html#dom-lang lang];<br />
attribute boolean [https://html.spec.whatwg.org/multipage/dom.html#dom-translate translate];<br />
attribute DOMString [https://html.spec.whatwg.org/multipage/dom.html#dom-dir dir];<br />
[[https://heycam.github.io/webidl/#SameObject SameObject]] readonly attribute [https://www.w3.org/TR/html/infrastructure.html#domstringmap-domstringmap DOMStringMap] [https://html.spec.whatwg.org/multipage/dom.html#dom-dataset dataset];<br />
<br />
// user interaction<br />
attribute boolean [https://html.spec.whatwg.org/multipage/embedded-content.html#dom-texttrack-hidden hidden];<br />
void [https://html.spec.whatwg.org/multipage/interaction.html#dom-click click]();<br />
attribute long [https://html.spec.whatwg.org/multipage/interaction.html#dom-tabindex tabIndex];<br />
void [https://html.spec.whatwg.org/multipage/interaction.html#dom-focus focus]();<br />
void [https://html.spec.whatwg.org/multipage/interaction.html#dom-blur blur]();<br />
attribute DOMString [https://www.w3.org/TR/html/editing.html#dom-htmlelement-accesskey accessKey];<br />
attribute boolean [https://www.w3.org/TR/html/editing.html#dom-htmlelement-draggable draggable];<br />
[[https://heycam.github.io/webidl/#PutForwards PutForwards]=[https://dom.spec.whatwg.org/#dom-domtokenlist-value value]] readonly attribute [https://dom.spec.whatwg.org/#domtokenlist DOMTokenList] [https://www.w3.org/TR/html/editing.html#dom-htmlelement-dropzone dropzone];<br />
attribute [https://www.w3.org/TR/html/interactive-elements.html#htmlmenuelement-htmlmenuelement HTMLMenuElement]? [https://www.w3.org/TR/html/interactive-elements.html#dom-htmlelement-contextmenu contextMenu];<br />
attribute boolean [https://html.spec.whatwg.org/multipage/interaction.html#dom-spellcheck spellcheck];<br />
void [https://html.spec.whatwg.org/multipage/interaction.html#dom-forcespellcheck forceSpellCheck]();<br />
};<br />
<br />
X3DElement implements [https://www.w3.org/TR/html/webappapis.html#globaleventhandlers-globaleventhandlers GlobalEventHandlers];<br />
<br />
X3DElement implements [https://www.w3.org/TR/html/webappapis.html#documentandelementeventhandlers-documentandelementeventhandlers DocumentAndElementEventHandlers];<br />
<br />
X3DElement implements [https://www.w3.org/TR/html/editing.html#elementcontenteditable-elementcontenteditable ElementContentEditable];<br />
<br />
'''Candidate B'''<br />
<br />
Take the SVGElement interface, substituting X3D for all occurrences of SVG.<br />
Note: The original names have been retained in order to include the hyperlinks.<br />
<br />
interface SVGElement : [https://www.w3.org/TR/2014/WD-dom-20140204/#element Element] {<br />
<br />
[SameObject] readonly attribute [https://www.w3.org/TR/SVG2/types.html#InterfaceSVGAnimatedString SVGAnimatedString] [https://www.w3.org/TR/SVG2/types.html#__svg__SVGElement__className className];<br />
[SameObject] readonly attribute [https://www.w3.org/TR/2014/CR-html5-20140204/infrastructure.html#domstringmap DOMStringMap] [https://www.w3.org/TR/SVG2/types.html#__svg__SVGElement__dataset dataset];<br />
readonly attribute [https://www.w3.org/TR/SVG2/struct.html#InterfaceSVGSVGElement SVGSVGElement]? [https://www.w3.org/TR/SVG2/types.html#__svg__SVGElement__ownerSVGElement ownerSVGElement];<br />
readonly attribute [https://www.w3.org/TR/SVG2/types.html#InterfaceSVGElement SVGElement]? [https://www.w3.org/TR/SVG2/types.html#__svg__SVGElement__viewportElement viewportElement];<br />
attribute long [https://www.w3.org/TR/SVG2/types.html#__svg__SVGElement__tabIndex tabIndex];<br />
void [https://www.w3.org/TR/SVG2/types.html#__svg__SVGElement__focus focus]();<br />
void [https://www.w3.org/TR/SVG2/types.html#__svg__SVGElement__blur blur]();<br />
};<br />
<br />
[https://www.w3.org/TR/SVG2/types.html#InterfaceSVGElement SVGElement] implements [https://www.w3.org/TR/2014/CR-html5-20140204/webappapis.html#globaleventhandlers GlobalEventHandlers];<br />
<br />
[https://www.w3.org/TR/SVG2/types.html#InterfaceSVGElement SVGElement] implements [https://www.w3.org/TR/SVG2/struct.html#InterfaceSVGElementInstance SVGElementInstance];<br />
<br />
=== HTML encodings ===<br />
: HTML5 has two encodings, not one. Each consistently maps to DOM. The WG developing corresponding functionality and syntax that supports both encodings will add tremendous value to everyone.<br />
:: HTML5 Recommendation section 8. The HTML syntax https://www.w3.org/TR/html5/syntax.html#syntax<br />
:: HTML5 Recommendation section 9. The XHTML syntax https://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax<br />
: The differences between HTML and XHTML in the appearance of the elements and attributes is that XHTML is strict. This amounts to closing elements, elements and attributes are lower case, mandatory elements and attributes, different MIME type (text/html vs. application/xml or applications/xhtml+xml), and quoted attributes -- see https://www.w3schools.com/html/html_xhtml.asp for details. The WhatWG has a pretty good documentation page on the differences at https://wiki.whatwg.org/wiki/HTML_vs._XHTML. There are differences in scripting. Most of the differences are obvious extensions from XHTML being an XML document. The W3C HTML5 specification (https://www.w3.org/TR/html5/introduction.html#html-vs-xhtml) is consistent with the above comments. All of the formalities aside, from my observations there is very little use of the XHTML document type for regular web pages.<br />
<br />
=== Functions "like" HTML ===<br />
: All nodes shall be fully integrated with the DOM [This may need to change if certain nodes need to remain hidden from the DOM. For example, the manner which X3DOM implements Inline.]<br />
: The scene graph does not need to be DOM (or a portion of it).<br />
:: X3DOM keeps a separate scene graph from the DOM. The rendering occurs from the scene graph. Changes to the DOM cause changes to the scene graph and vice versa.<br />
: Changes to the DOM shall be reflected in the scene graph<br />
: Changes to the scene graph shall be reflected in the DOM<br />
:: Using the DOM to maintain and reflect state is often considered slow. Could this be optional? Changes to the scene graph cause events which can be listened to if required. (This is why cobweb-dom does not reflect back interpolator output to the DOM at this point)<br />
:: Perhaps it is better to set all current fields that are initialized to be (generally) non-updated. If you want to see a particular value, you need to listen to the appropriate event. Certain events would cause the initialized fields to be updated. I know that this is not written well.<br />
: Events are handled as HTML events<br />
: DOM is the external (i.e., from the web page) API to the scene graph<br />
:: X3dom does it that way. One could add that this external API could be implemented using the SAI thereby guaranteeing X3D event flow determinism<br />
:: Would it be possible to implement the SAI over DOM? I am concerned about having more than one fundamental API. It will cause confusion and errors.<br />
Note: The notes on Cobweb DOM by Andreas Plesch should be noted. See https://github.com/andreasplesch/cobweb_dom<br />
<br />
=== Other HTML related ===<br />
: X3D scenes can pass events to/from the DOM and ROUTE events within the scene graph.<br />
: HTML elements, SVG elements and css blocks can be interspersed with X3D elements.<br />
: HTML Script, SVG Script and X3D Script elements are unique and distinguishable.<br />
:: I still have not heard a good reason to have X3D scripts. They cannot have the same element name so legacy X3D files cannot run. At that point using HTML JavaScript for all processing appears to be the right thing to do. I see it as very important to content developers not to have multiple flavors of JavaScript running.<br />
: String-based DOM events correlate with strongly typed X3D events by defined correspondences<br />
:: Multiple candidate approaches can be listed and compared<br />
:: The events I am referring to are those that cross between X3D and HTML or any other non-X3D environment (e.g., display, orientation, etc.).<br />
<br />
=== X3D shall support the evolving web standards for flat-3D (WebGL), VR (WebVR) and AR ===<br />
<br />
=== Existing features & functionality ===<br />
: Perform the following tasks with the requirements that is be conflict with the above<br />
:: Conduct a review of all existing features (nodes) to determine if any should be deprecated in V4<br />
:: Conduct a review of all existing functionality (run-time) to determine if any should be deprecated or changed in V4<br />
: Include all features and functionality that passes the above reviews<br />
<br />
=== Additional features to be added ===<br />
: Deformable-skin joint based animation<br />
: Support for multiple geometry formats, including OBJ, glTF<br />
:: Leonard has a pretty good understanding about binary glTF support in x3dom. There are issues posted under the X3DOM project at GitHub, but resolution of those issues will take quite a bit of work.<br />
: Increased Material support with a standard library of pre-defined shaders<br />
:: Three.js has good shaders including for PBR. But again quite a bit of work. Not sure if Fraunhofer is that engaged since there may be commercialization interest.<br />
:: Including programmable shaders in declarative language and not providing predefined operations seems like a poor choice. This is an attempt to start to rectify it.<br />
: Mechanism to navigate a scene without a pointing device<br />
: Mechanism to touch or select objects without a pointing device<br />
:: Or with wand or controller.<br />
: Review other 3D/VR display technologies (XML3D, A-Frame, GLAM, etc.) to determine if there are features that should be included<br />
:: The three.js examples are also inspiring. Postprocessing of the rendered frame in another shader stage comes to mind. There are probably many more modern graphics methods which need some support. Ambient occlusion ssao? Motion blur? Distance defocus?<br />
<br />
== Issues ==<br />
What encodings are needed? For example, do we need an HTML encoding. Or an XHTML encoding. Or can we simply reference the XML encoding, with modifications as appropriate, if required?<br />
<br />
== Existing implementation designs ==<br />
<br />
There are currently two implementations that enable X3D to be integrated into HTML web pages. These are:<br />
: X3DOM - Developed by Fraunhofer - see https://www.x3dom.org/. Version is 1.7.2 at the time of writing.<br />
: Cobweb - Developed by Holger Seelig - see http://titania.create3000.de/cobweb/. Version is 3.2 at the time of writing.<br />
:: See also the Cobweb DOM developed by Andreas Plesch - see https://github.com/andreasplesch/cobweb_dom<br />
<br />
The remainder of this section will consider some of the design patterns of these two implementations<br />
<br />
=== Commonalities ===<br />
<br />
: Both Cobweb/Cobweb DOM and X3DOM support the embedding of X3D scenes directly into the HTML. Both implementations also support referencing an external X3D file.<br />
<br />
: Both X3DOM and Cobweb/Cobweb DOM have a parallel dual-node setup. That is, they have both a DOM document fragment that integrates directly with the remainder of the HTML in the web page, and an internal X3D scene graph. The two sets of nodes are synchronized, so that changes in either one are reflected into the other. The DOM document fragment permits all the usual HTML/DOM interactions. The X3D scene graph permits the regular X3D interactions. In Cobweb, the synchronization functionality for the X3D scene graph is faithful to the scene access interface (SAI).<br />
<br />
: Both Cobweb/Cobweb DOM and X3DOM use the HTML canvas tag for rendering the scene. Each implementation will automatically incorporate the canvas tag into the DOM document fragment.<br />
<br />
: Both X3DOM and Cobweb/Cobweb DOM support both the X3D "DEF" attribute and the HTML "id" attribute. Cobweb maintains these in the appropriate document fragment, with no mapping from one to the other. While X3DOM supports both "DEF" and "id", it also provides some mapping between them. All "id" attributes are automatically mapped to "DEF" attributes if no "DEF" attribute is defined. The reverse mapping is only optionally allowed for Inline scenes, where the Inline node has an additional attribute "mapDEFToID" defined.<br />
<br />
: With embedded X3D scenes both X3DOM and Cobweb/Cobweb DOM incorporate all nodes into the DOM. This can be verified by inspection of the HTML web page when loaded into a browser.<br />
<br />
=== Differences === <br />
<br />
: In order for the X3D tag to faithfully follow the standard and not include extra attributes Cobweb has an additional X3DCanvas tag that is used as a parent to the X3D tag. This X3DCanvas tag has all the additional properties that might be required for integrating an X3D scene into a web page. In contrast, X3DOM simply adds additional properties to the X3D tag.<br />
<br />
: Cobweb supports both prototypes and scripts. X3DOM supports neither. In order to recognize the difference between an HTML script element and an X3D script element the X3D script element in the Cobweb implementation has been given an additional attribute named "type" that is analogous to the HTML script tag attribute "type". For X3D scripts, the value for this attribute should be "application/x-vrmlscript".<br />
:: As a consequence of the current X3DOM implementation not supporting prototypes and scripts it cannot support the "Immersive" or "Full" profiles. ''TODO: Find out if variables and functions from X3D Script nodes can be accessed in other HTML scripts.''<br />
<br />
: Cobweb/Cobweb DOM runs the X3D scenegraph portion of the scene using the standard X3D event models. Output events are translated into custom DOM events. ''TODO: Find out what X3DOM does.''<br />
<br />
: Cobweb/Cobweb DOM is designed to be a faithful implementation of the X3D standard. X3DOM, however, has significant differences from the standard. ''TODO: Enumerate these differences.''<br />
<br />
: X3DOM only permits the external referencing of XML encoded X3D files. Cobweb can externally reference both XML and Classic VRML encoded X3D files.<br />
<br />
{| class="wikitable"<br />
|+Comparison of implementations<br />
!style="text-align:left;"|Description<br />
!X3DOM<br />
!Cobweb<br />
!Cobweb/DOM<br />
|-<br />
|Embedding X3D<br />
|Supported<br />
|Supported<br />
|Supported<br />
|-<br />
|Referencing external X3D<br />
|Supported<br />
|Supported<br />
|Supported<br />
|}<br />
<br />
== General comments ==<br />
<br />
Generally, the vrml spec. was written before the advent of powerful GPUs (massively parallel super computers) where it now can be faster to repeat the same fragment shader operation for each pixel (perhaps a million times) rather than update data between cpu and gpu once. Not sure what the consequences exactly are other than being shader friendly in some way.<br />
<br />
Deformable skin from joint animation calculations are typically carried out on the GPU. Too much for serial processors. I'm sure there are other items.<br />
<br />
=== HTML empty tag closing ===<br />
<br />
In general web browsers are not very good at recognizing self-closing empty tags. For example:<br />
<pre><br />
&lt;Material diffuseColor='1 1 1' /&gt;<br />
&lt;ImageTexture url='"MyImage.jpg"' /&gt;<br />
</pre><br />
will be incorrectly interpreted, with ImageTexture being loaded as a child, and not a sibling, of Material. Instead, these must be written as:<br />
<pre><br />
&lt;Material diffuseColor='1 1 1'&gt;&lt;/Material&gt;<br />
&lt;ImageTexture url='"MyImage.jpg"'&gt;&lt;/ImageTexture&gt;<br />
</pre><br />
NOTE: It must be remembered that all X3D nodes can contain children, if only a metdata node. Therefore, they are not empty elements by design.<br />
<br />
=== MFString quoting ===<br />
<br />
In accordance with the standards MFString fields should have double quotes, as illustrated in the examples above. While X3DOM will be tolerant of single quote usage, Cobweb will not.<br />
<br />
=== DEF/USE in HTML ===<br />
<br />
'''(Comment by Leonard)'''<br />
The original purpose (and still used in this manner) of the 'USE' attribute is to indicate that another node should also appear in place of the node declaring 'USE'. In fact the specification states (4.4.3 - http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#DEFL_USESemantics) that "the same node is inserted into the scene graph a second time, resulting in the node having multiple parents".<br />
<br />
This requirement is not allowed in DOM (see https://www.w3.org/TR/dom/#concept-node-tree for the standard, https://www.w3.org/wiki/Traversing_the_DOM#Nodes for the explanation). A DOM element is allowed to have at most one parent. It is possible to create a (deep) copy of the node and insert it into the tree. That gives a structure like:<br />
<br />
<pre><br />
B - C - D<br />
/ <br />
A <br />
\ <br />
E - CC - DD<br />
</pre><br />
<br />
Where A is the parent of this (sub-)tree, B is the node that start one branch (e.g., Transform). C is the 'DEF'ed node with a child of D. E is a separate child of A (e.g., a different Transform) CC is the 'USE' version of C. Since HTML does not allow multiple parents ('B' and 'E'), a copy of 'C' needs to be made. This needs to be a deep copy (all children) as no node can have more than one parent.<br />
<br />
'''(Comment by Andreas)'''<br />
It may be also instructive to determine how x3dom currently deals with DEF/USE. My recollection is that DOM elements with a USE attribute have just one parent (they have to) but are mapped to x3dom nodes (in javascript memory) which have the DEF parent (through a map).<br />
<br />
cobweb_dom is initially loading nodes including USE nodes with the SAI importDocument(DomNode) function (http://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#t-FunctionsBrowserObject). USE nodes added later to the DOM are parsed into the x3d graph using cobwebs parser which I think takes care of parenting to the x3d DEF node.<br />
<br />
A-frame has an assets systems which allows reuse of components in multiple entities. I suspect A-frame avoids copying and would reference the same asset multiple times. This is possible because A-frame also has a parallel scene graph (the THREE graph) which exists in memory apart from the DOM.<br />
<br />
Another angle is the shadow DOM but I am not sure if that applies since I suspect that it also does not allow multiple parents.<br />
<br />
I think SVG has DEF/USE as well. SVG then must define some exceptions (?).<br />
<br />
Overall, it looks like it may be necessary to rely on more than the DOM alone for DEF/USE functionality.<br />
<br />
'''(Comment by Leonard)'''<br />
I have looked through the code and have not yet been able to find the specific lines that deal with 'USE'. X3DOM does deal with 'USE' as can be seen in the example at https://examples.x3dom.org/example/x3dom_defUse.xhtml. View-source shows that it is used in the second 'Shape'. I suspect that the second 'Shape' is removed from the DOM but kept in the scene graph. <br />
<br />
This particular method breaks (2 - not all X3D nodes are in the DOM). I believe Andreas describes Cobweb as doing essentially the same thing.<br />
<br />
''cobweb_dom is initally loading nodes including USE nodes with the SAI importDocument(DomNode) function (http://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#t-FunctionsBrowserObject) . USE nodes added later to the DOM are parsed into the x3d graph using cobwebs parser which I think takes care of parenting to the x3d DEF node.''<br />
<br />
A-frame has an assets systems which allows reuse of components in multiple entities. I suspect A-frame avoids copying and would reference the same asset multiple times. This is possible because A-frame also has a parallel scene graph (the THREE graph) which exists in memory apart from the DOM.<br />
<br />
I have looked at the asset system in A-Frame, but not in sufficient depth to determine whether <br />
1) It uses the data as a single copy inserted into the DOM in the asset statement with the uses not appearing in the DOM<br />
2) It copies the information from the asset definition to the node that uses it<br />
3) It uses the asset-defined information by reference<br />
<br />
If the asset system does not expand nodes in the DOM when it is used, then it could very easily work like CSS by supplying a common definition that other nodes just refer to (#3 above).<br />
<br />
''Another angle is the shadow DOM but I am not sure if that applies since I suspect that it also does not allow multiple parents.''<br />
<br />
Shadow DOM is (sort-of) like regular DOM. You are right about not allowing multiple parents. It allows you to expose elements to the (page) renderer without them being directly visible in the DOM. Since the scene graph is roughly parallel to the DOM, adding another DOM seems to me to be increasing the complexity without necessarily solving the problem. <br />
<br />
Even though it is 6 years old, this article provides a good basic description of Shadow DOM - https://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/<br />
<br />
''I think SVG has DEF/USE as well. SVG then must define some exceptions (?).''<br />
<br />
Not being an SVG expert, I had to look this up. I found this Stack Overflow questions: https://stackoverflow.com/questions/19246232/svg-reuse-a-line-node-with-def-and-use<br />
<br />
It describes that the 'use' attribute does a deep clone and inserted into the generated tree. Unfortunately, the answer did not provide a reference, but it does look like it is quoting something important.<br />
<br />
''Overall, it looks like it may be necessary to rely on more than the DOM alone for DEF/USE functionality.''<br />
<br />
Offering another possibility. Unreal (and I think Unity) create a class for each object. If something is "copied", then it is sub-classed from the original class. Changes to the parent propagate to all subclasses; however, a sub-class can override any property (which would then propagate to sub-sub-classes). I think that means in "X3D"-speak, the "DEF" node defines the master class. Any node that "USE"s it would create a subclass. A USE node could also redefine fields for that subclass, and even make itself available for subclassing by using a DEF statement. This would look something like:<br />
<br />
<Transform DEF='Master' translation='1 2 3' rotation='0 1 0 0' scale='1 1 1'>...</Transform><br />
<br />
<Transform USE='Master'>...</Transform> <!-- strict subclass of Master --><br />
<Transform USE='Master' DEF='Alpha' rotation='1 0 0 1.57'>...</Transform> <!-- subclass of Master with a change of rotation --><br />
<Transform USE='Master' DEF='Beta' rotation='0 0 1 1.57'>...</Transform> <!-- different subclass of Master with a change of rotation --><br />
<Transform USE='alpha' scale='2 2 2'>...</Transform> <!-- subclass of Alpha with a change of scale --><br />
<br />
'''(Comment by Andreas)'''<br />
The second shape is still in the DOM. But I am not sure what happens if its USE attribute is modified.<br />
<br />
https://github.com/x3dom/x3dom/search?utf8=✓&q=defmap&type=<br />
<br />
shows how DEF is implemented.<br />
<br />
The svg spec. needs a lot of language to deal with def/use:<br />
<br />
https://www.w3.org/TR/SVG/struct.html#Head<br />
<br />
https://www.w3.org/TR/SVG/struct.html#UseElement<br />
<br />
An excerpt:<br />
"The effect of a ‘use’ element is as if the contents of the referenced element were deeply cloned into a separate non-exposed DOM tree which had the ‘use’ element as its parent and all of the ‘use’ element's ancestors as its higher-level ancestors. Because the cloned DOM tree is non-exposed, the SVG Document Object Model (DOM) only contains the ‘use’ element and its attributes. The SVG DOM does not show the referenced element's contents as children of ‘use’ element."<br />
<br />
Mostly use seems understood as referencing def but the actual representation then needs to be a deep and unexposed copy.<br />
<br />
Svg also allows reusing a modified use for subclassing, judging from the spec. . I have never tried this.<br />
<br />
Could be cool. There may be a chance to make this a backwards compatible addition to x3d ?<br />
<br />
Trying to come up with a practical use case. Cars. Blue Cars. Blue cars with lights on.<br />
<br />
'''(Comment by Leonard)'''<br />
Examples where you might wish to sub-class an object. You have one master car wheel. The ones on the other side need to have their geometry inverted, but not their rotation characteristics. The ones in front turn, the ones in back don't. Going around corners cause the tires to rotate at different speeds.<br />
<br />
Another one is trees. They may all be the same, but they will bend differently depending on how the wind blows through the forest.<br />
<br />
The people who build Unreal environments do this all time. I can ask a couple of illustrated examples if that would help.<br />
<br />
<br />
=== Scripting ===<br />
<br />
* See https://www.w3.org/TR/SVG/script.html<br />
* See the example in 18.2 The 'script' element at https://www.w3.org/TR/SVG/script.html#ScriptElement<br />
* See the DOM interface definition for SVGScriptElement at https://www.w3.org/TR/SVG/script.html#InterfaceSVGScriptElement<br />
<!-- <br />
DO NOT REMOVE THIS COMMENT<br />
Note that there is something in the text from the third bullet below to the <br />
end of the text prior to the comment that triggers a security error in Apache (SQL injection). <br />
This section MUST be the last in the list.<br />
DO NOT REMOVE THIS COMMENT<br />
--><br />
<br />
==== Scripting Examples ====<br />
<br />
This section added because of a structural reason in the parent that prevents additional items from being added there<br />
<br />
=== OBJ file format ===<br />
<br />
I applaud the idea of multiple geometry formats, as we need interoperability, and glTF is a nice standard.<br />
<br />
But I would remove OBJ from the list, or be careful what parts of the OBJ are necessary to be supported.<br />
* The OBJ is an old format. It doesn't have many features nice for modern rendering (like a specification of shading suitable for modern GPUs). And it does have some features that are unhandy, and were probably really useful only by the initial Wavefront OBJ implementation (trace_obj).<br />
* The OBJ specification is not officially maintained by anyone, I think. It's not updated. The creators of it, and the original software implementing it, are closed now. (https://en.wikipedia.org/wiki/Wavefront_Technologies , https://en.wikipedia.org/wiki/The_Advanced_Visualizer ). No-one since then has taken the effort to update the OBJ specification in any way, as far as I know.<br />
* Although it has a specification http://www.martinreddy.net/gfx/3d/OBJ.spec, most implementations treat it more like a "de-facto" standard, implementing different subsets of the format, whatever seems useful. There are features in OBJ format that are widely supported (vertexes with normals, tex coords), and there are features not supported by any existing implementation (I have not seen yet an implementation that supports Bezier patches defined in OBJ files; or one that supports d_interp or trace_obj).<br />
<br />
Bottom line: While OBJ is a popular format, I would either discourage from using it (we made X3D for a reason iii it's really better on all accounts), or at least specify only a precise subset of OBJ features required to be supported.<br />
<br />
A very informative link to Wikipedia description of OBJ: https://en.wikipedia.org/wiki/Wavefront_.obj_file<br />
<br />
I included OBJ because it is a very popular format for the exchange of geometry and normal information. I have only seen it with triangles. I am in complete agreement with Michalis about limiting it's scope.<br />
For example, SVG also has a script node that seems to operate just fine in combination with HTML.</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_version_4.0_Development&diff=9598X3D version 4.0 Development2017-04-26T15:31:28Z<p>Webmaster: /* Architectural Considerations */ DOM considerations</p>
<hr />
<div>==Genesis and Strategic Overview==<br />
<br />
Web3D Consortium working groups currently define specification goals and requirements. Working group efforts are often the focus for defining and testing new X3D components.<br />
<br />
We publicly review these goals annually during [http://web3dconference.org/ Web3D Conference] and [http://www.siggraph.org/attend/annual-conferences SIGGRAPH] Birds of a Feather (BOF) meetings ([http://www.web3d.org/event/siggraph-2016-conference-colocated-web3d-2016-anaheim-california SIGGRAPH 2016], upcoming SIGGRAPH 2017).<br />
<br />
Suggestions, development and discussion via the [http://web3d.org/mailman/listinfo/x3d-public_web3d.org x3d-public mailing list] is ongoing.<br />
<br />
X3D version 3.4 Development efforts were evolutionary improvements to the widely proven X3D Graphics architecture. Consortium members decided to skip version 3.4 and go straight to version 4.0, prior goals and requirements have all been merged here.<br />
<br />
The [http://www.web3d.org/wiki/index.php?title=X3D_version_4.0_Development#Candidate_Capabilities Candidate Capabilities] list shows that a lot of interesting capabilities have been proposed and are under way for X3D version 4. However, topics on this list are not guaranteed to be completed! Rather these are all works in progress.<br />
<br />
Activity and approval proceeds based on technical contributions and Web3D Consortium Member priorities. Please consider [http://web3d.org/membership/join joining Web3D Consortium] to help advance 3D graphics on the Web.These X3D version 4.0 Development efforts are considering potentially major additions to the baseline X3D architecture.<br />
<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_HTML5 HTML5], [http://www.w3.org/community/declarative3d/ Declarative 3D], CSS, [http://www.x3dom.org X3DOM] (see [http://web3d.org/wiki/images/f/f2/X3DOM_4_WebGL_audience_10_2013.pdf Summary slides (Oct 2013)]), and [http://titania.create3000.de/cobweb/ Cobweb]<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_Augmented_Reality Mixed and Augmented Reality (MAR)] (renamed from Augmented Reality Continuum (ARC)<br />
* Relaxing prior design constraints can enable a broader new basis for X3D integration<br />
* Normalizing interaction semantics with HTML5 can further open up X3D for the vast majority of Web authors<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered. X3D Futures planning is primarily a Web3D Consortium member-only activity, with community input.<br />
<br />
== Legacy Issues ==<br />
<br />
We plan to confirm the existence of complete capabilities for X3D v3.3 prior to final approval of X3D version 4.<br />
<br />
* Full support for all existing X3D v3.3 components:<br />
** At least two compatible implementations (including at least one in open source) plus repeatable example scenes<br />
** Layer, ParticleSystems, RigidBodyPhysics, Shaders, TODO others<br />
** TransformSensor node: [http://doc.instantreality.org/documentation/nodetype/TransformSensor/ IGD] and [http://www.parallelgraphics.com/developer/products/cortona/extensions/transformsensor/ old Cortona]<br />
** Note that it is not a requirement that all features and capabilities in X3D V3.3 are included in V4.0<br />
<br />
* Is it necessary for Layout component to be deprecated or improved?<br />
* Are there other features or capabilities that should not or are not able to move into V4.0?<br />
<br />
== Candidate Capabilities ==<br />
<br />
Each of the following possibilities for X3D version 4 have been discussed by the various X3D working groups during meetings and on mailing lists.<br />
Each potential capability is considered to be a feasible (and in most cases, straightforward) addition to the existing X3D version 3.3 architecture.<br />
<br />
*'''Appearance'''<br />
**'''Images''': recommended formats for imagery and video (.gif .bmp .svg .flv .exr .hdr etc.). Consider [http://en.wikipedia.org/wiki/QR_code QR codes] as a first-class image type since it contains imagery and information, especially useful in Mixed Augmented Reality (MAR) applications. Note that SVG is not an image/video format. FLV is not an open format and use of Flash has been deprecated.<br />
**'''Materials''': advanced parameters<br />
**[[X3D Multitexture | Multitexture]]: review for correctness, completeness and conformance of rendering example scenes<br />
**'''Rendering''': bump maps, [http://doc.instantreality.org/tutorial/dynamic-shadows/ shadows], edge smoothing, gamma correction, Non-Photorealistic Rendering (NPR)<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/shaders.html Shaders]: improved support and better interoperability, library of examples; [http://doc.instantreality.org/documentation/nodetype/CommonSurfaceShader/ CommonSurfaceShader?]<br />
**'''Texturing''': [http://en.wikipedia.org/wiki/Texture_atlas Texture atlas], [http://en.wikipedia.org/wiki/Projective_texture_mapping projective texture mapping (PTM)], [http://www.xj3d.org/extensions/render_texture.html RenderedTexture node] for multipass rendering - 2D texture version of GeneratedCubeMapTexture, first proposed by Xj3D and also implemented in X3DOM and InstantReality, useful for all kinds of NPR, shadows, mirrors, etc.<br />
*'''Audio and video''': alignment with [https://www.w3.org/2011/audio W3C Audio Working Group], especially for [https://webaudio.github.io/web-audio-api Web Audio API] and [https://webaudio.github.io/web-midi-api Web Midi API]. Adding royalty-free formats, streamability, [http://web3d.org/pipermail/x3d-public_web3d.org/2013-December/002681.html disabling attenuation], 3D aural spatialization using reflection from simple geometry (such as [http://gamma.cs.unc.edu/Sound/RESound RESOUND]).<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/computer-aided-design-cad Computer Aided Design (CAD)]''' Interactive Profile, to include:<br />
**[http://www.web3d.org/wiki/index.php/X3D_v4.0_CAD_Improvements X3D v4.0 CAD Improvements] with 3D printing + 3D scanning included<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/CADInterchange.html CADInterchange profile] plus FillProperties/LineProperties, primitive/Geometry2D nodes, Extrusion, NURBS, ClipPlane<br />
**Part selection/animation, 3D printing, [http://www.web3d.org/realtime-3d/news/3d-graphics-compress-call-contributions Compressed Binary Encoding (CBE)], possibly [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html annotations component]<br />
** Building Information Models (BIM), Architecture Engineering Construction (AEC), Physical Sensors<br />
*'''[http://www.ecma-international.org/publications/standards/Ecma-262.htm ECMAScript]''' (Javascript) specification revision compatibility with [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html X3D scripting]; possibly add C# or Python support. Note that it is not certain the the current X3D Script node can migrate into DOM-Integrated X3D.<br />
*'''Events'''<br />
** Review X3D event interoperability with other event models, such as Document Object Model (DOM) Recommendations<br />
** Add capability for Event logging and playback so that deterministic replay is possible for demonstrations and debugging<br />
*'''Generalized input/output interface support'''<br />
** Possibly [http://www.cs.unc.edu/Research/vrpn/index.html Virtual Reality Peripheral Network (VRPN)], gesture recognition (such as [http://en.wikipedia.org/wiki/Kinect KINECT], [http://www.leapmotion.com LEAP]), etc.<br />
** Support for arbitrary sensors and user interaction devices<br />
* '''Geometry''': point size (or perspective rendering), progressive meshes (suitable for both compression and streaming), 3D ExtrudedText, support for [http://en.wikipedia.org/wiki/Web_typography Web typography] using [http://www.w3.org/TR/WOFF Web Open Fonts Format (WOFF)]<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/x3d-earth Geospatial X3D]''' component<br />
** [http://www.igraphics.com/Standards/EnhancedGeospatialComponent_2007_10_30/Part01/X3D.html Enhanced Geospatial Component - spatial reference frame (SRF)] and [http://www.opengeospatial.org/standards/kml KML] support, [http://www.opengeospatial.org/projects/initiatives/3dpie OGC 3D Portrayal], [http://web3d.org/pipermail/x3d-public_web3d.org/2010-December/001187.html GpsSensor], [http://openlayers.org OpenLayer] mashups<br />
** GeoSet collection of adjacent GeoElevationGrid nodes to enable proper computation of normals for edge boundaries of adjacent grids<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/h-anim Humanoid Animation (H-Anim)]''' anatomical correctness for skeleton and skinning, motion capture (mocap) and playback, interchangeable avatars, animation for hands feet and faces<br />
* '''Interoperability''': include ''class'' attribute for all nodes to all encodings<br />
* '''[http://www.json.org JSON]''': JavaScript Object Notation as an X3D encoding ([http://web3d.org/pipermail/x3d-public_web3d.org/2014-July/thread.html#2854 assessment thread]), relation to [http://www.khronos.org/gltf GlTF], streaming considerations<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/medx3d Medical working group]''' capabilities<br />
** [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html Annotations component] and metadata usage<br />
** Archival 3D medical records, potential emphasis on [http://en.wikipedia.org/wiki/Traumatic_brain_injury Traumatic brain injury (TBI)] volume visualization<br />
** Haptics component for force feedback; [http://www.w3.org/TR/vibration W3C Vibrations API] for tactile feedback<br />
** Soft-body physics component to complement rigid-body physics component<br />
* '''Mobile Profile.''' TODO - needed? Calling out a reduced palette for mobile devices remains interesting, but might instead remain a browser-optional optimization.<br />
* '''[http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#Nodereference Metadata]''': support for embedding information useful for applications utilizing X3D<br />
** Enumerated types: better access, typing, naming, and validation than using MetadataSet/MetadataString combinations<br />
* '''Mixed and Augmented Reality (MAR)''': follow ISO MAR Reference Model, integrate multiple capabilities with devices situated in real world<br />
*'''Networking''': consider [http://www.web3d.org/x3d/content/examples/Basic/Networking NetworkSensor] and event-passing issues, streaming using [http://www.json.org JSON], server-side 3D topics<br />
*'''Security and privacy''':<br />
** Include X3D Networking Component Level 4 support for https in Immersive, Interactive and other commonly used profiles<br />
** Review X3D specifications to ensure that Security Considerations are fully documented throughout in every component<br />
** [http://www.w3.org/standards/xml/security XML Security] provides best-available encryption, digital signature (authentication)<br />
** [http://www.w3.org/standards/webdesign/privacy Web Privacy]: examine X3D compatibility with Do Not Track, P3P, POWDER<br />
*'''Viewing and navigation''': [http://www.web3d.org/x3d/content/examples/Basic/development/CameraExamplesIndex.html cinematic camera control], alternative navigation types (such as PAN, [http://www.x3dom.org/?p=3536 TURNTABLE] etc.), [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/behaviours.html Recommended navigation behaviours] review, and old MatrixTransform node (esp. useful for CAD, VR/AR etc., implemented in X3DOM and InstantReality)<br />
*'''Virtual Reality (VR)''': requirements definition needed includes viewing with stereo devices, interocular distance, frame-rate requirements, comparison (and potential profile) for [https://webvr.info WebVR] capabilities, physiological considerations, health and safety, relation with Mixed Augmented Reality (MAR), etc.<br />
<br />
All suggestions and recommendations are welcome. Component improvements and additions are approved by Web3D Consortium members.<br />
<br />
* TODO: Which experimental nodes are ready? Candidates include [http://doc.instantreality.org Fraunhofer], X3DOM, Cobweb, other members and working groups?<br />
* TODO: articulate Big Data and Cloud, server-side visualization, related issues.<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered.<br />
<br />
== Backwards and Forwards Compatibility ==<br />
<br />
A major benefit of using the X3D standard is full backwards compatibility with prior VRML97 and X3D content.<br />
Thanks to careful design and insistence on implementation/evaluation, the X3D International Standard has maintained both steady growth and interoperability ever since Virtual Reality Modeling Language (VRML) in 1997. This track record of stability and innovation is among the best in the 3D graphics industry.<br />
<br />
Our goal is to maximize, but not necessarily require, backwards compatibility in version 4.0 with the version 3.x specifications<br />
* A great majority of X3D nodes and features are likely achievable without change<br />
* Some X3D features may require import/export conversion for compatibility (event model reconciliation, ROUTEs and sensors perhaps)<br />
* A few features might be refactored, deprecated or obsoleted (none yet identified)<br />
* Name deconfliction: HTML Script versus embedded X3D Script<br />
<br />
The comprehensive forward compatibility of VRML97 and X3D with later-developed X3D versions shows that careful anticipatory design is achievable.<br />
<br />
X3D version 4.0 Development efforts are currently focused on HTML5, Declarative 3D, X3DOM, and Cobweb with many more issues under consideration.<br />
* Discussion of [[Importing and adding nodes in HTML]]<br />
<br />
X3D Version 4.1 is focused on Mixed and Augmented Reality (MAR) capabilities, which may also require architectural changes. Some new technologies may get pushed from 4.0 to 4.1 (or back again) after careful consideration by the respective working groups.<br />
<br />
Related specification support and changes<br />
*As with all other X3D components, all work is defined in the abstract specification has corresponding file encodings (.x3d .x3dv .x3db) and language bindings (ECMAScript and Java). <br />
*Compatibility concerns include evolutionary efforts to upgrade the X3D Compressed Binary Encoding (CBE), as described in the [http://www.web3d.org/realtime-3d/working-groups/x3d/compressed-binary/x3d-compressed-binary-encoding-call-contributions X3D Compressed Binary Encoding Call For Contributions].<br />
*ECMAScript (JavaScript) support in X3D needs to be upgraded to the new standard for that rapidly improving programming language.<br />
**[http://standards.iso.org/ittf/PubliclyAvailableStandards/c055755_ISO_IEC_16262_2011(E).zip ISO/IEC 16262:2011 Information technology — ECMAScript language specification] (.zip download)<br />
**Downloadable from [http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html ISO Publicly Available Standards] site without charge<br />
**This relates to [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html 19777-1 Part 2, X3D Scene Access Interface (SAI) language bindings for EcmaScript]<br />
<br />
== Architectural Considerations ==<br />
<br />
This section will synopsize significant differences between X3D version 4 and X3D version 3 that may require structural changes in tools and scenes. Special attention is needed to minimize incompatibilities with legacy software and content.<br />
<br />
Much depends on the target environment. X3D V3.x presumes a controlled environment that interacts with the rest of the (computing) world through a well defined API (called SAI). When X3D is running in the browser (as in fully integrated with the DOM), the DOM defines a portion of the environment in which X3D must operate. For that environment it will be necessary to make changes to X3D so that it is compatible with the DOM.<br />
<br />
== Open Questions ==<br />
<br />
* Are MAR abstract design and X3D AR proposals sufficiently mature to enable integration with HTML5/Declarative 3D/X3DOM/Cobweb issues?<br />
* Are the previously X3D Layer/Layering components compatible with HTML5 overlay model? Are they still needed, perhaps for multiscreen or CAVE support?<br />
* Mashup and interoperability support: is anything else needed for broader use with the Web? YouTube etc.<br />
<br />
== Related Work==<br />
<br />
Much careful planning is involved, we are working to ensure that X3D version 4 can be coherently advanced in combination with a [http://www.web3d.org/specifications/X3dSpecificationRelationships.png coordinated set of steadily evolving ISO/IEC standards].<br />
*'''X3D Efficient Binary Encoding (EBE).''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings. See also SRC format (Web3D 2014)and ExternalGeometry node in InstantPlayer and X3DOM<br />
*'''X3D JavaScript Object Notation (JSON) Encoding.''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings.<br />
*'''X3D version 4.0 (HTML5/X3D DOM)'''. This work is proceeding in parallel. X3D version 4 support is expected.<br />
*'''X3D version 4.1 (Mixed and Augmented Reality)'''. Nodes and capabilities in this arena will build on v4.0 and HTML5. Experimentation, evolution and evaluation occurs throughout.<br />
** '''[[Essential Elements of X3D]]''' collects elements that are essential to X3D<br />
<br />
Technologies and activities that relate to X3D version 4 are: <br />
* [https://webvr.info/ '''WebVR'''] "bringing virtual reality to the web" - standardize the interface to VR displays and controllers <br />
* [https://www.w3.org/community/decwebvr/ '''W3C's Declarative WebVR Community Group'''] formed to developed a declarative 3D standard for WebVR<br />
* [https://threejs.org/ '''three.js'''], a JavaScript library<br />
* [https://aframe.io/ '''A-Frame'''] "a web framework for building virtual reality experiences"<br />
* [http://xml3d.org/ '''XML3D'''] " seamless integration of 3D content into HTML pages"<br />
<br />
== Schedule ==<br />
<br />
'''ISO Considerations'''<br />
* Deciding readiness for ISO New Work Item Proposal (NWIP): we need Committee Draft (CD) specification prose for each planned capability.<br />
* Web3D Consortium is not locked into an annual schedule, ISO handling is flexible.<br />
* Once the NWIP is approved, ISO rules for schedule and review are established.<br />
<br />
'''Execution goals'''<br />
* Review progress during monthly calls, Web3D Conference, and SIGGRAPH Conference.<br />
* We are continuing a monthly review schedule for submissions so that we can build out X3D version 4 one component at a time.<br />
* We are planning to have a 1-year deadline for completion of CD specification prose, rather than wait until all possible version 4 work is ready.<br />
* Web3D Consortium members and public review when a final draft specification is ready to proceed to ISO.<br />
* Any new components not meeting Web3D deadlines might be a candidate for deferral to V4.1. Or considered not ready.<br />
<br />
'''Progress'''<br />
<br />
* Active development of X3D, X3DOM and Cobweb content is tracking HTML 5 capabilities now<br />
* We participate and contribute to the W3C Community Group for [http://www.w3.org/community/declarative3d Declarative 3D]</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_version_4.0_Development&diff=9595X3D version 4.0 Development2017-04-26T15:19:23Z<p>Webmaster: /* Candidate Capabilities */ Minor changes related to image formats and ECMAScript.</p>
<hr />
<div>==Genesis and Strategic Overview==<br />
<br />
Web3D Consortium working groups currently define specification goals and requirements. Working group efforts are often the focus for defining and testing new X3D components.<br />
<br />
We publicly review these goals annually during [http://web3dconference.org/ Web3D Conference] and [http://www.siggraph.org/attend/annual-conferences SIGGRAPH] Birds of a Feather (BOF) meetings ([http://www.web3d.org/event/siggraph-2016-conference-colocated-web3d-2016-anaheim-california SIGGRAPH 2016], upcoming SIGGRAPH 2017).<br />
<br />
Suggestions, development and discussion via the [http://web3d.org/mailman/listinfo/x3d-public_web3d.org x3d-public mailing list] is ongoing.<br />
<br />
X3D version 3.4 Development efforts were evolutionary improvements to the widely proven X3D Graphics architecture. Consortium members decided to skip version 3.4 and go straight to version 4.0, prior goals and requirements have all been merged here.<br />
<br />
The Candidate Capabilities list shows that a lot of interesting capabilities have been proposed and are under way for X3D version 4. However, topics on this list are not guaranteed to be completed! Rather these are all works in progress.<br />
<br />
Activity and approval proceeds based on technical contributions and Web3D Consortium Member priorities. Please consider [http://web3d.org/membership/join joining Web3D Consortium] to help advance 3D graphics on the Web.These X3D version 4.0 Development efforts are considering potentially major additions to the baseline X3D architecture.<br />
<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_HTML5 HTML5], [http://www.w3.org/community/declarative3d/ Declarative 3D], CSS, [http://www.x3dom.org X3DOM] (see [http://web3d.org/wiki/images/f/f2/X3DOM_4_WebGL_audience_10_2013.pdf Summary slides (Oct 2013)]), and [http://titania.create3000.de/cobweb/ Cobweb]<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_Augmented_Reality Mixed and Augmented Reality (MAR)] (renamed from Augmented Reality Continuum (ARC)<br />
* Relaxing prior design constraints can enable a broader new basis for X3D integration<br />
* Normalizing interaction semantics with HTML5 can further open up X3D for the vast majority of Web authors<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered. X3D Futures planning is primarily a Web3D Consortium member-only activity, with community input.<br />
<br />
== Legacy Issues ==<br />
<br />
We plan to confirm the existence of complete capabilities for X3D v3.3 prior to final approval of X3D version 4.<br />
<br />
* Full support for all existing X3D v3.3 components:<br />
** At least two compatible implementations (including at least one in open source) plus repeatable example scenes<br />
** Layer, ParticleSystems, RigidBodyPhysics, Shaders, TODO others<br />
** TransformSensor node: [http://doc.instantreality.org/documentation/nodetype/TransformSensor/ IGD] and [http://www.parallelgraphics.com/developer/products/cortona/extensions/transformsensor/ old Cortona]<br />
** Note that it is not a requirement that all features and capabilities in X3D V3.3 are included in V4.0<br />
<br />
* Is it necessary for Layout component to be deprecated or improved?<br />
* Are there other features or capabilities that should not or are not able to move into V4.0?<br />
<br />
== Candidate Capabilities ==<br />
<br />
Each of the following possibilities for X3D version 4 have been discussed by the various X3D working groups during meetings and on mailing lists.<br />
Each potential capability is considered to be a feasible (and in most cases, straightforward) addition to the existing X3D version 3.3 architecture.<br />
<br />
*'''Appearance'''<br />
**'''Images''': recommended formats for imagery and video (.gif .bmp .svg .flv .exr .hdr etc.). Consider [http://en.wikipedia.org/wiki/QR_code QR codes] as a first-class image type since it contains imagery and information, especially useful in Mixed Augmented Reality (MAR) applications. Note that SVG is not an image/video format. FLV is not an open format and use of Flash has been deprecated.<br />
**'''Materials''': advanced parameters<br />
**[[X3D Multitexture | Multitexture]]: review for correctness, completeness and conformance of rendering example scenes<br />
**'''Rendering''': bump maps, [http://doc.instantreality.org/tutorial/dynamic-shadows/ shadows], edge smoothing, gamma correction, Non-Photorealistic Rendering (NPR)<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/shaders.html Shaders]: improved support and better interoperability, library of examples; [http://doc.instantreality.org/documentation/nodetype/CommonSurfaceShader/ CommonSurfaceShader?]<br />
**'''Texturing''': [http://en.wikipedia.org/wiki/Texture_atlas Texture atlas], [http://en.wikipedia.org/wiki/Projective_texture_mapping projective texture mapping (PTM)], [http://www.xj3d.org/extensions/render_texture.html RenderedTexture node] for multipass rendering - 2D texture version of GeneratedCubeMapTexture, first proposed by Xj3D and also implemented in X3DOM and InstantReality, useful for all kinds of NPR, shadows, mirrors, etc.<br />
*'''Audio and video''': alignment with [https://www.w3.org/2011/audio W3C Audio Working Group], especially for [https://webaudio.github.io/web-audio-api Web Audio API] and [https://webaudio.github.io/web-midi-api Web Midi API]. Adding royalty-free formats, streamability, [http://web3d.org/pipermail/x3d-public_web3d.org/2013-December/002681.html disabling attenuation], 3D aural spatialization using reflection from simple geometry (such as [http://gamma.cs.unc.edu/Sound/RESound RESOUND]).<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/computer-aided-design-cad Computer Aided Design (CAD)]''' Interactive Profile, to include:<br />
**[http://www.web3d.org/wiki/index.php/X3D_v4.0_CAD_Improvements X3D v4.0 CAD Improvements] with 3D printing + 3D scanning included<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/CADInterchange.html CADInterchange profile] plus FillProperties/LineProperties, primitive/Geometry2D nodes, Extrusion, NURBS, ClipPlane<br />
**Part selection/animation, 3D printing, [http://www.web3d.org/realtime-3d/news/3d-graphics-compress-call-contributions Compressed Binary Encoding (CBE)], possibly [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html annotations component]<br />
** Building Information Models (BIM), Architecture Engineering Construction (AEC), Physical Sensors<br />
*'''[http://www.ecma-international.org/publications/standards/Ecma-262.htm ECMAScript]''' (Javascript) specification revision compatibility with [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html X3D scripting]; possibly add C# or Python support. Note that it is not certain the the current X3D Script node can migrate into DOM-Integrated X3D.<br />
*'''Events'''<br />
** Review X3D event interoperability with other event models, such as Document Object Model (DOM) Recommendations<br />
** Add capability for Event logging and playback so that deterministic replay is possible for demonstrations and debugging<br />
*'''Generalized input/output interface support'''<br />
** Possibly [http://www.cs.unc.edu/Research/vrpn/index.html Virtual Reality Peripheral Network (VRPN)], gesture recognition (such as [http://en.wikipedia.org/wiki/Kinect KINECT], [http://www.leapmotion.com LEAP]), etc.<br />
** Support for arbitrary sensors and user interaction devices<br />
* '''Geometry''': point size (or perspective rendering), progressive meshes (suitable for both compression and streaming), 3D ExtrudedText, support for [http://en.wikipedia.org/wiki/Web_typography Web typography] using [http://www.w3.org/TR/WOFF Web Open Fonts Format (WOFF)]<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/x3d-earth Geospatial X3D]''' component<br />
** [http://www.igraphics.com/Standards/EnhancedGeospatialComponent_2007_10_30/Part01/X3D.html Enhanced Geospatial Component - spatial reference frame (SRF)] and [http://www.opengeospatial.org/standards/kml KML] support, [http://www.opengeospatial.org/projects/initiatives/3dpie OGC 3D Portrayal], [http://web3d.org/pipermail/x3d-public_web3d.org/2010-December/001187.html GpsSensor], [http://openlayers.org OpenLayer] mashups<br />
** GeoSet collection of adjacent GeoElevationGrid nodes to enable proper computation of normals for edge boundaries of adjacent grids<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/h-anim Humanoid Animation (H-Anim)]''' anatomical correctness for skeleton and skinning, motion capture (mocap) and playback, interchangeable avatars, animation for hands feet and faces<br />
* '''Interoperability''': include ''class'' attribute for all nodes to all encodings<br />
* '''[http://www.json.org JSON]''': JavaScript Object Notation as an X3D encoding ([http://web3d.org/pipermail/x3d-public_web3d.org/2014-July/thread.html#2854 assessment thread]), relation to [http://www.khronos.org/gltf GlTF], streaming considerations<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/medx3d Medical working group]''' capabilities<br />
** [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html Annotations component] and metadata usage<br />
** Archival 3D medical records, potential emphasis on [http://en.wikipedia.org/wiki/Traumatic_brain_injury Traumatic brain injury (TBI)] volume visualization<br />
** Haptics component for force feedback; [http://www.w3.org/TR/vibration W3C Vibrations API] for tactile feedback<br />
** Soft-body physics component to complement rigid-body physics component<br />
* '''Mobile Profile.''' TODO - needed? Calling out a reduced palette for mobile devices remains interesting, but might instead remain a browser-optional optimization.<br />
* '''[http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#Nodereference Metadata]''': support for embedding information useful for applications utilizing X3D<br />
** Enumerated types: better access, typing, naming, and validation than using MetadataSet/MetadataString combinations<br />
* '''Mixed and Augmented Reality (MAR)''': follow ISO MAR Reference Model, integrate multiple capabilities with devices situated in real world<br />
*'''Networking''': consider [http://www.web3d.org/x3d/content/examples/Basic/Networking NetworkSensor] and event-passing issues, streaming using [http://www.json.org JSON], server-side 3D topics<br />
*'''Security and privacy''':<br />
** Include X3D Networking Component Level 4 support for https in Immersive, Interactive and other commonly used profiles<br />
** Review X3D specifications to ensure that Security Considerations are fully documented throughout in every component<br />
** [http://www.w3.org/standards/xml/security XML Security] provides best-available encryption, digital signature (authentication)<br />
** [http://www.w3.org/standards/webdesign/privacy Web Privacy]: examine X3D compatibility with Do Not Track, P3P, POWDER<br />
*'''Viewing and navigation''': [http://www.web3d.org/x3d/content/examples/Basic/development/CameraExamplesIndex.html cinematic camera control], alternative navigation types (such as PAN, [http://www.x3dom.org/?p=3536 TURNTABLE] etc.), [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/behaviours.html Recommended navigation behaviours] review, and old MatrixTransform node (esp. useful for CAD, VR/AR etc., implemented in X3DOM and InstantReality)<br />
*'''Virtual Reality (VR)''': requirements definition needed includes viewing with stereo devices, interocular distance, frame-rate requirements, comparison (and potential profile) for [https://webvr.info WebVR] capabilities, physiological considerations, health and safety, relation with Mixed Augmented Reality (MAR), etc.<br />
<br />
All suggestions and recommendations are welcome. Component improvements and additions are approved by Web3D Consortium members.<br />
<br />
* TODO: Which experimental nodes are ready? Candidates include [http://doc.instantreality.org Fraunhofer], X3DOM, Cobweb, other members and working groups?<br />
* TODO: articulate Big Data and Cloud, server-side visualization, related issues.<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered.<br />
<br />
== Backwards and Forwards Compatibility ==<br />
<br />
A major benefit of using the X3D standard is full backwards compatibility with prior VRML97 and X3D content.<br />
Thanks to careful design and insistence on implementation/evaluation, the X3D International Standard has maintained both steady growth and interoperability ever since Virtual Reality Modeling Language (VRML) in 1997. This track record of stability and innovation is among the best in the 3D graphics industry.<br />
<br />
Our goal is to maximize, but not necessarily require, backwards compatibility in version 4.0 with the version 3.x specifications<br />
* A great majority of X3D nodes and features are likely achievable without change<br />
* Some X3D features may require import/export conversion for compatibility (event model reconciliation, ROUTEs and sensors perhaps)<br />
* A few features might be refactored, deprecated or obsoleted (none yet identified)<br />
* Name deconfliction: HTML Script versus embedded X3D Script<br />
<br />
The comprehensive forward compatibility of VRML97 and X3D with later-developed X3D versions shows that careful anticipatory design is achievable.<br />
<br />
X3D version 4.0 Development efforts are currently focused on HTML5, Declarative 3D, X3DOM, and Cobweb with many more issues under consideration.<br />
* Discussion of [[Importing and adding nodes in HTML]]<br />
<br />
X3D Version 4.1 is focused on Mixed and Augmented Reality (MAR) capabilities, which may also require architectural changes. Some new technologies may get pushed from 4.0 to 4.1 (or back again) after careful consideration by the respective working groups.<br />
<br />
Related specification support and changes<br />
*As with all other X3D components, all work is defined in the abstract specification has corresponding file encodings (.x3d .x3dv .x3db) and language bindings (ECMAScript and Java). <br />
*Compatibility concerns include evolutionary efforts to upgrade the X3D Compressed Binary Encoding (CBE), as described in the [http://www.web3d.org/realtime-3d/working-groups/x3d/compressed-binary/x3d-compressed-binary-encoding-call-contributions X3D Compressed Binary Encoding Call For Contributions].<br />
*ECMAScript (JavaScript) support in X3D needs to be upgraded to the new standard for that rapidly improving programming language.<br />
**[http://standards.iso.org/ittf/PubliclyAvailableStandards/c055755_ISO_IEC_16262_2011(E).zip ISO/IEC 16262:2011 Information technology — ECMAScript language specification] (.zip download)<br />
**Downloadable from [http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html ISO Publicly Available Standards] site without charge<br />
**This relates to [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html 19777-1 Part 2, X3D Scene Access Interface (SAI) language bindings for EcmaScript]<br />
<br />
== Architectural Considerations ==<br />
<br />
This section will synopsize significant differences between X3D version 4 and X3D version 3 that may require structural changes in tools and scenes. Special attention is needed to minimize incompatibilities with legacy software and content.<br />
<br />
== Open Questions ==<br />
<br />
* Are MAR abstract design and X3D AR proposals sufficiently mature to enable integration with HTML5/Declarative 3D/X3DOM/Cobweb issues?<br />
* Are the previously X3D Layer/Layering components compatible with HTML5 overlay model? Are they still needed, perhaps for multiscreen or CAVE support?<br />
* Mashup and interoperability support: is anything else needed for broader use with the Web? YouTube etc.<br />
<br />
== Related Work==<br />
<br />
Much careful planning is involved, we are working to ensure that X3D version 4 can be coherently advanced in combination with a [http://www.web3d.org/specifications/X3dSpecificationRelationships.png coordinated set of steadily evolving ISO/IEC standards].<br />
*'''X3D Efficient Binary Encoding (EBE).''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings. See also SRC format (Web3D 2014)and ExternalGeometry node in InstantPlayer and X3DOM<br />
*'''X3D JavaScript Object Notation (JSON) Encoding.''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings.<br />
*'''X3D version 4.0 (HTML5/X3D DOM)'''. This work is proceeding in parallel. X3D version 4 support is expected.<br />
*'''X3D version 4.1 (Mixed and Augmented Reality)'''. Nodes and capabilities in this arena will build on v4.0 and HTML5. Experimentation, evolution and evaluation occurs throughout.<br />
** '''[[Essential Elements of X3D]]''' collects elements that are essential to X3D<br />
<br />
Technologies and activities that relate to X3D version 4 are: <br />
* [https://webvr.info/ '''WebVR'''] "bringing virtual reality to the web" - standardize the interface to VR displays and controllers <br />
* [https://www.w3.org/community/decwebvr/ '''W3C's Declarative WebVR Community Group'''] formed to developed a declarative 3D standard for WebVR<br />
* [https://threejs.org/ '''three.js'''], a JavaScript library<br />
* [https://aframe.io/ '''A-Frame'''] "a web framework for building virtual reality experiences"<br />
* [http://xml3d.org/ '''XML3D'''] " seamless integration of 3D content into HTML pages"<br />
<br />
== Schedule ==<br />
<br />
'''ISO Considerations'''<br />
* Deciding readiness for ISO New Work Item Proposal (NWIP): we need Committee Draft (CD) specification prose for each planned capability.<br />
* Web3D Consortium is not locked into an annual schedule, ISO handling is flexible.<br />
* Once the NWIP is approved, ISO rules for schedule and review are established.<br />
<br />
'''Execution goals'''<br />
* Review progress during monthly calls, Web3D Conference, and SIGGRAPH Conference.<br />
* We are continuing a monthly review schedule for submissions so that we can build out X3D version 4 one component at a time.<br />
* We are planning to have a 1-year deadline for completion of CD specification prose, rather than wait until all possible version 4 work is ready.<br />
* Web3D Consortium members and public review when a final draft specification is ready to proceed to ISO.<br />
* Any new components not meeting Web3D deadlines might be a candidate for deferral to V4.1. Or considered not ready.<br />
<br />
'''Progress'''<br />
<br />
* Active development of X3D, X3DOM and Cobweb content is tracking HTML 5 capabilities now<br />
* We participate and contribute to the W3C Community Group for [http://www.w3.org/community/declarative3d Declarative 3D]</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_version_4.0_Development&diff=9592X3D version 4.0 Development2017-04-26T15:07:06Z<p>Webmaster: /* Legacy Issues */ notes about V4.0 is not a superset of V3.3</p>
<hr />
<div>==Genesis and Strategic Overview==<br />
<br />
Web3D Consortium working groups currently define specification goals and requirements. Working group efforts are often the focus for defining and testing new X3D components.<br />
<br />
We publicly review these goals annually during [http://web3dconference.org/ Web3D Conference] and [http://www.siggraph.org/attend/annual-conferences SIGGRAPH] Birds of a Feather (BOF) meetings ([http://www.web3d.org/event/siggraph-2016-conference-colocated-web3d-2016-anaheim-california Siggraph 2016]).<br />
<br />
Suggestions, development and discussion via the [http://web3d.org/mailman/listinfo/x3d-public_web3d.org x3d-public mailing list] is ongoing.<br />
<br />
X3D version 3.4 Development efforts were evolutionary improvements to the widely proven X3D Graphics architecture. Consortium members decided to skip version 3.4 and go straight to version 4.0, prior goals and requirements have all been merged here.<br />
<br />
The Candidate Capabilities list shows that a lot of interesting capabilities have been proposed and are under way for X3D version 4. However, topics on this list are not guaranteed to be completed! Rather these are all works in progress.<br />
<br />
Activity and approval proceeds based on technical contributions and Web3D Consortium Member priorities. Please consider [http://web3d.org/membership/join joining Web3D Consortium] to help advance 3D graphics on the Web.These X3D version 4.0 Development efforts are considering potentially major additions to the baseline X3D architecture.<br />
<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_HTML5 HTML5], [http://www.w3.org/community/declarative3d/ Declarative 3D], CSS, [http://www.x3dom.org X3DOM] (see [http://web3d.org/wiki/images/f/f2/X3DOM_4_WebGL_audience_10_2013.pdf Summary slides (Oct 2013)]), and [http://titania.create3000.de/cobweb/ Cobweb]<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_Augmented_Reality Mixed and Augmented Reality (MAR)] (renamed from Augmented Reality Continuum (ARC)<br />
* Relaxing prior design constraints can enable a broader new basis for X3D integration<br />
* Normalizing interaction semantics with HTML5 can further open up X3D for the vast majority of Web authors<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered. X3D Futures planning is primarily a Web3D Consortium member-only activity, with community input.<br />
<br />
== Legacy Issues ==<br />
<br />
We plan to confirm the existence of complete capabilities for X3D v3.3 prior to final approval of X3D version 4.<br />
<br />
* Full support for all existing X3D v3.3 components:<br />
** At least two compatible implementations (including at least one in open source) plus repeatable example scenes<br />
** Layer, ParticleSystems, RigidBodyPhysics, Shaders, TODO others<br />
** TransformSensor node: [http://doc.instantreality.org/documentation/nodetype/TransformSensor/ IGD] and [http://www.parallelgraphics.com/developer/products/cortona/extensions/transformsensor/ old Cortona]<br />
** Note that it is not a requirement that all features and capabilities in X3D V3.3 are included in V4.0<br />
<br />
* Is it necessary for Layout component to be deprecated or improved?<br />
* Are there other features or capabilities are should not or are not able to move into V4.0?<br />
<br />
== Candidate Capabilities ==<br />
<br />
Each of the following possibilities for X3D version 4 have been discussed by the various X3D working groups during meetings and on mailing lists.<br />
Each potential capability is considered to be a feasible (and in most cases, straightforward) addition to the existing X3D version 3.3 architecture.<br />
<br />
*'''Appearance'''<br />
**'''Images''': recommended formats for imagery and video (.gif .bmp .svg .flv .exr .hdr etc.). Consider [http://en.wikipedia.org/wiki/QR_code QR codes] as a first-class image type since it contains imagery and information, especially useful in Mixed Augmented Reality (MAR) applications<br />
**'''Materials''': advanced parameters<br />
**[[X3D Multitexture | Multitexture]]: review for correctness, completeness and conformance of rendering example scenes<br />
**'''Rendering''': bump maps, [http://doc.instantreality.org/tutorial/dynamic-shadows/ shadows], edge smoothing, gamma correction, Non-Photorealistic Rendering (NPR)<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/shaders.html Shaders]: improved support and better interoperability, library of examples; [http://doc.instantreality.org/documentation/nodetype/CommonSurfaceShader/ CommonSurfaceShader?]<br />
**'''Texturing''': [http://en.wikipedia.org/wiki/Texture_atlas Texture atlas], [http://en.wikipedia.org/wiki/Projective_texture_mapping projective texture mapping (PTM)], [http://www.xj3d.org/extensions/render_texture.html RenderedTexture node] for multipass rendering - 2D texture version of GeneratedCubeMapTexture, first proposed by Xj3D and also implemented in X3DOM and InstantReality, useful for all kinds of NPR, shadows, mirrors, etc.<br />
*'''Audio and video''': alignment with [https://www.w3.org/2011/audio W3C Audio Working Group], especially for [https://webaudio.github.io/web-audio-api Web Audio API] and [https://webaudio.github.io/web-midi-api Web Midi API]. Adding royalty-free formats, streamability, [http://web3d.org/pipermail/x3d-public_web3d.org/2013-December/002681.html disabling attenuation], 3D aural spatialization using reflection from simple geometry (such as [http://gamma.cs.unc.edu/Sound/RESound RESOUND]).<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/computer-aided-design-cad Computer Aided Design (CAD)]''' Interactive Profile, to include:<br />
**[http://www.web3d.org/wiki/index.php/X3D_v4.0_CAD_Improvements X3D v4.0 CAD Improvements] with 3D printing + 3D scanning included<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/CADInterchange.html CADInterchange profile] plus FillProperties/LineProperties, primitive/Geometry2D nodes, Extrusion, NURBS, ClipPlane<br />
**Part selection/animation, 3D printing, [http://www.web3d.org/realtime-3d/news/3d-graphics-compress-call-contributions Compressed Binary Encoding (CBE)], possibly [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html annotations component]<br />
** Building Information Models (BIM), Architecture Engineering Construction (AEC), Physical Sensors<br />
*'''[http://www.ecma-international.org/publications/standards/Ecma-262.htm ECMAScript]''' (Javascript) specification revision compatibility with [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html X3D scripting]; possibly add C# or Python support<br />
*'''Events'''<br />
** Review X3D event interoperability with other event models, such as Document Object Model (DOM) Recommendations<br />
** Add capability for Event logging and playback so that deterministic replay is possible for demonstrations and debugging<br />
*'''Generalized input/output interface support'''<br />
** Possibly [http://www.cs.unc.edu/Research/vrpn/index.html Virtual Reality Peripheral Network (VRPN)], gesture recognition (such as [http://en.wikipedia.org/wiki/Kinect KINECT], [http://www.leapmotion.com LEAP]), etc.<br />
** Support for arbitrary sensors and user interaction devices<br />
* '''Geometry''': point size (or perspective rendering), progressive meshes (suitable for both compression and streaming), 3D ExtrudedText, support for [http://en.wikipedia.org/wiki/Web_typography Web typography] using [http://www.w3.org/TR/WOFF Web Open Fonts Format (WOFF)]<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/x3d-earth Geospatial X3D]''' component<br />
** [http://www.igraphics.com/Standards/EnhancedGeospatialComponent_2007_10_30/Part01/X3D.html Enhanced Geospatial Component - spatial reference frame (SRF)] and [http://www.opengeospatial.org/standards/kml KML] support, [http://www.opengeospatial.org/projects/initiatives/3dpie OGC 3D Portrayal], [http://web3d.org/pipermail/x3d-public_web3d.org/2010-December/001187.html GpsSensor], [http://openlayers.org OpenLayer] mashups<br />
** GeoSet collection of adjacent GeoElevationGrid nodes to enable proper computation of normals for edge boundaries of adjacent grids<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/h-anim Humanoid Animation (H-Anim)]''' anatomical correctness for skeleton and skinning, motion capture (mocap) and playback, interchangeable avatars, animation for hands feet and faces<br />
* '''Interoperability''': include ''class'' attribute for all nodes to all encodings<br />
* '''[http://www.json.org JSON]''': JavaScript Object Notation as an X3D encoding ([http://web3d.org/pipermail/x3d-public_web3d.org/2014-July/thread.html#2854 assessment thread]), relation to [http://www.khronos.org/gltf GlTF], streaming considerations<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/medx3d Medical working group]''' capabilities<br />
** [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html Annotations component] and metadata usage<br />
** Archival 3D medical records, potential emphasis on [http://en.wikipedia.org/wiki/Traumatic_brain_injury Traumatic brain injury (TBI)] volume visualization<br />
** Haptics component for force feedback; [http://www.w3.org/TR/vibration W3C Vibrations API] for tactile feedback<br />
** Soft-body physics component to complement rigid-body physics component<br />
* '''Mobile Profile.''' TODO - needed? Calling out a reduced palette for mobile devices remains interesting, but might instead remain a browser-optional optimization.<br />
* '''[http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#Nodereference Metadata]''': support for embedding information useful for applications utilizing X3D<br />
** Enumerated types: better access, typing, naming, and validation than using MetadataSet/MetadataString combinations<br />
* '''Mixed and Augmented Reality (MAR)''': follow ISO MAR Reference Model, integrate multiple capabilities with devices situated in real world<br />
*'''Networking''': consider [http://www.web3d.org/x3d/content/examples/Basic/Networking NetworkSensor] and event-passing issues, streaming using [http://www.json.org JSON], server-side 3D topics<br />
*'''Security and privacy''':<br />
** Include X3D Networking Component Level 4 support for https in Immersive, Interactive and other commonly used profiles<br />
** Review X3D specifications to ensure that Security Considerations are fully documented throughout in every component<br />
** [http://www.w3.org/standards/xml/security XML Security] provides best-available encryption, digital signature (authentication)<br />
** [http://www.w3.org/standards/webdesign/privacy Web Privacy]: examine X3D compatibility with Do Not Track, P3P, POWDER<br />
*'''Viewing and navigation''': [http://www.web3d.org/x3d/content/examples/Basic/development/CameraExamplesIndex.html cinematic camera control], alternative navigation types (such as PAN, [http://www.x3dom.org/?p=3536 TURNTABLE] etc.), [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/behaviours.html Recommended navigation behaviours] review, and old MatrixTransform node (esp. useful for CAD, VR/AR etc., implemented in X3DOM and InstantReality)<br />
*'''Virtual Reality (VR)''': requirements definition needed includes viewing with stereo devices, interocular distance, frame-rate requirements, comparison (and potential profile) for [https://webvr.info WebVR] capabilities, physiological considerations, health and safety, relation with Mixed Augmented Reality (MAR), etc.<br />
<br />
All suggestions and recommendations are welcome. Component improvements and additions are approved by Web3D Consortium members.<br />
<br />
* TODO: Which experimental nodes are ready? Candidates include [http://doc.instantreality.org Fraunhofer], X3DOM, Cobweb, other members and working groups?<br />
* TODO: articulate Big Data and Cloud, server-side visualization, related issues.<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered.<br />
<br />
== Backwards and Forwards Compatibility ==<br />
<br />
A major benefit of using the X3D standard is full backwards compatibility with prior VRML97 and X3D content.<br />
Thanks to careful design and insistence on implementation/evaluation, the X3D International Standard has maintained both steady growth and interoperability ever since Virtual Reality Modeling Language (VRML) in 1997. This track record of stability and innovation is among the best in the 3D graphics industry.<br />
<br />
Our goal is to maximize, but not necessarily require, backwards compatibility in version 4.0 with the version 3.x specifications<br />
* A great majority of X3D nodes and features are likely achievable without change<br />
* Some X3D features may require import/export conversion for compatibility (event model reconciliation, ROUTEs and sensors perhaps)<br />
* A few features might be refactored, deprecated or obsoleted (none yet identified)<br />
* Name deconfliction: HTML Script versus embedded X3D Script<br />
<br />
The comprehensive forward compatibility of VRML97 and X3D with later-developed X3D versions shows that careful anticipatory design is achievable.<br />
<br />
X3D version 4.0 Development efforts are currently focused on HTML5, Declarative 3D, X3DOM, and Cobweb with many more issues under consideration.<br />
* Discussion of [[Importing and adding nodes in HTML]]<br />
<br />
X3D Version 4.1 is focused on Mixed and Augmented Reality (MAR) capabilities, which may also require architectural changes. Some new technologies may get pushed from 4.0 to 4.1 (or back again) after careful consideration by the respective working groups.<br />
<br />
Related specification support and changes<br />
*As with all other X3D components, all work is defined in the abstract specification has corresponding file encodings (.x3d .x3dv .x3db) and language bindings (ECMAScript and Java). <br />
*Compatibility concerns include evolutionary efforts to upgrade the X3D Compressed Binary Encoding (CBE), as described in the [http://www.web3d.org/realtime-3d/working-groups/x3d/compressed-binary/x3d-compressed-binary-encoding-call-contributions X3D Compressed Binary Encoding Call For Contributions].<br />
*ECMAScript (JavaScript) support in X3D needs to be upgraded to the new standard for that rapidly improving programming language.<br />
**[http://standards.iso.org/ittf/PubliclyAvailableStandards/c055755_ISO_IEC_16262_2011(E).zip ISO/IEC 16262:2011 Information technology — ECMAScript language specification] (.zip download)<br />
**Downloadable from [http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html ISO Publicly Available Standards] site without charge<br />
**This relates to [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html 19777-1 Part 2, X3D Scene Access Interface (SAI) language bindings for EcmaScript]<br />
<br />
== Architectural Considerations ==<br />
<br />
This section will synopsize significant differences between X3D version 4 and X3D version 3 that may require structural changes in tools and scenes. Special attention is needed to minimize incompatibilities with legacy software and content.<br />
<br />
== Open Questions ==<br />
<br />
* Are MAR abstract design and X3D AR proposals sufficiently mature to enable integration with HTML5/Declarative 3D/X3DOM/Cobweb issues?<br />
* Are the previously X3D Layer/Layering components compatible with HTML5 overlay model? Are they still needed, perhaps for multiscreen or CAVE support?<br />
* Mashup and interoperability support: is anything else needed for broader use with the Web? YouTube etc.<br />
<br />
== Related Work==<br />
<br />
Much careful planning is involved, we are working to ensure that X3D version 4 can be coherently advanced in combination with a [http://www.web3d.org/specifications/X3dSpecificationRelationships.png coordinated set of steadily evolving ISO/IEC standards].<br />
*'''X3D Efficient Binary Encoding (EBE).''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings. See also SRC format (Web3D 2014)and ExternalGeometry node in InstantPlayer and X3DOM<br />
*'''X3D JavaScript Object Notation (JSON) Encoding.''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings.<br />
*'''X3D version 4.0 (HTML5/X3D DOM)'''. This work is proceeding in parallel. X3D version 4 support is expected.<br />
*'''X3D version 4.1 (Mixed and Augmented Reality)'''. Nodes and capabilities in this arena will build on v4.0 and HTML5. Experimentation, evolution and evaluation occurs throughout.<br />
** '''[[Essential Elements of X3D]]''' collects elements that are essential to X3D<br />
<br />
Technologies and activities that relate to X3D version 4 are: <br />
* [https://webvr.info/ '''WebVR'''] "bringing virtual reality to the web" - standardize the interface to VR displays and controllers <br />
* [https://www.w3.org/community/decwebvr/ '''W3C's Declarative WebVR Community Group'''] formed to developed a declarative 3D standard for WebVR<br />
* [https://threejs.org/ '''three.js'''], a JavaScript library<br />
* [https://aframe.io/ '''A-Frame'''] "a web framework for building virtual reality experiences"<br />
* [http://xml3d.org/ '''XML3D'''] " seamless integration of 3D content into HTML pages"<br />
<br />
== Schedule ==<br />
<br />
'''ISO Considerations'''<br />
* Deciding readiness for ISO New Work Item Proposal (NWIP): we need Committee Draft (CD) specification prose for each planned capability.<br />
* Web3D Consortium is not locked into an annual schedule, ISO handling is flexible.<br />
* Once the NWIP is approved, ISO rules for schedule and review are established.<br />
<br />
'''Execution goals'''<br />
* Review progress during monthly calls, Web3D Conference, and SIGGRAPH Conference.<br />
* We are continuing a monthly review schedule for submissions so that we can build out X3D version 4 one component at a time.<br />
* We are planning to have a 1-year deadline for completion of CD specification prose, rather than wait until all possible version 4 work is ready.<br />
* Web3D Consortium members and public review when a final draft specification is ready to proceed to ISO.<br />
* Any new components not meeting Web3D deadlines might be a candidate for deferral to V4.1. Or considered not ready.<br />
<br />
'''Progress'''<br />
<br />
* Active development of X3D, X3DOM and Cobweb content is tracking HTML 5 capabilities now<br />
* We participate and contribute to the W3C Community Group for [http://www.w3.org/community/declarative3d Declarative 3D]</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_version_4.0_Development&diff=9583X3D version 4.0 Development2017-04-19T16:10:14Z<p>Webmaster: /* Genesis and Strategic Overview */ Updated SIGGRAPH BOF link</p>
<hr />
<div>==Genesis and Strategic Overview==<br />
<br />
Web3D Consortium working groups currently define specification goals and requirements. Working group efforts are often the focus for defining and testing new X3D components.<br />
<br />
We publicly review these goals annually during [http://web3dconference.org/ Web3D Conference] and SIGGRAPH BOF ([http://s2016.siggraph.org/birds-feather SIGGRAPH 2016]) meetings.<br />
<br />
Suggestions, development and discussion via the [http://web3d.org/mailman/listinfo/x3d-public_web3d.org x3d-public mailing list] is ongoing.<br />
<br />
X3D version 3.4 Development efforts were evolutionary improvements to the widely proven X3D Graphics architecture. Consortium members decided to skip version 3.4 and go straight to version 4.0, prior goals and requirements have all been merged here.<br />
<br />
The Candidate Capabilities list shows that a lot of interesting capabilities have been proposed and are under way for X3D version 4. However, topics on this list are not guaranteed to be completed! Rather these are all works in progress.<br />
<br />
Activity and approval proceeds based on technical contributions and Web3D Consortium Member priorities. Please consider [http://web3d.org/membership/join joining Web3D Consortium] to help advance 3D graphics on the Web.These X3D version 4.0 Development efforts are considering potentially major additions to the baseline X3D architecture.<br />
<br />
* [http://web3d.org/wiki/images/f/f2/X3DOM_4_WebGL_audience_10_2013.pdf Summary slides here (Oct 2013)] summarize this steadily continuing effort<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_HTML5 HTML5], [http://www.w3.org/community/declarative3d/ Declarative 3D], [http://www.x3dom.org X3DOM], and possibly CSS<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_Augmented_Reality Augmented Reality Continuum (ARC)] (being renamed as Mixed Augmented Reality MAR)<br />
* Relaxing prior design constraints can enable a broader new basis for X3D integration<br />
* Normalizing interaction semantics with HTML5 - now a stable W3C Recommendation - can further open up X3D for the vast majority of Web authors<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered. X3D Futures planning is currently a Web3D Consortium member-only activity.<br />
<br />
== Legacy Issues ==<br />
<br />
We plan to confirm the existence of complete capabilities for X3D v3.3 prior to final approval of X3D version 4.<br />
<br />
* Full support for all existing X3D v3.3 components:<br />
** At least two compatible implementations (including at least one in open source) plus repeatable example scenes<br />
** Layer, ParticleSystems, RigidBodyPhysics, Shaders, TODO others<br />
** TransformSensor node: [http://doc.instantreality.org/documentation/nodetype/TransformSensor/ IGD] and [http://www.parallelgraphics.com/developer/products/cortona/extensions/transformsensor/ old Cortona]<br />
<br />
* Is it necessary for Layout component to be deprecated or improved?<br />
<br />
== Candidate Capabilities ==<br />
<br />
Each of the following possibilities for X3D version 4 have been discussed by the various X3D working groups during meetings and on mailing lists.<br />
Each potential capability is considered to be a feasible (and in most cases, straightforward) addition to the existing X3D version 3.3 architecture.<br />
<br />
*'''Appearance'''<br />
**'''Images''': recommended formats for imagery and video (.gif .bmp .svg .flv .exr .hdr etc.). Consider [http://en.wikipedia.org/wiki/QR_code QR codes] as a first-class image type since it contains imagery and information, especially useful in Mixed Augmented Reality (MAR) applications<br />
**'''Materials''': advanced parameters<br />
**[[X3D Multitexture | Multitexture]]: review for correctness, completeness and conformance of rendering example scenes<br />
**'''Rendering''': bump maps, [http://doc.instantreality.org/tutorial/dynamic-shadows/ shadows], edge smoothing, gamma correction, Non-Photorealistic Rendering (NPR)<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/shaders.html Shaders]: improved support and better interoperability, library of examples; [http://doc.instantreality.org/documentation/nodetype/CommonSurfaceShader/ CommonSurfaceShader?]<br />
**'''Texturing''': [http://en.wikipedia.org/wiki/Texture_atlas Texture atlas], [http://en.wikipedia.org/wiki/Projective_texture_mapping projective texture mapping (PTM)], [http://www.xj3d.org/extensions/render_texture.html RenderedTexture node] for multipass rendering - 2D texture version of GeneratedCubeMapTexture, first proposed by Xj3D and also implemented in X3DOM and InstantReality, useful for all kinds of NPR, shadows, mirrors, etc.<br />
*'''Audio and video''': alignment with [https://www.w3.org/2011/audio W3C Audio Working Group], especially for [https://webaudio.github.io/web-audio-api Web Audio API] and [https://webaudio.github.io/web-midi-api Web Midi API]. Adding royalty-free formats, streamability, [http://web3d.org/pipermail/x3d-public_web3d.org/2013-December/002681.html disabling attenuation], 3D aural spatialization using reflection from simple geometry (such as [http://gamma.cs.unc.edu/Sound/RESound RESOUND]).<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/computer-aided-design-cad Computer Aided Design (CAD)]''' Interactive Profile, to include:<br />
**[http://www.web3d.org/wiki/index.php/X3D_v4.0_CAD_Improvements X3D v4.0 CAD Improvements] with 3D printing + 3D scanning included<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/CADInterchange.html CADInterchange profile] plus FillProperties/LineProperties, primitive/Geometry2D nodes, Extrusion, NURBS, ClipPlane<br />
**Part selection/animation, 3D printing, [http://www.web3d.org/realtime-3d/news/3d-graphics-compress-call-contributions Compressed Binary Encoding (CBE)], possibly [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html annotations component]<br />
** Building Information Models (BIM), Architecture Engineering Construction (AEC), Physical Sensors<br />
*'''[http://www.ecma-international.org/publications/standards/Ecma-262.htm ECMAScript]''' (Javascript) specification revision compatibility with [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html X3D scripting]; possibly add C# or Python support<br />
*'''Events'''<br />
** Review X3D event interoperability with other event models, such as Document Object Model (DOM) Recommendations<br />
** Add capability for Event logging and playback so that deterministic replay is possible for demonstrations and debugging<br />
*'''Generalized input/output interface support'''<br />
** Possibly [http://www.cs.unc.edu/Research/vrpn/index.html Virtual Reality Peripheral Network (VRPN)], gesture recognition (such as [http://en.wikipedia.org/wiki/Kinect KINECT], [http://www.leapmotion.com LEAP]), etc.<br />
** Support for arbitrary sensors and user interaction devices<br />
* '''Geometry''': point size (or perspective rendering), progressive meshes (suitable for both compression and streaming), 3D ExtrudedText, support for [http://en.wikipedia.org/wiki/Web_typography Web typography] using [http://www.w3.org/TR/WOFF Web Open Fonts Format (WOFF)]<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/x3d-earth Geospatial X3D]''' component<br />
** [http://www.igraphics.com/Standards/EnhancedGeospatialComponent_2007_10_30/Part01/X3D.html Enhanced Geospatial Component - spatial reference frame (SRF)] and [http://www.opengeospatial.org/standards/kml KML] support, [http://www.opengeospatial.org/projects/initiatives/3dpie OGC 3D Portrayal], [http://web3d.org/pipermail/x3d-public_web3d.org/2010-December/001187.html GpsSensor], [http://openlayers.org OpenLayer] mashups<br />
** GeoSet collection of adjacent GeoElevationGrid nodes to enable proper computation of normals for edge boundaries of adjacent grids<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/h-anim Humanoid Animation (H-Anim)]''' anatomical correctness for skeleton and skinning, motion capture (mocap) and playback, interchangeable avatars, animation for hands feet and faces<br />
* '''Interoperability''': include ''class'' attribute for all nodes to all encodings<br />
* '''[http://www.json.org JSON]''': JavaScript Object Notation as an X3D encoding ([http://web3d.org/pipermail/x3d-public_web3d.org/2014-July/thread.html#2854 assessment thread]), relation to [http://www.khronos.org/gltf GlTF], streaming considerations<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/medx3d Medical working group]''' capabilities<br />
** [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html Annotations component] and metadata usage<br />
** Archival 3D medical records, potential emphasis on [http://en.wikipedia.org/wiki/Traumatic_brain_injury Traumatic brain injury (TBI)] volume visualization<br />
** Haptics component for force feedback; [http://www.w3.org/TR/vibration W3C Vibrations API] for tactile feedback<br />
** Soft-body physics component to complement rigid-body physics component<br />
* '''Mobile Profile.''' TODO - needed? Calling out a reduced palette for mobile devices remains interesting, but might instead remain a browser-optional optimization.<br />
* '''[http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#Nodereference Metadata]''': support for embedding information useful for applications utilizing X3D<br />
** Enumerated types: better access, typing, naming, and validation than using MetadataSet/MetadataString combinations<br />
* '''Mixed and Augmented Reality (MAR)''': follow ISO MAR Reference Model, integrate multiple capabilities with devices situated in real world<br />
*'''Networking''': consider [http://www.web3d.org/x3d/content/examples/Basic/Networking NetworkSensor] and event-passing issues, streaming using [http://www.json.org JSON], server-side 3D topics<br />
*'''Security and privacy''':<br />
** Include X3D Networking Component Level 4 support for https in Immersive, Interactive and other commonly used profiles<br />
** Review X3D specifications to ensure that Security Considerations are fully documented throughout in every component<br />
** [http://www.w3.org/standards/xml/security XML Security] provides best-available encryption, digital signature (authentication)<br />
** [http://www.w3.org/standards/webdesign/privacy Web Privacy]: examine X3D compatibility with Do Not Track, P3P, POWDER<br />
*'''Viewing and navigation''': [http://www.web3d.org/x3d/content/examples/Basic/development/CameraExamplesIndex.html cinematic camera control], alternative navigation types (such as PAN, [http://www.x3dom.org/?p=3536 TURNTABLE] etc.), [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/behaviours.html Recommended navigation behaviours] review, and old MatrixTransform node (esp. useful for CAD, VR/AR etc., implemented in X3DOM and InstantReality)<br />
*'''Virtual Reality (VR)''': requirements definition needed includes viewing with stereo devices, interocular distance, frame-rate requirements, comparison (and potential profile) for [https://webvr.info WebVR] capabilities, physiological considerations, health and safety, relation with Mixed Augmented Reality (MAR), etc.<br />
<br />
All suggestions and recommendations are welcome. Component improvements and additions are approved by Web3D Consortium members.<br />
<br />
* TODO: Which experimental nodes are ready? Candidates include [http://doc.instantreality.org Fraunhofer], X3DOM, Cobweb, other members and working groups?<br />
* TODO: articulate Big Data and Cloud, server-side visualization, related issues.<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered.<br />
<br />
== Backwards and Forwards Compatibility ==<br />
<br />
A major benefit of using the X3D standard is full backwards compatibility with prior VRML97 and X3D content.<br />
Thanks to careful design and insistence on implementation/evaluation, the X3D International Standard has maintained both steady growth and interoperability ever since Virtual Reality Modeling Language (VRML) in 1997. This track record of stability and innovation is among the best in the 3D graphics industry.<br />
<br />
Our goal is to maximize, but not necessarily require, backwards compatibility in version 4.0 with the version 3.x specifications<br />
* A great majority of X3D nodes and features are likely achievable without change<br />
* Some X3D features may require import/export conversion for compatibility (event model reconciliation, ROUTEs and sensors perhaps)<br />
* A few features might be refactored, deprecated or obsoleted (none yet identified)<br />
* Name deconfliction: HTML Script versus embedded X3D Script<br />
<br />
The comprehensive forward compatibility of VRML97 and X3D with later-developed X3D versions shows that careful anticipatory design is achievable.<br />
<br />
X3D version 4.0 Development efforts are currently focused on HTML5, Declarative 3D, X3DOM, and Cobweb with many more issues under consideration.<br />
* Discussion of [[Importing and adding nodes in HTML]]<br />
<br />
X3D Version 4.1 is focused on Mixed Augmented Reality (MAR) capabilities, which may also require architectural changes. Some new technologies may get pushed from 4.0 to 4.1 (or back again) after careful consideration by the respective working groups.<br />
<br />
Related specification support and changes<br />
*As with all other X3D components, all work is defined in the abstract specification has corresponding file encodings (.x3d .x3dv .x3db) and language bindings (ECMAScript and Java). <br />
*Compatibility concerns include evolutionary efforts to upgrade the X3D Compressed Binary Encoding (CBE), as described in the [http://www.web3d.org/realtime-3d/working-groups/x3d/compressed-binary/x3d-compressed-binary-encoding-call-contributions X3D Compressed Binary Encoding Call For Contributions].<br />
*ECMAScript (JavaScript) support in X3D needs to be upgraded to the new standard for that rapidly improving programming language.<br />
**[http://standards.iso.org/ittf/PubliclyAvailableStandards/c055755_ISO_IEC_16262_2011(E).zip ISO/IEC 16262:2011 Information technology — ECMAScript language specification] (.zip download)<br />
**Downloadable from [http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html ISO Publicly Available Standards] site without charge<br />
**This relates to [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html 19777-1 Part 2, X3D Scene Access Interface (SAI) language bindings for EcmaScript]<br />
<br />
== Architectural Considerations ==<br />
<br />
This section will synopsize significant differences between X3D version 4 and X3D version 3 that may require structural changes in tools and scenes. Special attention is needed to minimize incompatibilities with legacy software and content.<br />
<br />
== Open Questions ==<br />
<br />
* Are ARC abstract design and X3D AR proposals sufficiently mature to enable integration with HTML5/Declarative 3D/X3DOM issues?<br />
* Are the previously X3D Layer/Layering components compatible with HTML5 overlay model? Are they still needed, perhaps for multiscreen or CAVE support?<br />
* Mashup and interoperability support: is anything else needed for broader use with the Web? YouTube etc.<br />
<br />
== Related Work==<br />
<br />
Much careful planning is involved, we are working to ensure that X3D version 4 can be coherently advanced in combination with a [http://www.web3d.org/specifications/X3dSpecificationRelationships.png coordinated set of steadily evolving ISO/IEC standards].<br />
*'''X3D Efficient Binary Encoding (EBE).''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings. See also SRC format (Web3D 2014)and ExternalGeometry node in InstantPlayer and X3DOM<br />
*'''X3D JavaScript Object Notation (JSON) Encoding.''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings.<br />
*'''X3D version 4.0 (HTML5/X3D DOM)'''. This work is proceeding in parallel. X3D version 4 support is expected.<br />
*'''X3D version 4.1 (Mixed Augmented Reality)'''. Nodes and capabilities in this arena will build on v4.0 and HTML5. Experimentation, evolution and evaluation<br />
occurs throughout.<br />
* [https://webvr.info/ '''WebVR'''] "bringing virtual reality to the web" - standardize the interface to VR displays and controllers <br />
* [https://www.w3.org/community/decwebvr/ '''W3C's Declarative WebVR Community Group'''] formed to developed a declaractive 3D standard for WebVR<br />
** '''[[Essential Elements of X3D]]''' collects elements that are essential to X3D<br />
<br />
== Schedule ==<br />
<br />
'''ISO Considerations'''<br />
* Deciding readiness for ISO New Work Item Proposal (NWIP): we need Committee Draft (CD) specification prose for each planned capability.<br />
* Web3D Consortium is not locked into an annual schedule, ISO handling is flexible.<br />
* Once the NWIP is approved, ISO rules for schedule and review are established.<br />
<br />
'''Execution goals'''<br />
* Review progress during monthly calls, Web3D Conference, and SIGGRAPH Conference.<br />
* We are continuing a monthly review schedule for submissions so that we can build out X3D version 4 one component at a time.<br />
* We are planning to have a 1-year deadline for completion of CD specification prose, rather than wait until all possible version 4 work is ready.<br />
* Web3D Consortium members and public review when a final draft specification is ready to proceed to ISO.<br />
* Any new components not meeting Web3D deadlines might be a candidate for deferral to V4.1. Or considered not ready.<br />
<br />
'''Progress'''<br />
<br />
* Active development of X3D, X3DOM and Cobweb content is tracking HTML 5 capabilities now<br />
* We participate and contribute to the W3C Community Group for [http://www.w3.org/community/declarative3d Declarative 3D]</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_version_4.0_Development&diff=9582X3D version 4.0 Development2017-04-19T16:05:20Z<p>Webmaster: /* Genesis and Strategic Overview */ Fixed URL to Web3D Conferences</p>
<hr />
<div>==Genesis and Strategic Overview==<br />
<br />
Web3D Consortium working groups currently define specification goals and requirements. Working group efforts are often the focus for defining and testing new X3D components.<br />
<br />
We publicly review these goals annually during [http://web3dconference.org/ Web3D Conference] and [http://s2014.siggraph.org/attendees/birds-feather SIGGRAPH BOF] meetings.<br />
<br />
Suggestions, development and discussion via the [http://web3d.org/mailman/listinfo/x3d-public_web3d.org x3d-public mailing list] is ongoing.<br />
<br />
X3D version 3.4 Development efforts were evolutionary improvements to the widely proven X3D Graphics architecture. Consortium members decided to skip version 3.4 and go straight to version 4.0, prior goals and requirements have all been merged here.<br />
<br />
The Candidate Capabilities list shows that a lot of interesting capabilities have been proposed and are under way for X3D version 4. However, topics on this list are not guaranteed to be completed! Rather these are all works in progress.<br />
<br />
Activity and approval proceeds based on technical contributions and Web3D Consortium Member priorities. Please consider [http://web3d.org/membership/join joining Web3D Consortium] to help advance 3D graphics on the Web.These X3D version 4.0 Development efforts are considering potentially major additions to the baseline X3D architecture.<br />
<br />
* [http://web3d.org/wiki/images/f/f2/X3DOM_4_WebGL_audience_10_2013.pdf Summary slides here (Oct 2013)] summarize this steadily continuing effort<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_HTML5 HTML5], [http://www.w3.org/community/declarative3d/ Declarative 3D], [http://www.x3dom.org X3DOM], and possibly CSS<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_Augmented_Reality Augmented Reality Continuum (ARC)] (being renamed as Mixed Augmented Reality MAR)<br />
* Relaxing prior design constraints can enable a broader new basis for X3D integration<br />
* Normalizing interaction semantics with HTML5 - now a stable W3C Recommendation - can further open up X3D for the vast majority of Web authors<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered. X3D Futures planning is currently a Web3D Consortium member-only activity.<br />
<br />
== Legacy Issues ==<br />
<br />
We plan to confirm the existence of complete capabilities for X3D v3.3 prior to final approval of X3D version 4.<br />
<br />
* Full support for all existing X3D v3.3 components:<br />
** At least two compatible implementations (including at least one in open source) plus repeatable example scenes<br />
** Layer, ParticleSystems, RigidBodyPhysics, Shaders, TODO others<br />
** TransformSensor node: [http://doc.instantreality.org/documentation/nodetype/TransformSensor/ IGD] and [http://www.parallelgraphics.com/developer/products/cortona/extensions/transformsensor/ old Cortona]<br />
<br />
* Is it necessary for Layout component to be deprecated or improved?<br />
<br />
== Candidate Capabilities ==<br />
<br />
Each of the following possibilities for X3D version 4 have been discussed by the various X3D working groups during meetings and on mailing lists.<br />
Each potential capability is considered to be a feasible (and in most cases, straightforward) addition to the existing X3D version 3.3 architecture.<br />
<br />
*'''Appearance'''<br />
**'''Images''': recommended formats for imagery and video (.gif .bmp .svg .flv .exr .hdr etc.). Consider [http://en.wikipedia.org/wiki/QR_code QR codes] as a first-class image type since it contains imagery and information, especially useful in Mixed Augmented Reality (MAR) applications<br />
**'''Materials''': advanced parameters<br />
**[[X3D Multitexture | Multitexture]]: review for correctness, completeness and conformance of rendering example scenes<br />
**'''Rendering''': bump maps, [http://doc.instantreality.org/tutorial/dynamic-shadows/ shadows], edge smoothing, gamma correction, Non-Photorealistic Rendering (NPR)<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/shaders.html Shaders]: improved support and better interoperability, library of examples; [http://doc.instantreality.org/documentation/nodetype/CommonSurfaceShader/ CommonSurfaceShader?]<br />
**'''Texturing''': [http://en.wikipedia.org/wiki/Texture_atlas Texture atlas], [http://en.wikipedia.org/wiki/Projective_texture_mapping projective texture mapping (PTM)], [http://www.xj3d.org/extensions/render_texture.html RenderedTexture node] for multipass rendering - 2D texture version of GeneratedCubeMapTexture, first proposed by Xj3D and also implemented in X3DOM and InstantReality, useful for all kinds of NPR, shadows, mirrors, etc.<br />
*'''Audio and video''': alignment with [https://www.w3.org/2011/audio W3C Audio Working Group], especially for [https://webaudio.github.io/web-audio-api Web Audio API] and [https://webaudio.github.io/web-midi-api Web Midi API]. Adding royalty-free formats, streamability, [http://web3d.org/pipermail/x3d-public_web3d.org/2013-December/002681.html disabling attenuation], 3D aural spatialization using reflection from simple geometry (such as [http://gamma.cs.unc.edu/Sound/RESound RESOUND]).<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/computer-aided-design-cad Computer Aided Design (CAD)]''' Interactive Profile, to include:<br />
**[http://www.web3d.org/wiki/index.php/X3D_v4.0_CAD_Improvements X3D v4.0 CAD Improvements] with 3D printing + 3D scanning included<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/CADInterchange.html CADInterchange profile] plus FillProperties/LineProperties, primitive/Geometry2D nodes, Extrusion, NURBS, ClipPlane<br />
**Part selection/animation, 3D printing, [http://www.web3d.org/realtime-3d/news/3d-graphics-compress-call-contributions Compressed Binary Encoding (CBE)], possibly [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html annotations component]<br />
** Building Information Models (BIM), Architecture Engineering Construction (AEC), Physical Sensors<br />
*'''[http://www.ecma-international.org/publications/standards/Ecma-262.htm ECMAScript]''' (Javascript) specification revision compatibility with [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html X3D scripting]; possibly add C# or Python support<br />
*'''Events'''<br />
** Review X3D event interoperability with other event models, such as Document Object Model (DOM) Recommendations<br />
** Add capability for Event logging and playback so that deterministic replay is possible for demonstrations and debugging<br />
*'''Generalized input/output interface support'''<br />
** Possibly [http://www.cs.unc.edu/Research/vrpn/index.html Virtual Reality Peripheral Network (VRPN)], gesture recognition (such as [http://en.wikipedia.org/wiki/Kinect KINECT], [http://www.leapmotion.com LEAP]), etc.<br />
** Support for arbitrary sensors and user interaction devices<br />
* '''Geometry''': point size (or perspective rendering), progressive meshes (suitable for both compression and streaming), 3D ExtrudedText, support for [http://en.wikipedia.org/wiki/Web_typography Web typography] using [http://www.w3.org/TR/WOFF Web Open Fonts Format (WOFF)]<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/x3d-earth Geospatial X3D]''' component<br />
** [http://www.igraphics.com/Standards/EnhancedGeospatialComponent_2007_10_30/Part01/X3D.html Enhanced Geospatial Component - spatial reference frame (SRF)] and [http://www.opengeospatial.org/standards/kml KML] support, [http://www.opengeospatial.org/projects/initiatives/3dpie OGC 3D Portrayal], [http://web3d.org/pipermail/x3d-public_web3d.org/2010-December/001187.html GpsSensor], [http://openlayers.org OpenLayer] mashups<br />
** GeoSet collection of adjacent GeoElevationGrid nodes to enable proper computation of normals for edge boundaries of adjacent grids<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/h-anim Humanoid Animation (H-Anim)]''' anatomical correctness for skeleton and skinning, motion capture (mocap) and playback, interchangeable avatars, animation for hands feet and faces<br />
* '''Interoperability''': include ''class'' attribute for all nodes to all encodings<br />
* '''[http://www.json.org JSON]''': JavaScript Object Notation as an X3D encoding ([http://web3d.org/pipermail/x3d-public_web3d.org/2014-July/thread.html#2854 assessment thread]), relation to [http://www.khronos.org/gltf GlTF], streaming considerations<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/medx3d Medical working group]''' capabilities<br />
** [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html Annotations component] and metadata usage<br />
** Archival 3D medical records, potential emphasis on [http://en.wikipedia.org/wiki/Traumatic_brain_injury Traumatic brain injury (TBI)] volume visualization<br />
** Haptics component for force feedback; [http://www.w3.org/TR/vibration W3C Vibrations API] for tactile feedback<br />
** Soft-body physics component to complement rigid-body physics component<br />
* '''Mobile Profile.''' TODO - needed? Calling out a reduced palette for mobile devices remains interesting, but might instead remain a browser-optional optimization.<br />
* '''[http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#Nodereference Metadata]''': support for embedding information useful for applications utilizing X3D<br />
** Enumerated types: better access, typing, naming, and validation than using MetadataSet/MetadataString combinations<br />
* '''Mixed and Augmented Reality (MAR)''': follow ISO MAR Reference Model, integrate multiple capabilities with devices situated in real world<br />
*'''Networking''': consider [http://www.web3d.org/x3d/content/examples/Basic/Networking NetworkSensor] and event-passing issues, streaming using [http://www.json.org JSON], server-side 3D topics<br />
*'''Security and privacy''':<br />
** Include X3D Networking Component Level 4 support for https in Immersive, Interactive and other commonly used profiles<br />
** Review X3D specifications to ensure that Security Considerations are fully documented throughout in every component<br />
** [http://www.w3.org/standards/xml/security XML Security] provides best-available encryption, digital signature (authentication)<br />
** [http://www.w3.org/standards/webdesign/privacy Web Privacy]: examine X3D compatibility with Do Not Track, P3P, POWDER<br />
*'''Viewing and navigation''': [http://www.web3d.org/x3d/content/examples/Basic/development/CameraExamplesIndex.html cinematic camera control], alternative navigation types (such as PAN, [http://www.x3dom.org/?p=3536 TURNTABLE] etc.), [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/behaviours.html Recommended navigation behaviours] review, and old MatrixTransform node (esp. useful for CAD, VR/AR etc., implemented in X3DOM and InstantReality)<br />
*'''Virtual Reality (VR)''': requirements definition needed includes viewing with stereo devices, interocular distance, frame-rate requirements, comparison (and potential profile) for [https://webvr.info WebVR] capabilities, physiological considerations, health and safety, relation with Mixed Augmented Reality (MAR), etc.<br />
<br />
All suggestions and recommendations are welcome. Component improvements and additions are approved by Web3D Consortium members.<br />
<br />
* TODO: Which experimental nodes are ready? Candidates include [http://doc.instantreality.org Fraunhofer], X3DOM, Cobweb, other members and working groups?<br />
* TODO: articulate Big Data and Cloud, server-side visualization, related issues.<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered.<br />
<br />
== Backwards and Forwards Compatibility ==<br />
<br />
A major benefit of using the X3D standard is full backwards compatibility with prior VRML97 and X3D content.<br />
Thanks to careful design and insistence on implementation/evaluation, the X3D International Standard has maintained both steady growth and interoperability ever since Virtual Reality Modeling Language (VRML) in 1997. This track record of stability and innovation is among the best in the 3D graphics industry.<br />
<br />
Our goal is to maximize, but not necessarily require, backwards compatibility in version 4.0 with the version 3.x specifications<br />
* A great majority of X3D nodes and features are likely achievable without change<br />
* Some X3D features may require import/export conversion for compatibility (event model reconciliation, ROUTEs and sensors perhaps)<br />
* A few features might be refactored, deprecated or obsoleted (none yet identified)<br />
* Name deconfliction: HTML Script versus embedded X3D Script<br />
<br />
The comprehensive forward compatibility of VRML97 and X3D with later-developed X3D versions shows that careful anticipatory design is achievable.<br />
<br />
X3D version 4.0 Development efforts are currently focused on HTML5, Declarative 3D, X3DOM, and Cobweb with many more issues under consideration.<br />
* Discussion of [[Importing and adding nodes in HTML]]<br />
<br />
X3D Version 4.1 is focused on Mixed Augmented Reality (MAR) capabilities, which may also require architectural changes. Some new technologies may get pushed from 4.0 to 4.1 (or back again) after careful consideration by the respective working groups.<br />
<br />
Related specification support and changes<br />
*As with all other X3D components, all work is defined in the abstract specification has corresponding file encodings (.x3d .x3dv .x3db) and language bindings (ECMAScript and Java). <br />
*Compatibility concerns include evolutionary efforts to upgrade the X3D Compressed Binary Encoding (CBE), as described in the [http://www.web3d.org/realtime-3d/working-groups/x3d/compressed-binary/x3d-compressed-binary-encoding-call-contributions X3D Compressed Binary Encoding Call For Contributions].<br />
*ECMAScript (JavaScript) support in X3D needs to be upgraded to the new standard for that rapidly improving programming language.<br />
**[http://standards.iso.org/ittf/PubliclyAvailableStandards/c055755_ISO_IEC_16262_2011(E).zip ISO/IEC 16262:2011 Information technology — ECMAScript language specification] (.zip download)<br />
**Downloadable from [http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html ISO Publicly Available Standards] site without charge<br />
**This relates to [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html 19777-1 Part 2, X3D Scene Access Interface (SAI) language bindings for EcmaScript]<br />
<br />
== Architectural Considerations ==<br />
<br />
This section will synopsize significant differences between X3D version 4 and X3D version 3 that may require structural changes in tools and scenes. Special attention is needed to minimize incompatibilities with legacy software and content.<br />
<br />
== Open Questions ==<br />
<br />
* Are ARC abstract design and X3D AR proposals sufficiently mature to enable integration with HTML5/Declarative 3D/X3DOM issues?<br />
* Are the previously X3D Layer/Layering components compatible with HTML5 overlay model? Are they still needed, perhaps for multiscreen or CAVE support?<br />
* Mashup and interoperability support: is anything else needed for broader use with the Web? YouTube etc.<br />
<br />
== Related Work==<br />
<br />
Much careful planning is involved, we are working to ensure that X3D version 4 can be coherently advanced in combination with a [http://www.web3d.org/specifications/X3dSpecificationRelationships.png coordinated set of steadily evolving ISO/IEC standards].<br />
*'''X3D Efficient Binary Encoding (EBE).''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings. See also SRC format (Web3D 2014)and ExternalGeometry node in InstantPlayer and X3DOM<br />
*'''X3D JavaScript Object Notation (JSON) Encoding.''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings.<br />
*'''X3D version 4.0 (HTML5/X3D DOM)'''. This work is proceeding in parallel. X3D version 4 support is expected.<br />
*'''X3D version 4.1 (Mixed Augmented Reality)'''. Nodes and capabilities in this arena will build on v4.0 and HTML5. Experimentation, evolution and evaluation<br />
occurs throughout.<br />
* [https://webvr.info/ '''WebVR'''] "bringing virtual reality to the web" - standardize the interface to VR displays and controllers <br />
* [https://www.w3.org/community/decwebvr/ '''W3C's Declarative WebVR Community Group'''] formed to developed a declaractive 3D standard for WebVR<br />
** '''[[Essential Elements of X3D]]''' collects elements that are essential to X3D<br />
<br />
== Schedule ==<br />
<br />
'''ISO Considerations'''<br />
* Deciding readiness for ISO New Work Item Proposal (NWIP): we need Committee Draft (CD) specification prose for each planned capability.<br />
* Web3D Consortium is not locked into an annual schedule, ISO handling is flexible.<br />
* Once the NWIP is approved, ISO rules for schedule and review are established.<br />
<br />
'''Execution goals'''<br />
* Review progress during monthly calls, Web3D Conference, and SIGGRAPH Conference.<br />
* We are continuing a monthly review schedule for submissions so that we can build out X3D version 4 one component at a time.<br />
* We are planning to have a 1-year deadline for completion of CD specification prose, rather than wait until all possible version 4 work is ready.<br />
* Web3D Consortium members and public review when a final draft specification is ready to proceed to ISO.<br />
* Any new components not meeting Web3D deadlines might be a candidate for deferral to V4.1. Or considered not ready.<br />
<br />
'''Progress'''<br />
<br />
* Active development of X3D, X3DOM and Cobweb content is tracking HTML 5 capabilities now<br />
* We participate and contribute to the W3C Community Group for [http://www.w3.org/community/declarative3d Declarative 3D]</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_V4_HTML_Integration_Requirements&diff=9579X3D V4 HTML Integration Requirements2017-04-05T16:34:05Z<p>Webmaster: /* Additional features to be added */</p>
<hr />
<div><br />
== Web3D Strategy ==<br />
"Next-generation evolution + revolution is combined with archival compatibility of existing legacy content." See http://www.web3d.org/strategy Web3D Standards Strategy<br />
<br />
== Boundary conditions ==<br />
<br />
# This is just for X3D running in a web browser and integrated with HTML. This could be expressed as <x3d> ... </x3d> can be treated as a document fragment in the body of an HTML document. If there is X3D outside of this limitation, these requirements may or may not apply.<br />
# Changes to X3D Abstract Specification? I had not gone as far as indicating which changes needed to go where. Obviously new nodes would need to be in the Abstract specification. But even before going there it is necessary to determine what environments X3D will operate in. My limitations are only for a web browser environment. Environments beside that one are not a concern of the requirements I stated. If there are to be other environments than those differences and similarities would need to be worked out.<br />
# Defining an HTML5 Encoding, and perhaps a corresponding HTML5 Profile<br />
<br />
== Notes ==<br />
<br />
# Some of these requirements may overlap by varying amounts. It was easier to specify them this way then trying to make a complete and non-overlapping set. I'm not going to even claim that this is a complete set, but it is a beginning.<br />
# For those that want XHTML, then convert all references to HTML to XHTML and make the appropriate syntax changes. The differences between HTML and XHTML in the appearance of the elements and attributes is that XHTML is strict. This amounts to closing elements, elements and attributes are lower case, mandatory elements and attributes, different MIME type (text/html vs. application/xml or applications/xhtml+xml), and quoted attributes -- see https://www.w3schools.com/html/html_xhtml.asp for details. The WhatWG has a pretty good documentation page on the differences at https://wiki.whatwg.org/wiki/HTML_vs._XHTML.<br />
# Cross-check with the following pages:<br />
## X3D V4 at http://www.web3d.org/x3d4<br />
## X3D V4 development at http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development<br />
<br />
== Candidate Requirements ==<br />
<br />
=== Looks "like" HTML ===<br />
: Elements (nodes in X3D-speak) shall be case independent<br />
: Attributes (fields in X3D-speak) shall be case independent<br />
: X3D nodes shall not have name conflicts with any HTML-defined elements<br />
:: I believe the HTML5 Custom Elements spec requires a prefix-name format for element names. While allowing lowercase should we also allow 'x3d-transform' format alternative names?<br />
:: In that case, each node would be aliased with a HTML5 Custom Element compatible name.<br />
: All X3D nodes shall support all HTML Global Attributes https://www.w3schools.com/tags/ref_standardattributes.asp<br />
:: Is this equivalent to requiring that X3D nodes need to derive from HTMLElement as defined in the DOM?<br />
: All X3D fields with the same name as HTML attributes shall behave as the HTML element<br />
: TBD: Not all style attributes apply to X3D nodes & fields<br />
<br />
=== HTML encodings ===<br />
: HTML5 has two encodings, not one. Each consistently maps to DOM. The WG developing corresponding functionality and syntax that supports both encodings will add tremendous value to everyone.<br />
:: HTML5 Recommendation section 8. The HTML syntax https://www.w3.org/TR/html5/syntax.html#syntax<br />
:: HTML5 Recommendation section 9. The XHTML syntax https://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax<br />
: The differences between HTML and XHTML in the appearance of the elements and attributes is that XHTML is strict. This amounts to closing elements, elements and attributes are lower case, mandatory elements and attributes, different MIME type (text/html vs. application/xml or applications/xhtml+xml), and quoted attributes -- see https://www.w3schools.com/html/html_xhtml.asp for details. The WhatWG has a pretty good documentation page on the differences at https://wiki.whatwg.org/wiki/HTML_vs._XHTML. There are differences in scripting. Most of the differences are obvious extensions from XHTML being an XML document. The W3C HTML5 specification (https://www.w3.org/TR/html5/introduction.html#html-vs-xhtml) is consistent with the above comments. All of the formalities aside, from my observations there is very little use of the XHTML document type for regular web pages.<br />
<br />
=== Functions "like" HTML ===<br />
: All nodes shall be fully integrated with the DOM [This may need to change if certain nodes need to remain hidden from the DOM. For example, the manner which X3DOM implements Inline.]<br />
: The scene graph does not need to be DOM (or a portion of it).<br />
:: X3DOM keeps a separate scene graph from the DOM. The rendering occurs from the scene graph. Changes to the DOM cause changes to the scene graph and vice versa.<br />
: Changes to the DOM shall be reflected in the scene graph<br />
: Changes to the scene graph shall be reflected in the DOM<br />
:: Using the DOM to maintain and reflect state is often considered slow. Could this be optional? Changes to the scene graph cause events which can be listened to if required. (This is why cobweb-dom does not reflect back interpolator output to the DOM at this point)<br />
:: Perhaps it is better to set all current fields that are initialized to be (generally) non-updated. If you want to see a particular value, you need to listen to the appropriate event. Certain events would cause the initialized fields to be updated. I know that this is not written well.<br />
: Events are handled as HTML events<br />
: DOM is the external (i.e., from the web page) API to the scene graph<br />
:: X3dom does it that way. One could add that this external API could be implemented using the SAI thereby guaranteeing X3D event flow determinism<br />
:: Would it be possible to implement the SAI over DOM? I am concerned about having more than one fundamental API. It will cause confusion and errors.<br />
<br />
=== Other HTML related ===<br />
: X3D scenes can pass events to/from the DOM and ROUTE events within the scene graph.<br />
: HTML elements, SVG elements and css blocks can be interspersed with X3D elements.<br />
: HTML Script, SVG Script and X3D Script elements are unique and distinguishable.<br />
:: I still have not heard a good reason to have X3D scripts. They cannot have the same element name so legacy X3D files cannot run. At that point using HTML JavaScript for all processing appears to be the right thing to do. I see it as very important to content developers not to have multiple flavors of JavaScript running.<br />
: String-based DOM events correlate with strongly typed X3D events by defined correspondences<br />
:: Multiple candidate approaches can be listed and compared<br />
:: The events I am referring to are those that cross between X3D and HTML or any other non-X3D environment (e.g., display, orientation, etc.).<br />
<br />
=== X3D shall support the evolving web standards for flat-3D (WebGL), VR (WebVR) and AR ===<br />
<br />
=== Existing features & functionality ===<br />
: Perform the following tasks with the requirements that is be conflict with the above<br />
:: Conduct a review of all existing features (nodes) to determine if any should be deprecated in V4<br />
:: Conduct a review of all existing functionality (run-time) to determine if any should be deprecated or changed in V4<br />
: Include all features and functionality that passes the above reviews<br />
<br />
=== Additional features to be added ===<br />
: Deformable-skin joint based animation<br />
: Support for multiple geometry formats, including OBJ, glTF<br />
:: Leonard has a pretty good understanding about binary glTF support in x3dom. There are issues posted under the X3DOM project at GitHub, but resolution of those issues will take quite a bit of work.<br />
: Increased Material support with a standard library of pre-defined shaders<br />
:: Three.js has good shaders including for PBR. But again quite a bit of work. Not sure if Fraunhofer is that engaged since there may be commercialization interest.<br />
:: Including programmable shaders in declarative language and not providing predefined operations seems like a poor choice. This is an attempt to start to rectify it.<br />
: Mechanism to navigate a scene without a pointing device<br />
: Mechanism to touch or select objects without a pointing device<br />
:: Or with wand or controller.<br />
: Review other 3D/VR display technologies (XML3D, A-Frame, GLAM, etc.) to determine if there are features that should be included<br />
:: The three.js examples are also inspiring. Postprocessing of the rendered frame in another shader stage comes to mind. There are probably many more modern graphics methods which need some support. Ambient occlusion ssao? Motion blur? Distance defocus?<br />
<br />
== Issues ==<br />
<br />
== General comments ==<br />
<br />
Generally, the vrml spec. was written before the advent of powerful GPUs (massively parallel super computers) where it now can be faster to repeat the same fragment shader operation for each pixel (perhaps a million times) rather than update data between cpu and gpu once. Not sure what the consequences exactly are other than being shader friendly in some way.<br />
<br />
Deformable skin from joint animation calculations are typically carried out on the GPU. Too much for serial processors. I'm sure there are other items.<br />
<br />
=== Scripting ===<br />
<br />
* See https://www.w3.org/TR/SVG/script.html<br />
* See the example in 18.2 The 'script' element at https://www.w3.org/TR/SVG/script.html#ScriptElement<br />
* See the DOM interface definition for SVGScriptElement at https://www.w3.org/TR/SVG/script.html#InterfaceSVGScriptElement<br />
<!-- <br />
DO NOT REMOVE THIS COMMENT<br />
Note that there is something in the text from the third bullet below to the <br />
end of the text prior to the comment that triggers a security error in Apache (SQL injection). <br />
This section MUST be the last in the list.<br />
DO NOT REMOVE THIS COMMENT<br />
--><br />
<br />
=== OBJ file format ===<br />
<br />
I applaud the idea of multiple geometry formats, as we need interoperability, and glTF is a nice standard.<br />
<br />
But I would remove OBJ from the list, or be careful what parts of the OBJ are necessary to be supported.<br />
* The OBJ is an old format. It doesn't have many features nice for modern rendering (like a specification of shading suitable for modern GPUs). And it does have some features that are unhandy, and were probably really useful only by the initial Wavefront OBJ implementation (trace_obj).<br />
* The OBJ specification is not officially maintained by anyone, I think. It's not updated. The creators of it, and the original software implementing it, are closed now. (https://en.wikipedia.org/wiki/Wavefront_Technologies , https://en.wikipedia.org/wiki/The_Advanced_Visualizer ). No-one since then has taken the effort to update the OBJ specification in any way, as far as I know.<br />
* Although it has a specification http://www.martinreddy.net/gfx/3d/OBJ.spec, most implementations treat it more like a "de-facto" standard, implementing different subsets of the format, whatever seems useful. There are features in OBJ format that are widely supported (vertexes with normals, tex coords), and there are features not supported by any existing implementation (I have not seen yet an implementation that supports Bezier patches defined in OBJ files; or one that supports d_interp or trace_obj).<br />
<br />
Bottom line: While OBJ is a popular format, I would either discourage from using it (we made X3D for a reason iii it's really better on all accounts), or at least specify only a precise subset of OBJ features required to be supported.<br />
<br />
A very informative link to Wikipedia description of OBJ: https://en.wikipedia.org/wiki/Wavefront_.obj_file<br />
<br />
I included OBJ because it is a very popular format for the exchange of geometry and normal information. I have only seen it with triangles. I am in complete agreement with Michalis about limiting it's scope.<br />
For example, SVG also has a script node that seems to operate just fine in combination with HTML.</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_V4_HTML_Integration_Requirements&diff=9578X3D V4 HTML Integration Requirements2017-04-05T16:29:15Z<p>Webmaster: /* X3D shall support the evolving web standards for flat-3D (WebGL), VR WebVR) and AR */</p>
<hr />
<div><br />
== Web3D Strategy ==<br />
"Next-generation evolution + revolution is combined with archival compatibility of existing legacy content." See http://www.web3d.org/strategy Web3D Standards Strategy<br />
<br />
== Boundary conditions ==<br />
<br />
# This is just for X3D running in a web browser and integrated with HTML. This could be expressed as <x3d> ... </x3d> can be treated as a document fragment in the body of an HTML document. If there is X3D outside of this limitation, these requirements may or may not apply.<br />
# Changes to X3D Abstract Specification? I had not gone as far as indicating which changes needed to go where. Obviously new nodes would need to be in the Abstract specification. But even before going there it is necessary to determine what environments X3D will operate in. My limitations are only for a web browser environment. Environments beside that one are not a concern of the requirements I stated. If there are to be other environments than those differences and similarities would need to be worked out.<br />
# Defining an HTML5 Encoding, and perhaps a corresponding HTML5 Profile<br />
<br />
== Notes ==<br />
<br />
# Some of these requirements may overlap by varying amounts. It was easier to specify them this way then trying to make a complete and non-overlapping set. I'm not going to even claim that this is a complete set, but it is a beginning.<br />
# For those that want XHTML, then convert all references to HTML to XHTML and make the appropriate syntax changes. The differences between HTML and XHTML in the appearance of the elements and attributes is that XHTML is strict. This amounts to closing elements, elements and attributes are lower case, mandatory elements and attributes, different MIME type (text/html vs. application/xml or applications/xhtml+xml), and quoted attributes -- see https://www.w3schools.com/html/html_xhtml.asp for details. The WhatWG has a pretty good documentation page on the differences at https://wiki.whatwg.org/wiki/HTML_vs._XHTML.<br />
# Cross-check with the following pages:<br />
## X3D V4 at http://www.web3d.org/x3d4<br />
## X3D V4 development at http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development<br />
<br />
== Candidate Requirements ==<br />
<br />
=== Looks "like" HTML ===<br />
: Elements (nodes in X3D-speak) shall be case independent<br />
: Attributes (fields in X3D-speak) shall be case independent<br />
: X3D nodes shall not have name conflicts with any HTML-defined elements<br />
:: I believe the HTML5 Custom Elements spec requires a prefix-name format for element names. While allowing lowercase should we also allow 'x3d-transform' format alternative names?<br />
:: In that case, each node would be aliased with a HTML5 Custom Element compatible name.<br />
: All X3D nodes shall support all HTML Global Attributes https://www.w3schools.com/tags/ref_standardattributes.asp<br />
:: Is this equivalent to requiring that X3D nodes need to derive from HTMLElement as defined in the DOM?<br />
: All X3D fields with the same name as HTML attributes shall behave as the HTML element<br />
: TBD: Not all style attributes apply to X3D nodes & fields<br />
<br />
=== HTML encodings ===<br />
: HTML5 has two encodings, not one. Each consistently maps to DOM. The WG developing corresponding functionality and syntax that supports both encodings will add tremendous value to everyone.<br />
:: HTML5 Recommendation section 8. The HTML syntax https://www.w3.org/TR/html5/syntax.html#syntax<br />
:: HTML5 Recommendation section 9. The XHTML syntax https://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax<br />
: The differences between HTML and XHTML in the appearance of the elements and attributes is that XHTML is strict. This amounts to closing elements, elements and attributes are lower case, mandatory elements and attributes, different MIME type (text/html vs. application/xml or applications/xhtml+xml), and quoted attributes -- see https://www.w3schools.com/html/html_xhtml.asp for details. The WhatWG has a pretty good documentation page on the differences at https://wiki.whatwg.org/wiki/HTML_vs._XHTML. There are differences in scripting. Most of the differences are obvious extensions from XHTML being an XML document. The W3C HTML5 specification (https://www.w3.org/TR/html5/introduction.html#html-vs-xhtml) is consistent with the above comments. All of the formalities aside, from my observations there is very little use of the XHTML document type for regular web pages.<br />
<br />
=== Functions "like" HTML ===<br />
: All nodes shall be fully integrated with the DOM [This may need to change if certain nodes need to remain hidden from the DOM. For example, the manner which X3DOM implements Inline.]<br />
: The scene graph does not need to be DOM (or a portion of it).<br />
:: X3DOM keeps a separate scene graph from the DOM. The rendering occurs from the scene graph. Changes to the DOM cause changes to the scene graph and vice versa.<br />
: Changes to the DOM shall be reflected in the scene graph<br />
: Changes to the scene graph shall be reflected in the DOM<br />
:: Using the DOM to maintain and reflect state is often considered slow. Could this be optional? Changes to the scene graph cause events which can be listened to if required. (This is why cobweb-dom does not reflect back interpolator output to the DOM at this point)<br />
:: Perhaps it is better to set all current fields that are initialized to be (generally) non-updated. If you want to see a particular value, you need to listen to the appropriate event. Certain events would cause the initialized fields to be updated. I know that this is not written well.<br />
: Events are handled as HTML events<br />
: DOM is the external (i.e., from the web page) API to the scene graph<br />
:: X3dom does it that way. One could add that this external API could be implemented using the SAI thereby guaranteeing X3D event flow determinism<br />
:: Would it be possible to implement the SAI over DOM? I am concerned about having more than one fundamental API. It will cause confusion and errors.<br />
<br />
=== Other HTML related ===<br />
: X3D scenes can pass events to/from the DOM and ROUTE events within the scene graph.<br />
: HTML elements, SVG elements and css blocks can be interspersed with X3D elements.<br />
: HTML Script, SVG Script and X3D Script elements are unique and distinguishable.<br />
:: I still have not heard a good reason to have X3D scripts. They cannot have the same element name so legacy X3D files cannot run. At that point using HTML JavaScript for all processing appears to be the right thing to do. I see it as very important to content developers not to have multiple flavors of JavaScript running.<br />
: String-based DOM events correlate with strongly typed X3D events by defined correspondences<br />
:: Multiple candidate approaches can be listed and compared<br />
:: The events I am referring to are those that cross between X3D and HTML or any other non-X3D environment (e.g., display, orientation, etc.).<br />
<br />
=== X3D shall support the evolving web standards for flat-3D (WebGL), VR (WebVR) and AR ===<br />
<br />
=== Existing features & functionality ===<br />
: Perform the following tasks with the requirements that is be conflict with the above<br />
:: Conduct a review of all existing features (nodes) to determine if any should be deprecated in V4<br />
:: Conduct a review of all existing functionality (run-time) to determine if any should be deprecated or changed in V4<br />
: Include all features and functionality that passes the above reviews<br />
<br />
=== Additional features to be added ===<br />
: Deformable-skin joint based animation<br />
: Support for multiple geometry formats, including OBJ, glTF<br />
:: I have a pretty good idea about gltf2 support in x3dom, see my x3dom GitHub issue. But since it is quite a bit of work, it will be some time/use case.<br />
: Increased Material support with a standard library of pre-defined shaders<br />
:: Three.js has good shaders including for PBR. But again quite a bit of work. Not sure if Fraunhofer is that engaged since there may be commercialization interest.<br />
:: Including programmable shaders in declarative language and not providing predefined operations seems like a poor choice. This is an attempt to start to rectify it.<br />
: Mechanism to navigate a scene without a pointing device<br />
: Mechanism to touch or select objects without a pointing device<br />
:: Or with wand or controller.<br />
: Review other 3D/VR display technologies (XML3D, A-Frame, GLAM, etc.) to determine if there are features that should be included<br />
:: The three.js examples are also inspiring. Postprocessing of the rendered frame in another shader stage comes to mind. There are probably many more modern graphics methods which need some support. Ambient occlusion ssao? Motion blur? Distance defocus?<br />
<br />
== Issues ==<br />
<br />
== General comments ==<br />
<br />
Generally, the vrml spec. was written before the advent of powerful GPUs (massively parallel super computers) where it now can be faster to repeat the same fragment shader operation for each pixel (perhaps a million times) rather than update data between cpu and gpu once. Not sure what the consequences exactly are other than being shader friendly in some way.<br />
<br />
Deformable skin from joint animation calculations are typically carried out on the GPU. Too much for serial processors. I'm sure there are other items.<br />
<br />
=== Scripting ===<br />
<br />
* See https://www.w3.org/TR/SVG/script.html<br />
* See the example in 18.2 The 'script' element at https://www.w3.org/TR/SVG/script.html#ScriptElement<br />
* See the DOM interface definition for SVGScriptElement at https://www.w3.org/TR/SVG/script.html#InterfaceSVGScriptElement<br />
<!-- <br />
DO NOT REMOVE THIS COMMENT<br />
Note that there is something in the text from the third bullet below to the <br />
end of the text prior to the comment that triggers a security error in Apache (SQL injection). <br />
This section MUST be the last in the list.<br />
DO NOT REMOVE THIS COMMENT<br />
--><br />
<br />
=== OBJ file format ===<br />
<br />
I applaud the idea of multiple geometry formats, as we need interoperability, and glTF is a nice standard.<br />
<br />
But I would remove OBJ from the list, or be careful what parts of the OBJ are necessary to be supported.<br />
* The OBJ is an old format. It doesn't have many features nice for modern rendering (like a specification of shading suitable for modern GPUs). And it does have some features that are unhandy, and were probably really useful only by the initial Wavefront OBJ implementation (trace_obj).<br />
* The OBJ specification is not officially maintained by anyone, I think. It's not updated. The creators of it, and the original software implementing it, are closed now. (https://en.wikipedia.org/wiki/Wavefront_Technologies , https://en.wikipedia.org/wiki/The_Advanced_Visualizer ). No-one since then has taken the effort to update the OBJ specification in any way, as far as I know.<br />
* Although it has a specification http://www.martinreddy.net/gfx/3d/OBJ.spec, most implementations treat it more like a "de-facto" standard, implementing different subsets of the format, whatever seems useful. There are features in OBJ format that are widely supported (vertexes with normals, tex coords), and there are features not supported by any existing implementation (I have not seen yet an implementation that supports Bezier patches defined in OBJ files; or one that supports d_interp or trace_obj).<br />
<br />
Bottom line: While OBJ is a popular format, I would either discourage from using it (we made X3D for a reason iii it's really better on all accounts), or at least specify only a precise subset of OBJ features required to be supported.<br />
<br />
A very informative link to Wikipedia description of OBJ: https://en.wikipedia.org/wiki/Wavefront_.obj_file<br />
<br />
I included OBJ because it is a very popular format for the exchange of geometry and normal information. I have only seen it with triangles. I am in complete agreement with Michalis about limiting it's scope.<br />
For example, SVG also has a script node that seems to operate just fine in combination with HTML.</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_V4_HTML_Integration_Requirements&diff=9577X3D V4 HTML Integration Requirements2017-04-05T15:22:38Z<p>Webmaster: Changes & notification for identifying problem with formatting pate. This summary applies to all Webmaster edits on 2017-04-05</p>
<hr />
<div><br />
== Web3D Strategy ==<br />
"Next-generation evolution + revolution is combined with archival compatibility of existing legacy content." See http://www.web3d.org/strategy Web3D Standards Strategy<br />
<br />
== Boundary conditions ==<br />
<br />
# This is just for X3D running in a web browser and integrated with HTML. This could be expressed as <x3d> ... </x3d> can be treated as a document fragment in the body of an HTML document. If there is X3D outside of this limitation, these requirements may or may not apply.<br />
# Changes to X3D Abstract Specification? I had not gone as far as indicating which changes needed to go where. Obviously new nodes would need to be in the Abstract specification. But even before going there it is necessary to determine what environments X3D will operate in. My limitations are only for a web browser environment. Environments beside that one are not a concern of the requirements I stated. If there are to be other environments than those differences and similarities would need to be worked out.<br />
# Defining an HTML5 Encoding, and perhaps a corresponding HTML5 Profile<br />
<br />
== Notes ==<br />
<br />
# Some of these requirements may overlap by varying amounts. It was easier to specify them this way then trying to make a complete and non-overlapping set. I'm not going to even claim that this is a complete set, but it is a beginning.<br />
# For those that want XHTML, then convert all references to HTML to XHTML and make the appropriate syntax changes. The differences between HTML and XHTML in the appearance of the elements and attributes is that XHTML is strict. This amounts to closing elements, elements and attributes are lower case, mandatory elements and attributes, different MIME type (text/html vs. application/xml or applications/xhtml+xml), and quoted attributes -- see https://www.w3schools.com/html/html_xhtml.asp for details. The WhatWG has a pretty good documentation page on the differences at https://wiki.whatwg.org/wiki/HTML_vs._XHTML.<br />
# Cross-check with the following pages:<br />
## X3D V4 at http://www.web3d.org/x3d4<br />
## X3D V4 development at http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development<br />
<br />
== Candidate Requirements ==<br />
<br />
=== Looks "like" HTML ===<br />
: Elements (nodes in X3D-speak) shall be case independent<br />
: Attributes (fields in X3D-speak) shall be case independent<br />
: X3D nodes shall not have name conflicts with any HTML-defined elements<br />
:: I believe the HTML5 Custom Elements spec requires a prefix-name format for element names. While allowing lowercase should we also allow 'x3d-transform' format alternative names?<br />
:: In that case, each node would be aliased with a HTML5 Custom Element compatible name.<br />
: All X3D nodes shall support all HTML Global Attributes https://www.w3schools.com/tags/ref_standardattributes.asp<br />
:: Is this equivalent to requiring that X3D nodes need to derive from HTMLElement as defined in the DOM?<br />
: All X3D fields with the same name as HTML attributes shall behave as the HTML element<br />
: TBD: Not all style attributes apply to X3D nodes & fields<br />
<br />
=== HTML encodings ===<br />
: HTML5 has two encodings, not one. Each consistently maps to DOM. The WG developing corresponding functionality and syntax that supports both encodings will add tremendous value to everyone.<br />
:: HTML5 Recommendation section 8. The HTML syntax https://www.w3.org/TR/html5/syntax.html#syntax<br />
:: HTML5 Recommendation section 9. The XHTML syntax https://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax<br />
: The differences between HTML and XHTML in the appearance of the elements and attributes is that XHTML is strict. This amounts to closing elements, elements and attributes are lower case, mandatory elements and attributes, different MIME type (text/html vs. application/xml or applications/xhtml+xml), and quoted attributes -- see https://www.w3schools.com/html/html_xhtml.asp for details. The WhatWG has a pretty good documentation page on the differences at https://wiki.whatwg.org/wiki/HTML_vs._XHTML. There are differences in scripting. Most of the differences are obvious extensions from XHTML being an XML document. The W3C HTML5 specification (https://www.w3.org/TR/html5/introduction.html#html-vs-xhtml) is consistent with the above comments. All of the formalities aside, from my observations there is very little use of the XHTML document type for regular web pages.<br />
<br />
=== Functions "like" HTML ===<br />
: All nodes shall be fully integrated with the DOM [This may need to change if certain nodes need to remain hidden from the DOM. For example, the manner which X3DOM implements Inline.]<br />
: The scene graph does not need to be DOM (or a portion of it).<br />
:: X3DOM keeps a separate scene graph from the DOM. The rendering occurs from the scene graph. Changes to the DOM cause changes to the scene graph and vice versa.<br />
: Changes to the DOM shall be reflected in the scene graph<br />
: Changes to the scene graph shall be reflected in the DOM<br />
:: Using the DOM to maintain and reflect state is often considered slow. Could this be optional? Changes to the scene graph cause events which can be listened to if required. (This is why cobweb-dom does not reflect back interpolator output to the DOM at this point)<br />
:: Perhaps it is better to set all current fields that are initialized to be (generally) non-updated. If you want to see a particular value, you need to listen to the appropriate event. Certain events would cause the initialized fields to be updated. I know that this is not written well.<br />
: Events are handled as HTML events<br />
: DOM is the external (i.e., from the web page) API to the scene graph<br />
:: X3dom does it that way. One could add that this external API could be implemented using the SAI thereby guaranteeing X3D event flow determinism<br />
:: Would it be possible to implement the SAI over DOM? I am concerned about having more than one fundamental API. It will cause confusion and errors.<br />
<br />
=== Other HTML related ===<br />
: X3D scenes can pass events to/from the DOM and ROUTE events within the scene graph.<br />
: HTML elements, SVG elements and css blocks can be interspersed with X3D elements.<br />
: HTML Script, SVG Script and X3D Script elements are unique and distinguishable.<br />
:: I still have not heard a good reason to have X3D scripts. They cannot have the same element name so legacy X3D files cannot run. At that point using HTML JavaScript for all processing appears to be the right thing to do. I see it as very important to content developers not to have multiple flavors of JavaScript running.<br />
: String-based DOM events correlate with strongly typed X3D events by defined correspondences<br />
:: Multiple candidate approaches can be listed and compared<br />
:: The events I am referring to are those that cross between X3D and HTML or any other non-X3D environment (e.g., display, orientation, etc.).<br />
<br />
=== X3D shall support the evolving web standards for flat-3D (WebGL), VR WebVR) and AR ===<br />
<br />
=== Existing features & functionality ===<br />
: Perform the following tasks with the requirements that is be conflict with the above<br />
:: Conduct a review of all existing features (nodes) to determine if any should be deprecated in V4<br />
:: Conduct a review of all existing functionality (run-time) to determine if any should be deprecated or changed in V4<br />
: Include all features and functionality that passes the above reviews<br />
<br />
=== Additional features to be added ===<br />
: Deformable-skin joint based animation<br />
: Support for multiple geometry formats, including OBJ, glTF<br />
:: I have a pretty good idea about gltf2 support in x3dom, see my x3dom GitHub issue. But since it is quite a bit of work, it will be some time/use case.<br />
: Increased Material support with a standard library of pre-defined shaders<br />
:: Three.js has good shaders including for PBR. But again quite a bit of work. Not sure if Fraunhofer is that engaged since there may be commercialization interest.<br />
:: Including programmable shaders in declarative language and not providing predefined operations seems like a poor choice. This is an attempt to start to rectify it.<br />
: Mechanism to navigate a scene without a pointing device<br />
: Mechanism to touch or select objects without a pointing device<br />
:: Or with wand or controller.<br />
: Review other 3D/VR display technologies (XML3D, A-Frame, GLAM, etc.) to determine if there are features that should be included<br />
:: The three.js examples are also inspiring. Postprocessing of the rendered frame in another shader stage comes to mind. There are probably many more modern graphics methods which need some support. Ambient occlusion ssao? Motion blur? Distance defocus?<br />
<br />
== Issues ==<br />
<br />
== General comments ==<br />
<br />
Generally, the vrml spec. was written before the advent of powerful GPUs (massively parallel super computers) where it now can be faster to repeat the same fragment shader operation for each pixel (perhaps a million times) rather than update data between cpu and gpu once. Not sure what the consequences exactly are other than being shader friendly in some way.<br />
<br />
Deformable skin from joint animation calculations are typically carried out on the GPU. Too much for serial processors. I'm sure there are other items.<br />
<br />
=== Scripting ===<br />
<br />
* See https://www.w3.org/TR/SVG/script.html<br />
* See the example in 18.2 The 'script' element at https://www.w3.org/TR/SVG/script.html#ScriptElement<br />
* See the DOM interface definition for SVGScriptElement at https://www.w3.org/TR/SVG/script.html#InterfaceSVGScriptElement<br />
<!-- <br />
DO NOT REMOVE THIS COMMENT<br />
Note that there is something in the text from the third bullet below to the <br />
end of the text prior to the comment that triggers a security error in Apache (SQL injection). <br />
This section MUST be the last in the list.<br />
DO NOT REMOVE THIS COMMENT<br />
--><br />
<br />
=== OBJ file format ===<br />
<br />
I applaud the idea of multiple geometry formats, as we need interoperability, and glTF is a nice standard.<br />
<br />
But I would remove OBJ from the list, or be careful what parts of the OBJ are necessary to be supported.<br />
* The OBJ is an old format. It doesn't have many features nice for modern rendering (like a specification of shading suitable for modern GPUs). And it does have some features that are unhandy, and were probably really useful only by the initial Wavefront OBJ implementation (trace_obj).<br />
* The OBJ specification is not officially maintained by anyone, I think. It's not updated. The creators of it, and the original software implementing it, are closed now. (https://en.wikipedia.org/wiki/Wavefront_Technologies , https://en.wikipedia.org/wiki/The_Advanced_Visualizer ). No-one since then has taken the effort to update the OBJ specification in any way, as far as I know.<br />
* Although it has a specification http://www.martinreddy.net/gfx/3d/OBJ.spec, most implementations treat it more like a "de-facto" standard, implementing different subsets of the format, whatever seems useful. There are features in OBJ format that are widely supported (vertexes with normals, tex coords), and there are features not supported by any existing implementation (I have not seen yet an implementation that supports Bezier patches defined in OBJ files; or one that supports d_interp or trace_obj).<br />
<br />
Bottom line: While OBJ is a popular format, I would either discourage from using it (we made X3D for a reason iii it's really better on all accounts), or at least specify only a precise subset of OBJ features required to be supported.<br />
<br />
A very informative link to Wikipedia description of OBJ: https://en.wikipedia.org/wiki/Wavefront_.obj_file<br />
<br />
I included OBJ because it is a very popular format for the exchange of geometry and normal information. I have only seen it with triangles. I am in complete agreement with Michalis about limiting it's scope.<br />
For example, SVG also has a script node that seems to operate just fine in combination with HTML.</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_V4_HTML_Integration_Requirements&diff=9576X3D V4 HTML Integration Requirements2017-04-05T15:20:55Z<p>Webmaster: </p>
<hr />
<div><br />
== Web3D Strategy ==<br />
"Next-generation evolution + revolution is combined with archival compatibility of existing legacy content." See http://www.web3d.org/strategy Web3D Standards Strategy<br />
<br />
== Boundary conditions ==<br />
<br />
# This is just for X3D running in a web browser and integrated with HTML. This could be expressed as <x3d> ... </x3d> can be treated as a document fragment in the body of an HTML document. If there is X3D outside of this limitation, these requirements may or may not apply.<br />
# Changes to X3D Abstract Specification? I had not gone as far as indicating which changes needed to go where. Obviously new nodes would need to be in the Abstract specification. But even before going there it is necessary to determine what environments X3D will operate in. My limitations are only for a web browser environment. Environments beside that one are not a concern of the requirements I stated. If there are to be other environments than those differences and similarities would need to be worked out.<br />
# Defining an HTML5 Encoding, and perhaps a corresponding HTML5 Profile<br />
<br />
== Notes ==<br />
<br />
# Some of these requirements may overlap by varying amounts. It was easier to specify them this way then trying to make a complete and non-overlapping set. I'm not going to even claim that this is a complete set, but it is a beginning.<br />
# For those that want XHTML, then convert all references to HTML to XHTML and make the appropriate syntax changes. The differences between HTML and XHTML in the appearance of the elements and attributes is that XHTML is strict. This amounts to closing elements, elements and attributes are lower case, mandatory elements and attributes, different MIME type (text/html vs. application/xml or applications/xhtml+xml), and quoted attributes -- see https://www.w3schools.com/html/html_xhtml.asp for details. The WhatWG has a pretty good documentation page on the differences at https://wiki.whatwg.org/wiki/HTML_vs._XHTML.<br />
# Cross-check with the following pages:<br />
## X3D V4 at http://www.web3d.org/x3d4<br />
## X3D V4 development at http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development<br />
<br />
== Candidate Requirements ==<br />
<br />
=== Looks "like" HTML ===<br />
: Elements (nodes in X3D-speak) shall be case independent<br />
: Attributes (fields in X3D-speak) shall be case independent<br />
: X3D nodes shall not have name conflicts with any HTML-defined elements<br />
:: I believe the HTML5 Custom Elements spec requires a prefix-name format for element names. While allowing lowercase should we also allow 'x3d-transform' format alternative names?<br />
:: In that case, each node would be aliased with a HTML5 Custom Element compatible name.<br />
: All X3D nodes shall support all HTML Global Attributes https://www.w3schools.com/tags/ref_standardattributes.asp<br />
:: Is this equivalent to requiring that X3D nodes need to derive from HTMLElement as defined in the DOM?<br />
: All X3D fields with the same name as HTML attributes shall behave as the HTML element<br />
: TBD: Not all style attributes apply to X3D nodes & fields<br />
<br />
=== HTML encodings ===<br />
: HTML5 has two encodings, not one. Each consistently maps to DOM. The WG developing corresponding functionality and syntax that supports both encodings will add tremendous value to everyone.<br />
:: HTML5 Recommendation section 8. The HTML syntax https://www.w3.org/TR/html5/syntax.html#syntax<br />
:: HTML5 Recommendation section 9. The XHTML syntax https://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax<br />
: The differences between HTML and XHTML in the appearance of the elements and attributes is that XHTML is strict. This amounts to closing elements, elements and attributes are lower case, mandatory elements and attributes, different MIME type (text/html vs. application/xml or applications/xhtml+xml), and quoted attributes -- see https://www.w3schools.com/html/html_xhtml.asp for details. The WhatWG has a pretty good documentation page on the differences at https://wiki.whatwg.org/wiki/HTML_vs._XHTML. There are differences in scripting. Most of the differences are obvious extensions from XHTML being an XML document. The W3C HTML5 specification (https://www.w3.org/TR/html5/introduction.html#html-vs-xhtml) is consistent with the above comments. All of the formalities aside, from my observations there is very little use of the XHTML document type for regular web pages.<br />
<br />
=== Functions "like" HTML ===<br />
: All nodes shall be fully integrated with the DOM [This may need to change if certain nodes need to remain hidden from the DOM. For example, the manner which X3DOM implements Inline.]<br />
: The scene graph does not need to be DOM (or a portion of it).<br />
:: X3DOM keeps a separate scene graph from the DOM. The rendering occurs from the scene graph. Changes to the DOM cause changes to the scene graph and vice versa.<br />
: Changes to the DOM shall be reflected in the scene graph<br />
: Changes to the scene graph shall be reflected in the DOM<br />
:: Using the DOM to maintain and reflect state is often considered slow. Could this be optional? Changes to the scene graph cause events which can be listened to if required. (This is why cobweb-dom does not reflect back interpolator output to the DOM at this point)<br />
:: Perhaps it is better to set all current fields that are initialized to be (generally) non-updated. If you want to see a particular value, you need to listen to the appropriate event. Certain events would cause the initialized fields to be updated. I know that this is not written well.<br />
: Events are handled as HTML events<br />
: DOM is the external (i.e., from the web page) API to the scene graph<br />
:: X3dom does it that way. One could add that this external API could be implemented using the SAI thereby guaranteeing X3D event flow determinism<br />
:: Would it be possible to implement the SAI over DOM? I am concerned about having more than one fundamental API. It will cause confusion and errors.<br />
<br />
=== Other HTML related ===<br />
: X3D scenes can pass events to/from the DOM and ROUTE events within the scene graph.<br />
: HTML elements, SVG elements and css blocks can be interspersed with X3D elements.<br />
: HTML Script, SVG Script and X3D Script elements are unique and distinguishable.<br />
:: I still have not heard a good reason to have X3D scripts. They cannot have the same element name so legacy X3D files cannot run. At that point using HTML JavaScript for all processing appears to be the right thing to do. I see it as very important to content developers not to have multiple flavors of JavaScript running.<br />
: String-based DOM events correlate with strongly typed X3D events by defined correspondences<br />
:: Multiple candidate approaches can be listed and compared<br />
:: The events I am referring to are those that cross between X3D and HTML or any other non-X3D environment (e.g., display, orientation, etc.).<br />
<br />
=== X3D shall support the evolving web standards for flat-3D (WebGL), VR WebVR) and AR ===<br />
<br />
=== Existing features & functionality ===<br />
: Perform the following tasks with the requirements that is be conflict with the above<br />
:: Conduct a review of all existing features (nodes) to determine if any should be deprecated in V4<br />
:: Conduct a review of all existing functionality (run-time) to determine if any should be deprecated or changed in V4<br />
: Include all features and functionality that passes the above reviews<br />
<br />
=== Additional features to be added ===<br />
: Deformable-skin joint based animation<br />
: Support for multiple geometry formats, including OBJ, glTF<br />
:: I have a pretty good idea about gltf2 support in x3dom, see my x3dom GitHub issue. But since it is quite a bit of work, it will be some time/use case.<br />
: Increased Material support with a standard library of pre-defined shaders<br />
:: Three.js has good shaders including for PBR. But again quite a bit of work. Not sure if Fraunhofer is that engaged since there may be commercialization interest.<br />
:: Including programmable shaders in declarative language and not providing predefined operations seems like a poor choice. This is an attempt to start to rectify it.<br />
: Mechanism to navigate a scene without a pointing device<br />
: Mechanism to touch or select objects without a pointing device<br />
:: Or with wand or controller.<br />
: Review other 3D/VR display technologies (XML3D, A-Frame, GLAM, etc.) to determine if there are features that should be included<br />
:: The three.js examples are also inspiring. Postprocessing of the rendered frame in another shader stage comes to mind. There are probably many more modern graphics methods which need some support. Ambient occlusion ssao? Motion blur? Distance defocus?<br />
<br />
== Issues ==<br />
<br />
== General comments ==<br />
<br />
Generally, the vrml spec. was written before the advent of powerful GPUs (massively parallel super computers) where it now can be faster to repeat the same fragment shader operation for each pixel (perhaps a million times) rather than update data between cpu and gpu once. Not sure what the consequences exactly are other than being shader friendly in some way.<br />
<br />
Deformable skin from joint animation calculations are typically carried out on the GPU. Too much for serial processors. I'm sure there are other items.<br />
<br />
=== Scripting ===<br />
<br />
* See https://www.w3.org/TR/SVG/script.html<br />
* See the example in 18.2 The 'script' element at https://www.w3.org/TR/SVG/script.html#ScriptElement<br />
* See the DOM interface definition for SVGScriptElement at https://www.w3.org/TR/SVG/script.html#InterfaceSVGScriptElement<br />
<br />
<!-- <br />
DO NOT REMOVE THIS COMMENT<br />
Note that there is something in the text from the third bullet below to the <br />
end of the text prior to the comment that triggers a security error in Apache (SQL injection). <br />
This section MUST be the last in the list.<br />
DO NOT REMOVE THIS COMMENT<br />
--><br />
<br />
=== OBJ file format ===<br />
<br />
I applaud the idea of multiple geometry formats, as we need interoperability, and glTF is a nice standard.<br />
<br />
But I would remove OBJ from the list, or be careful what parts of the OBJ are necessary to be supported.<br />
* The OBJ is an old format. It doesn't have many features nice for modern rendering (like a specification of shading suitable for modern GPUs). And it does have some features that are unhandy, and were probably really useful only by the initial Wavefront OBJ implementation (trace_obj).<br />
* The OBJ specification is not officially maintained by anyone, I think. It's not updated. The creators of it, and the original software implementing it, are closed now. (https://en.wikipedia.org/wiki/Wavefront_Technologies , https://en.wikipedia.org/wiki/The_Advanced_Visualizer ). No-one since then has taken the effort to update the OBJ specification in any way, as far as I know.<br />
* Although it has a specification http://www.martinreddy.net/gfx/3d/OBJ.spec, most implementations treat it more like a "de-facto" standard, implementing different subsets of the format, whatever seems useful. There are features in OBJ format that are widely supported (vertexes with normals, tex coords), and there are features not supported by any existing implementation (I have not seen yet an implementation that supports Bezier patches defined in OBJ files; or one that supports d_interp or trace_obj).<br />
<br />
Bottom line: While OBJ is a popular format, I would either discourage from using it (we made X3D for a reason iii it's really better on all accounts), or at least specify only a precise subset of OBJ features required to be supported.<br />
<br />
A very informative link to Wikipedia description of OBJ: https://en.wikipedia.org/wiki/Wavefront_.obj_file<br />
<br />
I included OBJ because it is a very popular format for the exchange of geometry and normal information. I have only seen it with triangles. I am in complete agreement with Michalis about limiting it's scope.<br />
For example, SVG also has a script node that seems to operate just fine in combination with HTML.</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_V4_HTML_Integration_Requirements&diff=9575X3D V4 HTML Integration Requirements2017-04-05T15:07:16Z<p>Webmaster: </p>
<hr />
<div><br />
== Web3D Strategy ==<br />
"Next-generation evolution + revolution is combined with archival compatibility of existing legacy content." See http://www.web3d.org/strategy Web3D Standards Strategy<br />
<br />
== Boundary conditions ==<br />
<br />
# This is just for X3D running in a web browser and integrated with HTML. This could be expressed as <x3d> ... </x3d> can be treated as a document fragment in the body of an HTML document. If there is X3D outside of this limitation, these requirements may or may not apply.<br />
# Changes to X3D Abstract Specification? I had not gone as far as indicating which changes needed to go where. Obviously new nodes would need to be in the Abstract specification. But even before going there it is necessary to determine what environments X3D will operate in. My limitations are only for a web browser environment. Environments beside that one are not a concern of the requirements I stated. If there are to be other environments than those differences and similarities would need to be worked out.<br />
# Defining an HTML5 Encoding, and perhaps a corresponding HTML5 Profile<br />
<br />
== Notes ==<br />
<br />
# Some of these requirements may overlap by varying amounts. It was easier to specify them this way then trying to make a complete and non-overlapping set. I'm not going to even claim that this is a complete set, but it is a beginning.<br />
# For those that want XHTML, then convert all references to HTML to XHTML and make the appropriate syntax changes. The differences between HTML and XHTML in the appearance of the elements and attributes is that XHTML is strict. This amounts to closing elements, elements and attributes are lower case, mandatory elements and attributes, different MIME type (text/html vs. application/xml or applications/xhtml+xml), and quoted attributes -- see https://www.w3schools.com/html/html_xhtml.asp for details. The WhatWG has a pretty good documentation page on the differences at https://wiki.whatwg.org/wiki/HTML_vs._XHTML.<br />
# Cross-check with the following pages:<br />
## X3D V4 at http://www.web3d.org/x3d4<br />
## X3D V4 development at http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development<br />
<br />
== Candidate Requirements ==<br />
<br />
=== Looks "like" HTML ===<br />
: Elements (nodes in X3D-speak) shall be case independent<br />
: Attributes (fields in X3D-speak) shall be case independent<br />
: X3D nodes shall not have name conflicts with any HTML-defined elements<br />
:: I believe the HTML5 Custom Elements spec requires a prefix-name format for element names. While allowing lowercase should we also allow 'x3d-transform' format alternative names?<br />
:: In that case, each node would be aliased with a HTML5 Custom Element compatible name.<br />
: All X3D nodes shall support all HTML Global Attributes https://www.w3schools.com/tags/ref_standardattributes.asp<br />
:: Is this equivalent to requiring that X3D nodes need to derive from HTMLElement as defined in the DOM?<br />
: All X3D fields with the same name as HTML attributes shall behave as the HTML element<br />
: TBD: Not all style attributes apply to X3D nodes & fields<br />
<br />
=== HTML encodings ===<br />
: HTML5 has two encodings, not one. Each consistently maps to DOM. The WG developing corresponding functionality and syntax that supports both encodings will add tremendous value to everyone.<br />
:: HTML5 Recommendation section 8. The HTML syntax https://www.w3.org/TR/html5/syntax.html#syntax<br />
:: HTML5 Recommendation section 9. The XHTML syntax https://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax<br />
: The differences between HTML and XHTML in the appearance of the elements and attributes is that XHTML is strict. This amounts to closing elements, elements and attributes are lower case, mandatory elements and attributes, different MIME type (text/html vs. application/xml or applications/xhtml+xml), and quoted attributes -- see https://www.w3schools.com/html/html_xhtml.asp for details. The WhatWG has a pretty good documentation page on the differences at https://wiki.whatwg.org/wiki/HTML_vs._XHTML. There are differences in scripting. Most of the differences are obvious extensions from XHTML being an XML document. The W3C HTML5 specification (https://www.w3.org/TR/html5/introduction.html#html-vs-xhtml) is consistent with the above comments. All of the formalities aside, from my observations there is very little use of the XHTML document type for regular web pages.<br />
<br />
=== Functions "like" HTML ===<br />
: All nodes shall be fully integrated with the DOM [This may need to change if certain nodes need to remain hidden from the DOM. For example, the manner which X3DOM implements Inline.]<br />
: The scene graph does not need to be DOM (or a portion of it).<br />
:: X3DOM keeps a separate scene graph from the DOM. The rendering occurs from the scene graph. Changes to the DOM cause changes to the scene graph and vice versa.<br />
: Changes to the DOM shall be reflected in the scene graph<br />
: Changes to the scene graph shall be reflected in the DOM<br />
:: Using the DOM to maintain and reflect state is often considered slow. Could this be optional? Changes to the scene graph cause events which can be listened to if required. (This is why cobweb-dom does not reflect back interpolator output to the DOM at this point)<br />
:: Perhaps it is better to set all current fields that are initialized to be (generally) non-updated. If you want to see a particular value, you need to listen to the appropriate event. Certain events would cause the initialized fields to be updated. I know that this is not written well.<br />
: Events are handled as HTML events<br />
: DOM is the external (i.e., from the web page) API to the scene graph<br />
:: X3dom does it that way. One could add that this external API could be implemented using the SAI thereby guaranteeing X3D event flow determinism<br />
:: Would it be possible to implement the SAI over DOM? I am concerned about having more than one fundamental API. It will cause confusion and errors.<br />
<br />
=== Other HTML related ===<br />
: X3D scenes can pass events to/from the DOM and ROUTE events within the scene graph.<br />
: HTML elements, SVG elements and css blocks can be interspersed with X3D elements.<br />
: HTML Script, SVG Script and X3D Script elements are unique and distinguishable.<br />
:: I still have not heard a good reason to have X3D scripts. They cannot have the same element name so legacy X3D files cannot run. At that point using HTML JavaScript for all processing appears to be the right thing to do. I see it as very important to content developers not to have multiple flavors of JavaScript running.<br />
: String-based DOM events correlate with strongly typed X3D events by defined correspondences<br />
:: Multiple candidate approaches can be listed and compared<br />
:: The events I am referring to are those that cross between X3D and HTML or any other non-X3D environment (e.g., display, orientation, etc.).<br />
<br />
=== X3D shall support the evolving web standards for flat-3D (WebGL), VR WebVR) and AR ===<br />
<br />
=== Existing features & functionality ===<br />
: Perform the following tasks with the requirements that is be conflict with the above<br />
:: Conduct a review of all existing features (nodes) to determine if any should be deprecated in V4<br />
:: Conduct a review of all existing functionality (run-time) to determine if any should be deprecated or changed in V4<br />
: Include all features and functionality that passes the above reviews<br />
<br />
=== Additional features to be added ===<br />
: Deformable-skin joint based animation<br />
: Support for multiple geometry formats, including OBJ, glTF<br />
:: I have a pretty good idea about gltf2 support in x3dom, see my x3dom GitHub issue. But since it is quite a bit of work, it will be some time/use case.<br />
: Increased Material support with a standard library of pre-defined shaders<br />
:: Three.js has good shaders including for PBR. But again quite a bit of work. Not sure if Fraunhofer is that engaged since there may be commercialization interest.<br />
:: Including programmable shaders in declarative language and not providing predefined operations seems like a poor choice. This is an attempt to start to rectify it.<br />
: Mechanism to navigate a scene without a pointing device<br />
: Mechanism to touch or select objects without a pointing device<br />
:: Or with wand or controller.<br />
: Review other 3D/VR display technologies (XML3D, A-Frame, GLAM, etc.) to determine if there are features that should be included<br />
:: The three.js examples are also inspiring. Postprocessing of the rendered frame in another shader stage comes to mind. There are probably many more modern graphics methods which need some support. Ambient occlusion ssao? Motion blur? Distance defocus?<br />
<br />
== Issues ==<br />
<br />
== General comments ==<br />
<br />
Generally, the vrml spec. was written before the advent of powerful GPUs (massively parallel super computers) where it now can be faster to repeat the same fragment shader operation for each pixel (perhaps a million times) rather than update data between cpu and gpu once. Not sure what the consequences exactly are other than being shader friendly in some way.<br />
<br />
Deformable skin from joint animation calculations are typically carried out on the GPU. Too much for serial processors. I'm sure there are other items.<br />
<br />
=== Scripting ===<br />
<br />
* See https://www.w3.org/TR/SVG/script.html<br />
* See the example in 18.2 The 'script' element at https://www.w3.org/TR/SVG/script.html#ScriptElement<br />
* See the DOM interface definition for SVGScriptElement at https://www.w3.org/TR/SVG/script.html#InterfaceSVGScriptElement<br />
<br />
=== OBJ file format ===<br />
<br />
I applaud the idea of multiple geometry formats, as we need interoperability, and glTF is a nice standard.<br />
<br />
But I would remove OBJ from the list, or be careful what parts of the OBJ are necessary to be supported.<br />
* The OBJ is an old format. It doesn't have many features nice for modern rendering (like a specification of shading suitable for modern GPUs). And it does have some features that are unhandy, and were probably really useful only by the initial Wavefront OBJ implementation (trace_obj).<br />
* The OBJ specification is not officially maintained by anyone, I think. It's not updated. The creators of it, and the original software implementing it, are closed now. (https://en.wikipedia.org/wiki/Wavefront_Technologies , https://en.wikipedia.org/wiki/The_Advanced_Visualizer ). No-one since then has taken the effort to update the OBJ specification in any way, as far as I know.<br />
* Although it has a specification http://www.martinreddy.net/gfx/3d/OBJ.spec, most implementations treat it more like a "de-facto" standard, implementing different subsets of the format, whatever seems useful. There are features in OBJ format that are widely supported (vertexes with normals, tex coords), and there are features not supported by any existing implementation (I have not seen yet an implementation that supports Bezier patches defined in OBJ files; or one that supports d_interp or trace_obj).<br />
<br />
Bottom line: While OBJ is a popular format, I would either discourage from using it (we made X3D for a reason --- it's really better on all accounts), or at least specify only a precise subset of OBJ features required to be supported.<br />
<br />
A very informative link to Wikipedia description of OBJ: https://en.wikipedia.org/wiki/Wavefront_.obj_file<br />
<br />
I included OBJ because it is a very popular format for the exchange of geometry and normal information. I have only seen it with triangles. I am in complete agreement with Michalis about limiting it's scope.<br />
For example, SVG also has a script node that seems to operate just fine in combination with HTML.</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=Essential_Elements_of_X3D&diff=9502Essential Elements of X3D2016-11-27T18:24:46Z<p>Webmaster: </p>
<hr />
<div>This table lists the essential elements of X3D as supplied by community members. If you wish to add to this collection, please start a new column with your name as the column header. You can add rows to include elements not currently listed.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Element<br />
! Description<br />
! Leonard<br />
! Andreas<br />
! Doug<br />
|-<br />
| Extensible<br />
| Definition can be extended by the user/developer in a non-fatal manner<br />
| X<br />
| X<br />
| <br />
|-<br />
| Long lasting<br />
| Supports encodings from the past or 10 years into the future<br />
| X<br />
| X<br />
| <br />
|-<br />
| Declarative<br />
| Defines all elements declaratively<br />
| X<br />
| <br />
| <br />
|-<br />
| Multi-platform<br />
| Runs the (nearly) the same on all supported platforms<br />
| X<br />
| X<br />
| <br />
|-<br />
| Modeling<br />
| Allows for the definition of 3D models<br />
| <br />
| <br />
| <br />
|-<br />
| Feature rich<br />
| The definitions contains many features and capabilities<br />
| <br />
| X<br />
| <br />
|-<br />
| Volume displays<br />
| Capable of displaying more than just surfaces<br />
| <br />
| <br />
| <br />
|-<br />
| Built-in navigation<br />
| tbd<br />
| <br />
| X<br />
| <br />
|-<br />
| Deterministic time model<br />
| tbd<br />
| <br />
| <br />
| <br />
|-<br />
| Simulation capable<br />
| Supports high fidelity simulations<br />
| <br />
| X<br />
| <br />
|-<br />
| Self documenting<br />
| Definition supports self-documenting structures (e.g., Metadata)<br />
| X<br />
| X<br />
| <br />
|}</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=Essential_Elements_of_X3D&diff=9501Essential Elements of X3D2016-11-27T18:21:36Z<p>Webmaster: Initial page creation</p>
<hr />
<div>This table lists the essential elements of X3D as supplied by community members. If you wish to add to this collection, please start a new column with your name as the column header. You can add rows to include elements not currently listed.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Element<br />
! Description<br />
! Leonard<br />
! Andreas<br />
! Doug<br />
|-<br />
| Extensible<br />
| Definition can be extended by the user/developer in a non-fatal manner<br />
| X<br />
| X<br />
| <br />
|-<br />
| Long lasting<br />
| Supports encodings from the past or 10 years into the future<br />
| X<br />
| X<br />
| <br />
|-<br />
| Declarative<br />
| Defines all elements declaratively<br />
| X<br />
| <br />
| <br />
|-<br />
| Multi-platform<br />
| Runs the (nearly) the same on all supported platforms<br />
| X<br />
| X<br />
| <br />
|-<br />
| Modeling<br />
| Allows for the definition of 3D models<br />
| <br />
| <br />
| <br />
|-<br />
| Feature rich<br />
| The definitions contains many features and capabilities<br />
| <br />
| <br />
| <br />
|-<br />
| Volume displays<br />
| Capable of displaying more than just surfaces<br />
| <br />
| <br />
| <br />
|-<br />
| Built-in navigation<br />
| tbd<br />
| <br />
| <br />
| <br />
|-<br />
| Deterministic time model<br />
| tbd<br />
| <br />
| <br />
| <br />
|-<br />
| Simulation capable<br />
| Supports high fidelity simulations<br />
| <br />
| X<br />
| <br />
|-<br />
| Self documenting<br />
| Definition supports self-documenting structures (e.g., Metadata)<br />
| X<br />
| X<br />
| <br />
|}</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_version_4.0_Development&diff=9500X3D version 4.0 Development2016-11-27T18:05:23Z<p>Webmaster: /* Related Work */ Added information about non-Consortium VR initiatives</p>
<hr />
<div>==Genesis and Strategic Overview==<br />
<br />
Web3D Consortium working groups currently define specification goals and requirements. Working group efforts are often the focus for defining and testing new X3D components.<br />
<br />
We publicly review these goals annually during [http://www.web3d2015.org Web3D Conference] and [http://s2014.siggraph.org/attendees/birds-feather SIGGRAPH BOF] meetings.<br />
<br />
Suggestions, development and discussion via the [http://web3d.org/mailman/listinfo/x3d-public_web3d.org x3d-public mailing list] is ongoing.<br />
<br />
X3D version 3.4 Development efforts were evolutionary improvements to the widely proven X3D Graphics architecture. Consortium members decided to skip version 3.4 and go straight to version 4.0, prior goals and requirements have all been merged here.<br />
<br />
The Candidate Capabilities list shows that a lot of interesting capabilities have been proposed and are under way for X3D version 4. However, topics on this list are not guaranteed to be completed! Rather these are all works in progress.<br />
<br />
Activity and approval proceeds based on technical contributions and Web3D Consortium Member priorities. Please consider [http://web3d.org/membership/join joining Web3D Consortium] to help advance 3D graphics on the Web.These X3D version 4.0 Development efforts are considering potentially major additions to the baseline X3D architecture.<br />
<br />
* [http://web3d.org/wiki/images/f/f2/X3DOM_4_WebGL_audience_10_2013.pdf Summary slides here (Oct 2013)] summarize this steadily continuing effort<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_HTML5 HTML5], [http://www.w3.org/community/declarative3d/ Declarative 3D], [http://www.x3dom.org X3DOM], and possibly CSS<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_Augmented_Reality Augmented Reality Continuum (ARC)] (being renamed as Mixed Augmented Reality MAR)<br />
* Relaxing prior design constraints can enable a broader new basis for X3D integration<br />
* Normalizing interaction semantics with HTML5 - now a stable W3C Recommendation - can further open up X3D for the vast majority of Web authors<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered. X3D Futures planning is currently a Web3D Consortium member-only activity.<br />
<br />
== Legacy Issues ==<br />
<br />
We plan to confirm the existence of complete capabilities for X3D v3.3 prior to final approval of X3D version 4.<br />
<br />
* Full support for all existing X3D v3.3 components:<br />
** At least two compatible implementations (including at least one in open source) plus repeatable example scenes<br />
** Layer, ParticleSystems, RigidBodyPhysics, Shaders, TODO others<br />
** TransformSensor node: [http://doc.instantreality.org/documentation/nodetype/TransformSensor/ IGD] and [http://www.parallelgraphics.com/developer/products/cortona/extensions/transformsensor/ old Cortona]<br />
<br />
* Is it necessary for Layout component to be deprecated or improved?<br />
<br />
== Candidate Capabilities ==<br />
<br />
Each of the following possibilities for X3D version 4 have been discussed by the various X3D working groups during meetings and on mailing lists.<br />
Each potential capability is considered to be a feasible (and in most cases, straightforward) addition to the existing X3D version 3.3 architecture.<br />
<br />
*'''Appearance'''<br />
**'''Images''': recommended formats for imagery and video (.gif .bmp .svg .flv .exr .hdr etc.). Consider [http://en.wikipedia.org/wiki/QR_code QR codes] as a first-class image type since it contains imagery and information, especially useful in Mixed Augmented Reality (MAR) applications<br />
**'''Materials''': advanced parameters<br />
**[[X3D Multitexture | Multitexture]]: review for correctness, completeness and conformance of rendering example scenes<br />
**'''Rendering''': bump maps, [http://doc.instantreality.org/tutorial/dynamic-shadows/ shadows], edge smoothing, gamma correction, Non-Photorealistic Rendering (NPR)<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/shaders.html Shaders]: improved support and better interoperability, library of examples; [http://doc.instantreality.org/documentation/nodetype/CommonSurfaceShader/ CommonSurfaceShader?]<br />
**'''Texturing''': [http://en.wikipedia.org/wiki/Texture_atlas Texture atlas], [http://en.wikipedia.org/wiki/Projective_texture_mapping projective texture mapping (PTM)], [http://www.xj3d.org/extensions/render_texture.html RenderedTexture node] for multipass rendering - 2D texture version of GeneratedCubeMapTexture, first proposed by Xj3D and also implemented in X3DOM and InstantReality, useful for all kinds of NPR, shadows, mirrors, etc.<br />
*'''Audio and video''': alignment with [https://www.w3.org/2011/audio W3C Audio Working Group], especially for [https://webaudio.github.io/web-audio-api Web Audio API] and [https://webaudio.github.io/web-midi-api Web Midi API]. Adding royalty-free formats, streamability, [http://web3d.org/pipermail/x3d-public_web3d.org/2013-December/002681.html disabling attenuation], 3D aural spatialization using reflection from simple geometry (such as [http://gamma.cs.unc.edu/Sound/RESound RESOUND]).<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/computer-aided-design-cad Computer Aided Design (CAD)]''' Interactive Profile, to include:<br />
**[http://www.web3d.org/wiki/index.php/X3D_v4.0_CAD_Improvements X3D v4.0 CAD Improvements] with 3D printing + 3D scanning included<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/CADInterchange.html CADInterchange profile] plus FillProperties/LineProperties, primitive/Geometry2D nodes, Extrusion, NURBS, ClipPlane<br />
**Part selection/animation, 3D printing, [http://www.web3d.org/realtime-3d/news/3d-graphics-compress-call-contributions Compressed Binary Encoding (CBE)], possibly [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html annotations component]<br />
** Building Information Models (BIM), Architecture Engineering Construction (AEC), Physical Sensors<br />
*'''[http://www.ecma-international.org/publications/standards/Ecma-262.htm ECMAScript]''' (Javascript) specification revision compatibility with [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html X3D scripting]; possibly add C# or Python support<br />
*'''Events'''<br />
** Review X3D event interoperability with other event models, such as Document Object Model (DOM) Recommendations<br />
** Add capability for Event logging and playback so that deterministic replay is possible for demonstrations and debugging<br />
*'''Generalized input/output interface support'''<br />
** Possibly [http://www.cs.unc.edu/Research/vrpn/index.html Virtual Reality Peripheral Network (VRPN)], gesture recognition (such as [http://en.wikipedia.org/wiki/Kinect KINECT], [http://www.leapmotion.com LEAP]), etc.<br />
** Support for arbitrary sensors and user interaction devices<br />
* '''Geometry''': point size (or perspective rendering), progressive meshes (suitable for both compression and streaming), 3D ExtrudedText, support for [http://en.wikipedia.org/wiki/Web_typography Web typography] using [http://www.w3.org/TR/WOFF Web Open Fonts Format (WOFF)]<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/x3d-earth Geospatial X3D]''' component<br />
** [http://www.igraphics.com/Standards/EnhancedGeospatialComponent_2007_10_30/Part01/X3D.html Enhanced Geospatial Component - spatial reference frame (SRF)] and [http://www.opengeospatial.org/standards/kml KML] support, [http://www.opengeospatial.org/projects/initiatives/3dpie OGC 3D Portrayal], [http://web3d.org/pipermail/x3d-public_web3d.org/2010-December/001187.html GpsSensor], [http://openlayers.org OpenLayer] mashups<br />
** GeoSet collection of adjacent GeoElevationGrid nodes to enable proper computation of normals for edge boundaries of adjacent grids<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/h-anim Humanoid Animation (H-Anim)]''' anatomical correctness for skeleton and skinning, motion capture (mocap) and playback, interchangeable avatars, animation for hands feet and faces<br />
* '''Interoperability''': include ''class'' attribute for all nodes to all encodings<br />
* '''[http://www.json.org JSON]''': JavaScript Object Notation as an X3D encoding ([http://web3d.org/pipermail/x3d-public_web3d.org/2014-July/thread.html#2854 assessment thread]), relation to [http://www.khronos.org/gltf GlTF], streaming considerations<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/medx3d Medical working group]''' capabilities<br />
** [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html Annotations component] and metadata usage<br />
** Archival 3D medical records, potential emphasis on [http://en.wikipedia.org/wiki/Traumatic_brain_injury Traumatic brain injury (TBI)] volume visualization<br />
** Haptics component for force feedback; [http://www.w3.org/TR/vibration W3C Vibrations API] for tactile feedback<br />
** Soft-body physics component to complement rigid-body physics component<br />
* '''Mobile Profile.''' TODO - needed? Calling out a reduced palette for mobile devices remains interesting, but might instead remain a browser-optional optimization.<br />
* '''[http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#Nodereference Metadata]''': support for embedding information useful for applications utilizing X3D<br />
** Enumerated types: better access, typing, naming, and validation than using MetadataSet/MetadataString combinations<br />
* '''Mixed and Augmented Reality (MAR)''': follow ISO MAR Reference Model, integrate multiple capabilities with devices situated in real world<br />
*'''Networking''': consider [http://www.web3d.org/x3d/content/examples/Basic/Networking NetworkSensor] and event-passing issues, streaming using [http://www.json.org JSON], server-side 3D topics<br />
*'''Security and privacy''':<br />
** Include X3D Networking Component Level 4 support for https in Immersive, Interactive and other commonly used profiles<br />
** Review X3D specifications to ensure that Security Considerations are fully documented throughout in every component<br />
** [http://www.w3.org/standards/xml/security XML Security] provides best-available encryption, digital signature (authentication)<br />
** [http://www.w3.org/standards/webdesign/privacy Web Privacy]: examine X3D compatibility with Do Not Track, P3P, POWDER<br />
*'''Viewing and navigation''': [http://www.web3d.org/x3d/content/examples/Basic/development/CameraExamplesIndex.html cinematic camera control], alternative navigation types (such as PAN, [http://www.x3dom.org/?p=3536 TURNTABLE] etc.), [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/behaviours.html Recommended navigation behaviours] review, and old MatrixTransform node (esp. useful for CAD, VR/AR etc., implemented in X3DOM and InstantReality)<br />
*'''Virtual Reality (VR)''': requirements definition needed includes viewing with stereo devices, interocular distance, frame-rate requirements, comparison (and potential profile) for [https://webvr.info WebVR] capabilities, physiological considerations, health and safety, relation with Mixed Augmented Reality (MAR), etc.<br />
<br />
All suggestions and recommendations are welcome. Component improvements and additions are approved by Web3D Consortium members.<br />
<br />
* TODO: Which experimental nodes are ready? Candidates include [http://doc.instantreality.org Fraunhofer], X3DOM, Cobweb, other members and working groups?<br />
* TODO: articulate Big Data and Cloud, server-side visualization, related issues.<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered.<br />
<br />
== Backwards and Forwards Compatibility ==<br />
<br />
A major benefit of using the X3D standard is full backwards compatibility with prior VRML97 and X3D content.<br />
Thanks to careful design and insistence on implementation/evaluation, the X3D International Standard has maintained both steady growth and interoperability ever since Virtual Reality Modeling Language (VRML) in 1997. This track record of stability and innovation is among the best in the 3D graphics industry.<br />
<br />
Our goal is to maximize, but not necessarily require, backwards compatibility in version 4.0 with the version 3.x specifications<br />
* A great majority of X3D nodes and features are likely achievable without change<br />
* Some X3D features may require import/export conversion for compatibility (event model reconciliation, ROUTEs and sensors perhaps)<br />
* A few features might be refactored, deprecated or obsoleted (none yet identified)<br />
* Name deconfliction: HTML Script versus embedded X3D Script<br />
<br />
The comprehensive forward compatibility of VRML97 and X3D with later-developed X3D versions shows that careful anticipatory design is achievable.<br />
<br />
X3D version 4.0 Development efforts are currently focused on HTML5, Declarative 3D, X3DOM, and Cobweb with many more issues under consideration.<br />
* Discussion of [[Importing and adding nodes in HTML]]<br />
<br />
X3D Version 4.1 is focused on Mixed Augmented Reality (MAR) capabilities, which may also require architectural changes. Some new technologies may get pushed from 4.0 to 4.1 (or back again) after careful consideration by the respective working groups.<br />
<br />
Related specification support and changes<br />
*As with all other X3D components, all work is defined in the abstract specification has corresponding file encodings (.x3d .x3dv .x3db) and language bindings (ECMAScript and Java). <br />
*Compatibility concerns include evolutionary efforts to upgrade the X3D Compressed Binary Encoding (CBE), as described in the [http://www.web3d.org/realtime-3d/working-groups/x3d/compressed-binary/x3d-compressed-binary-encoding-call-contributions X3D Compressed Binary Encoding Call For Contributions].<br />
*ECMAScript (JavaScript) support in X3D needs to be upgraded to the new standard for that rapidly improving programming language.<br />
**[http://standards.iso.org/ittf/PubliclyAvailableStandards/c055755_ISO_IEC_16262_2011(E).zip ISO/IEC 16262:2011 Information technology — ECMAScript language specification] (.zip download)<br />
**Downloadable from [http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html ISO Publicly Available Standards] site without charge<br />
**This relates to [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html 19777-1 Part 2, X3D Scene Access Interface (SAI) language bindings for EcmaScript]<br />
<br />
== Architectural Considerations ==<br />
<br />
This section will synopsize significant differences between X3D version 4 and X3D version 3 that may require structural changes in tools and scenes. Special attention is needed to minimize incompatibilities with legacy software and content.<br />
<br />
== Open Questions ==<br />
<br />
* Are ARC abstract design and X3D AR proposals sufficiently mature to enable integration with HTML5/Declarative 3D/X3DOM issues?<br />
* Are the previously X3D Layer/Layering components compatible with HTML5 overlay model? Are they still needed, perhaps for multiscreen or CAVE support?<br />
* Mashup and interoperability support: is anything else needed for broader use with the Web? YouTube etc.<br />
<br />
== Related Work==<br />
<br />
Much careful planning is involved, we are working to ensure that X3D version 4 can be coherently advanced in combination with a [http://www.web3d.org/specifications/X3dSpecificationRelationships.png coordinated set of steadily evolving ISO/IEC standards].<br />
*'''X3D Efficient Binary Encoding (EBE).''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings. See also SRC format (Web3D 2014)and ExternalGeometry node in InstantPlayer and X3DOM<br />
*'''X3D JavaScript Object Notation (JSON) Encoding.''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings.<br />
*'''X3D version 4.0 (HTML5/X3D DOM)'''. This work is proceeding in parallel. X3D version 4 support is expected.<br />
*'''X3D version 4.1 (Mixed Augmented Reality)'''. Nodes and capabilities in this arena will build on v4.0 and HTML5. Experimentation, evolution and evaluation<br />
occurs throughout.<br />
* [https://webvr.info/ '''WebVR'''] "bringing virtual reality to the web" - standardize the interface to VR displays and controllers <br />
* [https://www.w3.org/community/decwebvr/ '''W3C's Declarative WebVR Community Group'''] formed to developed a declaractive 3D standard for WebVR<br />
** '''[[Essential Elements of X3D]]''' collects elements that are essential to X3D<br />
<br />
== Schedule ==<br />
<br />
'''ISO Considerations'''<br />
* Deciding readiness for ISO New Work Item Proposal (NWIP): we need Committee Draft (CD) specification prose for each planned capability.<br />
* Web3D Consortium is not locked into an annual schedule, ISO handling is flexible.<br />
* Once the NWIP is approved, ISO rules for schedule and review are established.<br />
<br />
'''Execution goals'''<br />
* Review progress during monthly calls, Web3D Conference, and SIGGRAPH Conference.<br />
* We are continuing a monthly review schedule for submissions so that we can build out X3D version 4 one component at a time.<br />
* We are planning to have a 1-year deadline for completion of CD specification prose, rather than wait until all possible version 4 work is ready.<br />
* Web3D Consortium members and public review when a final draft specification is ready to proceed to ISO.<br />
* Any new components not meeting Web3D deadlines might be a candidate for deferral to V4.1. Or considered not ready.<br />
<br />
'''Progress'''<br />
<br />
* Active development of X3D, X3DOM and Cobweb content is tracking HTML 5 capabilities now<br />
* We participate and contribute to the W3C Community Group for [http://www.w3.org/community/declarative3d Declarative 3D]</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=Importing_and_adding_nodes_in_HTML&diff=9448Importing and adding nodes in HTML2016-10-02T16:22:03Z<p>Webmaster: Created page with "Dynamic HTML allows the addition of elements to an existing page. X3D allows the importation of nodes (Inline) into an existing scene. This page is to record major discussion..."</p>
<hr />
<div>Dynamic HTML allows the addition of elements to an existing page. X3D allows the importation of nodes (Inline) into an existing scene. This page is to record major discussion points and solution(s) so that X3D and HTML5 play nicely.<br />
<br />
X3D has defined in V3.3 does not directly interact with HTML. It is defined in a stand-alone environment. If it is used in a web page, then there is a "firewall" between the X3D environment and HTML environment that is breached only via the SAI. This discussion applies only in an X3D/HTML5 integrated environment with the DOM is shared and used by both.</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_version_4.0_Development&diff=9447X3D version 4.0 Development2016-10-02T16:17:44Z<p>Webmaster: /* Backwards and Forwards Compatibility */</p>
<hr />
<div>==Genesis and Strategic Overview==<br />
<br />
Web3D Consortium working groups currently define specification goals and requirements. Working group efforts are often the focus for defining and testing new X3D components.<br />
<br />
We publicly review these goals annually during [http://www.web3d2015.org Web3D Conference] and [http://s2014.siggraph.org/attendees/birds-feather SIGGRAPH BOF] meetings.<br />
<br />
Suggestions, development and discussion via the [http://web3d.org/mailman/listinfo/x3d-public_web3d.org x3d-public mailing list] is ongoing.<br />
<br />
X3D version 3.4 Development efforts were evolutionary improvements to the widely proven X3D Graphics architecture. Consortium members decided to skip version 3.4 and go straight to version 4.0, prior goals and requirements have all been merged here.<br />
<br />
The Candidate Capabilities list shows that a lot of interesting capabilities have been proposed and are under way for X3D version 4. However, topics on this list are not guaranteed to be completed! Rather these are all works in progress.<br />
<br />
Activity and approval proceeds based on technical contributions and Web3D Consortium Member priorities. Please consider [http://web3d.org/membership/join joining Web3D Consortium] to help advance 3D graphics on the Web.These X3D version 4.0 Development efforts are considering potentially major additions to the baseline X3D architecture.<br />
<br />
* [http://web3d.org/wiki/images/f/f2/X3DOM_4_WebGL_audience_10_2013.pdf Summary slides here (Oct 2013)] summarize this steadily continuing effort<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_HTML5 HTML5], [http://www.w3.org/community/declarative3d/ Declarative 3D], [http://www.x3dom.org X3DOM], and possibly CSS<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_Augmented_Reality Augmented Reality Continuum (ARC)] (being renamed as Mixed Augmented Reality MAR)<br />
* Relaxing prior design constraints can enable a broader new basis for X3D integration<br />
* Normalizing interaction semantics with HTML5 - now a stable W3C Recommendation - can further open up X3D for the vast majority of Web authors<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered. X3D Futures planning is currently a Web3D Consortium member-only activity.<br />
<br />
== Legacy Issues ==<br />
<br />
We plan to confirm the existence of complete capabilities for X3D v3.3 prior to final approval of X3D version 4.<br />
<br />
* Full support for all existing X3D v3.3 components:<br />
** At least two compatible implementations (including at least one in open source) plus repeatable example scenes<br />
** Layer, ParticleSystems, RigidBodyPhysics, Shaders, TODO others<br />
** TransformSensor node: [http://doc.instantreality.org/documentation/nodetype/TransformSensor/ IGD] and [http://www.parallelgraphics.com/developer/products/cortona/extensions/transformsensor/ old Cortona]<br />
<br />
* Is it necessary for Layout component to be deprecated or improved?<br />
<br />
== Candidate Capabilities ==<br />
<br />
Each of the following possibilities for X3D version 4 have been discussed by the various X3D working groups during meetings and on mailing lists.<br />
Each potential capability is considered to be a feasible (and in most cases, straightforward) addition to the existing X3D version 3.3 architecture.<br />
<br />
*'''Appearance'''<br />
**'''Images''': recommended formats for imagery and video (.gif .bmp .svg .flv .exr .hdr etc.). Consider [http://en.wikipedia.org/wiki/QR_code QR codes] as a first-class image type since it contains imagery and information, especially useful in Mixed Augmented Reality (MAR) applications<br />
**'''Materials''': advanced parameters<br />
**[[X3D Multitexture | Multitexture]]: review for correctness, completeness and conformance of rendering example scenes<br />
**'''Rendering''': bump maps, [http://doc.instantreality.org/tutorial/dynamic-shadows/ shadows], edge smoothing, gamma correction, Non-Photorealistic Rendering (NPR)<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/shaders.html Shaders]: improved support and better interoperability, library of examples; [http://doc.instantreality.org/documentation/nodetype/CommonSurfaceShader/ CommonSurfaceShader?]<br />
**'''Texturing''': [http://en.wikipedia.org/wiki/Texture_atlas Texture atlas], [http://en.wikipedia.org/wiki/Projective_texture_mapping projective texture mapping (PTM)], [http://www.xj3d.org/extensions/render_texture.html RenderedTexture node] for multipass rendering - 2D texture version of GeneratedCubeMapTexture, first proposed by Xj3D and also implemented in X3DOM and InstantReality, useful for all kinds of NPR, shadows, mirrors, etc.<br />
*'''Audio and video''': adding royalty-free formats, streamability, [http://web3d.org/pipermail/x3d-public_web3d.org/2013-December/002681.html disabling attenuation], 3D aural spatialization using reflection from simple geometry (such as [http://gamma.cs.unc.edu/Sound/RESound RESOUND] or [http://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html Web Audio API])<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/computer-aided-design-cad Computer Aided Design (CAD)]''' Interactive Profile, to include:<br />
**[http://www.web3d.org/wiki/index.php/X3D_v4.0_CAD_Improvements X3D v4.0 CAD Improvements] with 3D printing + 3D scanning included<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/CADInterchange.html CADInterchange profile] plus FillProperties/LineProperties, primitive/Geometry2D nodes, Extrusion, NURBS, ClipPlane<br />
**Part selection/animation, 3D printing, [http://www.web3d.org/realtime-3d/news/3d-graphics-compress-call-contributions Compressed Binary Encoding (CBE)], possibly [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html annotations component]<br />
** Building Information Models (BIM), Architecture Engineering Construction (AEC), Physical Sensors<br />
*'''[http://www.ecma-international.org/publications/standards/Ecma-262.htm ECMAScript]''' (Javascript) specification revision compatibility with [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html X3D scripting]; possibly add C# or Python support<br />
*'''Events'''<br />
** Review X3D event interoperability with other event models, such as Document Object Model (DOM) Recommendations<br />
** Add capability for Event logging and playback so that deterministic replay is possible for demonstrations and debugging<br />
*'''Generalized input/output interface support'''<br />
** Possibly [http://www.cs.unc.edu/Research/vrpn/index.html Virtual Reality Peripheral Network (VRPN)], gesture recognition (such as [http://en.wikipedia.org/wiki/Kinect KINECT], [http://www.leapmotion.com LEAP]), etc.<br />
** Support for arbitrary sensors and user interaction devices<br />
* '''Geometry''': point size (or perspective rendering), progressive meshes (suitable for both compression and streaming), 3D ExtrudedText, support for [http://en.wikipedia.org/wiki/Web_typography Web typography] using [http://www.w3.org/TR/WOFF Web Open Fonts Format (WOFF)]<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/x3d-earth Geospatial X3D]''' component<br />
** [http://www.igraphics.com/Standards/EnhancedGeospatialComponent_2007_10_30/Part01/X3D.html Enhanced Geospatial Component - spatial reference frame (SRF)] and [http://www.opengeospatial.org/standards/kml KML] support, [http://www.opengeospatial.org/projects/initiatives/3dpie OGC 3D Portrayal], [http://web3d.org/pipermail/x3d-public_web3d.org/2010-December/001187.html GpsSensor], [http://openlayers.org OpenLayer] mashups<br />
** GeoSet collection of adjacent GeoElevationGrid nodes to enable proper computation of normals for edge boundaries of adjacent grids<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/h-anim Humanoid Animation (H-Anim)]''' anatomical correctness for skeleton and skinning, motion capture (mocap) and playback, interchangeable avatars, animation for hands feet and faces<br />
* '''Interoperability''': include ''class'' attribute for all nodes to all encodings<br />
* '''[http://www.json.org JSON]''': JavaScript Object Notation as an X3D encoding ([http://web3d.org/pipermail/x3d-public_web3d.org/2014-July/thread.html#2854 assessment thread]), relation to [http://www.khronos.org/gltf GlTF], streaming considerations<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/medx3d Medical working group]''' capabilities<br />
** [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html Annotations component] and metadata usage<br />
** Archival 3D medical records, potential emphasis on [http://en.wikipedia.org/wiki/Traumatic_brain_injury Traumatic brain injury (TBI)] volume visualization<br />
** Haptics component for force feedback; [http://www.w3.org/TR/vibration W3C Vibrations API] for tactile feedback<br />
** Soft-body physics component to complement rigid-body physics component<br />
* '''Mobile Profile.''' TODO - needed? Calling out a reduced palette for mobile devices remains interesting, but might instead remain a browser-optional optimization.<br />
* '''[http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#Nodereference Metadata]''': support for embedding information useful for applications utilizing X3D<br />
** Enumerated types: better access, typing, naming, and validation than using MetadataSet/MetadataString combinations<br />
* '''Mixed and Augmented Reality (MAR)''': follow ISO MAR Reference Model, integrate multiple capabilities with devices situated in real world<br />
*'''Networking''': consider [http://www.web3d.org/x3d/content/examples/Basic/Networking NetworkSensor] and event-passing issues, streaming using [http://www.json.org JSON], server-side 3D topics<br />
*'''Security and privacy''':<br />
** Include X3D Networking Component Level 4 support for https in Immersive, Interactive and other commonly used profiles<br />
** Review X3D specifications to ensure that Security Considerations are fully documented throughout in every component<br />
** [http://www.w3.org/standards/xml/security XML Security] provides best-available encryption, digital signature (authentication)<br />
** [http://www.w3.org/standards/webdesign/privacy Web Privacy]: examine X3D compatibility with Do Not Track, P3P, POWDER<br />
*'''Viewing and navigation''': cinematic camera control, alternative navigation types (such as PAN, [http://www.x3dom.org/?p=3536 TURNTABLE] etc.), [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/behaviours.html Recommended navigation behaviours] review, and old MatrixTransform node (esp. useful for CAD, VR/AR etc., implemented in X3DOM and InstantReality)<br />
*'''Virtual Reality (VR)''': requirements definition needed includes viewing with stereo devices, interocular distance, frame-rate requirements, comparison with [https://webvr.info WebVR] capabilities, physiological considerations, health and safety, relation with Mixed Augmented Reality (MAR), etc.<br />
<br />
All suggestions and recommendations are welcome. Component improvements and additions are approved by Web3D Consortium members.<br />
<br />
* TODO: Which experimental nodes are ready? Candidates include [http://doc.instantreality.org Fraunhofer], X3DOM, Cobweb, other members and working groups?<br />
* TODO: articulate Big Data and Cloud, server-side visualization, related issues<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered.<br />
<br />
== Backwards and Forwards Compatibility ==<br />
<br />
A major benefit of using the X3D standard is full backwards compatibility with prior VRML97 and X3D content.<br />
Thanks to careful design and insistence on implementation/evaluation, the X3D International Standard has maintained both steady growth and interoperability ever since Virtual Reality Modeling Language (VRML) in 1997. This track record of stability and innovation is among the best in the 3D graphics industry.<br />
<br />
Our goal is to maximize, but not necessarily require, backwards compatibility in version 4.0 with the version 3.x specifications<br />
* A great majority of X3D nodes and features are likely achievable without change<br />
* Some X3D features may require import/export conversion for compatibility (event model reconciliation, ROUTEs and sensors perhaps)<br />
* A few features might be refactored, deprecated or obsoleted (none yet identified)<br />
* Name deconfliction: HTML Script versus embedded X3D Script<br />
<br />
The comprehensive forward compatibility of VRML97 and X3D with later-developed X3D versions shows that careful anticipatory design is achievable.<br />
<br />
X3D version 4.0 Development efforts are currently focused on HTML5, Declarative 3D, X3DOM, and Cobweb with many more issues under consideration.<br />
* Discussion of [[Importing and adding nodes in HTML]]<br />
<br />
X3D Version 4.1 is focused on Mixed Augmented Reality (MAR) capabilities, which may also require architectural changes. Some new technologies may get pushed from 4.0 to 4.1 (or back again) after careful consideration by the respective working groups.<br />
<br />
Related specification support and changes<br />
*As with all other X3D components, all work is defined in the abstract specification has corresponding file encodings (.x3d .x3dv .x3db) and language bindings (ECMAScript and Java). <br />
*Compatibility concerns include evolutionary efforts to upgrade the X3D Compressed Binary Encoding (CBE), as described in the [http://www.web3d.org/realtime-3d/working-groups/x3d/compressed-binary/x3d-compressed-binary-encoding-call-contributions X3D Compressed Binary Encoding Call For Contributions].<br />
*ECMAScript (JavaScript) support in X3D needs to be upgraded to the new standard for that rapidly improving programming language.<br />
**[http://standards.iso.org/ittf/PubliclyAvailableStandards/c055755_ISO_IEC_16262_2011(E).zip ISO/IEC 16262:2011 Information technology — ECMAScript language specification] (.zip download)<br />
**Downloadable from [http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html ISO Publicly Available Standards] site without charge<br />
**This relates to [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html 19777-1 Part 2, X3D Scene Access Interface (SAI) language bindings for EcmaScript]<br />
<br />
== Architectural Considerations ==<br />
<br />
This section will synopsize significant differences between X3D version 4 and X3D version 3 that may require structural changes in tools and scenes. Special attention is needed to minimize incompatibilities with legacy software and content.<br />
<br />
== Open Questions ==<br />
<br />
* Are ARC abstract design and X3D AR proposals sufficiently mature to enable integration with HTML5/Declarative 3D/X3DOM issues?<br />
* Are the previously X3D Layer/Layering components compatible with HTML5 overlay model? Are they still needed, perhaps for multiscreen or CAVE support?<br />
* Mashup and interoperability support: is anything else needed for broader use with the Web? YouTube etc.<br />
<br />
== Related Work==<br />
<br />
Much careful planning is involved, we are working to ensure that X3D version 4 can be coherently advanced in combination with a [http://www.web3d.org/specifications/X3dSpecificationRelationships.png coordinated set of steadily evolving ISO/IEC standards].<br />
*'''X3D Efficient Binary Encoding (EBE).''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings. See also SRC format (Web3D 2014)and ExternalGeometry node in InstantPlayer and X3DOM<br />
*'''X3D JavaScript Object Notation (JSON) Encoding.''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings.<br />
*'''X3D version 4.0 (HTML5/X3D DOM)'''. This work is proceeding in parallel. X3D version 4 support is expected.<br />
*'''X3D version 4.1 (Mixed Augmented Reality)'''. Nodes and capabilities in this arena will build on v4.0 and HTML5. Experimentation, evolution and evaluation<br />
occurs throughout.<br />
<br />
== Schedule ==<br />
<br />
'''ISO Considerations'''<br />
* Deciding readiness for ISO New Work Item Proposal (NWIP): we need Committee Draft (CD) specification prose for each planned capability.<br />
* Web3D Consortium is not locked into an annual schedule, ISO handling is flexible.<br />
* Once the NWIP is approved, ISO rules for schedule and review are established.<br />
<br />
'''Execution goals'''<br />
* Review progress during monthly calls, Web3D Conference, and SIGGRAPH Conference.<br />
* We are continuing a monthly review schedule for submissions so that we can build out X3D version 4 one component at a time.<br />
* We are planning to have a 1-year deadline for completion of CD specification prose, rather than wait until all possible version 4 work is ready.<br />
* Web3D Consortium members and public review when a final draft specification is ready to proceed to ISO.<br />
* Any new components not meeting Web3D deadlines might be a candidate for deferral to V4.1. Or considered not ready.<br />
<br />
'''Progress'''<br />
<br />
* Active development of X3D, X3DOM and Cobweb content is tracking HTML 5 capabilities now<br />
* We participate and contribute to the W3C Community Group for [http://www.w3.org/community/declarative3d Declarative 3D]</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_version_4.0_Development&diff=9446X3D version 4.0 Development2016-10-02T16:16:40Z<p>Webmaster: /* Backwards and Forwards Compatibility */ -- Added link to new page on importing/adding nodes in HTML</p>
<hr />
<div>==Genesis and Strategic Overview==<br />
<br />
Web3D Consortium working groups currently define specification goals and requirements. Working group efforts are often the focus for defining and testing new X3D components.<br />
<br />
We publicly review these goals annually during [http://www.web3d2015.org Web3D Conference] and [http://s2014.siggraph.org/attendees/birds-feather SIGGRAPH BOF] meetings.<br />
<br />
Suggestions, development and discussion via the [http://web3d.org/mailman/listinfo/x3d-public_web3d.org x3d-public mailing list] is ongoing.<br />
<br />
X3D version 3.4 Development efforts were evolutionary improvements to the widely proven X3D Graphics architecture. Consortium members decided to skip version 3.4 and go straight to version 4.0, prior goals and requirements have all been merged here.<br />
<br />
The Candidate Capabilities list shows that a lot of interesting capabilities have been proposed and are under way for X3D version 4. However, topics on this list are not guaranteed to be completed! Rather these are all works in progress.<br />
<br />
Activity and approval proceeds based on technical contributions and Web3D Consortium Member priorities. Please consider [http://web3d.org/membership/join joining Web3D Consortium] to help advance 3D graphics on the Web.These X3D version 4.0 Development efforts are considering potentially major additions to the baseline X3D architecture.<br />
<br />
* [http://web3d.org/wiki/images/f/f2/X3DOM_4_WebGL_audience_10_2013.pdf Summary slides here (Oct 2013)] summarize this steadily continuing effort<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_HTML5 HTML5], [http://www.w3.org/community/declarative3d/ Declarative 3D], [http://www.x3dom.org X3DOM], and possibly CSS<br />
* Major technology under consideration: [http://www.web3d.org/wiki/index.php/X3D_and_Augmented_Reality Augmented Reality Continuum (ARC)] (being renamed as Mixed Augmented Reality MAR)<br />
* Relaxing prior design constraints can enable a broader new basis for X3D integration<br />
* Normalizing interaction semantics with HTML5 - now a stable W3C Recommendation - can further open up X3D for the vast majority of Web authors<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered. X3D Futures planning is currently a Web3D Consortium member-only activity.<br />
<br />
== Legacy Issues ==<br />
<br />
We plan to confirm the existence of complete capabilities for X3D v3.3 prior to final approval of X3D version 4.<br />
<br />
* Full support for all existing X3D v3.3 components:<br />
** At least two compatible implementations (including at least one in open source) plus repeatable example scenes<br />
** Layer, ParticleSystems, RigidBodyPhysics, Shaders, TODO others<br />
** TransformSensor node: [http://doc.instantreality.org/documentation/nodetype/TransformSensor/ IGD] and [http://www.parallelgraphics.com/developer/products/cortona/extensions/transformsensor/ old Cortona]<br />
<br />
* Is it necessary for Layout component to be deprecated or improved?<br />
<br />
== Candidate Capabilities ==<br />
<br />
Each of the following possibilities for X3D version 4 have been discussed by the various X3D working groups during meetings and on mailing lists.<br />
Each potential capability is considered to be a feasible (and in most cases, straightforward) addition to the existing X3D version 3.3 architecture.<br />
<br />
*'''Appearance'''<br />
**'''Images''': recommended formats for imagery and video (.gif .bmp .svg .flv .exr .hdr etc.). Consider [http://en.wikipedia.org/wiki/QR_code QR codes] as a first-class image type since it contains imagery and information, especially useful in Mixed Augmented Reality (MAR) applications<br />
**'''Materials''': advanced parameters<br />
**[[X3D Multitexture | Multitexture]]: review for correctness, completeness and conformance of rendering example scenes<br />
**'''Rendering''': bump maps, [http://doc.instantreality.org/tutorial/dynamic-shadows/ shadows], edge smoothing, gamma correction, Non-Photorealistic Rendering (NPR)<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/shaders.html Shaders]: improved support and better interoperability, library of examples; [http://doc.instantreality.org/documentation/nodetype/CommonSurfaceShader/ CommonSurfaceShader?]<br />
**'''Texturing''': [http://en.wikipedia.org/wiki/Texture_atlas Texture atlas], [http://en.wikipedia.org/wiki/Projective_texture_mapping projective texture mapping (PTM)], [http://www.xj3d.org/extensions/render_texture.html RenderedTexture node] for multipass rendering - 2D texture version of GeneratedCubeMapTexture, first proposed by Xj3D and also implemented in X3DOM and InstantReality, useful for all kinds of NPR, shadows, mirrors, etc.<br />
*'''Audio and video''': adding royalty-free formats, streamability, [http://web3d.org/pipermail/x3d-public_web3d.org/2013-December/002681.html disabling attenuation], 3D aural spatialization using reflection from simple geometry (such as [http://gamma.cs.unc.edu/Sound/RESound RESOUND] or [http://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html Web Audio API])<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/computer-aided-design-cad Computer Aided Design (CAD)]''' Interactive Profile, to include:<br />
**[http://www.web3d.org/wiki/index.php/X3D_v4.0_CAD_Improvements X3D v4.0 CAD Improvements] with 3D printing + 3D scanning included<br />
**[http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/CADInterchange.html CADInterchange profile] plus FillProperties/LineProperties, primitive/Geometry2D nodes, Extrusion, NURBS, ClipPlane<br />
**Part selection/animation, 3D printing, [http://www.web3d.org/realtime-3d/news/3d-graphics-compress-call-contributions Compressed Binary Encoding (CBE)], possibly [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html annotations component]<br />
** Building Information Models (BIM), Architecture Engineering Construction (AEC), Physical Sensors<br />
*'''[http://www.ecma-international.org/publications/standards/Ecma-262.htm ECMAScript]''' (Javascript) specification revision compatibility with [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html X3D scripting]; possibly add C# or Python support<br />
*'''Events'''<br />
** Review X3D event interoperability with other event models, such as Document Object Model (DOM) Recommendations<br />
** Add capability for Event logging and playback so that deterministic replay is possible for demonstrations and debugging<br />
*'''Generalized input/output interface support'''<br />
** Possibly [http://www.cs.unc.edu/Research/vrpn/index.html Virtual Reality Peripheral Network (VRPN)], gesture recognition (such as [http://en.wikipedia.org/wiki/Kinect KINECT], [http://www.leapmotion.com LEAP]), etc.<br />
** Support for arbitrary sensors and user interaction devices<br />
* '''Geometry''': point size (or perspective rendering), progressive meshes (suitable for both compression and streaming), 3D ExtrudedText, support for [http://en.wikipedia.org/wiki/Web_typography Web typography] using [http://www.w3.org/TR/WOFF Web Open Fonts Format (WOFF)]<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/x3d-earth Geospatial X3D]''' component<br />
** [http://www.igraphics.com/Standards/EnhancedGeospatialComponent_2007_10_30/Part01/X3D.html Enhanced Geospatial Component - spatial reference frame (SRF)] and [http://www.opengeospatial.org/standards/kml KML] support, [http://www.opengeospatial.org/projects/initiatives/3dpie OGC 3D Portrayal], [http://web3d.org/pipermail/x3d-public_web3d.org/2010-December/001187.html GpsSensor], [http://openlayers.org OpenLayer] mashups<br />
** GeoSet collection of adjacent GeoElevationGrid nodes to enable proper computation of normals for edge boundaries of adjacent grids<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/h-anim Humanoid Animation (H-Anim)]''' anatomical correctness for skeleton and skinning, motion capture (mocap) and playback, interchangeable avatars, animation for hands feet and faces<br />
* '''Interoperability''': include ''class'' attribute for all nodes to all encodings<br />
* '''[http://www.json.org JSON]''': JavaScript Object Notation as an X3D encoding ([http://web3d.org/pipermail/x3d-public_web3d.org/2014-July/thread.html#2854 assessment thread]), relation to [http://www.khronos.org/gltf GlTF], streaming considerations<br />
*'''[http://www.web3d.org/realtime-3d/working-groups/medx3d Medical working group]''' capabilities<br />
** [http://svn.xj3d.org/xj3d_website/trunk/extensions/annotation.html Annotations component] and metadata usage<br />
** Archival 3D medical records, potential emphasis on [http://en.wikipedia.org/wiki/Traumatic_brain_injury Traumatic brain injury (TBI)] volume visualization<br />
** Haptics component for force feedback; [http://www.w3.org/TR/vibration W3C Vibrations API] for tactile feedback<br />
** Soft-body physics component to complement rigid-body physics component<br />
* '''Mobile Profile.''' TODO - needed? Calling out a reduced palette for mobile devices remains interesting, but might instead remain a browser-optional optimization.<br />
* '''[http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#Nodereference Metadata]''': support for embedding information useful for applications utilizing X3D<br />
** Enumerated types: better access, typing, naming, and validation than using MetadataSet/MetadataString combinations<br />
* '''Mixed and Augmented Reality (MAR)''': follow ISO MAR Reference Model, integrate multiple capabilities with devices situated in real world<br />
*'''Networking''': consider [http://www.web3d.org/x3d/content/examples/Basic/Networking NetworkSensor] and event-passing issues, streaming using [http://www.json.org JSON], server-side 3D topics<br />
*'''Security and privacy''':<br />
** Include X3D Networking Component Level 4 support for https in Immersive, Interactive and other commonly used profiles<br />
** Review X3D specifications to ensure that Security Considerations are fully documented throughout in every component<br />
** [http://www.w3.org/standards/xml/security XML Security] provides best-available encryption, digital signature (authentication)<br />
** [http://www.w3.org/standards/webdesign/privacy Web Privacy]: examine X3D compatibility with Do Not Track, P3P, POWDER<br />
*'''Viewing and navigation''': cinematic camera control, alternative navigation types (such as PAN, [http://www.x3dom.org/?p=3536 TURNTABLE] etc.), [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/behaviours.html Recommended navigation behaviours] review, and old MatrixTransform node (esp. useful for CAD, VR/AR etc., implemented in X3DOM and InstantReality)<br />
*'''Virtual Reality (VR)''': requirements definition needed includes viewing with stereo devices, interocular distance, frame-rate requirements, comparison with [https://webvr.info WebVR] capabilities, physiological considerations, health and safety, relation with Mixed Augmented Reality (MAR), etc.<br />
<br />
All suggestions and recommendations are welcome. Component improvements and additions are approved by Web3D Consortium members.<br />
<br />
* TODO: Which experimental nodes are ready? Candidates include [http://doc.instantreality.org Fraunhofer], X3DOM, Cobweb, other members and working groups?<br />
* TODO: articulate Big Data and Cloud, server-side visualization, related issues<br />
<br />
Please [http://www.web3d.org/realtime-3d/contact contact us] if you think additional technologies need to be considered.<br />
<br />
== Backwards and Forwards Compatibility ==<br />
<br />
A major benefit of using the X3D standard is full backwards compatibility with prior VRML97 and X3D content.<br />
Thanks to careful design and insistence on implementation/evaluation, the X3D International Standard has maintained both steady growth and interoperability ever since Virtual Reality Modeling Language (VRML) in 1997. This track record of stability and innovation is among the best in the 3D graphics industry.<br />
<br />
Our goal is to maximize, but not necessarily require, backwards compatibility in version 4.0 with the version 3.x specifications<br />
* A great majority of X3D nodes and features are likely achievable without change<br />
* Some X3D features may require import/export conversion for compatibility (event model reconciliation, ROUTEs and sensors perhaps)<br />
* A few features might be refactored, deprecated or obsoleted (none yet identified)<br />
* Name deconfliction: HTML Script versus embedded X3D Script<br />
<br />
The comprehensive forward compatibility of VRML97 and X3D with later-developed X3D versions shows that careful anticipatory design is achievable.<br />
<br />
X3D version 4.0 Development efforts are currently focused on HTML5, Declarative 3D, X3DOM, and Cobweb with many more issues under consideration.<br />
* Discussion of [Importing and adding nodes in HTML]<br />
<br />
X3D Version 4.1 is focused on Mixed Augmented Reality (MAR) capabilities, which may also require architectural changes. Some new technologies may get pushed from 4.0 to 4.1 (or back again) after careful consideration by the respective working groups.<br />
<br />
Related specification support and changes<br />
*As with all other X3D components, all work is defined in the abstract specification has corresponding file encodings (.x3d .x3dv .x3db) and language bindings (ECMAScript and Java). <br />
*Compatibility concerns include evolutionary efforts to upgrade the X3D Compressed Binary Encoding (CBE), as described in the [http://www.web3d.org/realtime-3d/working-groups/x3d/compressed-binary/x3d-compressed-binary-encoding-call-contributions X3D Compressed Binary Encoding Call For Contributions].<br />
*ECMAScript (JavaScript) support in X3D needs to be upgraded to the new standard for that rapidly improving programming language.<br />
**[http://standards.iso.org/ittf/PubliclyAvailableStandards/c055755_ISO_IEC_16262_2011(E).zip ISO/IEC 16262:2011 Information technology — ECMAScript language specification] (.zip download)<br />
**Downloadable from [http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html ISO Publicly Available Standards] site without charge<br />
**This relates to [http://www.web3d.org/files/specifications/19777-1/V3.0/index.html 19777-1 Part 2, X3D Scene Access Interface (SAI) language bindings for EcmaScript]<br />
<br />
== Architectural Considerations ==<br />
<br />
This section will synopsize significant differences between X3D version 4 and X3D version 3 that may require structural changes in tools and scenes. Special attention is needed to minimize incompatibilities with legacy software and content.<br />
<br />
== Open Questions ==<br />
<br />
* Are ARC abstract design and X3D AR proposals sufficiently mature to enable integration with HTML5/Declarative 3D/X3DOM issues?<br />
* Are the previously X3D Layer/Layering components compatible with HTML5 overlay model? Are they still needed, perhaps for multiscreen or CAVE support?<br />
* Mashup and interoperability support: is anything else needed for broader use with the Web? YouTube etc.<br />
<br />
== Related Work==<br />
<br />
Much careful planning is involved, we are working to ensure that X3D version 4 can be coherently advanced in combination with a [http://www.web3d.org/specifications/X3dSpecificationRelationships.png coordinated set of steadily evolving ISO/IEC standards].<br />
*'''X3D Efficient Binary Encoding (EBE).''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings. See also SRC format (Web3D 2014)and ExternalGeometry node in InstantPlayer and X3DOM<br />
*'''X3D JavaScript Object Notation (JSON) Encoding.''' This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings.<br />
*'''X3D version 4.0 (HTML5/X3D DOM)'''. This work is proceeding in parallel. X3D version 4 support is expected.<br />
*'''X3D version 4.1 (Mixed Augmented Reality)'''. Nodes and capabilities in this arena will build on v4.0 and HTML5. Experimentation, evolution and evaluation<br />
occurs throughout.<br />
<br />
== Schedule ==<br />
<br />
'''ISO Considerations'''<br />
* Deciding readiness for ISO New Work Item Proposal (NWIP): we need Committee Draft (CD) specification prose for each planned capability.<br />
* Web3D Consortium is not locked into an annual schedule, ISO handling is flexible.<br />
* Once the NWIP is approved, ISO rules for schedule and review are established.<br />
<br />
'''Execution goals'''<br />
* Review progress during monthly calls, Web3D Conference, and SIGGRAPH Conference.<br />
* We are continuing a monthly review schedule for submissions so that we can build out X3D version 4 one component at a time.<br />
* We are planning to have a 1-year deadline for completion of CD specification prose, rather than wait until all possible version 4 work is ready.<br />
* Web3D Consortium members and public review when a final draft specification is ready to proceed to ISO.<br />
* Any new components not meeting Web3D deadlines might be a candidate for deferral to V4.1. Or considered not ready.<br />
<br />
'''Progress'''<br />
<br />
* Active development of X3D, X3DOM and Cobweb content is tracking HTML 5 capabilities now<br />
* We participate and contribute to the W3C Community Group for [http://www.w3.org/community/declarative3d Declarative 3D]</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_V4_Open_Meeting&diff=9360X3D V4 Open Meeting2016-06-08T15:11:01Z<p>Webmaster: /* Contribution 9 */ contributor identification</p>
<hr />
<div>X3D V4.0 Open Workshop / Meeting June 8th 2016<br />
<br />
<br />
== Topics ==<br />
<br />
Note: The red question marks at the end of each question are place-holders for any short answers to emerge from the discussions.<br />
<br />
*What level of X3D integration into HTML5 do we want? <span style="color: red;">???</span><br />
**Do we want to be fully integrated like SVG? <span style="color: red;">???</span><br />
*Do we want/need a DOM spec? If so: <span style="color: red;">???</span><br />
**Which DOM version should it be based on? <span style="color: red;">???</span><br />
**Do we want to fully support all DOM/HTML features? <span style="color: red;">???</span><br />
*Do we want to maximize the backwards compatibility of V4.0 with V3.3? Or break away completely? <span style="color: red;">???</span><br />
**Do we want to retain SAI? <span style="color: red;">???</span><br />
*What features do we want? For example, <span style="color: red;">???</span><br />
**How is animation to be handled? The X3D way of TimeSensor and ROUTEs, or an HTML way, such as CSS3 animations, or else JavaScript? <span style="color: red;">???</span><br />
**How is user interaction to be handled? The X3D way of Sensors, or the HTML way with event handlers? <span style="color: red;">???</span><br />
**Do we need any different nodes? One example might be a mesh node? <span style="color: red;">???</span><br />
**Do we want Scripts and Prototypes in HTML5? <span style="color: red;">???</span><br />
**How do we want to handle styling? <span style="color: red;">???</span><br />
*What profile(s) do we need for HTML? <span style="color: red;">???</span><br />
<br />
== Attendees and contributors ==<br />
<br />
<br />
E-mail contributors: Mike Aratow, Don Brutzman, John Carlson, Leonard Daly, Yves Piguet, Andreas Plesch, Philipp Slusallek<br />
<br />
Meeting Attendees: Vince Marchetti, Dick Puk, Leonard Daly, Anita Havele, Christophe Mouton, Nicholas Polys, Roy Walmsley<br />
<br />
Apologies: Don Brutzman, Andreas Plesch<br />
<br />
== Discussion Capture ==<br />
<br />
Note: This section is intended for the capture of discussion points.<br />
<br />
== Prior e-mail contributions: ==<br />
<br />
Note 1: Contributions are presented in chronological order.<br />
<br />
Note 2: Links within the preformatted sections do not appear. So any used have been added as references at the end of the contribution.<br />
<br />
===Contribution 1===<br />
<br />
<pre style="white-space: pre-wrap;"><br />
I think the bigger question of what should be done with X3D. Is X3D solely going to exist within HTML or will X3D have a separate life inside and outside of HTML.<br />
<br />
If the life is solely within HTML, then the questions below become inclusive of all X3D. If there are separate existences, then the first question is what is the cross-compatibility between X3D/HTML and X3D/other.<br />
</pre><br />
<br />
===Contribution 2===<br />
<br />
<pre style="white-space: pre-wrap;"><br />
Relevant working-group references follow. A lot of excellent work has been accomplished already.<br />
<br />
X3D Version 4<br />
http://www.web3d.org/x3d4<br />
<br />
Web3D Consortium Standards Strategy<br />
http://www.web3d.org/strategy<br />
<br />
X3D Graphics Standards: Specification Relationships<br />
http://www.web3d.org/specifications/X3dSpecificationRelationships.png<br />
<br />
X3D Version 4.0 Development<br />
http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development<br />
<br />
A 5-10 minute quicklook discussion across these resources might help. We are pretty far up X3D4 Mountain already!<br />
<br />
The posted discussion-topics list is a good start for renewed activity, and an important way to keep track of everyone's many valuable ideas. Suggestion: create some kind of topics-discussion page, probably easily linked off the preceding wiki page.<br />
<br />
My general inputs for each of these topics are guiding questions:<br />
<br />
a. What do the HTML5/DOM/CSS/SVG/MathML specifications actually say?<br />
<br />
b. How is cross-language HTML page integration actually accomplished, as shown in best practices by key exemplars?<br />
<br />
c. What is the minimal addition needed to achieve a given technical goal using current X3D capabilities?<br />
<br />
Editorial observation: the word "want" appears 9 times in this list... Understandable from common usage, but not a very good way to achieve consensus over a long-term effort. Also not very useful for measuring successful resolution.<br />
<br />
Pragmatic engineering rephrase: "what problem are you trying to fix?"<br />
<br />
Over 20 years of successful working-group + community efforts can guide us in these endeavors - we know how to succeed together. An effective path for building consensus is to:<br />
- define goals that are illustrated by use cases,<br />
- derive technical requirements,<br />
- perform gap analysis, and then<br />
- execute loosely coordinated task accomplishment according to each participant's priorities.<br />
<br />
How to execute each specification addition: write prose, create examples, implement, evaluate. Repeat until done, topic by topic.<br />
</pre><br />
<br />
References:<br />
<br />
*[http://www.web3d.org/x3d4 X3D Version 4]<br />
*[http://www.web3d.org/strategy Web3D Consortium Standards Strategy]<br />
*[http://www.web3d.org/specifications/X3dSpecificationRelationships.png X3D Graphics Standards: Specification Relationships]<br />
*[http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development X3D Version 4.0 Development]<br />
<br />
===Contribution 3===<br />
<pre style="white-space: pre-wrap;"><br />
The discussion on introducing an id field seemed to point towards the need to have fuller integration in the sense that it is difficult to isolate features. It may be necessary to define a x3d dom similar to the svg dom, with the corresponding interfaces. svg is very successful on the web but it took a long time to arrive there.<br />
<br />
x3dom has a dual graph approach. There is the x3d graph and in parallel the page dom graph which are kept in sync but are both fully populated. Johannes Behr would know better how to explain the concept.<br />
It looks like FHG decided that x3dom is now considered community (only?) supported. This probably means it will be out of sync as newer web browsers arrive, or webgl is updated.<br />
<br />
I explored Aframe a bit more. It will be popular for VR. It is still in flux and evolves rapidly. The developers (mozilla) focus on its basic architecture (which is non-hierarchical, a composable component system) and expects users to use javascript to develop more advanced functionality (in the form of shareable components). So it is quite different, fun for developers, and for basic scenes easy for consumers. Since most mobile VR content at this point is basic (mostly video spheres and panos), it is a good solution for many.<br />
<br />
(As a test I also implemented indexedfaceset as an Aframe component, and it was pretty easy - after learning some Three.js. So it would be possible to have x3d geometry nodes on top of aframe. Protos, events and routes are another matter but also may not be impossible).<br />
<br />
There is still space for x3d as a more permanent, and optionally sophisticated 3d content format on the web.<br />
<br />
Event system: My limited understanding is that on a web page, the browser emits events when certain things happen. Custom events can also be emitted by js code (via DOM functions) for any purpose. (All ?) events have a time stamp and can have data attached. Then, events can be listened to. There is no restriction to listening, eg. all existing events are available to any listener. A listener then invokes a handler which does something related to the event. js code can consume, cancel, or relay events as needed (via DOM functions). It is not unusual that many events are managed on a web page. events can be used to guarantee that there is a sequence of processing.<br />
<br />
So how does the x3d event system relate ? There is a cascade, and directivity. How long does an event live ? one frame ? Until it fully cascaded through the scene graph ?<br />
<br />
Since x3dom and cobweb are currently the only options, from a practical stand point a question to ask may be this: what is needed to make x3dom and cobweb easy to use and interact with on a web page ? Typically, the web page would provide an UI, the connection to databases or other sources of data, and the x3d scene is responsible for rendering, and interacting with the 3d content. For VR, the UI would need to be in the scene, but connections and data sources would still be handled by the web page.<br />
<br />
Cobweb in effect allows use of the defined SAI functions. Is it possible to define a wrapper around these functions to allow a DOM like API (createElement, element.setAttribute .. element = null) ? It may be since they are similar anyways and it would go a long way. But it still would not be sufficient to let other js libraries such as D3.js or react control and modify a scene since they would expect x3d nodes to be real DOM elements.<br />
<br />
VR: A current issue is control devices. It would be probably useful to go over the spec. and see where there is an implicit assumption that mouse or keyboard input is available. VR HMDs have different controls (head position and orientation(pose), one button) and hand held controllers (gamepads, special sticks with their own position/orientations) or the tracked hands themselves become more popular. In VR, you do want to your hands in some way.<br />
<br />
Perhaps, it makes sense to have <Right/LeftHand/> nodes paralleling <Viewpoint/> with position/orientation fields which can be routed to transforms to manipulate objects ? How a browser would feed the <Hand> nodes would be up to the browser. InstantReality has a generic IOSensor.<br />
</pre><br />
<br />
===Contribution 4===<br />
<pre style="white-space: pre-wrap;"><br />
I am not sure that I will be able to join the meeting, so let me present some of our ideas in this context by email already. As you might know we have done a lot of work on declarative 3D -- in the alternate universe called XML3D. The reason for this unfortunate split, lies in the fact that it has been rather difficult to bridge the gap between our ideas of a minimum and generic extensions to HTML-5 to enable declarative 3D while staying as close as possible to the current Web technology stack on the one side and the need for backward compatibility that people strived for in X3D(OM).<br />
<br />
Now, there may be a quite interesting these two world views could be resolved with each other. The basic idea for that was already proposed and discussed between us and the X3DOM group: Merging X3DOM and XML3D by identifying the (significant and large!) common core and a layering X3D/XMl3D compatible interfaces on top of this (or eventually identifying common set of Dec3D elements). Unfortunately, this idea was not really picked up by anyone back then.<br />
<br />
However, with newer technology like WebComponent (a version of prototypes in HTML5) this now becomes a highly interesting and much more practical option. We are actually exploring this right now. First results look very promising and a first paper on this has just been accepted for Web3D this year.<br />
<br />
At the core of this approach we are using a clean interface to rendering engines, where we use Three.js a default option. Other engines like game engines or ray tracing etc. would be alternatives. (We are also exploring server-based real-time ray tracing based on a generic real-time synchronization layer between scene descriptions as one example.)<br />
<br />
On top of this is a slightly refined generic data handling layer that is derived from our Xflow. Xflow has been tremendously useful for us and makes data management significantly easier than with the specialized nodes in X3D. It is the perfect building block for WebComponents. We are also integrating into this layer a programmable data processing engine that is derived from our flexible shade.js compiler for programmable shading.<br />
<br />
Everything on top of this is essentially fair game for WebComponents (similar to a-frame, but with mny more options). The more specialized and often domain-specific nodes from X3D would be prime examples for this. We have actually started to implemented some of the basic X3D nodes already, plus the non-core XML3D nodes. Pretty much along the lines of what we discussed with X3DOM several years ago. Given the powerful underlying engine, it actually becomes rather straight forward to implement these nodes as Web Components, especially the X3DOM subset.<br />
But we are just starting.<br />
<br />
We are even exploring having a public repository of WebComponents that people could develop independently and that get automatically loaded when referenced in a scene (subject to some security policy, of course).<br />
Talk about leveraging the power of the distributed web :-).<br />
<br />
We are finalizing the paper for the final version right now but can make a preprint available as soon as this is ready. People would be more than welcome to help design and develop this further. Maybe this could also be an interesting basis for some of the work on X3D V4?<br />
</pre><br />
<br />
===Contribution 5===<br />
<pre style="white-space: pre-wrap;"><br />
As repeated a few days ago, I remain keen for us to establish some kind of X3D v4 wiki page. We need to collaboratively show how these different categories of concepts can be defined along with their associated pros and cons. Email and meeting discussions can then grow those sections effectively, to show that use-case goals and design requirements can be defined and met.<br />
<br />
Wondering if the x3dom dual-graph page dom structures align with the draft work on Shadow DOM at W3C.<br />
https://www.w3.org/TR/shadow-dom<br />
<br />
I'm hoping that John Carlson gets a chance to look at whether his JSON prototype expander might be adaptable as part of x3dom - that would be pretty valuable. Although Fraunhofer has outstanding prototype support in their Instant Reality engine, it has never been clear why that code can't simply be applied in x3dom as well. Certainly a consistent approach would seem to make both codebases more coherent and maintainable for them. If Fraunhofer refuses to adapt or release the Instant Reality prototype code then we will just have to do it ourselves... John's work seems like a big step in that direction.<br />
<br />
Also thanks for pointing out important questions about Fraunhofer's stewardship of the X3DOM project. It will be good to learn more about their intentions so that our community can align effectively. There has been no handoff.<br />
<br />
Regarding the X3D event system: a changing value of any field in any node can be sent as an input to any field in any node, as long as types strictly match (apples to apples). Rephrased: a ROUTE passes a time-stamped value from one node to another. Internal to an X3D scene graph, that has been implemented dozens of times. Seems extremely simple.<br />
<br />
External to an X3D scene graph, meaning via a browser using the Scene Access Interface (SAI), mechanisms are similarly well defined. Since the DOM is string based, and since any X3D event value can be expressed as a string, it seems like we have a straight connect-the-dots approach awaiting us. Forgive me for using a four-letter word, but if interested individuals might actually _read_ the HTML5/DOM and X3D specifications, then the answers to most implementation & alignment questions are likely spelled out for us.<br />
</pre><br />
<br />
Reference:<br />
<br />
*[https://www.w3.org/TR/shadow-dom Shadow DOM]<br />
<br />
===Contribution 6===<br />
<pre style="white-space: pre-wrap;"><br />
Please do not go the route (sic!) of a string-based interface for implementing X3D routes. Yes, the DOM has a generic string-based interface, which is really important in general. But not for efficiently handling big 3D data. Any DOM node can additionally provide a "binary"<br />
JS API as well, ideally using Typed Aarrays in JS.<br />
<br />
Converting to strings and back will cause huge overhead and will rule out any GPU-based computation and acceleration. The latter is a must in today's environments, especially on mobiles. You do not want to create this overhead for large arrays of vertices or such and have to parse all the numbers again and again. It can also cause numerical inaccuracies in the conversion that may lead to inconsistencies in the binary representation, which can cause gaps in supposedly closed geometry.<br />
<br />
BTW, this is exactly why we have created Xflow: To efficiently be able to specify generic typed data arrays (available as GPU buffers in the engine as early as possible), flexibly composite individual buffers into sets of buffers (<data> elements that are define all the data the input for efficient draw calls), and also to process the data as necessary along the way (e.g. flexible animation, image processing, procedural shading, transitions, etc.).<br />
<br />
Xflow is actually much more powerful than routes and it fits much better to HTML5 -- in my opinion at least. Funded by Intel we are just extending Xflow to automatically make use of e.g. SIMD instructions (via<br />
SIMD.js) and other JS acceleration techniques. We are also looking at WebAssembly here for better performance even if not going to the GPU.<br />
</pre><br />
<br />
===Contribution 7===<br />
<pre style="white-space: pre-wrap;"><br />
Wondering if the x3dom dual-graph page dom structures align with the draft work on Shadow DOM at W3C.<br />
https://www.w3.org/TR/shadow-dom<br />
<br />
The shaw-dom spec is being upstreamed to the dom spec.<br />
<br />
https://dom.spec.whatwg.org/<br />
<br />
This is a good resource, since it also explains the web page DOM in detail.<br />
<br />
I am not sure if the shaw-dom aligns with the dual graph approach because the shadow-dom is still a dom structure and not a scene graph. I think it may be still necessary to define a x3d dom and interfaces similar to https://developer.mozilla.org/en-US/docs/DOM/DOM_Reference#SVG_interfaces<br />
<br />
I'm hoping that John Carlson gets a chance to look at whether his JSON prototype expander might be adaptable as part of x3dom - that would be pretty valuable. Although Fraunhofer has outstanding prototype support in their Instant Reality engine, it has never been clear why that code can't simply be applied in x3dom as well. Certainly a consistent approach would seem to make both codebases more coherent and maintainable for them. If Fraunhofer refuses to adapt or release the Instant Reality prototype code then we will just have to do it ourselves... John's work seems like a big step in that direction<br />
<br />
Well, I would not have a good idea on how to implement prototypes in x3dom. Not sure if the Instant Reality code would really help. One idea may be to see if there is an existing declarative way to register new custom elements using web components, and extend that. But I do not think there is.<br />
https://www.w3.org/TR/custom-elements/<br />
<br />
<br />
Also thanks for pointing out important questions about Fraunhofer's stewardship of the X3DOM project. It will be good to learn more about their intentions so that our community can align effectively. There has been no handoff.<br />
<br />
Well, there have been no fixes or updates to the code base on github for a long time and a recent issue response suggested that FHG considers x3dom community supported.<br />
<br />
Regarding the X3D event system: a changing value of any field in any node can be sent as an input to any field in any node, as long as types strictly match (apples to apples). Rephrased: a ROUTE passes a time-stamped value from one node to another. Internal to an X3D scene graph, that has been implemented dozens of times. Seems extremely simple. <br />
<br />
External to an X3D scene graph, meaning via a browser using the Scene Access Interface (SAI), mechanisms are similarly well defined. Since the DOM is string based, and since any X3D event value can be expressed as a string, it seems like we have a straight connect-the-dots approach awaiting us. Forgive me for using a four-letter word, but if interested individuals might actually _read_ the HTML5/DOM and X3D specifications, then the answers to most implementation & alignment questions are likely spelled out for us.<br />
<br />
https://dom.spec.whatwg.org/#events would be HTML5 side of events.<br />
Is the statement at https://dom.spec.whatwg.org/#action-versus-occurance compatible with http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#Events ?<br />
<br />
It will be great to get our wiki organized for clarity and go-forward action on these important X3D version 4 design issues.<br />
<br />
Thanks for letting us know about your other explanations - very interesting! 8)<br />
<br />
Yeah, VR is not really part of this discussion (although it could be a V4 topic) .<br />
<br />
Looking forward to continuing, sustainable evolution and progress together.<br />
<br />
I think if there is way to open spec. drafting more along the lines of other www spec. efforts on github, there is a chance to attract a wider community for more man power which would be much needed.<br />
</pre><br />
<br />
References:<br />
<br />
*[https://www.w3.org/TR/shadow-dom Shadow DOM]<br />
*[https://dom.spec.whatwg.org/ Shaw-DOM spec]<br />
*[https://developer.mozilla.org/en-US/docs/DOM/DOM_Reference#SVG_interfaces SVG Interfaces]<br />
*[https://www.w3.org/TR/custom-elements/ custom elements]<br />
*[https://dom.spec.whatwg.org/#events HTML5 events]<br />
*[https://dom.spec.whatwg.org/#action-versus-occurance action vs occurrence]<br />
*[http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#Events X3D Events]<br />
<br />
===Contribution 8===<br />
<pre style="white-space: pre-wrap;"><br />
Before we can answer these questions, we need to know who the V4.0 targetted audience is. Who are V4.0’s users? Purely web developers and users? Geo? Medical? CAD? H-Anim? Which working groups are involved?</pre><br />
<br />
===Contribution 9===<br />
From Leonard Daly (http://web3d.org/pipermail/x3d-public_web3d.org/2016-June/004817.html)<br />
<br />
<pre style="white-space: pre-wrap;"><br />
X3D needs to run in the HTML5/DOM environment. A few nodes need to be removed, but all capabilities remain.<br />
Preliminary proposed V4 document at: http://tools.realism.com/specification/x3d-v40<br />
<br />
I am going to start my position with a response to a question asked by John Carlson on a different list (x3dom-users): are we adding HTML5 capabilities to X3D or 3D (X3D in particular) capabilities to HTML5?<br />
HTML is the dominant environment world-wide. It provides text, image, 2D graphics (SVG), video, and other capabilities. The size of the HTML5 development community far exceeds the total of the entire X3D community. Forcing HTML5 into X3D is a losing game right from the start -- whether you want all of HTML5 or just a portion. So in my mind, the only choice with a future is to add 3D to HTML5. Running in the HTML5 environment means full integration with the HTML5 DOM (or later versions when they happen). BTW, there are already a number of non-Web3D Consortium efforts to do so. We are not out in front of the effort and are about to be made irrelevant. There is no more time for delays or debates.<br />
So now that the environment is settled, it is important to identify what in current X3D (V3.3) is incompatible with HTML5. There are only three obvious features - Script node, event handling, and case sensitivity. There are other capabilities that are dependent on these capabilities -- I'll discuss those later.<br />
<br />
Starting with the easiest one first - case sensitivity. HTML5 is case insensitive. Relaxing X3D's rules on that allows existing X3D code to run in a browser. If everything gets converted to lower-case prior to handling (except quoted strings), then there is not a problem.<br />
<br />
There is an obvious naming incompatibility with Script -- the name. HTML5 is already using that name. Under my initial condition there cannot be an X3D Script node. That does not mean all scripting functions are given up. HTML5 provides a wonderful script interface a more flexible structure. In X3D, Scripts are meant to process events, so the function argument is always an event (except for X3D-Script internal functions). Functions in HTML5 are a lot more flexible and can include events, objects, scalars, arrays, etc. So there is no loss of functionality by giving up X3D-Script.<br />
<br />
Event handling is different between HTML5 and X3D. In X3D events are "routed" from one node to another. They allow one part of the scene graph to "talk" to another part. In HTML5, events "bubble-up" from the originator to the event through any handler that may be attached to any parent node of the originator until the event is cancelled. In all of my design work on V4 I have not found any instance where HTML5-Scripts could not provide the same functionality as X3D-Script+ROUTE. It requires a little different mind-set, but the HTML5 mind-set is very familiar to JavaScript programmers and other front-end developers. I also believe that a graphical development interface can be built that completely simplifies the differences.<br />
<br />
The biggest issue I have seen with event handling is scene graph updating. X3D updates the scene graph once all non-looping events in the cascade have completed. After the scene graph is updated, a new frame is rendered. This can cause a large delay between rendered frames. HTML5 renders as it goes. Rendering happens asynchronously to changes to the DOM. There is no concept of accessing the DOM before or after all events for that frame. X3D worlds that depend on that feature will probably not be able to be ported to X3D V4.<br />
<br />
Summarizing the three incompatibilities - with the exception of some event processing, none will prevent X3D from doing what it currently can do and all can be easily migrated to the HTML5 environment.<br />
<br />
<br />
There are a number of features that I think should not be included in X3D V4, but these are just features and not fundamental capabilities. These include all nodes that generate geometry (e.g., Extrusion, ElevationGrid, Text) with the exception of simple solids and perhaps a couple of additions. My view here is based on the availability of free modeling software (e.g., Blender) that does all of the above, and a lot more efficiently than X3D can. Also by not including these nodes, the resultant models will look better.<br />
<br />
Lastly (for now), I believe that there is no purpose for a PROTO node. Without a X3D-Script node, PROTOs just become convenience generators. To replace that feature, I am proposing a MACRO node that takes X3D and does string substitution prior to inserting the result into the scene graph (and DOM). I have a partial implementation of this for X3DOM. <br />
<br />
Summarizing: The Consortium needs to get out and lead the way for 3D on the web (and this includes VR) or it will be by-passed and left with the relics of history like blinking text, and Flash. The environment must be HTML5/DOM and X3D must stay current with the web environment. There will always be someone who needs something specialized that does not use a web environment, but those will be individual cases and not worth significant volunteer efforts.<br />
</pre><br />
<br />
Reference:<br />
*[http://tools.realism.com/specification/x3d-v40 V4 preliminary proposal]<br />
<br />
===Contribution 10===<br />
<pre style="white-space: pre-wrap;"><br />
• What level of X3D integration into HTML5 do we want?<br />
o Do we want to be fully integrated like SVG?<br />
<br />
In the spirit of openness, I say may the best implementation win. That means that there should not be full integration. However, there should be a standard.<br />
<br />
<br />
• Do we want/need a DOM spec? If so:<br />
o Which DOM version should it be based on?<br />
<br />
HTML5???<br />
<br />
o Do we want to fully support all DOM/HTML features?<br />
<br />
We should document what tags and attributes we are adding. If not DOM, what declarative language do you want to use? CSS may be an option<br />
<br />
• Do we want to maximize the backwards compatibility of V4.0 with V3.3? Or break away completely?<br />
o Do we want to retain SAI?<br />
<br />
Not retain SAI. Not be backwards compatible.<br />
<br />
<br />
• What features do we want? For example,<br />
o How is animation to be handled? The X3D way of TimeSensor and ROUTEs, or an HTML way, such as CSS3 animations, or else JavaScript?<br />
<br />
HTML way<br />
<br />
o How is user interaction to be handled? The X3D way of Sensors, or the HTML way with event handlers?<br />
<br />
HTML way and user can add own event emitters. We can also add JavaScript emitters which can be added as attributes.<br />
<br />
o Do we need any different nodes? One example might be a mesh node?<br />
<br />
We need a way to provide templates or macros, which might be provided through picking an existing one.<br />
<br />
o Do we want Scripts and Prototypes in HTML5?<br />
<br />
No.<br />
<br />
<br />
o How do we want to handle styling?<br />
<br />
By declaratively addressing the fragment shader on objects.<br />
<br />
<br />
• What profile(s) do we need for HTML?<br />
<br />
IDK<br />
</pre><br />
<br />
===Contribution 11===<br />
<pre style="white-space: pre-wrap;"><br />
X3D needs to run in the HTML5/DOM environment. A few nodes need to be removed, but all capabilities remain.<br />
Preliminary proposed V4 document at: http://tools.realism.com/specification/x3d-v40<br />
<br />
I am going to start my position with a response to a question asked by John Carlson on a different list (x3dom-users): are we adding HTML5 capabilities to X3D or 3D (X3D in particular) capabilities to HTML5?<br />
HTML is the dominant environment world-wide. It provides text, image, 2D graphics (SVG), video, and other capabilities. The size of the HTML5 development community far exceeds the total of the entire X3D community. Forcing HTML5 into X3D is a losing game right from the start -- whether you want all of HTML5 or just a portion. So in my mind, the only choice with a future is to add 3D to HTML5. Running in the HTML5 environment means full integration with the HTML5 DOM (or later versions when they happen). BTW, there are already a number of non-Web3D Consortium efforts to do so. We are not out in front of the effort and are about to be made irrelevant. There is no more time for delays or debates.<br />
I think the only DOM items that are required are canvas and script. These can be moved to X3D if name conflicts are resolved.<br />
<br />
<br />
So now that the environment is settled, it is important to identify what in current X3D (V3.3) is incompatible with HTML5. There are only three obvious features - Script node, event handling, and case sensitivity. There are other capabilities that are dependent on these capabilities -- I'll discuss those later.<br />
<br />
Did you just throw out Cobweb which runs successfully in several browsers?<br />
<br />
<br />
<br />
<br />
Starting with the easiest one first - case sensitivity. HTML5 is case insensitive. Relaxing X3D's rules on that allows existing X3D code to run in a browser. If everything gets converted to lower-case prior to handling (except quoted strings), then there is not a problem.<br />
<br />
Not a problem.<br />
<br />
<br />
<br />
There is an obvious naming incompatibility with Script -- the name. HTML5 is already using that name. Under my initial condition there cannot be an X3D Script node. That does not mean all scripting functions are given up. HTML5 provides a wonderful script interface a more flexible structure. In X3D, Scripts are meant to process events, so the function argument is always an event (except for X3D-Script internal functions). Functions in HTML5 are a lot more flexible and can include events, objects, scalars, arrays, etc. So there is no loss of functionality by giving up X3D-Script.<br />
<br />
Linkage of Scripts with ROUTEs is given up. Data binding has to be reinvented, or borrowed. Cobweb has shown that Scripts can be available in HTML5 browsers.<br />
<br />
<br />
<br />
Event handling is different between HTML5 and X3D. In X3D events are "routed" from one node to another. They allow one part of the scene graph to "talk" to another part. In HTML5, events "bubble-up" from the originator to the event through any handler that may be attached to any parent node of the originator until the event is cancelled. In all of my design work on V4 I have not found any instance where HTML5-Scripts could not provide the same functionality as X3D-Script+ROUTE. It requires a little different mind-set, but the HTML5 mind-set is very familiar to JavaScript programmers and other front-end developers. I also believe that a graphical development interface can be built that completely simplifies the differences.<br />
<br />
Agreed.<br />
<br />
<br />
<br />
The biggest issue I have seen with event handling is scene graph updating. X3D updates the scene graph once all non-looping events in the cascade have completed. After the scene graph is updated, a new frame is rendered. This can cause a large delay between rendered frames. HTML5 renders as it goes. Rendering happens asynchronously to changes to the DOM. There is no concept of accessing the DOM before or after all events for that frame. X3D worlds that depend on that feature will probably not be able to be ported to X3D V4.<br />
What does WebGL do separate from HTML5? We really need to find out what WebGL/Canvas does before jumping straight into DOM and HTML5.<br />
<br />
<br />
Summarizing the three incompatibilities - with the exception of some event processing, none will prevent X3D from doing what it currently can do and all can be easily migrated to the HTML5 environment.<br />
<br />
<br />
There are a number of features that I think should not be included in X3D V4, but these are just features and not fundamental capabilities. These include all nodes that generate geometry (e.g., Extrusion, ElevationGrid, Text) with the exception of simple solids and perhaps a couple of additions. My view here is based on the availability of free modeling software (e.g., Blender) that does all of the above, and a lot more efficiently than X3D can. Also by not including these nodes, the resultant models will look better.<br />
<br />
Lastly (for now), I believe that there is no purpose for a PROTO node. Without a X3D-Script node, PROTOs just become convenience generators. To replace that feature, I am proposing a MACRO node that takes X3D and does string substitution prior to inserting the result into the scene graph (and DOM). I have a partial implementation of this for X3DOM. <br />
<br />
I don’t think we should spend effort generating our our implementation of templates, unless done for efficiency. Underscore, handlebars, meteor, angular, mustache etc all present templating frameworks which are likely highly superior to MACROs at this point. If all we are doing is manipulating DOM, we should use developed frameworks that other developers use, not invent our own templates. If we are manipulating WebGL, then we should look at the WebGL or GL frameworks for what is done with templating. Has anyone googled webgl templating or webgl macros? Is that what we are ultimately doing, providing WebGL macros?<br />
<br />
<br />
Summarizing: The Consortium needs to get out and lead the way for 3D on the web (and this includes VR) or it will be by-passed and left with the relics of history like blinking text, and Flash. The environment must be HTML5/DOM and X3D must stay current with the web environment. There will always be someone who needs something specialized that does not use a web environment, but those will be individual cases and not worth significant volunteer efforts.<br />
<br />
I believe our focus should be on providing a good component library or framework or integrated with an existing DOM templating system(s) as examples. My favorite is D3.js, but it may be too JavaScript heavy for some users. D3.js also leverages several extendable data models for tables, trees and graphs. I think these should be leveraged to show that capabilities can be quickly built up to build apps. We should make *H-Anim* and geo work well on the web. My gut is saying don’t build our own templating system. I think we should use existing data mechanisms (JSON ala meteor templates) to provide data to the templating system. If we want to provide a way to send XML and WRL to a templating system, this should be investigated, but no one will likely use it (I think everyone has moved to REST/JSON). If we can’t use X3DOM and Angular together, then perhaps that problem needs to be investigated with the Angular team.<br />
<br />
For a not perfect sample of Meteor 1.2’s templating system with X3DOM look at the bottom of the following link. {{ }} is what gets replaced, and the new tag is <template> and there are loops.<br />
<br />
https://github.com/coderextreme/jsondemons/blob/master/client/jsondemons.html<br />
<br />
I too believe that DOM should be used as the lingua franca in the short term, and if people need more performance, they can move to WebGL, PlayCanvas and Three.JS. I think JSON may be superior in speed to DOM however (run some tests?), and we should investigate a WebGL X3D JSON Loader that skips DOM.<br />
<br />
<br />
http://psteeleidem.com/the-javascript-templating-landscape/<br />
<br />
Here’s are the options of things to focus on:<br />
<br />
1. Providing declarative abstractions for the graphics card, since WebGL exposes the graphics card. This means fragment shader, textures, lighting and materials. (CSS4+images+canvas)<br />
2. Provide a barebones structure for the scenegraph. transforms OR groups, but not both. (DOM)<br />
3. Provide ways to generate simple generic geometry to build objects, like spheres which can be used by shaders, with configurable # of faces. The surfaces can be manipulated with vertex shaders. Provide ways to declaratively specify unique geometry (perlin noise, etc.)—Geometry Shader.<br />
4. Allow for more complex geometry specified by Blender. (SRC)<br />
5. Provide a way to apply fragment shaders and vertex shaders to objects (DOM).<br />
6. Provide a way to place and orient objects in the scenegraph.(DOM)<br />
7. H-Anim and physics.<br />
8. Geo.<br />
9. VR<br />
10. Mobile<br />
11. Templates or Macros of the above. (DOM). I think the only way our own templating system is going to fly is if we apply it to HTML5 and SVG as well.<br />
12. Proper support for HTML5 events on X3D objects.<br />
<br />
Wish List:<br />
<br />
13. SVG Extrusions for 3D printing Blind visualization.<br />
<br />
This sounds like a lot. We need to figure out what we already have and apply resources where necessary.<br />
<br />
There may be new items to standardize in 1) reflection, refraction, prismatic and DVD effects 3) easy ways to subdivide boxes and spheres (already in X3DOM, I think) 8) great circle interpolator 9) eye and motion control 10) standardized shader variable names.<br />
<br />
Here’s how X3DOM needs to be extended to meet the above focus items:<br />
<br />
1. Add a templating system { CHOOSE ONE OR MORE, EVALUATE }<br />
2. Add JSON { MEDIUM EFFORT }<br />
3. Standardized shader variables. { PROBABLY EASY }<br />
4. Access to CSS from X3DOM (through id, style and class attributes). { BIG EFFORT }<br />
5. Add VR devices (this should come for free from the browser vendors)<br />
<br />
<br />
The last 4 of these apply to Cobweb as well. Perhaps those should be the ones we focus on. If we want a JSON templating system, we’ll have to do that as well.<br />
</pre><br />
<br />
References:<br />
* [https://github.com/coderextreme/jsondemons/blob/master/client/jsondemons.html json demons]<br />
* [http://psteeleidem.com/the-javascript-templating-landscape/ JavaScript templating landscape]<br />
<br />
===Contribution 12===<br />
<pre style="white-space: pre-wrap;"><br />
Let me focus on the list at the end.<br />
<br />
> Here’s are the options of things to focus on:<br />
> <br />
> 1. Providing declarative abstractions for the graphics card, since <br />
> WebGL exposes the graphics card. This means fragment shader, <br />
> textures, lighting and materials. (CSS4+images+canvas)<br />
<br />
The only fully programmable option of I am aware of that does not use the low-level mechanism of glsl is shade.js from our group. It is full integrated into XML3D for rendering as well as Xflow for generic handling of the input data, but it could be used also in other frameworks with some effort. It uses a subset of JS for specifying shaders and offers to compile them into glsl for both both forward and deferred rendering. We also have a backend to ray tracing and globillum renderers.<br />
<br />
See http://xml3d.org/papers/ for the paper and XML3D.org for the implementation.<br />
<br />
> 2. Provide a barebones structure for the scenegraph. transforms OR <br />
> groups, but not both. (DOM)<br />
<br />
This is what I promoted in my email a bit earlier. We are then using webComponents on top of this core, which seems to be the best way forward in the Web technology stack and is really powerful.<br />
<br />
> 3. Provide ways to generate simple generic geometry to build objects, <br />
> like spheres which can be used by shaders, with configurable # of faces.<br />
> The surfaces can be manipulated with vertex shaders. Provide ways to <br />
> declaratively specify unique geometry (perlin noise, etc.)—Geometry Shader.<br />
<br />
Xflow offers exectly this capabilities. We already showed how (in suitable cases) the processing can be fully integrated into the vertex shader.<br />
<br />
In a project with Intel we are currently working on extensing the shade.js compiler to also generate code that could, for example, use SIMD.js for processing that is not suitable for the GPU.<br />
<br />
> 4. Allow for more complex geometry specified by Blender. (SRC)<br />
<br />
I would be a bit careful here but this should be discussed.<br />
<br />
Our approach would be to specify this domain-specific functionality in a WebComponent, whcih would also encapsulate the conversion into renderable geometry based on the input data.<br />
<br />
This functionality would not have to be in the core but could be loaded on demand.<br />
<br />
> 5. Provide a way to apply fragment shaders and vertex shaders to <br />
> objects (DOM).<br />
<br />
See shade.js, we even merge the vertex shading code with the other code that comes from the scene description (light iterators, shadowing, etc.). Shade .js then is able to extract all code int the specific stages automaticalls (using dependency analysis). As a result some code for fragment shading might get pulled into setting uniform variables in JS, if there is no varying data associated with the geometry that requires this code to be in the fragment shader stage.<br />
<br />
> 6. Provide a way to place and orient objects in the scenegraph.(DOM)<br />
<br />
> 7. H-Anim and physics.<br />
> 8. Geo.<br />
> 10. Mobile<br />
<br />
Many of these could be nicely implemented as separate WebComponents.<br />
<br />
> 9. VR<br />
<br />
WebVR is getting quite mature and we are currently integrating this in XML3D. Seems rather straight forward. Suitable VR authoring is another story, through.<br />
<br />
> 11. Templates or Macros of the above. (DOM). I think the only way <br />
> our own templating system is going to fly is if we apply it to HTML5 <br />
> and SVG as well.<br />
<br />
WebComponents is the HTML5 native way to here I would say.<br />
<br />
> 12. Proper support for HTML5 events on X3D objects.<br />
<br />
Already implemented in XML3D and being integrated into the new common structure.<br />
<br />
> 12a: I would add full support for CSS for 3D elements. We have shown<br />
how this should be done in a paper at last years Web3D. There are a few issues with proper support from CSS still waiting to be addressed, though.<br />
<br />
> Wish List:<br />
> <br />
> 13. SVG Extrusions for 3D printing Blind visualization.<br />
<br />
Could probably be done as another domain-specific WebComponent on top of the core.<br />
<br />
> This sounds like a lot. We need to figure out what we already have and<br />
> apply resources where necessary.<br />
<br />
As you see a lot of the functionality is already available (in the current XML3D and X3DOM) and we are putting a proof of concept to bring both of them together on top of a unified core.<br />
</pre><br />
<br />
Reference:<br />
*[http://xml3d.org/papers/ XML3D papers]<br />
<br />
===Contribution 13===<br />
<pre style="white-space: pre-wrap;"><br />
Thank you for that concise, clear and pragmatic summary of a possible bright future for an X3D V4.<br />
<br />
From a user and business standpoint, your approach puts X3D out in front and provides a path towards wide adoption and sustainability.<br />
<br />
I fully support your strategy.<br />
</pre><br />
<br />
===Contribution 14===<br />
<pre style="white-space: pre-wrap;"><br />
Thanks to all those who've expressed their view.<br />
<br />
I'm less sure about the need for a close integration between X3D and HTML5 at the DOM level. To me, 3D looks like it's at the same level as other multimedia such as video. The justification for MathML is much stronger, with the need to have inline math and style it with css the same way as surrounding text. Control of X3D from scripts in HTML pages, or pushing information from X3D to HTML, is useful but doesn't require DOM integration. I wouldn't mind it if it wasn't going to break compatibility with v3 in major ways.<br />
<br />
Which user case would it address? Why would a new X3D v4 be accepted rather than "modern" 3D approaches if compatibility is broken and deemed useless anyway?<br />
</pre></div>Webmasterhttps://www.web3d.org/wiki/index.php?title=File:BigImage.jpg&diff=9264File:BigImage.jpg2016-03-29T22:17:13Z<p>Webmaster: </p>
<hr />
<div></div>Webmasterhttps://www.web3d.org/wiki/index.php?title=Image_Test&diff=9263Image Test2016-03-29T22:16:02Z<p>Webmaster: </p>
<hr />
<div>Test page for uploading images<br />
<br />
<br />
[[File:web3d-logo.png]]<br />
<br />
[[File:w2.png]]<br />
<br />
[[File:BigImage.jpg]]</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=File:W2.png&diff=9262File:W2.png2016-03-29T22:14:01Z<p>Webmaster: </p>
<hr />
<div></div>Webmasterhttps://www.web3d.org/wiki/index.php?title=File:W2.jpg&diff=9261File:W2.jpg2016-03-29T22:10:04Z<p>Webmaster: </p>
<hr />
<div></div>Webmasterhttps://www.web3d.org/wiki/index.php?title=Image_Test&diff=9260Image Test2016-03-29T22:07:57Z<p>Webmaster: </p>
<hr />
<div>Test page for uploading images<br />
<br />
<br />
[[File:web3d-logo.png]]<br />
<br />
[[File:w2.png]]</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=File:Web3d-logo.png&diff=9259File:Web3d-logo.png2016-03-29T22:04:52Z<p>Webmaster: </p>
<hr />
<div></div>Webmasterhttps://www.web3d.org/wiki/index.php?title=Image_Test&diff=9258Image Test2016-03-29T22:03:30Z<p>Webmaster: </p>
<hr />
<div>Test page for uploading images<br />
<br />
<br />
[[File:web3d-logo.png]]</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=File:X3d_113x100.png&diff=9257File:X3d 113x100.png2016-03-29T21:59:18Z<p>Webmaster: </p>
<hr />
<div></div>Webmasterhttps://www.web3d.org/wiki/index.php?title=File:Hanim-logo.gif&diff=9256File:Hanim-logo.gif2016-03-29T21:54:36Z<p>Webmaster: </p>
<hr />
<div></div>Webmasterhttps://www.web3d.org/wiki/index.php?title=File:X3d-3d-2-NB.png&diff=9255File:X3d-3d-2-NB.png2016-03-29T21:48:39Z<p>Webmaster: </p>
<hr />
<div></div>Webmasterhttps://www.web3d.org/wiki/index.php?title=File:X3d-anywhere.png&diff=9254File:X3d-anywhere.png2016-03-29T21:43:27Z<p>Webmaster: </p>
<hr />
<div></div>Webmasterhttps://www.web3d.org/wiki/index.php?title=File:X3d2_154x97.gif&diff=9253File:X3d2 154x97.gif2016-03-29T21:17:49Z<p>Webmaster: XML-stylized X3D logo</p>
<hr />
<div>XML-stylized X3D logo</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=File:Yumetech.jpg&diff=9077File:Yumetech.jpg2015-11-13T19:11:42Z<p>Webmaster: Yumetech logo</p>
<hr />
<div>Yumetech logo</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=File:X3dAnywhere-white_89x55.png&diff=9076File:X3dAnywhere-white 89x55.png2015-11-13T19:09:38Z<p>Webmaster: X3D Anywhere Web3D logo</p>
<hr />
<div>X3D Anywhere Web3D logo</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=Main_Page&diff=9075Main Page2015-11-13T18:57:54Z<p>Webmaster: Reverted edits by Webmaster (talk) to last revision by Brutzman</p>
<hr />
<div>== Community Wiki ==<br />
<br />
Nearby: [http://www.web3d.org Web3D home], [http://www.web3d.org/realtime-3d/news-events Web3D events], and new [http://www.web3d.org/realtime-3d/member/wiki/Main Web3D Members-Only Wiki], and [http://www.web3d.org/wiki/index.php/Web3D_2014_Workshops_on_X3D_Evolution/Revolution Web3D 2014 Workshops]<br />
<br />
Please [http://www.web3d.org/contact?target=webSite Contact the WebMaster] if you need access to the wiki.<br />
<br />
__TOC__<br />
<br />
== Web3D and SIGGRAPH 2014 Conference Events ==<br />
<br />
These pages serve as the basis for meeting discussion and minutes<br />
<br />
* [[Web3D 2014 Workshops on X3D Evolution/Revolution]]<br />
* [[DIY X3D: Learning Teaching and Doing X3D Graphics with HTML5]]<br />
<br />
== Active X3D Working Groups: Public Pages ==<br />
<br />
=== X3D Working Group ===<br />
* The X3D Working Group ([http://www.web3d.org/realtime-3d/working-groups/x3d executive summary]) is the main forum for coordinating all X3D specification activities, including other working groups.<br />
* This group also performs future X3D design, resolution of X3D specification comments, and review of X3D implementation resources.<br />
* Working group teleconferences are every Wednesday at 08-0900 pacific time, 16-1700 GMT on the Web3D teleconference line.<br />
* Cochairs: Don Brutzman and Leonard Daly<br />
* ISO Convener: Dick Puk<br />
<br />
=== Current activities: JSON, Binary Compression, X3D v3.4, v4.0 and v4.1, etc. === <br />
* [[X3D JSON Encoding]]<br />
* [[X3D Binary Compression Capabilities and Plans]] for a new Efficient Binary Encoding<br />
* [[X3D Development Public Plans]] (contains public statements and links for the items below)<br />
** [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/X3D.html X3D version 3.3] has been finalized as an ISO International Standard (IS). The text has been sent to ISO/IEC for final ballot.<br />
*** [http://www.web3d.org/realtime-3d/member/wiki/x3d-v33-specification-changes X3D v3.3 Specification Changes] (members-only document<!--, formerly [http://www.web3d.org/membership/login/memberwiki/index.php/X3D_v3.3_Specification_Changes X3D v3.3 Specification Changes]-->) includes relevant information on deferred capabilities.<br />
** [[X3D version 3.4 Development]] efforts are evolutionary improvements to the proven X3D Graphics architecture.<br />
*** Working groups and individual contributions are currently defining future goals and requirements.<br />
** [[X3D version 4.0 Development]] efforts are considering major evolutionary changes to the baseline X3D architecture<br />
*** Major technology under consideration: HTML5/Declarative 3D/X3DOM<br />
** X3D version 4.1 development supports AR, VR devices<br />
*** Major technology under consideration: ISO Mixed and Augmented Reality (MAR) Reference Model<br />
** Please [http://www.web3d.org/realtime-3d/contact contact Web3D Consortium] or [http://www.web3d.org/realtime-3d/page/contact/x3d-chairs contact X3D cochairs] if you think additional technologies need to be considered.<br />
*** X3D futures planning is currently a Web3D Consortium member-only activity.<br />
* [[X3D MIME-Type]] in X3D Working Group to get official IETF MIME-Type recognition for X3D<br />
** This has been completed. The IETF listing is at [http://www.iana.org/assignments/media-types/media-types.xhtml#model]<br />
<br />
=== Access and Participation ===<br />
<br />
Many Web3D technical efforts are visible to the public. Some are restricted to Web3D Consortium members. Membership has value.<br />
<br />
* Web3D Consortium members are allowed to decide on specification priorities and whether new technology is accepted for our royalty-free X3D International Standard.<br />
* The general public is allowed to observe and comment at various stages of development.<br />
* Some working group activities are fully open, some activities are performed by Web3D Consortium members only.<br />
* Web3D Consortium members have agreed to the [http://web3d.org/membership/join Intellectual Property Rights (IPR) Policy] which effectively prevents any royalty-based technology from being adopted by X3D.<br />
* This approach provides great value to the public, and also allows both companies and individual professionals to contribute to X3D directly as Web3D Consortium members.<br />
* Meanwhile, each working group can still decide to place some work in the open and some with restricted access. For example, all HTML5/X3DOM work is completely in the open.<br />
* For private member-only communications, Web3D Members can also use the [http://www.web3d.org/membership/login/memberwiki/index.php/Main_Page Web3D Members-Only Wiki].<br />
<br />
=== [[X3D and Augmented Reality]] Continuum (ARC) Working Group: AR Extensions for X3D ===<br />
<br />
* The Augmented Reality (AR) Working Group was formed to address the needs of projecting computer generated information into the real world. The Working Group focuses on utilizing and extending X3D capabilities to support augmented reality (AR) and mixed reality (MR) applications.<br />
* [http://www.web3d.org/realtime-3d/working-groups/augmented-reality-ar X3D and Augmented Reality working group summary]<br />
* [[X3D and Augmented Reality]] wiki<br />
* Members are also participating in efforts by the ISO SC24 Working Group 9 for Augmented Reality Continuum (ARC)<br />
<br />
=== [[X3D CAD]] Working Group: Computer Aided Design (CAD) Extensions for X3D ===<br />
<br />
* The X3D CAD Working Group is now in its third generation of development effort. We are developing and demonstrating best practices for exporting any CAD model to X3D for Web applications.<br />
* [http://www.web3d.org/realtime-3d/working-groups/computer-aided-design-cad Computer Aided Design (CAD) working group summary]<br />
* [[X3D CAD]] working group wiki<br />
<br />
=== [[X3D Earth Working Group]] for geospatial representations ===<br />
* The X3D Earth Working Group uses the Web architecture, XML languages, and open protocols to build a standards-based X3D Earth specification usable by governments, industry, scientists, academia, and the general public. X3D-Earth efforts encompass client-side, server-side, authoring, and conversion technologies.<br />
''Vision:'' Make it easier to create and use 3D spatial data.<br />
''Mission.'' Promote spatial data use within X3D via open architectures.<br />
* [http://www.web3d.org/realtime-3d/working-groups/x3d-earth X3D Earth working group summary]<br />
* [[X3D Earth Working Group]] wiki<br />
<br />
=== X3D [[H-Anim]] Working Group: Humanoid Animation (H-Anim) ===<br />
* The Humanoid Animation (H-Anim) standard supports representative human models incorporating open best practices of haptic and kinematic interfaces and a certain default skeleton pose in order to enable shared animations.<br />
* There are corresponding documents for [http://www.web3d.org/files/specifications/19774/V1.0/index.html Humanoid Animation (H-Anim)] abstract specification and [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/hanim.html X3D Humanoid Animation component].<br />
* [http://www.web3d.org/realtime-3d/working-groups/h-anim H-Anim working group summary]<br />
* [[H-Anim]] wiki<br />
<br />
=== [[X3D Medical]] Working Group: Volume visualization and Medical uses ===<br />
* The Medical Working Group is developing an open interoperable standard for the representation of human anatomy based on input from a wide variety of imaging modalities.<br />
* [http://www.web3d.org/realtime-3d/working-groups/medx3d X3D Medical working group summary]<br />
* [[X3D Medical]] wiki<br />
<br />
=== [[Heritage]] Working Group: Cultural Heritage and Natural History ===<br />
<br />
* Initial efforts are following up on really interesting keynote presentation and workshop discussions at the Web3D 2014 Symposium.<br />
<br />
----<br />
<br />
== X3D Special Interest Groups: Public Pages ==<br />
X3D Special Interest groups are open to anyone interested in participating. <br />
This open approach provides great value to the public to explore new technologies and applications for X3D. It also allows both companies and individuals to contribute some technologies towards moving the X3D standard forward. <br />
<!-- none yet: * [[X3D and Networking]] Special Interest Group efforts --><br />
<!-- * [[X3D Mobile]] Working Group efforts --><br />
<br />
=== [[Xj3D Evolution]] ===<br />
<br />
Renewed open-source community effort.<br />
<br />
=== [[X3D and HTML5]] design efforts and [http://www.w3.org/community/declarative3d Declarative 3D Community Group] ===<br />
Numerous efforts are working to establish a solid foundation for proper X3D graphics support in HTML5. <br />
* [http://www.w3.org/community/declarative3d Declarative 3D Community Group] efforts include integration of Declarative 3D requirements as part of X3D version 4.0 design<br />
* [[X3D and HTML5]] wiki lists a wide variety of techniques for authors creating Web content<br />
<br />
=== [[X3D and E-Learning]] ===<br />
<br />
Special Interest Group efforts are discussed on the X3D mailing list.<br />
<br />
== About X3D ==<br />
* [http://www.web3d.org/about/overview/ What is X3D]<br />
** [http://www.web3d.org/about/faq/ X3D/VRML FAQ]<br />
** [[X3D and HTML FAQ]]<br />
* [[Features and Strengths of X3D]]<br />
* [[Industry Adopters]]<br />
* [http://www.web3d.org/membership/join/ Get Involved!]<br />
* [[Interviews and Outreach]]<br />
* [[Recent Events]]<br />
<br />
== X3D Community Information==<br />
* [[Player support for X3D components]]<br />
* [[Tool support for X3D components]]<br />
* [[X3D Plugfest]] to improve interoperability between X3D players<br />
* [[X3D Implementations]]<br />
<br />
== Technology Contributions ==<br />
<br />
The Web3D Consortium is always happy to receive proposals for [[Technology Contributions]] that might help to advance 3D graphics on the Web.<br />
<br />
== X3D Resources ==<br />
* [http://www.web3d.org/x3d/content/examples/X3dResources.html X3D Resources] provides comprehensive links to many X3D applications, sources and capabilities<br />
* [http://www.web3d.org/x3d/content/examples/X3dResources.html#Tooltips X3D Tooltips] provides multilingual details on the X3D vocabulary<br />
* [[How-To Guides]] and [[Node Reference]]<br />
* [http://www.web3d.org/x3d/specifications/ X3D Specifications] provides public copies of all Web3D specification work<br />
* [[Player support for X3D components]] and [[Tool support for X3D components]]<br />
* [[Plug-in and browser compliance]]<br />
* [[Recommendations for browser developers]]<br />
<br />
== Web3D Chapters ==<br />
Official Chapters (geographically oriented) of the Web3D Consortium<br />
<br />
* [http://web3d.kr Web3D Consortium Korea Chapter]<br />
* [[Korea Chapter Public Wiki]]<br />
* Nearby: [http://www.web3d.org/membership/login/memberwiki/index.php/Korea_Chapter_Members-Only_Wiki Korea Chapter Members-Only Wiki]<br />
<br />
== About the Public and Members-Only X3D Wiki ==<br />
* [[Usage Guidelines]]<br />
* [[How to wiki]]<br />
* [[Create New Page]]<br />
* [http://www.web3d.org/membership/login/memberwiki/index.php/Main_Page Web3D Members-Only Wiki]<br />
<br />
Administrative notes: <br />
* '''If you need an account on this wiki''', please [http://www.web3d.org/contact?target=webSite contact the Webmaster] and include 'Wiki Account' in the subject.<br />
* Because of some reported abuse to existing members, creation of all new accounts have been '''disabled'''. This state will continue until a better means of identifying members has been established.<br />
* SysAdmin Note: WikiMedia software upgraded to latest version (9 Jan 2013).</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=Image_Test&diff=9074Image Test2015-11-13T18:57:23Z<p>Webmaster: Created page with "Test page for uploading images"</p>
<hr />
<div>Test page for uploading images</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=Main_Page&diff=9073Main Page2015-11-13T18:57:03Z<p>Webmaster: /* Community Wiki */</p>
<hr />
<div>== Community Wiki ==<br />
<br />
Nearby: [http://www.web3d.org Web3D home], [http://www.web3d.org/realtime-3d/news-events Web3D events], and new [http://www.web3d.org/realtime-3d/member/wiki/Main Web3D Members-Only Wiki], and [http://www.web3d.org/wiki/index.php/Web3D_2014_Workshops_on_X3D_Evolution/Revolution Web3D 2014 Workshops]<br />
<br />
Please [http://www.web3d.org/contact?target=webSite Contact the WebMaster] if you need access to the wiki.<br />
<br />
__TOC__<br />
[[Image Test]]<br />
<br />
== Web3D and SIGGRAPH 2014 Conference Events ==<br />
<br />
These pages serve as the basis for meeting discussion and minutes<br />
<br />
* [[Web3D 2014 Workshops on X3D Evolution/Revolution]]<br />
* [[DIY X3D: Learning Teaching and Doing X3D Graphics with HTML5]]<br />
<br />
== Active X3D Working Groups: Public Pages ==<br />
<br />
=== X3D Working Group ===<br />
* The X3D Working Group ([http://www.web3d.org/realtime-3d/working-groups/x3d executive summary]) is the main forum for coordinating all X3D specification activities, including other working groups.<br />
* This group also performs future X3D design, resolution of X3D specification comments, and review of X3D implementation resources.<br />
* Working group teleconferences are every Wednesday at 08-0900 pacific time, 16-1700 GMT on the Web3D teleconference line.<br />
* Cochairs: Don Brutzman and Leonard Daly<br />
* ISO Convener: Dick Puk<br />
<br />
=== Current activities: JSON, Binary Compression, X3D v3.4, v4.0 and v4.1, etc. === <br />
* [[X3D JSON Encoding]]<br />
* [[X3D Binary Compression Capabilities and Plans]] for a new Efficient Binary Encoding<br />
* [[X3D Development Public Plans]] (contains public statements and links for the items below)<br />
** [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/X3D.html X3D version 3.3] has been finalized as an ISO International Standard (IS). The text has been sent to ISO/IEC for final ballot.<br />
*** [http://www.web3d.org/realtime-3d/member/wiki/x3d-v33-specification-changes X3D v3.3 Specification Changes] (members-only document<!--, formerly [http://www.web3d.org/membership/login/memberwiki/index.php/X3D_v3.3_Specification_Changes X3D v3.3 Specification Changes]-->) includes relevant information on deferred capabilities.<br />
** [[X3D version 3.4 Development]] efforts are evolutionary improvements to the proven X3D Graphics architecture.<br />
*** Working groups and individual contributions are currently defining future goals and requirements.<br />
** [[X3D version 4.0 Development]] efforts are considering major evolutionary changes to the baseline X3D architecture<br />
*** Major technology under consideration: HTML5/Declarative 3D/X3DOM<br />
** X3D version 4.1 development supports AR, VR devices<br />
*** Major technology under consideration: ISO Mixed and Augmented Reality (MAR) Reference Model<br />
** Please [http://www.web3d.org/realtime-3d/contact contact Web3D Consortium] or [http://www.web3d.org/realtime-3d/page/contact/x3d-chairs contact X3D cochairs] if you think additional technologies need to be considered.<br />
*** X3D futures planning is currently a Web3D Consortium member-only activity.<br />
* [[X3D MIME-Type]] in X3D Working Group to get official IETF MIME-Type recognition for X3D<br />
** This has been completed. The IETF listing is at [http://www.iana.org/assignments/media-types/media-types.xhtml#model]<br />
<br />
=== Access and Participation ===<br />
<br />
Many Web3D technical efforts are visible to the public. Some are restricted to Web3D Consortium members. Membership has value.<br />
<br />
* Web3D Consortium members are allowed to decide on specification priorities and whether new technology is accepted for our royalty-free X3D International Standard.<br />
* The general public is allowed to observe and comment at various stages of development.<br />
* Some working group activities are fully open, some activities are performed by Web3D Consortium members only.<br />
* Web3D Consortium members have agreed to the [http://web3d.org/membership/join Intellectual Property Rights (IPR) Policy] which effectively prevents any royalty-based technology from being adopted by X3D.<br />
* This approach provides great value to the public, and also allows both companies and individual professionals to contribute to X3D directly as Web3D Consortium members.<br />
* Meanwhile, each working group can still decide to place some work in the open and some with restricted access. For example, all HTML5/X3DOM work is completely in the open.<br />
* For private member-only communications, Web3D Members can also use the [http://www.web3d.org/membership/login/memberwiki/index.php/Main_Page Web3D Members-Only Wiki].<br />
<br />
=== [[X3D and Augmented Reality]] Continuum (ARC) Working Group: AR Extensions for X3D ===<br />
<br />
* The Augmented Reality (AR) Working Group was formed to address the needs of projecting computer generated information into the real world. The Working Group focuses on utilizing and extending X3D capabilities to support augmented reality (AR) and mixed reality (MR) applications.<br />
* [http://www.web3d.org/realtime-3d/working-groups/augmented-reality-ar X3D and Augmented Reality working group summary]<br />
* [[X3D and Augmented Reality]] wiki<br />
* Members are also participating in efforts by the ISO SC24 Working Group 9 for Augmented Reality Continuum (ARC)<br />
<br />
=== [[X3D CAD]] Working Group: Computer Aided Design (CAD) Extensions for X3D ===<br />
<br />
* The X3D CAD Working Group is now in its third generation of development effort. We are developing and demonstrating best practices for exporting any CAD model to X3D for Web applications.<br />
* [http://www.web3d.org/realtime-3d/working-groups/computer-aided-design-cad Computer Aided Design (CAD) working group summary]<br />
* [[X3D CAD]] working group wiki<br />
<br />
=== [[X3D Earth Working Group]] for geospatial representations ===<br />
* The X3D Earth Working Group uses the Web architecture, XML languages, and open protocols to build a standards-based X3D Earth specification usable by governments, industry, scientists, academia, and the general public. X3D-Earth efforts encompass client-side, server-side, authoring, and conversion technologies.<br />
''Vision:'' Make it easier to create and use 3D spatial data.<br />
''Mission.'' Promote spatial data use within X3D via open architectures.<br />
* [http://www.web3d.org/realtime-3d/working-groups/x3d-earth X3D Earth working group summary]<br />
* [[X3D Earth Working Group]] wiki<br />
<br />
=== X3D [[H-Anim]] Working Group: Humanoid Animation (H-Anim) ===<br />
* The Humanoid Animation (H-Anim) standard supports representative human models incorporating open best practices of haptic and kinematic interfaces and a certain default skeleton pose in order to enable shared animations.<br />
* There are corresponding documents for [http://www.web3d.org/files/specifications/19774/V1.0/index.html Humanoid Animation (H-Anim)] abstract specification and [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/hanim.html X3D Humanoid Animation component].<br />
* [http://www.web3d.org/realtime-3d/working-groups/h-anim H-Anim working group summary]<br />
* [[H-Anim]] wiki<br />
<br />
=== [[X3D Medical]] Working Group: Volume visualization and Medical uses ===<br />
* The Medical Working Group is developing an open interoperable standard for the representation of human anatomy based on input from a wide variety of imaging modalities.<br />
* [http://www.web3d.org/realtime-3d/working-groups/medx3d X3D Medical working group summary]<br />
* [[X3D Medical]] wiki<br />
<br />
=== [[Heritage]] Working Group: Cultural Heritage and Natural History ===<br />
<br />
* Initial efforts are following up on really interesting keynote presentation and workshop discussions at the Web3D 2014 Symposium.<br />
<br />
----<br />
<br />
== X3D Special Interest Groups: Public Pages ==<br />
X3D Special Interest groups are open to anyone interested in participating. <br />
This open approach provides great value to the public to explore new technologies and applications for X3D. It also allows both companies and individuals to contribute some technologies towards moving the X3D standard forward. <br />
<!-- none yet: * [[X3D and Networking]] Special Interest Group efforts --><br />
<!-- * [[X3D Mobile]] Working Group efforts --><br />
<br />
=== [[Xj3D Evolution]] ===<br />
<br />
Renewed open-source community effort.<br />
<br />
=== [[X3D and HTML5]] design efforts and [http://www.w3.org/community/declarative3d Declarative 3D Community Group] ===<br />
Numerous efforts are working to establish a solid foundation for proper X3D graphics support in HTML5. <br />
* [http://www.w3.org/community/declarative3d Declarative 3D Community Group] efforts include integration of Declarative 3D requirements as part of X3D version 4.0 design<br />
* [[X3D and HTML5]] wiki lists a wide variety of techniques for authors creating Web content<br />
<br />
=== [[X3D and E-Learning]] ===<br />
<br />
Special Interest Group efforts are discussed on the X3D mailing list.<br />
<br />
== About X3D ==<br />
* [http://www.web3d.org/about/overview/ What is X3D]<br />
** [http://www.web3d.org/about/faq/ X3D/VRML FAQ]<br />
** [[X3D and HTML FAQ]]<br />
* [[Features and Strengths of X3D]]<br />
* [[Industry Adopters]]<br />
* [http://www.web3d.org/membership/join/ Get Involved!]<br />
* [[Interviews and Outreach]]<br />
* [[Recent Events]]<br />
<br />
== X3D Community Information==<br />
* [[Player support for X3D components]]<br />
* [[Tool support for X3D components]]<br />
* [[X3D Plugfest]] to improve interoperability between X3D players<br />
* [[X3D Implementations]]<br />
<br />
== Technology Contributions ==<br />
<br />
The Web3D Consortium is always happy to receive proposals for [[Technology Contributions]] that might help to advance 3D graphics on the Web.<br />
<br />
== X3D Resources ==<br />
* [http://www.web3d.org/x3d/content/examples/X3dResources.html X3D Resources] provides comprehensive links to many X3D applications, sources and capabilities<br />
* [http://www.web3d.org/x3d/content/examples/X3dResources.html#Tooltips X3D Tooltips] provides multilingual details on the X3D vocabulary<br />
* [[How-To Guides]] and [[Node Reference]]<br />
* [http://www.web3d.org/x3d/specifications/ X3D Specifications] provides public copies of all Web3D specification work<br />
* [[Player support for X3D components]] and [[Tool support for X3D components]]<br />
* [[Plug-in and browser compliance]]<br />
* [[Recommendations for browser developers]]<br />
<br />
== Web3D Chapters ==<br />
Official Chapters (geographically oriented) of the Web3D Consortium<br />
<br />
* [http://web3d.kr Web3D Consortium Korea Chapter]<br />
* [[Korea Chapter Public Wiki]]<br />
* Nearby: [http://www.web3d.org/membership/login/memberwiki/index.php/Korea_Chapter_Members-Only_Wiki Korea Chapter Members-Only Wiki]<br />
<br />
== About the Public and Members-Only X3D Wiki ==<br />
* [[Usage Guidelines]]<br />
* [[How to wiki]]<br />
* [[Create New Page]]<br />
* [http://www.web3d.org/membership/login/memberwiki/index.php/Main_Page Web3D Members-Only Wiki]<br />
<br />
Administrative notes: <br />
* '''If you need an account on this wiki''', please [http://www.web3d.org/contact?target=webSite contact the Webmaster] and include 'Wiki Account' in the subject.<br />
* Because of some reported abuse to existing members, creation of all new accounts have been '''disabled'''. This state will continue until a better means of identifying members has been established.<br />
* SysAdmin Note: WikiMedia software upgraded to latest version (9 Jan 2013).</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=Main_Page&diff=9072Main Page2015-11-13T18:56:40Z<p>Webmaster: /* Community Wiki */</p>
<hr />
<div>== Community Wiki ==<br />
<br />
Nearby: [http://www.web3d.org Web3D home], [http://www.web3d.org/realtime-3d/news-events Web3D events], and new [http://www.web3d.org/realtime-3d/member/wiki/Main Web3D Members-Only Wiki], and [http://www.web3d.org/wiki/index.php/Web3D_2014_Workshops_on_X3D_Evolution/Revolution Web3D 2014 Workshops]<br />
<br />
Please [http://www.web3d.org/contact?target=webSite Contact the WebMaster] if you need access to the wiki.<br />
<br />
__TOC__<br />
[Image Test]<br />
<br />
== Web3D and SIGGRAPH 2014 Conference Events ==<br />
<br />
These pages serve as the basis for meeting discussion and minutes<br />
<br />
* [[Web3D 2014 Workshops on X3D Evolution/Revolution]]<br />
* [[DIY X3D: Learning Teaching and Doing X3D Graphics with HTML5]]<br />
<br />
== Active X3D Working Groups: Public Pages ==<br />
<br />
=== X3D Working Group ===<br />
* The X3D Working Group ([http://www.web3d.org/realtime-3d/working-groups/x3d executive summary]) is the main forum for coordinating all X3D specification activities, including other working groups.<br />
* This group also performs future X3D design, resolution of X3D specification comments, and review of X3D implementation resources.<br />
* Working group teleconferences are every Wednesday at 08-0900 pacific time, 16-1700 GMT on the Web3D teleconference line.<br />
* Cochairs: Don Brutzman and Leonard Daly<br />
* ISO Convener: Dick Puk<br />
<br />
=== Current activities: JSON, Binary Compression, X3D v3.4, v4.0 and v4.1, etc. === <br />
* [[X3D JSON Encoding]]<br />
* [[X3D Binary Compression Capabilities and Plans]] for a new Efficient Binary Encoding<br />
* [[X3D Development Public Plans]] (contains public statements and links for the items below)<br />
** [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/X3D.html X3D version 3.3] has been finalized as an ISO International Standard (IS). The text has been sent to ISO/IEC for final ballot.<br />
*** [http://www.web3d.org/realtime-3d/member/wiki/x3d-v33-specification-changes X3D v3.3 Specification Changes] (members-only document<!--, formerly [http://www.web3d.org/membership/login/memberwiki/index.php/X3D_v3.3_Specification_Changes X3D v3.3 Specification Changes]-->) includes relevant information on deferred capabilities.<br />
** [[X3D version 3.4 Development]] efforts are evolutionary improvements to the proven X3D Graphics architecture.<br />
*** Working groups and individual contributions are currently defining future goals and requirements.<br />
** [[X3D version 4.0 Development]] efforts are considering major evolutionary changes to the baseline X3D architecture<br />
*** Major technology under consideration: HTML5/Declarative 3D/X3DOM<br />
** X3D version 4.1 development supports AR, VR devices<br />
*** Major technology under consideration: ISO Mixed and Augmented Reality (MAR) Reference Model<br />
** Please [http://www.web3d.org/realtime-3d/contact contact Web3D Consortium] or [http://www.web3d.org/realtime-3d/page/contact/x3d-chairs contact X3D cochairs] if you think additional technologies need to be considered.<br />
*** X3D futures planning is currently a Web3D Consortium member-only activity.<br />
* [[X3D MIME-Type]] in X3D Working Group to get official IETF MIME-Type recognition for X3D<br />
** This has been completed. The IETF listing is at [http://www.iana.org/assignments/media-types/media-types.xhtml#model]<br />
<br />
=== Access and Participation ===<br />
<br />
Many Web3D technical efforts are visible to the public. Some are restricted to Web3D Consortium members. Membership has value.<br />
<br />
* Web3D Consortium members are allowed to decide on specification priorities and whether new technology is accepted for our royalty-free X3D International Standard.<br />
* The general public is allowed to observe and comment at various stages of development.<br />
* Some working group activities are fully open, some activities are performed by Web3D Consortium members only.<br />
* Web3D Consortium members have agreed to the [http://web3d.org/membership/join Intellectual Property Rights (IPR) Policy] which effectively prevents any royalty-based technology from being adopted by X3D.<br />
* This approach provides great value to the public, and also allows both companies and individual professionals to contribute to X3D directly as Web3D Consortium members.<br />
* Meanwhile, each working group can still decide to place some work in the open and some with restricted access. For example, all HTML5/X3DOM work is completely in the open.<br />
* For private member-only communications, Web3D Members can also use the [http://www.web3d.org/membership/login/memberwiki/index.php/Main_Page Web3D Members-Only Wiki].<br />
<br />
=== [[X3D and Augmented Reality]] Continuum (ARC) Working Group: AR Extensions for X3D ===<br />
<br />
* The Augmented Reality (AR) Working Group was formed to address the needs of projecting computer generated information into the real world. The Working Group focuses on utilizing and extending X3D capabilities to support augmented reality (AR) and mixed reality (MR) applications.<br />
* [http://www.web3d.org/realtime-3d/working-groups/augmented-reality-ar X3D and Augmented Reality working group summary]<br />
* [[X3D and Augmented Reality]] wiki<br />
* Members are also participating in efforts by the ISO SC24 Working Group 9 for Augmented Reality Continuum (ARC)<br />
<br />
=== [[X3D CAD]] Working Group: Computer Aided Design (CAD) Extensions for X3D ===<br />
<br />
* The X3D CAD Working Group is now in its third generation of development effort. We are developing and demonstrating best practices for exporting any CAD model to X3D for Web applications.<br />
* [http://www.web3d.org/realtime-3d/working-groups/computer-aided-design-cad Computer Aided Design (CAD) working group summary]<br />
* [[X3D CAD]] working group wiki<br />
<br />
=== [[X3D Earth Working Group]] for geospatial representations ===<br />
* The X3D Earth Working Group uses the Web architecture, XML languages, and open protocols to build a standards-based X3D Earth specification usable by governments, industry, scientists, academia, and the general public. X3D-Earth efforts encompass client-side, server-side, authoring, and conversion technologies.<br />
''Vision:'' Make it easier to create and use 3D spatial data.<br />
''Mission.'' Promote spatial data use within X3D via open architectures.<br />
* [http://www.web3d.org/realtime-3d/working-groups/x3d-earth X3D Earth working group summary]<br />
* [[X3D Earth Working Group]] wiki<br />
<br />
=== X3D [[H-Anim]] Working Group: Humanoid Animation (H-Anim) ===<br />
* The Humanoid Animation (H-Anim) standard supports representative human models incorporating open best practices of haptic and kinematic interfaces and a certain default skeleton pose in order to enable shared animations.<br />
* There are corresponding documents for [http://www.web3d.org/files/specifications/19774/V1.0/index.html Humanoid Animation (H-Anim)] abstract specification and [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/hanim.html X3D Humanoid Animation component].<br />
* [http://www.web3d.org/realtime-3d/working-groups/h-anim H-Anim working group summary]<br />
* [[H-Anim]] wiki<br />
<br />
=== [[X3D Medical]] Working Group: Volume visualization and Medical uses ===<br />
* The Medical Working Group is developing an open interoperable standard for the representation of human anatomy based on input from a wide variety of imaging modalities.<br />
* [http://www.web3d.org/realtime-3d/working-groups/medx3d X3D Medical working group summary]<br />
* [[X3D Medical]] wiki<br />
<br />
=== [[Heritage]] Working Group: Cultural Heritage and Natural History ===<br />
<br />
* Initial efforts are following up on really interesting keynote presentation and workshop discussions at the Web3D 2014 Symposium.<br />
<br />
----<br />
<br />
== X3D Special Interest Groups: Public Pages ==<br />
X3D Special Interest groups are open to anyone interested in participating. <br />
This open approach provides great value to the public to explore new technologies and applications for X3D. It also allows both companies and individuals to contribute some technologies towards moving the X3D standard forward. <br />
<!-- none yet: * [[X3D and Networking]] Special Interest Group efforts --><br />
<!-- * [[X3D Mobile]] Working Group efforts --><br />
<br />
=== [[Xj3D Evolution]] ===<br />
<br />
Renewed open-source community effort.<br />
<br />
=== [[X3D and HTML5]] design efforts and [http://www.w3.org/community/declarative3d Declarative 3D Community Group] ===<br />
Numerous efforts are working to establish a solid foundation for proper X3D graphics support in HTML5. <br />
* [http://www.w3.org/community/declarative3d Declarative 3D Community Group] efforts include integration of Declarative 3D requirements as part of X3D version 4.0 design<br />
* [[X3D and HTML5]] wiki lists a wide variety of techniques for authors creating Web content<br />
<br />
=== [[X3D and E-Learning]] ===<br />
<br />
Special Interest Group efforts are discussed on the X3D mailing list.<br />
<br />
== About X3D ==<br />
* [http://www.web3d.org/about/overview/ What is X3D]<br />
** [http://www.web3d.org/about/faq/ X3D/VRML FAQ]<br />
** [[X3D and HTML FAQ]]<br />
* [[Features and Strengths of X3D]]<br />
* [[Industry Adopters]]<br />
* [http://www.web3d.org/membership/join/ Get Involved!]<br />
* [[Interviews and Outreach]]<br />
* [[Recent Events]]<br />
<br />
== X3D Community Information==<br />
* [[Player support for X3D components]]<br />
* [[Tool support for X3D components]]<br />
* [[X3D Plugfest]] to improve interoperability between X3D players<br />
* [[X3D Implementations]]<br />
<br />
== Technology Contributions ==<br />
<br />
The Web3D Consortium is always happy to receive proposals for [[Technology Contributions]] that might help to advance 3D graphics on the Web.<br />
<br />
== X3D Resources ==<br />
* [http://www.web3d.org/x3d/content/examples/X3dResources.html X3D Resources] provides comprehensive links to many X3D applications, sources and capabilities<br />
* [http://www.web3d.org/x3d/content/examples/X3dResources.html#Tooltips X3D Tooltips] provides multilingual details on the X3D vocabulary<br />
* [[How-To Guides]] and [[Node Reference]]<br />
* [http://www.web3d.org/x3d/specifications/ X3D Specifications] provides public copies of all Web3D specification work<br />
* [[Player support for X3D components]] and [[Tool support for X3D components]]<br />
* [[Plug-in and browser compliance]]<br />
* [[Recommendations for browser developers]]<br />
<br />
== Web3D Chapters ==<br />
Official Chapters (geographically oriented) of the Web3D Consortium<br />
<br />
* [http://web3d.kr Web3D Consortium Korea Chapter]<br />
* [[Korea Chapter Public Wiki]]<br />
* Nearby: [http://www.web3d.org/membership/login/memberwiki/index.php/Korea_Chapter_Members-Only_Wiki Korea Chapter Members-Only Wiki]<br />
<br />
== About the Public and Members-Only X3D Wiki ==<br />
* [[Usage Guidelines]]<br />
* [[How to wiki]]<br />
* [[Create New Page]]<br />
* [http://www.web3d.org/membership/login/memberwiki/index.php/Main_Page Web3D Members-Only Wiki]<br />
<br />
Administrative notes: <br />
* '''If you need an account on this wiki''', please [http://www.web3d.org/contact?target=webSite contact the Webmaster] and include 'Wiki Account' in the subject.<br />
* Because of some reported abuse to existing members, creation of all new accounts have been '''disabled'''. This state will continue until a better means of identifying members has been established.<br />
* SysAdmin Note: WikiMedia software upgraded to latest version (9 Jan 2013).</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_Heritage&diff=8927X3D Heritage2015-05-19T17:52:39Z<p>Webmaster: </p>
<hr />
<div>'''This page is deprecated use [[Heritage]] instead.'''<br />
<br />
<br />
'''The Cultural and Natural Heritage Working Group''' is developing an open interoperable standard for the Archival and Retrieval of cultural heritage and natural objects based on input from a wide variety of imaging modalities.<br />
<br />
Millions of cultural heritage artifacts populate our museums and about 90% still await discovery in museum archives. In addition there are millions of natural objects, such as insects, hidden in museum drawers. 3D Digital models can provide arbitrary availability and concurrent access to digital alternates of heritage artifacts for historians and scientists. Moreover, virtual presentations (combined with new forms of presentation technologies, such as hybrid exhibitions) can be used as a means to increase attractiveness and public engagement.<br />
<br />
<h2 style="font-style: normal; font-variant: normal; line-height: 29.9999980926514px;"><strong><span style="font-family: Arial, Helvetica, sans-serif; font-size: 24px; line-height: 29.9999980926514px;"> Goals </span></strong></h2><br />
<br />
* Define Web3D Consortium strategic goals for open standards for Archival and Retrieval of cultural and natural heritage objects <br />
* Discuss data size, work flows, scanning, processing tools, publications and best practices <br />
* Characterize Cultural Heritage requirements and activities by museums, anthroplogy and government agencies<br />
<br />
<h2 style="font-style: normal; font-variant: normal; line-height: 29.9999980926514px;"><strong><span style="font-family: Arial, Helvetica, sans-serif; font-size: 24px; line-height: 29.9999980926514px;"> Events </span></strong></h2><br />
<br />
There will be a workshop at [http://web3d2015.web3d.org/workshops.html Web3D 2015] about Cultural and Natural Heritage. Go to the link to get all the information about submission!.<br />
<br />
<h2 style="font-style: normal; font-variant: normal;"><strong><span style="font-family: Arial, Helvetica, sans-serif; font-size: 24px; ">Working Group Resources</span></strong></h2><ul><li>Web3D Consortium Home Page examples (in X3DOM): <br />
[http://www.web3d.org/example/cultural-heritage-preservation Museums &amp; Artifacts], <br />
[http://www.web3d.org/example/cathedral-siena-italy Buildings / Structures]</li><br />
<li>CSIRO's insect collection ([http://tv.csiro.au/?v=xbz189zsuhn8 video], [http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0094346 paper], [http://www2.ala.org.au/chuong examples])</li><br />
<li>[http://metagrid1.sv.vt.edu/~npolys/SI3D/ Smithsonian 3D models] processed by Virginia Tech &amp; Fraunhofer IGD to X3DOM compressed geometry</li><br />
<li>Fraunhofer IGD's [http://www.cultlab3d.eu CultLab object acquisition system]</li><br />
<li>Geometry processing tool [http://www.meshlab.org/ Meshlab] (EU, open source)</li><br />
<li>Web3D 2015 Workshop (linked at bottom of page)&nbsp; - [http://web3d2014.web3d.org/workshops/ slides &amp; videos]</li><li>SIGGRAPH 2014 BOF [[sig14heritage]] slides</li><br />
<li>[http://www.x3dom.org/?p=3517 Digital Heritage 2013 slides] (X3DOM)</li></ul></div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_Heritage&diff=8926X3D Heritage2015-05-19T17:52:20Z<p>Webmaster: This page has been deprecated because of a name change of the WG</p>
<hr />
<div>This page is deprecated use [[Heritage]] instead.<br />
<br />
<br />
'''The Cultural and Natural Heritage Working Group''' is developing an open interoperable standard for the Archival and Retrieval of cultural heritage and natural objects based on input from a wide variety of imaging modalities.<br />
<br />
Millions of cultural heritage artifacts populate our museums and about 90% still await discovery in museum archives. In addition there are millions of natural objects, such as insects, hidden in museum drawers. 3D Digital models can provide arbitrary availability and concurrent access to digital alternates of heritage artifacts for historians and scientists. Moreover, virtual presentations (combined with new forms of presentation technologies, such as hybrid exhibitions) can be used as a means to increase attractiveness and public engagement.<br />
<br />
<h2 style="font-style: normal; font-variant: normal; line-height: 29.9999980926514px;"><strong><span style="font-family: Arial, Helvetica, sans-serif; font-size: 24px; line-height: 29.9999980926514px;"> Goals </span></strong></h2><br />
<br />
* Define Web3D Consortium strategic goals for open standards for Archival and Retrieval of cultural and natural heritage objects <br />
* Discuss data size, work flows, scanning, processing tools, publications and best practices <br />
* Characterize Cultural Heritage requirements and activities by museums, anthroplogy and government agencies<br />
<br />
<h2 style="font-style: normal; font-variant: normal; line-height: 29.9999980926514px;"><strong><span style="font-family: Arial, Helvetica, sans-serif; font-size: 24px; line-height: 29.9999980926514px;"> Events </span></strong></h2><br />
<br />
There will be a workshop at [http://web3d2015.web3d.org/workshops.html Web3D 2015] about Cultural and Natural Heritage. Go to the link to get all the information about submission!.<br />
<br />
<h2 style="font-style: normal; font-variant: normal;"><strong><span style="font-family: Arial, Helvetica, sans-serif; font-size: 24px; ">Working Group Resources</span></strong></h2><ul><li>Web3D Consortium Home Page examples (in X3DOM): <br />
[http://www.web3d.org/example/cultural-heritage-preservation Museums &amp; Artifacts], <br />
[http://www.web3d.org/example/cathedral-siena-italy Buildings / Structures]</li><br />
<li>CSIRO's insect collection ([http://tv.csiro.au/?v=xbz189zsuhn8 video], [http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0094346 paper], [http://www2.ala.org.au/chuong examples])</li><br />
<li>[http://metagrid1.sv.vt.edu/~npolys/SI3D/ Smithsonian 3D models] processed by Virginia Tech &amp; Fraunhofer IGD to X3DOM compressed geometry</li><br />
<li>Fraunhofer IGD's [http://www.cultlab3d.eu CultLab object acquisition system]</li><br />
<li>Geometry processing tool [http://www.meshlab.org/ Meshlab] (EU, open source)</li><br />
<li>Web3D 2015 Workshop (linked at bottom of page)&nbsp; - [http://web3d2014.web3d.org/workshops/ slides &amp; videos]</li><li>SIGGRAPH 2014 BOF [[sig14heritage]] slides</li><br />
<li>[http://www.x3dom.org/?p=3517 Digital Heritage 2013 slides] (X3DOM)</li></ul></div>Webmasterhttps://www.web3d.org/wiki/index.php?title=Heritage&diff=8925Heritage2015-05-19T17:51:35Z<p>Webmaster: Created page with " '''The Cultural and Natural Heritage Working Group''' is developing an open interoperable standard for the Archival and Retrieval of cultural heritage and natural objects ..."</p>
<hr />
<div><br />
<br />
'''The Cultural and Natural Heritage Working Group''' is developing an open interoperable standard for the Archival and Retrieval of cultural heritage and natural objects based on input from a wide variety of imaging modalities.<br />
<br />
Millions of cultural heritage artifacts populate our museums and about 90% still await discovery in museum archives. In addition there are millions of natural objects, such as insects, hidden in museum drawers. 3D Digital models can provide arbitrary availability and concurrent access to digital alternates of heritage artifacts for historians and scientists. Moreover, virtual presentations (combined with new forms of presentation technologies, such as hybrid exhibitions) can be used as a means to increase attractiveness and public engagement.<br />
<br />
<h2 style="font-style: normal; font-variant: normal; line-height: 29.9999980926514px;"><strong><span style="font-family: Arial, Helvetica, sans-serif; font-size: 24px; line-height: 29.9999980926514px;"> Goals </span></strong></h2><br />
<br />
* Define Web3D Consortium strategic goals for open standards for Archival and Retrieval of cultural and natural heritage objects <br />
* Discuss data size, work flows, scanning, processing tools, publications and best practices <br />
* Characterize Cultural Heritage requirements and activities by museums, anthroplogy and government agencies<br />
<br />
<h2 style="font-style: normal; font-variant: normal; line-height: 29.9999980926514px;"><strong><span style="font-family: Arial, Helvetica, sans-serif; font-size: 24px; line-height: 29.9999980926514px;"> Events </span></strong></h2><br />
<br />
There will be a workshop at [http://web3d2015.web3d.org/workshops.html Web3D 2015] about Cultural and Natural Heritage. Go to the link to get all the information about submission!.<br />
<br />
<h2 style="font-style: normal; font-variant: normal;"><strong><span style="font-family: Arial, Helvetica, sans-serif; font-size: 24px; ">Working Group Resources</span></strong></h2><ul><li>Web3D Consortium Home Page examples (in X3DOM): <br />
[http://www.web3d.org/example/cultural-heritage-preservation Museums &amp; Artifacts], <br />
[http://www.web3d.org/example/cathedral-siena-italy Buildings / Structures]</li><br />
<li>CSIRO's insect collection ([http://tv.csiro.au/?v=xbz189zsuhn8 video], [http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0094346 paper], [http://www2.ala.org.au/chuong examples])</li><br />
<li>[http://metagrid1.sv.vt.edu/~npolys/SI3D/ Smithsonian 3D models] processed by Virginia Tech &amp; Fraunhofer IGD to X3DOM compressed geometry</li><br />
<li>Fraunhofer IGD's [http://www.cultlab3d.eu CultLab object acquisition system]</li><br />
<li>Geometry processing tool [http://www.meshlab.org/ Meshlab] (EU, open source)</li><br />
<li>Web3D 2015 Workshop (linked at bottom of page)&nbsp; - [http://web3d2014.web3d.org/workshops/ slides &amp; videos]</li><li>SIGGRAPH 2014 BOF [[sig14heritage]] slides</li><br />
<li>[http://www.x3dom.org/?p=3517 Digital Heritage 2013 slides] (X3DOM)</li></ul></div>Webmasterhttps://www.web3d.org/wiki/index.php?title=Main_Page&diff=8924Main Page2015-05-19T17:50:32Z<p>Webmaster: Removed 'X3D' from shorthand group name (per charter)</p>
<hr />
<div>== Community Wiki ==<br />
<br />
Nearby: [http://www.web3d.org Web3D home], [http://www.web3d.org/realtime-3d/news-events Web3D events], and new [http://www.web3d.org/realtime-3d/member/wiki/Main Web3D Members-Only Wiki], and [http://www.web3d.org/wiki/index.php/Web3D_2014_Workshops_on_X3D_Evolution/Revolution Web3D 2014 Workshops]<br />
<br />
Please [http://www.web3d.org/contact?target=webSite Contact the WebMaster] if you need access to the wiki.<br />
<br />
__TOC__<br />
<br />
== Web3D and SIGGRAPH 2014 Conference Events ==<br />
<br />
These pages serve as the basis for meeting discussion and minutes<br />
<br />
* [[Web3D 2014 Workshops on X3D Evolution/Revolution]]<br />
* [[DIY X3D: Learning Teaching and Doing X3D Graphics with HTML5]]<br />
<br />
== Active X3D Working Groups: Public Pages ==<br />
<br />
=== X3D Working Group ===<br />
* The X3D Working Group ([http://www.web3d.org/realtime-3d/working-groups/x3d executive summary]) is the main forum for coordinating all X3D specification activities, including other working groups.<br />
* This group also performs future X3D design, resolution of X3D specification comments, and review of X3D implementation resources.<br />
* Working group teleconferences are every Wednesday at 08-0900 pacific time, 16-1700 GMT on the Web3D teleconference line.<br />
* Cochairs: Don Brutzman and Leonard Daly<br />
* ISO Convener: Dick Puk<br />
<br />
=== Current activities: JSON, Binary Compression, X3D v3.4 and v4.0, etc. === <br />
* [[X3D JSON Encoding]]<br />
* [[X3D Binary Compression Capabilities and Plans]]<br />
* [[X3D Development Public Plans]] (contains public statements and links for the items below)<br />
** [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/X3D.html X3D version 3.3] has been finalized as an ISO International Standard (IS). The text has been sent to ISO/IEC for final ballot.<br />
*** [http://www.web3d.org/realtime-3d/member/wiki/x3d-v33-specification-changes X3D v3.3 Specification Changes] (members-only document<!--, formerly [http://www.web3d.org/membership/login/memberwiki/index.php/X3D_v3.3_Specification_Changes X3D v3.3 Specification Changes]-->) includes relevant information on deferred capabilities.<br />
** [[X3D version 3.4 Development]] efforts are evolutionary improvements to the proven X3D Graphics architecture.<br />
*** Working groups and individual contributions are currently defining future goals and requirements.<br />
** [[X3D version 4.0 Development]] efforts are considering potentially major additions to the baseline X3D architecture.<br />
*** Major technology under consideration: HTML5/Declarative 3D/X3DOM<br />
*** Major technology under consideration: Mixed and Augmented Reality (MAR) Continuum (formerly ARC)<br />
*** Please [http://www.web3d.org/realtime-3d/contact contact Web3D Consortium] or [http://www.web3d.org/realtime-3d/page/contact/x3d-chairs contact X3D cochairs] if you think additional technologies need to be considered.<br />
*** X3D futures planning is currently a Web3D Consortium member-only activity.<br />
* [[X3D MIME-Type]] in X3D Working Group to get official IETF MIME-Type recognition for X3D<br />
** This has been completed. The IETF listing is at [http://www.iana.org/assignments/media-types/media-types.xhtml#model]<br />
<br />
=== Access and Participation ===<br />
<br />
Many Web3D technical efforts are visible to the public. Some are restricted to Web3D Consortium members. Membership has value.<br />
<br />
* Web3D Consortium members are allowed to decide on specification priorities and whether new technology is accepted for our royalty-free X3D International Standard.<br />
* The general public is allowed to observe and comment at various stages of development.<br />
* Some working group activities are fully open, some activities are performed by Web3D Consortium members only.<br />
* Web3D Consortium members have agreed to the [http://web3d.org/membership/join Intellectual Property Rights (IPR) Policy] which effectively prevents any royalty-based technology from being adopted by X3D.<br />
* This approach provides great value to the public, and also allows both companies and individual professionals to contribute to X3D directly as Web3D Consortium members.<br />
* Meanwhile, each working group can still decide to place some work in the open and some with restricted access. For example, all HTML5/X3DOM work is completely in the open.<br />
* For private member-only communications, Web3D Members can also use the [http://www.web3d.org/membership/login/memberwiki/index.php/Main_Page Web3D Members-Only Wiki].<br />
<br />
=== [[X3D and Augmented Reality]] Continuum (ARC) Working Group: AR Extensions for X3D ===<br />
<br />
* The Augmented Reality (AR) Working Group was formed to address the needs of projecting computer generated information into the real world. The Working Group focuses on utilizing and extending X3D capabilities to support augmented reality (AR) and mixed reality (MR) applications.<br />
* [http://www.web3d.org/realtime-3d/working-groups/augmented-reality-ar X3D and Augmented Reality working group summary]<br />
* [[X3D and Augmented Reality]] wiki<br />
* Members are also participating in efforts by the ISO SC24 Working Group 9 for Augmented Reality Continuum (ARC)<br />
<br />
=== [[X3D CAD]] Working Group: Computer Aided Design (CAD) Extensions for X3D ===<br />
<br />
* The X3D CAD Working Group is now in its third generation of development effort. We are developing and demonstrating best practices for exporting any CAD model to X3D for Web applications.<br />
* [http://www.web3d.org/realtime-3d/working-groups/computer-aided-design-cad Computer Aided Design (CAD) working group summary]<br />
* [[X3D CAD]] working group wiki<br />
<br />
=== [[X3D Earth Working Group]] for geospatial representations ===<br />
* The X3D Earth Working Group uses the Web architecture, XML languages, and open protocols to build a standards-based X3D Earth specification usable by governments, industry, scientists, academia, and the general public. X3D-Earth efforts encompass client-side, server-side, authoring, and conversion technologies.<br />
''Vision:'' Make it easier to create and use 3D spatial data.<br />
''Mission.'' Promote spatial data use within X3D via open architectures.<br />
* [http://www.web3d.org/realtime-3d/working-groups/x3d-earth X3D Earth working group summary]<br />
* [[X3D Earth Working Group]] wiki<br />
<br />
=== X3D [[H-Anim]] Working Group: Humanoid Animation (H-Anim) ===<br />
* The Humanoid Animation (H-Anim) standard supports representative human models incorporating open best practices of haptic and kinematic interfaces and a certain default skeleton pose in order to enable shared animations.<br />
* There are corresponding documents for [http://www.web3d.org/files/specifications/19774/V1.0/index.html Humanoid Animation (H-Anim)] abstract specification and [http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/hanim.html X3D Humanoid Animation component].<br />
* [http://www.web3d.org/realtime-3d/working-groups/h-anim H-Anim working group summary]<br />
* [[H-Anim]] wiki<br />
<br />
=== [[X3D Medical]] Working Group: Volume visualization and Medical uses ===<br />
* The Medical Working Group is developing an open interoperable standard for the representation of human anatomy based on input from a wide variety of imaging modalities.<br />
* [http://www.web3d.org/realtime-3d/working-groups/medx3d X3D Medical working group summary]<br />
* [[X3D Medical]] wiki<br />
<br />
=== [[Heritage]] Working Group: Cultural Heritage and Natural History ===<br />
<br />
* Initial efforts are following up on really interesting keynote presentation and workshop discussions at the Web3D 2014 Symposium.<br />
<br />
----<br />
<br />
== X3D Special Interest Groups: Public Pages ==<br />
X3D Special Interest groups are open to anyone interested in participating. <br />
This open approach provides great value to the public to explore new technologies and applications for X3D. It also allows both companies and individuals to contribute some technologies towards moving the X3D standard forward. <br />
<!-- none yet: * [[X3D and Networking]] Special Interest Group efforts --><br />
<!-- * [[X3D Mobile]] Working Group efforts --><br />
<br />
=== [[Xj3D Evolution]] ===<br />
<br />
Renewed open-source community effort.<br />
<br />
=== [[X3D and HTML5]] design efforts and [http://www.w3.org/community/declarative3d Declarative 3D Community Group] ===<br />
Numerous efforts are working to establish a solid foundation for proper X3D graphics support in HTML5. <br />
* [http://www.w3.org/community/declarative3d Declarative 3D Community Group] efforts include integration of Declarative 3D requirements as part of X3D version 4.0 design<br />
* [[X3D and HTML5]] wiki lists a wide variety of techniques for authors creating Web content<br />
<br />
=== [[X3D and E-Learning]] ===<br />
<br />
Special Interest Group efforts are discussed on the X3D mailing list.<br />
<br />
== About X3D ==<br />
* [http://www.web3d.org/about/overview/ What is X3D]<br />
** [http://www.web3d.org/about/faq/ X3D/VRML FAQ]<br />
** [[X3D and HTML FAQ]]<br />
* [[Features and Strengths of X3D]]<br />
* [[Industry Adopters]]<br />
* [http://www.web3d.org/membership/join/ Get Involved!]<br />
* [[Interviews and Outreach]]<br />
* [[Recent Events]]<br />
<br />
== X3D Community Information==<br />
* [[Player support for X3D components]]<br />
* [[Tool support for X3D components]]<br />
* [[X3D Plugfest]] to improve interoperability between X3D players<br />
* [[X3D Implementations]]<br />
<br />
== Technology Contributions ==<br />
<br />
The Web3D Consortium is always happy to receive proposals for [[Technology Contributions]] that might help to advance 3D graphics on the Web.<br />
<br />
== X3D Resources ==<br />
* [http://www.web3d.org/x3d/content/examples/X3dResources.html X3D Resources] provides comprehensive links to many X3D applications, sources and capabilities<br />
* [http://www.web3d.org/x3d/content/examples/X3dResources.html#Tooltips X3D Tooltips] provides multilingual details on the X3D vocabulary<br />
* [[How-To Guides]] and [[Node Reference]]<br />
* [http://www.web3d.org/x3d/specifications/ X3D Specifications] provides public copies of all Web3D specification work<br />
* [[Player support for X3D components]] and [[Tool support for X3D components]]<br />
* [[Plug-in and browser compliance]]<br />
* [[Recommendations for browser developers]]<br />
<br />
== Web3D Chapters ==<br />
Official Chapters (geographically oriented) of the Web3D Consortium<br />
<br />
* [http://web3d.kr Web3D Consortium Korea Chapter]<br />
* [[Korea Chapter Public Wiki]]<br />
* Nearby: [http://www.web3d.org/membership/login/memberwiki/index.php/Korea_Chapter_Members-Only_Wiki Korea Chapter Members-Only Wiki]<br />
<br />
== About the Public and Members-Only X3D Wiki ==<br />
* [[Usage Guidelines]]<br />
* [[How to wiki]]<br />
* [[Create New Page]]<br />
* [http://www.web3d.org/membership/login/memberwiki/index.php/Main_Page Web3D Members-Only Wiki]<br />
<br />
Administrative notes: <br />
* '''If you need an account on this wiki''', please [http://www.web3d.org/contact?target=webSite contact the Webmaster] and include 'Wiki Account' in the subject.<br />
* Because of some reported abuse to existing members, creation of all new accounts have been '''disabled'''. This state will continue until a better means of identifying members has been established.<br />
* SysAdmin Note: WikiMedia software upgraded to latest version (9 Jan 2013).</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_JSON_Encoding&diff=8828X3D JSON Encoding2015-04-08T16:07:04Z<p>Webmaster: /* Discussion points */</p>
<hr />
<div>These are X3D Working Group notes on the creation of an X3D JSON encoding and a corresponding conversion process.<br />
<br />
== Design Requirements, Goals and Use Cases ==<br />
<br />
Design requirement:<br />
* Round-trippable encoding supporting X3D abstract specification<br />
<br />
Design goals and primary use cases:<br />
* Exchange format for a variety of 3D geometry and scene graphs<br />
* Loader for various JavaScript-controlled renderers<br />
* Manipulate a scene graph using JavaScript<br />
<br />
Are there any special use cases for having X3D JSON available in JavaScript?<br />
* Are there any use cases that might modify how X3D is represented in JSON?<br />
* If so, it would be good to spell them out and understand them well.<br />
* We want conversion rules to permit implementations that can achieve user goals.<br />
<br />
== Initial implementations ==<br />
<br />
* Experimental [http://www.web3d.org/x3d/stylesheets/X3dToJson.xslt X3dToJson.xslt] stylesheet converts .x3d into .json encoding. In version control at [https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/X3dToJson.xslt sourceforge]<br />
** Current work: lists of comments; field/fieldValue representations for Scripts and prototypes<br />
* Embedded in [https://savage.nps.edu/X3D-Edit/ X3D-Edit] for testing<br />
* Initial Hello World examples deployed ([http://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorld.x3d .x3d]) ([http://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorld.html .html]) ([http://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorld.xhtml x3dom .xhtml]) ([http://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorld.json .json])<br />
* Conversion syntax discussions continue on [http://web3d.org/pipermail/x3d-public_web3d.org/2014-October/002981.html x3dom-developers mail list] (with [http://www.x3dom.org/x3dom/test/functional/flipper.html "dump scene as json" test] by Dr. Yvonne Jung)<br />
* X3D Examples include build scripts to convert .x3d to .json, then perform [http://www.jslint.com jslint] validation<br />
<br />
== Conversion Considerations ==<br />
<br />
Primary design criterion: round-trippable lossless representation of X3D scene.<br />
<br />
Conversion approach of greatest practical interest: XML to/from JSON. Issues:<br />
<br />
# How to convert attribute names to distinguish them from child elements. Resolution: "@attributeName".<br />
# JSON handling of container elements to preserve parent/child relationships, distinguishing child elements from attributes Resolution: use SFNode/MFNode field names as unique keys.<br />
# Creation of JSON elements with datatypes appropriate to content (e.g., integer, float, strings, etc.). Note special JSON rules for floats (not equivalent to IEEE floats).<br />
# Both X3D and JSON can include comments, and so need an option for inclusion (by default) or removal (optional) of comments in order to ensure 100% round-trip conversion capabilities. <br />
# jslint-validatable field/fieldValue representations within Scripts and prototypes <br />
# Support for singleton (self-closing) XML tags also needs to be considered, without loss of generality.<br />
# Inclusion and preservation of embedded XML namespace information in an XML (.x3d) document: might not be necessary or possible.<br />
<br />
== Standardization ==<br />
<br />
Probably smartest to first start out defining an X3D best practice.<br />
<br />
This capability likely needs to be defined as one of the [http://www.web3d.org/standards X3D standards] as shown in the [http://www.web3d.org/specifications/X3dSpecificationRelationships.png X3D Specification Relationships] diagram.<br />
<br />
The most probable place to put it is as a new Part 5 to ISO/IEC 19776. In this manner, it would correspond to the XML, Classic VRML, and Compressed Binary encodings.<br />
<br />
== Discussion points ==<br />
<br />
Here are suggested discussion points for X3D teleconferences and future followups.<br />
<br />
# Is there a good/consistent way for X3DOM to utilize such capabilities?<br />
# Is there a way for [http://threejs.org Three.js] X3D loader, [http://d3js.org D3.js] X3D loader, or other javascript libraries, to utilize such capabilities?<br />
# Is there a single authoritative reference for JSON itself? and for JSON-XML conversions? See [6] for the JSON Data Interchange Format, need to confirm no others.<br />
# What is the right file extension? .json is distinguishable from .js used in plain Javascript in Script code; .x3dj distinguishes X3D JSON<br />
## [http://en.wikipedia.org/wiki/JSON Wikipedia] (referencing ECMA) states that <code>.json</code> is the standard extension<br />
## Internet MIME-type is <code>application/json</code><br />
# Can a file reader distinguish the incoming encodings (.x3d .x3dv .x3db .x3de .json/.x3dj) independent of file extension or MIME media type?<br />
# Once a canonical form for X3D as JSON is established, add conversion capabilities to X3D-Edit and also autoconvert, test and publish JSON for all of the 3800+ scenes in the [http://www.web3d.org/x3d-resources/content/examples/X3dResources.html#Examples X3D Examples Archives]<br />
# Compare compression size and decompression speed of a TestMesh.x3d.json.gz to TestMesh.x3db and TestMesh.x3d.exi (EXI will likely win because it includes data typing)<br />
<br />
Probably lots more... What else?<br />
<br />
== References ==<br />
<br />
* XML to JSON Converter (provides option to assign a prefix to JSON attributes, default is @ character) http://www.freeformatter.com/xml-to-json-converter.html<br />
* Apache Camel, XML JSON Data Format (camel-xmljson) [http://camel.apache.org/xmljson.html<br />
* JavaScript Object Notation (JSON) Definition http://json.org<br />
* ECMA 404: JSON Data Interchange Format (Final Draft) http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf<br />
* JSON Markup Language (JsonML) http://www.jsonml.org/<br />
* XSLTJSON: Transforming XML to JSON using XSLT http://www.bramstein.com/projects/xsltjson<br />
* Converting Between XML and JSON http://www.xml.com/pub/a/2006/05/31/converting-between-xml-and-json.html<br />
* XML/JSON Perl Converter http://search.cpan.org/~ken/XML-XML2JSON-0.06/lib/XML/XML2JSON.pm<br />
* IBM's PHP converter http://www.ibm.com/developerworks/library/x-xml2jsonphp<br />
* Java Converter http://www.json.org/javadoc/org/json/XML.html<br />
* Google Code Library https://code.google.com/p/x2js<br />
<br />
'''Mailing list discussions'''<br />
* Initial message [http://web3d.org/pipermail/x3d-public_web3d.org/2014-July/002854.html]<br />
* July's thread listing [http://web3d.org/pipermail/x3d-public_web3d.org/2014-July/thread.html]<br />
* Ongoing on [http://www.web3d.org/mailman/listinfo/x3d-public_web3d.org x3d-public mailing list], occasionally on [http://www.x3dom.org/?page_id=3 x3dom mailing list]</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_JSON_Encoding&diff=8825X3D JSON Encoding2015-04-08T16:03:55Z<p>Webmaster: /* Discussion points */</p>
<hr />
<div>These are X3D Working Group notes on the creation of an X3D JSON encoding and a corresponding conversion process.<br />
<br />
== Design Requirements, Goals and Use Cases ==<br />
<br />
Design requirement:<br />
* Round-trippable encoding supporting X3D abstract specification<br />
<br />
Design goals and primary use cases:<br />
* Exchange format for a variety of 3D geometry and scene graphs<br />
* Loader for various JavaScript-controlled renderers<br />
* Manipulate a scene graph using JavaScript<br />
<br />
Are there any special use cases for having X3D JSON available in JavaScript?<br />
* Are there any use cases that might modify how X3D is represented in JSON?<br />
* If so, it would be good to spell them out and understand them well.<br />
* We want conversion rules to permit implementations that can achieve user goals.<br />
<br />
== Initial implementations ==<br />
<br />
* Experimental [http://www.web3d.org/x3d/stylesheets/X3dToJson.xslt X3dToJson.xslt] stylesheet converts .x3d into .json encoding. In version control at [https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/X3dToJson.xslt sourceforge]<br />
** Current work: lists of comments; field/fieldValue representations for Scripts and prototypes<br />
* Embedded in [https://savage.nps.edu/X3D-Edit/ X3D-Edit] for testing<br />
* Initial Hello World examples deployed ([http://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorld.x3d .x3d]) ([http://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorld.html .html]) ([http://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorld.xhtml x3dom .xhtml]) ([http://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorld.json .json])<br />
* Conversion syntax discussions continue on [http://web3d.org/pipermail/x3d-public_web3d.org/2014-October/002981.html x3dom-developers mail list] (with [http://www.x3dom.org/x3dom/test/functional/flipper.html "dump scene as json" test] by Dr. Yvonne Jung)<br />
* X3D Examples include build scripts to convert .x3d to .json, then perform [http://www.jslint.com jslint] validation<br />
<br />
== Conversion Considerations ==<br />
<br />
Primary design criterion: round-trippable lossless representation of X3D scene.<br />
<br />
Conversion approach of greatest practical interest: XML to/from JSON. Issues:<br />
<br />
# How to convert attribute names to distinguish them from child elements. Resolution: "@attributeName".<br />
# JSON handling of container elements to preserve parent/child relationships, distinguishing child elements from attributes Resolution: use SFNode/MFNode field names as unique keys.<br />
# Creation of JSON elements with datatypes appropriate to content (e.g., integer, float, strings, etc.). Note special JSON rules for floats (not equivalent to IEEE floats).<br />
# Both X3D and JSON can include comments, and so need an option for inclusion (by default) or removal (optional) of comments in order to ensure 100% round-trip conversion capabilities. <br />
# jslint-validatable field/fieldValue representations within Scripts and prototypes <br />
# Support for singleton (self-closing) XML tags also needs to be considered, without loss of generality.<br />
# Inclusion and preservation of embedded XML namespace information in an XML (.x3d) document: might not be necessary or possible.<br />
<br />
== Standardization ==<br />
<br />
Probably smartest to first start out defining an X3D best practice.<br />
<br />
This capability likely needs to be defined as one of the [http://www.web3d.org/standards X3D standards] as shown in the [http://www.web3d.org/specifications/X3dSpecificationRelationships.png X3D Specification Relationships] diagram.<br />
<br />
The most probable place to put it is as a new Part 5 to ISO/IEC 19776. In this manner, it would correspond to the XML, Classic VRML, and Compressed Binary encodings.<br />
<br />
== Discussion points ==<br />
<br />
Here are suggested discussion points for X3D teleconferences and future followups.<br />
<br />
# Is there a good/consistent way for X3DOM to utilize such capabilities?<br />
# Is there a way for [http://threejs.org Three.js] X3D loader, [http://d3js.org D3.js] X3D loader, or other javascript libraries, to utilize such capabilities?<br />
# Is there a single authoritative reference for JSON itself? and for JSON-XML conversions? See [6] for the JSON Data Interchange Format, need to confirm no others.<br />
# What is the right file extension? .json is distinguishable from .js used in plain Javascript in Script code; .x3dj distinguishes X3D JSON<br />
## [http://en.wikipedia.org/wiki/JSON Wikipedia] (referencing ECMA) states that .json is the standard extension<br />
## Internet MIME-type is application/json<br />
# Can a file reader distinguish the incoming encodings (.x3d .x3dv .x3db .x3de .json/.x3dj) independent of file extension or MIME media type?<br />
# Once a canonical form for X3D as JSON is established, add conversion capabilities to X3D-Edit and also autoconvert, test and publish JSON for all of the 3800+ scenes in the [http://www.web3d.org/x3d-resources/content/examples/X3dResources.html#Examples X3D Examples Archives]<br />
# Compare compression size and decompression speed of a TestMesh.x3d.json.gz to TestMesh.x3db and TestMesh.x3d.exi (EXI will likely win because it includes data typing)<br />
<br />
Probably lots more... What else?<br />
<br />
== References ==<br />
<br />
* XML to JSON Converter (provides option to assign a prefix to JSON attributes, default is @ character) http://www.freeformatter.com/xml-to-json-converter.html<br />
* Apache Camel, XML JSON Data Format (camel-xmljson) [http://camel.apache.org/xmljson.html<br />
* JavaScript Object Notation (JSON) Definition http://json.org<br />
* ECMA 404: JSON Data Interchange Format (Final Draft) http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf<br />
* JSON Markup Language (JsonML) http://www.jsonml.org/<br />
* XSLTJSON: Transforming XML to JSON using XSLT http://www.bramstein.com/projects/xsltjson<br />
* Converting Between XML and JSON http://www.xml.com/pub/a/2006/05/31/converting-between-xml-and-json.html<br />
* XML/JSON Perl Converter http://search.cpan.org/~ken/XML-XML2JSON-0.06/lib/XML/XML2JSON.pm<br />
* IBM's PHP converter http://www.ibm.com/developerworks/library/x-xml2jsonphp<br />
* Java Converter http://www.json.org/javadoc/org/json/XML.html<br />
* Google Code Library https://code.google.com/p/x2js<br />
<br />
'''Mailing list discussions'''<br />
* Initial message [http://web3d.org/pipermail/x3d-public_web3d.org/2014-July/002854.html]<br />
* July's thread listing [http://web3d.org/pipermail/x3d-public_web3d.org/2014-July/thread.html]</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_Binary_Compression_Capabilities_and_Plans&diff=8737X3D Binary Compression Capabilities and Plans2015-02-11T17:24:38Z<p>Webmaster: /* Call For Contributions */</p>
<hr />
<div>==Motivation==<br />
Lots of work has already been accomplished using the X3D Compressed Binary Encoding (CBE) standard.<br />
<br />
X3D has numerous coherent approaches already available that meet author requirements for a general Web-based 3D transmission format.<br />
<br />
We are working to demonstrate and standardize multiple interoperable improvements in 2013.<br />
<br />
==Strategy, 2013-2014==<br />
* We reviewed several goals and developmental capabilities at the [http://www.web3d2013.org Web3D 2013 Conference] in June 2013.<br />
* We accomplished our strategic goal to define X3D Compressed Binary Encoding (CBE) requirements and plan next steps during 2013.<br />
* We are now soliciting and reviewing multiple contributions to possibly accomplish all of these efforts during calendar year 2014.<br />
<br />
==Call For Contributions==<br />
X3D solutions currently support a wide range of author requirements. <br />
Further improvements and standards-based partnerships are possible for achieving broader industry interoperability. <br />
<br />
The [http://www.web3d.org/working-groups/x3d/compressed-binary-encoding-activity X3D Compressed Binary Encoding Call For Contributions] to help accomplish these achievable goals has been released. We are seeking next-generation improvements that further advance the technical capabilities of the X3D Graphics International Standard.<br />
<br />
'''Prior work is essential, useful and relevant.'''<br />
* The first-generation [http://www.web3d.org/x3d/binary/X3dBinaryRFP.html X3D Compressed Binary Encoding Request For Proposals (RFP)] (currently unavailable) from August 2003 illustrates this steady evolution. <br />
* The first-generation process successfully created the current [http://www.web3d.org/files/specifications/19776-3/V3.2/Part03/X3D_Binary.html X3D Compressed Binary Encoding (CBE)] International Standard.<br />
'''All submitters must meet certain requirements prior to consideration.'''<br />
* The [http://www.web3d.org/realtime-3d/about/legal Intellectual Property Rights (IPR)] protections for X3D specification.<br />
* Patented technologies can be considered, but only when eventual use will be royalty free for X3D use (if eventually accepted).<br />
* Submitters can restrict access to patented submissions during member-only working group review, if desired.<br />
<br />
== Existing Compression Usage for X3D and VRML97 ==<br />
A solid foundation exists for continued progress.<br />
* Approved ISO standard [http://www.web3d.org/files/specifications/19776-3/V3.2/Part03/X3D_Binary.html Compressed Binary Encoding (CBE) for X3D].<br />
** Based on ISO standard [http://fi.java.net Fast Infoset (FI)] for XML compression.<br />
* Optional, alternative gzip compression and MIME Type definitions for X3D.<br />
** XML encoding ([http://www.web3d.org/files/specifications/19776-1/V3.2/Part01/concepts.html#X3DFilesAndTheWorldWideWeb .x3dz/.x3d.gz]), ClassicVRML encoding ([http://www.web3d.org/files/specifications/19776-2/V3.2/Part02/concepts.html#ClassicVRMLEncodedX3DFilesAndWWW .x3dvz/.x3dv.gz]) and Compressed Binary encoding ([http://www.web3d.org/files/specifications/19776-3/V3.1/Part03/concepts.html#X3DFilesAndTheWorldWideWeb .x3db.gz]) file extensions.<br />
* Optional, alternative gzip compression for VRML97.<br />
** Original compression technique of applying gzip to .wrl compressed VRML97 files was called .wrz.<br />
** This emerged as a common practice when gzip was originally used. No formal specification of .wrz or corresponding mime type was produced.<br />
** Occasionally authors might also gzip .wrl files while retaining the .wrl file extension.<br />
<br />
Multiple X3D compressed binary encoding (CBE) codebases exist for producing .x3db scenes under the existing standard. However, conformance interoperability between different implementations is not well tested.<br />
<br />
'''Web3D will not formally advance a next-generation X3D binary compression format as a candidate standard until current interoperability has been satisfactorily demonstrated for the existing standard.'''<br />
<br />
== Polygon Reduction and Geometric Compression ==<br />
Formal specifications:<br />
* The X3D Compressed Binary Encoding defines extensible, repeatable [http://www.web3d.org/files/specifications/19776-3/V3.2/Part03/concepts.html#X3DCompressionDataFlow compression] and [http://www.web3d.org/files/specifications/19776-3/V3.2/Part03/concepts.html#X3DDecompressionDataFlow decompression] algorithms for [http://www.web3d.org/files/specifications/19776-3/V3.2/Part03/concepts.html#OverviewIntroduction data-flow production chains]. Multiple type-specific [http://www.web3d.org/files/specifications/19776-3/V3.1/Part03/EncodingOfFields.html field encoders] and geometric compression algorithms can be used in concert, but no specific geometric compression algorithms are referenced or required.<br />
* [http://www.web3d.org/files/specifications/19776-3/V3.2/Part03/concepts.html#X3DCanonicalForm X3D Canonicalization (C14N)] provides standardized formatting so that digital signatures are not thwarted by whitespace variations.<br />
Best practices and examples:<br />
* [http://www.web3d.org/x3d/workgroups/cad CAD Distillation Filter (CDF)] technique allowing successive refinement of large X3D scenes into tighter X3D scenes.<br />
* A highly effective exemplar algorithm for [http://www.cs.unc.edu/~isenburg/research/asciicoder Coding Polygon Meshes as Compressable ASCII] is demonstrated in the [http://www.web3d.org/x3d/content/examples/Basic/ExperimentalBinaryCompression Experimental Binary Compression examples].<br />
* Multiple CAD Distillation Filter (CDF) algorithms implemented in [http://www.xj3d.org Xj3D] and [https://savage.nps.edu/X3D-Edit X3D-Edit] as open-source.<br />
* The [http://www2.hrp.no/vr/tools/chisel/install.htm Chisel VRML Optimisation Tool] has an excellent set of data-reduction tools for VRML that are worth repeating for X3D.<br />
* Multiple other [http://www.web3d.org/x3d/content/examples/X3dResources.html#Conversions conversion and translation tools] available with supporting capabilities.<br />
* Following submission of candidate technologies, we will build a table of 3D graphics compression benchmark results, providing a full comparison of existing tools (compression ratio, computational complexity, memory usage, etc.)<br />
* MPEG4 capabilities are welcome, if IPR prerequisites are met. Discussion to date has indicated that Royalty Free (RF) solutions are not available.<br />
* Related efforts reported in academic papers and Web3D conferences need to be reviewed and reflected here<br />
<br />
== Data-Centric Binary Encodings ==<br />
The X3D Compressed Binary Encoding (CBE) uses the ISO Fast Infoset (FI) standard to compress XML information, which is how the CBE maintains equivalent expressive power with other X3D scene encodings.<br />
* Plan to add a further-improved X3D Compressed Binary Encoding using now-approved W3C Recommendation for [http://www.w3.org/TR/exi/ Efficient XML Interchange (EXI)].<br />
* Web3D contributed to [http://www.w3.org/XML/EXI/ EXI working group] and [http://www.w3.org/XML/Binary XML Binary Characterization working group] efforts.<br />
** [http://www.w3.org/TR/xbc-use-cases/#x3dtrans 3D Model Compression, Serialization and Transmission] use-case requirements are defined and met by EXI.<br />
* Design includes compatibility with CDF techniques, [http://www.w3.org/TR/xmlenc-core XML Encryption], and [http://www.w3.org/TR/xmldsig-core/ XML Digital Signature] for author authentication.<br />
** Relevant example scenes maintained as part of [http://www.web3d.org/x3d/content/examples/Basic/Security X3D Basic Examples Archive - Security].<br />
* These capabilities meets most needs of digital authors for digital rights management (DRM).<br />
* '''Review Open Geospatial Consortium (OGC) requirements to determine whether additional optimizations might improve the already-excellent coverage of geospatial datasets'''<br />
** Also explore the possibility that additional compression algorithms may show better efficiency for geospatial datasets<br />
* Following submission of candidate technologies, we will build a table of data compression benchmark results, providing a full comparison of existing tools (compression ratio, computational complexity, memory usage, etc.)<br />
<br />
== Network Streaming ==<br />
* Multiple capabilities are already available in X3D for flexible network transmission.<br />
** Anchor, Inline, LOD, LoadSensor, Script and Prototype nodes support successive retrieval of content once initial model is displayed.<br />
* Progressive-mesh geometric streaming technologies hold definite interest. Mesh-compression algorithms that can be applied to existing X3D polygonal data will be the most valuable.<br />
* Need to demonstrate whether http/https and local-file url retrieval are sufficient for a network protocol for use cases of interest.<br />
** Other network protocols (Web sockets, P2P channels, etc.) might be possible or needed, but only if security restrictions and implementation/deployment can be handled satisfactorily.<br />
* Javascript Object Notation (JSON) might be suitable for simple streaming of X3D scene-graph data via Script node or external HTML page, which can be useful for progressive mesh and other incremental network-update approaches.<br />
** Support in clients and servers is becoming widely available.<br />
** JSON might have other uses as well, see Khronos work on [https://github.com/KhronosGroup/glTF/blob/master/specification/README.md Collada2JSON and glTF]. This is an active area of work.<br />
<br />
== Resource Bundling ==<br />
* Mechanisms for bundling multiple files (e.g. X3D scene, Inlined subscenes, image files, audio and video files, etc.) into a single archive file will be considered.<br />
* Similar bundling capabilities are emerging for uncompressed X3D scenes embedded within HTML pages.<br />
* Benefits support improved deployability and archivability of X3D content<br />
* Technical issues include .gzip versus .zip, bundling of metadata (demonstrated by Java .jar and .war formats), etc.<br />
* The [http://freewrl.sourceforge.net FreeWRL project] is implementing and exploring possible approaches to this challenge<br />
<br />
== X3D Implementations and Benchmark Testing==<br />
The following tools implement the X3D Compressed Binary Encoding (CBE) standard.<br />
* Two independent open-source implementations available.<br />
** C++ codebase: [http://forge.collaviz.org/community/xiot XIOT X3D Input Output Tool] library.<br />
** Java codebase: [http://www.xj3d.org Xj3D].<br />
* Ongoing status is maintained on Web3D-member wiki pages:<br />
** [[Player support for X3D components]]<br />
** [[Tool support for X3D components]]<br />
* Several thousand [http://www.web3d.org/x3d/content/examples/X3dResources.html#Examples X3D Examples] are available in ''.x3db'' form, encoded by Xj3D.<br />
<br />
Existing assets can be improved to establish a comprehensive X3D compression benchmark suite.<br />
* Such a suite can facilitate testing of new contributed capabilities.<br />
* We plan to automate conversions and comparisons, using Xj3D XIOT and other submissions, for cross-check interoperability and validation testing.<br />
* It will be easy to automate such a suite using our many example scenes and the already-existing nightly build (continuous integration) processes.<br />
* This will automate the production of results summarized in the compression performance tables constructed as part of the call for technologies.<br />
* Primary metrics are file size, conversion speed and memory requirements. Visual inspection of result quality will also be provided.<br />
<br />
== Looking Ahead ==<br />
'''Work in Progress.'''<br />
* Web3D's X3D and [http://www.web3d.org/realtime-3d/computer-aided-design-cad CAD] Working Groups each have member commitments to pursue this continued innovative work during 2013-2014.<br />
* We are always keen to consider common, sharable technical strategies with other industry standards. Web3D Consortium has been waiting for a response from The Khronos Group and MPEG standards SC 29 committee since a joint meeting at SIGGRAPH conference August 2012. To date, formal MPEG4 communications have indicated that a royalty-free solution is not possible. Khronos work appears likely but royalty requirements and design compatiblity remains unclear.<br />
<br />
'''Meetings.'''<br />
* The first weekly X3D Working Group meeting of each month is dedicated to an X3D Futures discussion, including X3D Binary Compression Capabilities and Plans. <br />
* The [http://web3d2013.org Web3D 2013 conference] included an open meeting on 3D Transmission Formats, to be held Wednesday 19 June 2013 in San Sebastian Spain.<br />
** Responses to the [http://www.web3d.org/realtime-3d/working-groups/x3d/compressed-binary/x3d-compressed-binary-encoding-call-contributions X3D Binary Compression Call for Contributions] will be reviewed and candidate technologies will be discussed. <br />
** Inquiries and presentation requests can be sent to the [http://www.web3d.org/realtime-3d/page/contact/x3d-chairs X3D Working Group Cochairs]. <br />
* We further plan to meet publicly at the annual SIGGRAPH Conferences.<br />
<br />
'''Adding example Use Cases will help evaluate the value of each contribution.'''<br />
* Technical requirements are important for performing comparative measurements, but sometimes they don't tell the whole story.<br />
* Also defining work-flow authoring requirements for compressed X3D scenes is helpful, providing useful criteria for evaluating technical capabilities. Use cases enable us to determine whether each possible improvement effectively meets a declared need.<br />
* X3D authors are asked to help us document common workflow practices. We will extend the requirements to build an updated set of use cases to help evaluation. The emerging next-generation standard is being designed to provide the best possible value to Web authors, users, and software developers.<br />
* Once the basic framework updated, we will ask each working group to identify special case examples for demonstrating value, avoiding problems, or further optimization.<br />
<br />
'''Follow-on work'''<br />
* Provide an additional [http://web3d.org/wiki/index.php/X3D_MIME-Type X3D MIME Type] submission to IANA<br />
* Update references in all other X3D specifications<br />
<br />
== Contributions Received ==<br />
<br />
* [http://web3d.org/wiki/images/7/77/Mesh_encodings_for_X3DOM_-_Recent_Advances_-_ML_-_12NOV2013.pdf Mesh encodings for X3DOM - Recent Advances] Fraunhofer provided a comprehensive list of proposed improvements on an X3D Working Group teleconference, 12 November 2013<br />
** Further detail available at [http://www.x3dom.org/pop | X3DOM Progressively Ordered Primitives (POP)]]</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_Binary_Compression_Capabilities_and_Plans&diff=8736X3D Binary Compression Capabilities and Plans2015-02-11T17:18:14Z<p>Webmaster: /* Call For Contributions */ - updated link to Call page</p>
<hr />
<div>==Motivation==<br />
Lots of work has already been accomplished using the X3D Compressed Binary Encoding (CBE) standard.<br />
<br />
X3D has numerous coherent approaches already available that meet author requirements for a general Web-based 3D transmission format.<br />
<br />
We are working to demonstrate and standardize multiple interoperable improvements in 2013.<br />
<br />
==Strategy, 2013-2014==<br />
* We reviewed several goals and developmental capabilities at the [http://www.web3d2013.org Web3D 2013 Conference] in June 2013.<br />
* We accomplished our strategic goal to define X3D Compressed Binary Encoding (CBE) requirements and plan next steps during 2013.<br />
* We are now soliciting and reviewing multiple contributions to possibly accomplish all of these efforts during calendar year 2014.<br />
<br />
==Call For Contributions==<br />
X3D solutions currently support a wide range of author requirements. <br />
Further improvements and standards-based partnerships are possible for achieving broader industry interoperability. <br />
<br />
The [http://www.web3d.org/working-groups/x3d/compressed-binary-encoding-activity X3D Compressed Binary Encoding Call For Contributions] to help accomplish these achievable goals has been released. We are seeking next-generation improvements that further advance the technical capabilities of the X3D Graphics International Standard.<br />
<br />
'''Prior work is essential, useful and relevant.'''<br />
* The first-generation [http://www.web3d.org/x3d/binary/X3dBinaryRFP.html X3D Compressed Binary Encoding Request For Proposals (RFP)] from August 2003 illustrates this steady evolution. <br />
* The first-generation process successfully created the current [http://www.web3d.org/files/specifications/19776-3/V3.2/Part03/X3D_Binary.html X3D Compressed Binary Encoding (CBE)] International Standard.<br />
'''All submitters must meet certain requirements prior to consideration.'''<br />
* The [http://www.web3d.org/realtime-3d/about/legal Intellectual Property Rights (IPR)] protections for X3D specification.<br />
* Patented technologies can be considered, but only when eventual use will be royalty free for X3D use (if eventually accepted).<br />
* Submitters can restrict access to patented submissions during member-only working group review, if desired.<br />
<br />
== Existing Compression Usage for X3D and VRML97 ==<br />
A solid foundation exists for continued progress.<br />
* Approved ISO standard [http://www.web3d.org/files/specifications/19776-3/V3.2/Part03/X3D_Binary.html Compressed Binary Encoding (CBE) for X3D].<br />
** Based on ISO standard [http://fi.java.net Fast Infoset (FI)] for XML compression.<br />
* Optional, alternative gzip compression and MIME Type definitions for X3D.<br />
** XML encoding ([http://www.web3d.org/files/specifications/19776-1/V3.2/Part01/concepts.html#X3DFilesAndTheWorldWideWeb .x3dz/.x3d.gz]), ClassicVRML encoding ([http://www.web3d.org/files/specifications/19776-2/V3.2/Part02/concepts.html#ClassicVRMLEncodedX3DFilesAndWWW .x3dvz/.x3dv.gz]) and Compressed Binary encoding ([http://www.web3d.org/files/specifications/19776-3/V3.1/Part03/concepts.html#X3DFilesAndTheWorldWideWeb .x3db.gz]) file extensions.<br />
* Optional, alternative gzip compression for VRML97.<br />
** Original compression technique of applying gzip to .wrl compressed VRML97 files was called .wrz.<br />
** This emerged as a common practice when gzip was originally used. No formal specification of .wrz or corresponding mime type was produced.<br />
** Occasionally authors might also gzip .wrl files while retaining the .wrl file extension.<br />
<br />
Multiple X3D compressed binary encoding (CBE) codebases exist for producing .x3db scenes under the existing standard. However, conformance interoperability between different implementations is not well tested.<br />
<br />
'''Web3D will not formally advance a next-generation X3D binary compression format as a candidate standard until current interoperability has been satisfactorily demonstrated for the existing standard.'''<br />
<br />
== Polygon Reduction and Geometric Compression ==<br />
Formal specifications:<br />
* The X3D Compressed Binary Encoding defines extensible, repeatable [http://www.web3d.org/files/specifications/19776-3/V3.2/Part03/concepts.html#X3DCompressionDataFlow compression] and [http://www.web3d.org/files/specifications/19776-3/V3.2/Part03/concepts.html#X3DDecompressionDataFlow decompression] algorithms for [http://www.web3d.org/files/specifications/19776-3/V3.2/Part03/concepts.html#OverviewIntroduction data-flow production chains]. Multiple type-specific [http://www.web3d.org/files/specifications/19776-3/V3.1/Part03/EncodingOfFields.html field encoders] and geometric compression algorithms can be used in concert, but no specific geometric compression algorithms are referenced or required.<br />
* [http://www.web3d.org/files/specifications/19776-3/V3.2/Part03/concepts.html#X3DCanonicalForm X3D Canonicalization (C14N)] provides standardized formatting so that digital signatures are not thwarted by whitespace variations.<br />
Best practices and examples:<br />
* [http://www.web3d.org/x3d/workgroups/cad CAD Distillation Filter (CDF)] technique allowing successive refinement of large X3D scenes into tighter X3D scenes.<br />
* A highly effective exemplar algorithm for [http://www.cs.unc.edu/~isenburg/research/asciicoder Coding Polygon Meshes as Compressable ASCII] is demonstrated in the [http://www.web3d.org/x3d/content/examples/Basic/ExperimentalBinaryCompression Experimental Binary Compression examples].<br />
* Multiple CAD Distillation Filter (CDF) algorithms implemented in [http://www.xj3d.org Xj3D] and [https://savage.nps.edu/X3D-Edit X3D-Edit] as open-source.<br />
* The [http://www2.hrp.no/vr/tools/chisel/install.htm Chisel VRML Optimisation Tool] has an excellent set of data-reduction tools for VRML that are worth repeating for X3D.<br />
* Multiple other [http://www.web3d.org/x3d/content/examples/X3dResources.html#Conversions conversion and translation tools] available with supporting capabilities.<br />
* Following submission of candidate technologies, we will build a table of 3D graphics compression benchmark results, providing a full comparison of existing tools (compression ratio, computational complexity, memory usage, etc.)<br />
* MPEG4 capabilities are welcome, if IPR prerequisites are met. Discussion to date has indicated that Royalty Free (RF) solutions are not available.<br />
* Related efforts reported in academic papers and Web3D conferences need to be reviewed and reflected here<br />
<br />
== Data-Centric Binary Encodings ==<br />
The X3D Compressed Binary Encoding (CBE) uses the ISO Fast Infoset (FI) standard to compress XML information, which is how the CBE maintains equivalent expressive power with other X3D scene encodings.<br />
* Plan to add a further-improved X3D Compressed Binary Encoding using now-approved W3C Recommendation for [http://www.w3.org/TR/exi/ Efficient XML Interchange (EXI)].<br />
* Web3D contributed to [http://www.w3.org/XML/EXI/ EXI working group] and [http://www.w3.org/XML/Binary XML Binary Characterization working group] efforts.<br />
** [http://www.w3.org/TR/xbc-use-cases/#x3dtrans 3D Model Compression, Serialization and Transmission] use-case requirements are defined and met by EXI.<br />
* Design includes compatibility with CDF techniques, [http://www.w3.org/TR/xmlenc-core XML Encryption], and [http://www.w3.org/TR/xmldsig-core/ XML Digital Signature] for author authentication.<br />
** Relevant example scenes maintained as part of [http://www.web3d.org/x3d/content/examples/Basic/Security X3D Basic Examples Archive - Security].<br />
* These capabilities meets most needs of digital authors for digital rights management (DRM).<br />
* '''Review Open Geospatial Consortium (OGC) requirements to determine whether additional optimizations might improve the already-excellent coverage of geospatial datasets'''<br />
** Also explore the possibility that additional compression algorithms may show better efficiency for geospatial datasets<br />
* Following submission of candidate technologies, we will build a table of data compression benchmark results, providing a full comparison of existing tools (compression ratio, computational complexity, memory usage, etc.)<br />
<br />
== Network Streaming ==<br />
* Multiple capabilities are already available in X3D for flexible network transmission.<br />
** Anchor, Inline, LOD, LoadSensor, Script and Prototype nodes support successive retrieval of content once initial model is displayed.<br />
* Progressive-mesh geometric streaming technologies hold definite interest. Mesh-compression algorithms that can be applied to existing X3D polygonal data will be the most valuable.<br />
* Need to demonstrate whether http/https and local-file url retrieval are sufficient for a network protocol for use cases of interest.<br />
** Other network protocols (Web sockets, P2P channels, etc.) might be possible or needed, but only if security restrictions and implementation/deployment can be handled satisfactorily.<br />
* Javascript Object Notation (JSON) might be suitable for simple streaming of X3D scene-graph data via Script node or external HTML page, which can be useful for progressive mesh and other incremental network-update approaches.<br />
** Support in clients and servers is becoming widely available.<br />
** JSON might have other uses as well, see Khronos work on [https://github.com/KhronosGroup/glTF/blob/master/specification/README.md Collada2JSON and glTF]. This is an active area of work.<br />
<br />
== Resource Bundling ==<br />
* Mechanisms for bundling multiple files (e.g. X3D scene, Inlined subscenes, image files, audio and video files, etc.) into a single archive file will be considered.<br />
* Similar bundling capabilities are emerging for uncompressed X3D scenes embedded within HTML pages.<br />
* Benefits support improved deployability and archivability of X3D content<br />
* Technical issues include .gzip versus .zip, bundling of metadata (demonstrated by Java .jar and .war formats), etc.<br />
* The [http://freewrl.sourceforge.net FreeWRL project] is implementing and exploring possible approaches to this challenge<br />
<br />
== X3D Implementations and Benchmark Testing==<br />
The following tools implement the X3D Compressed Binary Encoding (CBE) standard.<br />
* Two independent open-source implementations available.<br />
** C++ codebase: [http://forge.collaviz.org/community/xiot XIOT X3D Input Output Tool] library.<br />
** Java codebase: [http://www.xj3d.org Xj3D].<br />
* Ongoing status is maintained on Web3D-member wiki pages:<br />
** [[Player support for X3D components]]<br />
** [[Tool support for X3D components]]<br />
* Several thousand [http://www.web3d.org/x3d/content/examples/X3dResources.html#Examples X3D Examples] are available in ''.x3db'' form, encoded by Xj3D.<br />
<br />
Existing assets can be improved to establish a comprehensive X3D compression benchmark suite.<br />
* Such a suite can facilitate testing of new contributed capabilities.<br />
* We plan to automate conversions and comparisons, using Xj3D XIOT and other submissions, for cross-check interoperability and validation testing.<br />
* It will be easy to automate such a suite using our many example scenes and the already-existing nightly build (continuous integration) processes.<br />
* This will automate the production of results summarized in the compression performance tables constructed as part of the call for technologies.<br />
* Primary metrics are file size, conversion speed and memory requirements. Visual inspection of result quality will also be provided.<br />
<br />
== Looking Ahead ==<br />
'''Work in Progress.'''<br />
* Web3D's X3D and [http://www.web3d.org/realtime-3d/computer-aided-design-cad CAD] Working Groups each have member commitments to pursue this continued innovative work during 2013-2014.<br />
* We are always keen to consider common, sharable technical strategies with other industry standards. Web3D Consortium has been waiting for a response from The Khronos Group and MPEG standards SC 29 committee since a joint meeting at SIGGRAPH conference August 2012. To date, formal MPEG4 communications have indicated that a royalty-free solution is not possible. Khronos work appears likely but royalty requirements and design compatiblity remains unclear.<br />
<br />
'''Meetings.'''<br />
* The first weekly X3D Working Group meeting of each month is dedicated to an X3D Futures discussion, including X3D Binary Compression Capabilities and Plans. <br />
* The [http://web3d2013.org Web3D 2013 conference] included an open meeting on 3D Transmission Formats, to be held Wednesday 19 June 2013 in San Sebastian Spain.<br />
** Responses to the [http://www.web3d.org/realtime-3d/working-groups/x3d/compressed-binary/x3d-compressed-binary-encoding-call-contributions X3D Binary Compression Call for Contributions] will be reviewed and candidate technologies will be discussed. <br />
** Inquiries and presentation requests can be sent to the [http://www.web3d.org/realtime-3d/page/contact/x3d-chairs X3D Working Group Cochairs]. <br />
* We further plan to meet publicly at the annual SIGGRAPH Conferences.<br />
<br />
'''Adding example Use Cases will help evaluate the value of each contribution.'''<br />
* Technical requirements are important for performing comparative measurements, but sometimes they don't tell the whole story.<br />
* Also defining work-flow authoring requirements for compressed X3D scenes is helpful, providing useful criteria for evaluating technical capabilities. Use cases enable us to determine whether each possible improvement effectively meets a declared need.<br />
* X3D authors are asked to help us document common workflow practices. We will extend the requirements to build an updated set of use cases to help evaluation. The emerging next-generation standard is being designed to provide the best possible value to Web authors, users, and software developers.<br />
* Once the basic framework updated, we will ask each working group to identify special case examples for demonstrating value, avoiding problems, or further optimization.<br />
<br />
'''Follow-on work'''<br />
* Provide an additional [http://web3d.org/wiki/index.php/X3D_MIME-Type X3D MIME Type] submission to IANA<br />
* Update references in all other X3D specifications<br />
<br />
== Contributions Received ==<br />
<br />
* [http://web3d.org/wiki/images/7/77/Mesh_encodings_for_X3DOM_-_Recent_Advances_-_ML_-_12NOV2013.pdf Mesh encodings for X3DOM - Recent Advances] Fraunhofer provided a comprehensive list of proposed improvements on an X3D Working Group teleconference, 12 November 2013<br />
** Further detail available at [http://www.x3dom.org/pop | X3DOM Progressively Ordered Primitives (POP)]]</div>Webmasterhttps://www.web3d.org/wiki/index.php?title=X3D_JSON_Encoding&diff=8658X3D JSON Encoding2014-09-10T15:57:50Z<p>Webmaster: /* References */</p>
<hr />
<div>Preliminary notes on the creation of an X3D JSON encoding.<br />
* This page is to understand the conversion process so that a high-quality encoding definition can be created<br />
* Don Brutzman started a thread on the X3D-Public list.<br />
** Initial message [http://web3d.org/pipermail/x3d-public_web3d.org/2014-July/002854.html]<br />
** July's thread listing [http://web3d.org/pipermail/x3d-public_web3d.org/2014-July/thread.html]<br />
== Conversion Considerations ==<br />
<br />
Primary design criterion: round-trippable lossless representation of X3D scene.<br />
<br />
Conversion approach of greatest practical interest: XML to/from JSON. Issues:<br />
<br />
# How to convert attribute names to distinguish them from child elements<br />
# JSON handling of container elements to preserve parent/child relationships, distinguishing child elements from attributes<br />
# Creation of JSON elements with datatypes appropriate to content (e.g., integer, float, strings, etc.)<br />
# Both X3D and JSON can include comments, and so need an option for inclusion (by default) or removal (optional) of comments in order to ensure 100% round-trip conversion capabilities. <br />
# Support for singleton (self-closing) XML tags also needs to be considered<br />
# Inclusion and preservation of embedded XML namespace information in an XML (.x3d) document<br />
<br />
== Use cases ==<br />
<br />
Are there any special use cases for having X3D JSON available in JavaScript?<br />
* Are there any use cases that might modify how X3D is represented in JSON?<br />
* If so, it would be good to spell them out and understand them well.<br />
* We want conversion rules to permit implementations that can achieve user goals.<br />
<br />
== Discussion points ==<br />
<br />
Here are suggested discussion points for X3D teleconferences and future followups.<br />
<br />
# Is there a good/consistent way for X3DOM to utilize such capabilities?<br />
# Is there a way for [http://threejs.org Three.js] X3D loader, or other javascript libraries, to utilize such capabilities?<br />
# Is there a single authoritative reference for JSON itself? and for JSON-XML conversions? See [6] for the JSON Data Interchange Format, need to confirm no others.<br />
# Compare compression size and decompression speed of a TestMesh.x3d.json.gz to TestMesh.x3db and TestMesh.x3d.exi (EXI will likely win because it includes data typing)<br />
# Once a canonical form for X3D as JSON is established, add conversion capabilities to X3D-Edit and also autoconvert, test and publish JSON for all of the 3800+ scenes in the [http://www.web3d.org/x3d-resources/content/examples/X3dResources.html#Examples X3D Examples Archives]<br />
# Decide if this capability needs to be defined in one of the [http://www.web3d.org/specifications/X3dSpecificationRelationships.png X3D standards], or perhaps as an X3D best practice.<br />
# What is the right file extension? .json, .x3dj or others<br />
# Can a file reader distinguish the incoming encodings (.x3d .x3dv .x3db .x3de .json) independent of file extension or MIME media type?<br />
# Probably lots more... What else?<br />
<br />
== Contributors ==<br />
* LD - Leonard Daly<br />
* DPB - Don Brutzman<br />
<br />
== References ==<br />
* XML to JSON Converter (provides option to assign a prefix to JSON attributes, default is @ character) [http://www.freeformatter.com/xml-to-json-converter.html]<br />
* Apache Camel, XML JSON Data Format (camel-xmljson) [http://camel.apache.org/xmljson.html]<br />
* JSON Definition [http://json.org/]<br />
* ECMA 404: JSON Data Interchange Format (Final Draft) [http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf]<br />
* JSON Markup Language (JsonML) [http://www.jsonml.org/]<br />
* XSLTJSON: Transforming XML to JSON using XSLT [http://www.bramstein.com/projects/xsltjson/]<br />
* Converting Between XML and JSON [http://www.xml.com/pub/a/2006/05/31/converting-between-xml-and-json.html]<br />
* XML/JSON Perl Converter [http://search.cpan.org/~ken/XML-XML2JSON-0.06/lib/XML/XML2JSON.pm]<br />
* IBM's PHP converter [http://www.ibm.com/developerworks/library/x-xml2jsonphp/]<br />
* Java Converter [http://www.json.org/javadoc/org/json/XML.html]<br />
* Google Code Library [https://code.google.com/p/x2js/]</div>Webmaster