<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Phillip,<br>
<br>
Thanks for responding. Kristian sent me an email about 3 weeks ago
that I need to go back and read in detail. Because (I think) both
of your messages are very closely related, I will respond
together.<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
</div>
<blockquote cite="mid:56935521.90201@dfki.de" type="cite">
<pre wrap="">Hi Leonard, all,
Kristian Sons is currently finishing his PhD in which he has done an
extensive analysis and evaluation of the available options for adding
interactive declarative 3D to HTML.
Because of this analysis, the solutions that he came up with (all
implemented in XML3D) are quite a bit closer to HTML and uses a more
generic and orthogonal design approach than X3D, which allows for more
easily building new functionality on top of the basic tools provided
(one of the key design decision).
Prime examples are the generic data model (think generic buffers used in
GPU API today), the Xflow mechanism for dynamic and programmable
functionality (animation, image processing, AR, etc.), and its
connection to the graphics/rendering side (with optimal support for
programmable GPUs in mind). This approach provides many advantages that
are worth looking into. Unfortunately, they seem difficult to achieve
based on the current design of X3D (which is why he started fresh to
begin with).
As an example for this flexibility, together with Intel we are currently
looking into how to link Xflow directly to upcoming features like
SIMD.js and WebAssembly. It seems that very little (nothing?) needs to
be done at the format level to enable that. Being able to support these
browser features out of the box would dramatically help VR/AR in the
browser.
In several areas XML3D actually goes significantly beyond what X3D and
other approaches provide today (e.g. programmable materials that adapt
to the variability of assets). I believe there are many things in this
approach that should be strongly considered in your V4 discussions.
Kristian is currently putting final touches on his thesis and he could
probably make an early draft version available for this discussion here.
BTW, please do not see this as an anti-X3D post. We care strongly for
declarative 3D on the Web. We actually started based on X3D back then
but saw too many issues with X3D and the emerging mapping to HTML based
on X3DOM (all detailed in the thesis). So, XML3D is our vision of how
X3D could evolve. All of our code is out there as Open Source to use and
integrate.
Best,
Philipp
Am 11.01.2016 um 07:04 schrieb Leonard Daly:
</pre>
<blockquote type="cite">
<pre wrap="">Last week I sent a message to the X3D WG about my concerns on lack of
progress for developing a V4 specification. This message is expanding
the reach of the original message and providing additional requested
material, specifically examples of situations where I would want and/or
expect X3D to run in a browser. The list of examples is being expanded
as developments occur.
The marketplace is making significant progress in commercialization of
virtual and augmented reality. There is no standard format for
expressing 3D content. The marketplace will choose at least one format
and it will not likely be X3D. Already there are alternative markup
languages emerging that attempt to do what X3D has been doing for
decades: create an HTML like language for 3D graphics. GLAM is an
example proposed by Tony Parisi, and most recently Mozilla’s A-frame,
released 3 weeks ago, both attempting to speak in the language of web
developers to bring VR/AR to the browser.
I am very frustrated in the lack of progress of the Working Group in
developing a specification for X3D V4. There are number of issues that
have been raised about the fundamentals of designs of X3D that appear to
be incompatible with an HTML/DOM environment. A partial list includes
the following:
* name-scope handling
* scripting
* interfaces to the nodes and fields through the DOM API
* event handling
* profile structure and contents
* newly supported formats (geometry and media)
Examples of X3D/X3DOM: <a class="moz-txt-link-freetext" href="http://tools.realism.com/x3d-v4-issue-examples">http://tools.realism.com/x3d-v4-issue-examples</a>
There are other concerns about event model that are not expressed in
these examples mostly due to being unable to create an example that
clearly shows the problem. It does exists and you may see some of that
in sporadic or jerky movement in the animation examples using X3DOM.
I have a concept specification that is getting updated at
<a class="moz-txt-link-freetext" href="http://tools.realism.com/specification/x3d-v40">http://tools.realism.com/specification/x3d-v40</a>. The was first sent to
the X3D WG in November and has had a couple of other discussions.
My specific technical concerns with the specification are listed in the
Author's Notes at
<a class="moz-txt-link-freetext" href="http://tools.realism.com/specification/x3d-v40/authors-notes">http://tools.realism.com/specification/x3d-v40/authors-notes</a>
Most importantly, it is not clear to me who the WG believes is the
target audience for the specification and how the specification will
meet that audience’s needs.
As Co-Chair on Sabbatical and current member of the WG, I need to take
some responsibility for not getting there. I have been working on
developing a new specification and the beginning of an open-source
web-based application for building scenes in the new specification. The
web application is called “Basx3D - 3D the HTML Way”. I have posted an
article about it’s initial release - <a class="moz-txt-link-freetext" href="http://realism.com/blog/basx3d">http://realism.com/blog/basx3d</a>.
This post and one describing the X3D V4 proposal are publicly available.
The application is targeted at web developers who do not need to know
the details of creating an X3D by hand. The concept was based on Unreal
Engine and Unity editors. I will be continuing development of both the
application and proposal on a frequent and regular basis. Basx3D and the
proposed specification function as a two-way development effort with
Basx3D reflecting the proposal and providing implementation information
and experience back to the specification.
Although outside of its scope, the WG must be aware of the audience to
which the standard is written, and the audience to which the standard is
being promoted. This concept is crucial to the future adoption of X3D
and should ultimately be agreed upon by the BOD, but the WG needs to
understand and follow this strategy which will ultimately influence
prioritization of WG activity.
I am firmly committed to an open, royalty free, ISO ratified standard
that communicates 3D data and its behaviors over networks, especially
the dominant global network which is the internet, and which universally
supports HTML5. I don’t want to see the decades of work and passion
that have been invested in the standards maintained and promoted by the
Web3D Consortium relegated to the corridors of obscurity. Because of
many trends in software and hardware, a nexus of opportunity has been
created like never before of which we can take advantage to catapult the
Consortium’s standards to significant global adoption. Let’s not miss
this chance!
Leonard Daly
Basx3D and X3D V4 Specification Proposal Author
In Full Support
Mike Aratow
Treasurer, Web3D Consortium
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
X3D Co-Chair<br>
Cloud Consultant<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>