[x3d-public] [x3d] V4.0 Open discussion/workshop on X3DHTML integration

[Joe D Williams]

> I do not think that a HTML-based X3D version is necessarily much 
> slower
> than a native one.


Well, to me it depends upon what actually gets built-in to the html 
browser. Adding tons of javascript can only be an interim solution 
that sets the pattern for what code is actually running to produce 
whatever is represented in the <x3d> ... </x3d> user code. Demanding 
for a user to download big script files shows a way of implementing 
some x3d, but x3d in html by downloading whatever current script 
modules are available is not pretty or longlastig satisfaction to me. 
It all must be native, in the html browser finally. At this time we 
are treating the content like it needs to be supported by a 
script-based plugin.

>
> Additionally, Xflow also allows it to not only do this for 
> offloading
> for rendering part but also for a lot of the animation, geometry
> processing, image processing, and other tasks.

That is what I mean, you can probably make an outstanding X3D player 
with what you have now. Why not go there and show how your platform 
works node for node. Then you can also maybe show some things that 
could be added to basic X3D.

Features that are actually a part of html will be implemented natively 
by the html browser not dependent upon add-on scripties.

> I think that going forward we should have a single specification 
> that
> would work everywhere.

I don't think so because a standaone or embedable X3D tool, and the 
.x3d code and scene grapha and event graph will always be superior for 
high fi simulations and detailed documentation of a process. X3D in 
html <x3d> ... </x3d> will never be as extensible as x3d standalone or 
embedable players. SAI and its supporting tools wil always be better 
than DOM when time matters (well, maybe dom6 might workok).

> Because incompatible changes might be required
> (for HTML compatibility), "old" X3D would need to be converted to 
> run in
> the new environment.

I don't see html as a new environment. It is just one that we have 
always played in but we had to use an object or such to embed the 
player in the html document. For now we are mostly playing the same 
tune by embedding the x3d without actually embedding it then producing 
it using the underlying invisible supports of js and pieces of 
existing x3d browsers that may be installed. That is fine to prove a 
point but long term all is built-in or else no true added value.

http://www.hypermultimedia.com/ajax3d/index.htm

> But as the great JSON activites have shown this is
> possible and not really that hard. Its mostly "just" syntax.

True, and many times the same thing with different names. That is why 
I think you should implement a great x3d player using your project.


Any structures or sytax we change for this html application form of 
x3d ought to be able to be transformed into 'old' x3d.

Thanks and Best,
Joe



----- Original Message ----- 
From: "Philipp Slusallek" <philipp.slusallek at dfki.de>
To: "Joe D Williams" <joedwil at earthlink.net>; "Roy Walmsley" 
<roy.walmsley at ntlworld.com>; "'Don Brutzman'" <brutzman at nps.edu>; 
"'Leonard Daly'" <Leonard.Daly at realism.com>
Cc: "'X3D Graphics public mailing list'" <x3d-public at web3d.org>; "'x3D 
WG'" <x3d at web3d.org>
Sent: Thursday, June 09, 2016 7:31 PM
Subject: Re: [x3d-public] [x3d] V4.0 Open discussion/workshop on 
X3DHTML integration


> Hi Joe, all,
>
> I do not think that a HTML-based X3D version is necessarily much 
> slower
> than a native one. As I pointed out you can have the scene runtime 
> be in
> JS (via node.js/jsdom for example) but do all the heavy lifting in a 
> C++
> appliction with the latest and greates OpenGL or such (e.g. using an
> "old"-style X3D engine for example).
>
> Additionally, Xflow also allows it to not only do this for 
> offloading
> for rendering part but also for a lot of the animation, geometry
> processing, image processing, and other tasks. THis can be offloaded
> into the vertex shader, native code, into JS, and JS with various
> accelerators (asm.js, SIMD.js).
>
> I think that going forward we should have a single specification 
> that
> would work everywhere. Because incompatible changes might be 
> required
> (for HTML compatibility), "old" X3D would need to be converted to 
> run in
> the new environment. But as the great JSON activites have shown this 
> is
> possible and not really that hard. Its mostly "just" syntax.
>
> Best,
>
> Philipp
>
>
>
> Am 09.06.2016 um 22:11 schrieb Joe D Williams:
>> see below
>> Joe
>>
>> ----- Original Message ----- From: "Roy Walmsley"
>> <roy.walmsley at ntlworld.com>
>> To: "'Don Brutzman'" <brutzman at nps.edu>; "'Leonard Daly'"
>> <Leonard.Daly at realism.com>
>> Cc: "'X3D Graphics public mailing list'" <x3d-public at web3d.org>; 
>> "'x3D
>> WG'" <x3d at web3d.org>
>> Sent: Thursday, June 09, 2016 9:59 AM
>> Subject: Re: [x3d] [x3d-public] V4.0 Open discussion/workshop on 
>> X3DHTML
>> integration
>>
>>
>>> I feel the need to comment on the issue of progress that is raised 
>>> below.
>>>
>>>
>>>
>>> X3D V4.0 essentially consists of two strands:
>>>
>>>
>>>
>>> 1)      Evolving V3.3 by the addition (and possible deletion) of
>>> components.
>>
>>
>> It is of absolutely vital importance that this proceeds in two 
>> forks.
>>
>> 1. The enhancement and encouragment of 'standalone' X3D players 
>> that
>> preserve the current simulation and transportability legacy 
>> features of
>> VRML/X3D. In general this means a tool that follows the X3D 
>> realtime
>> concepts, includes animation automation such as timers, 
>> interpolators,
>> shaders, componenets and provides both 'internal' Script nodes and 
>> the
>> ability to be controlled by 'external' scripting.
>>
>> (Please note that the only X3D SAI difference between 'internal' 
>> and
>> 'external' scripting is that the 'external' controller can use
>> begin/endupdate to define when a set of SAI events should be 
>> processed
>> as same cascade or individually.)
>>
>> 2. Generation of a completely declarative XML (XHTML and HTML 
>> included)
>> DOM structure <x3d> ... </x3d> that depends upon host browser 
>> script
>> elements for 'external' control. In general this means a tool that
>> generally follows the X3D realtime concepts, syntax, and includes 
>> object
>> and viewpoint animation automation using timers and interpolators, 
>> but
>> provides only 'external' scripting according to DOM concepts.
>>
>> There will be no penalty for us to define this htmlized version of 
>> X3D
>> using strictest XHTML and XML syntax rules.
>>
>> I think one of the most important parts of this is defining how 
>> much of
>> the basic realtime animation automation features to include. 
>> Without
>> 'built-in features such as routes (definately in the CSS category!) 
>> and
>> timers and interpolators (possible also CSS!) the user must depend 
>> upon
>> 'external' DOM scripts which will be inadequate.
>>
>> SIdebar: I think this idea of putting all timers.intepolators, and
>> routes as CSS can simplify details. This transformation from legacy 
>> X3D
>> syntax to htmlized syntax using CSS can be done using variations of
>> existing tools. In fact, the most html-like feature of htmlized 
>> .x3d
>> would be to demand writing all DEFs as a CSS then only USE in the 
>> inline
>> user code. Maybe strange, but true.
>>
>> For existing 'standalone' tools, the integration with DOM has been
>> through <embed> or <object> (or recall html object declare?) where 
>> a DOM
>> script exchanged with the embedded object using syntax of the DOM 
>> for
>> control of input/outputs and use syntax of the embedded object to
>> control actual changes to the scenegraph.
>>
>> I would say this still works now in major X3D tools, less html
>> browser-dependant perhaps but still very dependant upon the 
>> capabilities
>> of the embedded object.
>>
>>>
>>> 2)      Integration of X3D into HTML.
>>>
>>
>> OK, that is also 2. above. Hey, X3D as .x3d standalone with a 
>> dedicated
>> internal engine or x3d in html will be different but it must be the 
>> same
>> feature set as much as possible. And the structure must look 
>> compatible
>> with other types of html. This is why I think using the very 
>> liberal
>> content rules for CSS as much a possible and take the opportunity 
>> to
>> move ROUTEs and DEFs and Timers and even sensors and shaders out of 
>> the
>> inline code and into CSS, which after all, is as alive as other 
>> elements
>> of the DOM.
>>
>>>
>>>
>>> The evolutionary strand 1) referred to above is progressing. A lot 
>>> has
>>> been
>>> accomplished. Great. Keep up the good work.
>>>
>>
>> This means keeping on with X3D progression as the model for a high
>> performance realtime network simulation tool fully hareware
>> accellerated. This means the type of engine that runs frestanding 
>> or as
>> as an html object. This thing is probably real fast because it uses 
>> X3D
>> event system and animation automations but most all computation and
>> rendering is handled by internal optimized code.
>>
>> Of secondary importance but showing relly great legs is the idea of
>> inline <x3d> user code where the X3D event system and automations 
>> are
>> accomplished running some resources provided by the host, like a
>> javescript engine and DOM structure. The fact that script engines 
>> are
>> have progressed so much makes this possible and is providing 
>> fantastic
>> results. The only 'problem' is that the htmlized x3d is retaining 
>> too
>> much of x3d legacy and that makes it look real easy at first 
>> because all
>> the old stuff that doesn't use Script or Proto works real fine. I 
>> think
>> we need to step back and ask can it really be this easy.
>>
>>>
>>>
>>> In contrast the integration strand 2) has made no significant 
>>> progress.
>>
>> When there are at least two implementations each showing lots of 
>> same
>> and some important differences, I think that is a sign of great 
>> progress
>> and promise.
>>
>> The main thing is not bending the 'standalone' operation of .x3d to 
>> the
>> inline code of <x3d>...</x3d> for now anyway. These are two 
>> separate and
>> almost independent projects. We are trying to fit X3D into HTML 
>> using
>> <x3d> ,,, </x3d> and various techniques to htmlize and domify and 
>> style
>> the user code. This is 2. above and for now an entirely different
>> project than 1. above.
>>
>> Just because X3DOM and Cobweb and other approaches are making it 
>> look
>> easy, almost too easy, don't think it is easy. But really, this 
>> (2.) has
>> literally nothing to do with progress on the 'standalone' tool. We 
>> want
>> to create a nice X3D environment for a certain style of <x3d>... 
>> </x3d>
>> user code inline in an html page but we don't wish to make somebody
>> think they can ever get the levels of performance of an optimized
>> high-powered standalone tool that is actually built for 
>> high-fidelity
>> simulations.
>>
>> For example, for the <x3d>,,,<x3d> applications we must stay within 
>> the
>> boundaries of WebGL, while a standalone, can use all of the GL.
>>
>> Of course there is the natural requirement that as much as possible 
>> must
>> be transportable between these
>> two distinct domains
>>
>> '.x3d standalone'
>>
>> and
>>
>> '<x3d>...>/x3d> inline'
>>
>> and fortunately if we stay in xml/css we have many fine tools to 
>> walk us
>> back and forth between the two application areas and the 
>> differences in
>> user code presentation.
>>
>> Thanks and Best
>> Joe
>>
>>
>>> This
>>> is why I am pushing it now. As far as I can see we have had 
>>> 'goals' and
>>> 'requirements' in terms of high level statements for some years. 
>>> These
>>> have
>>> not been translated into more detailed activities. I am not 
>>> suggesting
>>> that
>>> we start writing specifications today, but  I am suggesting 
>>> actions as
>>> follows:
>>>
>>>
>>>
>>> a)      Clarify what form the V4.0 specifications are likely to 
>>> exist in
>>>
>>> b)      Clarify if any major change, such as dropping SAI, is 
>>> likely
>>>
>>> c)       Review existing X3D implementations (X3DOM and Cobweb) to
>>> understand the implications for those specifications arising from 
>>> a)
>>> and b)
>>>
>>> d)      Review other 3D implementations to see what lessons can be
>>> learned
>>>
>>>
>>>
>>> The meeting discussions have contributed significantly to a) and 
>>> b).
>>> There
>>> was general agreement that the existing ISO/IEC standards 
>>> structure
>>> should
>>> be maintained, with no major removal of features such as SAI. 
>>> Despite
>>> raising this subject on previous occasions, this is the first time
>>> that any
>>> resolution of these questions has evolved, and been recorded (at 
>>> least it
>>> will be, when I have updated the wiki page from yesterday).
>>>
>>>
>>>
>>> Does anyone have any ideas about the general structure of the
>>> specifications? What should the major content be? I have not seen 
>>> any
>>> expressed, other than Leonards proposed changes to 19775-1, and my 
>>> own
>>> general thoughts on DOM extension. Inputs from anyone are always 
>>> welcome.
>>>
>>>
>>>
>>> We can now move on to actions c) and d). We had some excellent 
>>> input
>>> yesterday from Philipp with respect to XML3D for d). While 
>>> considering c)
>>> and d) we need to also look for practical candidate solutions to 
>>> the
>>> other
>>> issues that we are aware of, such as:
>>>
>>>
>>>
>>> .         Fields - DOMStrings vs X3D Types
>>>
>>> .         Event models
>>>
>>> .         DEF/USE vs ID/IDREF
>>>
>>> .         Capitalization
>>>
>>> .         Namespace
>>>
>>> .         Scripts and Prototypes
>>>
>>> .         (any I have missed)
>>>
>>>
>>>
>>> Of course, we don't just write specifications to concur with the
>>> implementations. But if we find multiple candidate solutions to 
>>> resolve a
>>> particular issue, with no great differing technical merit, having 
>>> a
>>> proven
>>> implementation of one would be a significant factor.
>>>
>>>
>>>
>>> I know that HTML/DOM are rapidly changing environments, and we 
>>> have to be
>>> careful about jumping in. It is another area we have to keep up 
>>> with.
>>> But we
>>> can't simply sit and watch. We need coordinated action. Someone 
>>> has to
>>> define a path forward, and encourage participation. And currently, 
>>> as
>>> I see
>>> it, a major proportion of that is study. But while studying, lets 
>>> also
>>> generate some practical output, ready for the next phase (actually
>>> writing
>>> specifications) when we are ready.
>>>
>>>
>>>
>>> Solutions to issues will be found. They may start as ideas 
>>> contributed by
>>> individuals. Brainstorming is an excellent activity. But they will 
>>> arise
>>> more easily with greater understanding.
>>>
>>>
>>>
>>> Keeping X3D alive and active is not only a technical activity but 
>>> a
>>> marketing one. With no technical activity, there can be no 
>>> marketing.
>>> With
>>> no marketing, there is less participation, and consequently even 
>>> less
>>> technical activity ..
>>>
>>>
>>>
>>> The upcoming Web3D / Siggraph conference is a major marketing
>>> opportunity.
>>> We have to supply technical inputs to support that.
>>>
>>>
>>>
>>> And another aspect  I haven't touched on is priority. That is a 
>>> business
>>> decision. While sound decisions may be strongly influenced by 
>>> external
>>> factors, they also rely on sound technical inputs.
>>>
>>>
>>>
>>> Roy
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf 
>>> Of Don
>>> Brutzman
>>> Sent: 09 June 2016 03:57
>>> To: Leonard Daly
>>> Cc: X3D Graphics public mailing list; 'x3D WG'
>>> Subject: Re: [x3d-public] [x3d] V4.0 Open discussion/workshop on 
>>> X3D HTML
>>> integration
>>>
>>>
>>>
>>> Leonard, please review the HTML5 Recommendation again for answers 
>>> to
>>> some of
>>> your issues.
>>>
>>>
>>>
>>> 1. Similar to X3D, HTML5 defines functionality in an abstract way
>>> before Two
>>> encodings are defined, in adjacent chapters: loose HTML syntax and 
>>> strict
>>> XML/XHTML syntax.  Both are compatible because they have 
>>> reconciled
>>> idiosyncrasies by aligning each with the DOM.  Indeed this dual 
>>> nature
>>> appears in the title of the W3C Recommendation.
>>>
>>>
>>>
>>> These links have been posted multiple times in the past:
>>>
>>>
>>>
>>>                HTML5: A vocabulary and associated APIs for HTML 
>>> and XHTML
>>>
>>>                 <https://www.w3.org/TR/html5/>
>>> https://www.w3.org/TR/html5/
>>>
>>>
>>>
>>>                8 The HTML syntax
>>>
>>>                 <https://www.w3.org/TR/html5/syntax.html#syntax>
>>> https://www.w3.org/TR/html5/syntax.html#syntax
>>>
>>>
>>>
>>>                9 The XHTML syntax
>>>
>>>
>>> <https://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax>
>>> https://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax
>>>
>>>
>>>
>>> Of note is that X3DOM itself works with both encodings.  Most of 
>>> the
>>> Fraunhofer examples use HTML syntax.  Over 3000 Web3D examples use 
>>> the
>>> XHTML
>>> syntax, where the XML is directly inserted into the HTML page. 
>>> Both work
>>> fine.
>>>
>>>
>>>
>>> X3D version 4 merely needs to allow alignment with HTML5 rules &
>>> relaxations
>>> when running in an HTML5 browser.  Since HTML browsers parse page 
>>> and
>>> scene
>>> data, it seems unlikely that anything we might define would 
>>> override
>>> that.
>>>
>>>
>>>
>>> Regarding events:
>>>
>>> -  DOM events pass a value from one element/node to another, 
>>> always as a
>>> string.
>>>
>>> - X3D events pass a value from one element/node to another, always 
>>> as
>>> timestamped typed value - which have defined expressions as a 
>>> string.
>>>
>>> - Reconcilable.
>>>
>>>
>>>
>>> Given the stability of browser environments, which took 14 years 
>>> to
>>> achieve
>>> when going from HTML4 to HTML5, we have a better environment for
>>> achieving
>>> excellent compatibility than at any time in our history.
>>>
>>>
>>>
>>> Regarding implementations: it is not reasonable to ask X3D players 
>>> to
>>> always
>>> act in a DOM way.  They are different environments.  Those that 
>>> want
>>> to use
>>> DOM for operations are welcome to.
>>>
>>>
>>>
>>> 2. Regarding X3D Script and X3D prototype: don't use them if you 
>>> don't
>>> want
>>> them.  But don't forbid others from using so much great work, 
>>> repeatedly
>>> implemented with success.  X3D would be much smaller and poorer 
>>> without
>>> prototype extensibility, it allowed us to build large portions of 
>>> the
>>> language.
>>>
>>>
>>>
>>> 3. Regarding Consortium:  you seem to think that some kind of 
>>> decision is
>>> needed.  We have a strategy, and we have lots of eyes on it, and 
>>> we have
>>> steady progress, and we can use lots more.  Encouraging activity 
>>> is not
>>> accomplished by opinions or subjective insider decisions.  We have 
>>> goals,
>>> requirements, process and proven track record across 2.5 versions 
>>> of
>>> VRML, 4
>>> versions of X3D, H-Anim, multiple encodings, multiple language
>>> bindings, all
>>> of which continue to grow compatibly with increasing quality &
>>> consistency
>>> in each passing month.  None (I repeat, none) of that was achieved 
>>> by
>>> "leadership decisions" that told volunteers how to spend their 
>>> time.
>>> All of
>>> that progress was achieved by cooperative engagement, building 
>>> consensus,
>>> and working hard to implement and evaluate.  Specifications, 
>>> example
>>> scenes
>>> and software implementations are the proof points.
>>>
>>>
>>>
>>> Not listening to repeated answers makes repetition of questions of
>>> limited
>>> use.  "Too long didn't read" indeed.
>>>
>>>
>>>
>>> Using your issues to help define issues/pros + cons/resolutions 
>>> can
>>> contribute to a constructive working group process that has a lot 
>>> of
>>> usefulness.
>>>
>>>
>>>
>>> Traits like "dominant" or popular or common or whatever can be 
>>> good
>>> guidelines, but they are not the bottom line.  Well-defined, 
>>> repeatable
>>> functional correctness is.  This is why we have specifications, 
>>> examples,
>>> implementation and evaluation - for HTML as well as X3D.  This is 
>>> why we
>>> have cooperation between standards development organizations like 
>>> W3C and
>>> Web3D.  That is why we have standardization strategies for HTML5, 
>>> MAR/VR
>>> etc. all worked out collaboratively and posted online.  That is 
>>> why
>>> today we
>>> are NOT saying "well a couple of people made a personal decision 
>>> 5-10-20
>>> years ago that we are forced to live with."
>>>
>>>
>>>
>>> I hope that this note helps explain to everyone how we continue to 
>>> make
>>> progress.
>>>
>>>
>>>
>>>
>>>
>>> On 6/7/2016 9:29 PM, Leonard Daly wrote:
>>>
>>>> Wednesday (8 June 2016) X3D WG call is dedicated to discussion 
>>>> X3D V4.
>>> Several people (including myself) have commented on the ideas over 
>>> the
>>> last
>>> couple of years. I am going to state my current position here. I 
>>> don't
>>> think
>>> it differs much from my position a year ago; however, I'm sure 
>>> there have
>>> been some clarifications.
>>>
>>>>
>>>
>>>> tl;dr
>>>
>>>>
>>>
>>>>     X3D needs to run in the HTML5/DOM environment. A few nodes 
>>>> need
>>>> to be
>>> removed, but all capabilities remain.
>>>
>>>>
>>>
>>>>     Preliminary proposed V4 document at:
>>> <http://tools.realism.com/specification/x3d-v40>
>>> http://tools.realism.com/specification/x3d-v40
>>>
>>>>
>>>
>>>>
>>>
>>>> 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?
>>>
>>>>
>>>
>>>> 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.
>>>
>>>>
>>>
>>>> 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.
>>>
>>>>
>>>
>>>> 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.
>>>
>>>>
>>>
>>>> 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.
>>>
>>>>
>>>
>>>> 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.
>>>
>>>>
>>>
>>>> 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.
>>>
>>>>
>>>
>>>> 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.
>>>
>>>>
>>>
>>>>
>>>
>>>> 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.
>>>
>>>>
>>>
>>>> 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.
>>>
>>>>
>>>
>>>> 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.
>>>
>>>>
>>>
>>>> -- 
>>>
>>>> *Leonard Daly*
>>>
>>>> 3D Systems & Cloud Consultant
>>>
>>>> X3D Co-Chair on Sabbatical
>>>
>>>> LA ACM SIGGRAPH Chair
>>>
>>>> President, Daly Realism - /Creating the Future/
>>>
>>>
>>>
>>>
>>>
>>> all the best, Don
>>>
>>> -- 
>>>
>>> Don Brutzman  Naval Postgraduate School, Code USW/Br
>>> <mailto:brutzman at nps.edu> brutzman at nps.edu
>>>
>>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA 
>>> +1.831.656.2149
>>>
>>> X3D graphics, virtual worlds, navy robotics
>>> <http://faculty.nps.edu/brutzman> http://faculty.nps.edu/brutzman
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> x3d-public mailing list
>>>
>>> <mailto:x3d-public at web3d.org> x3d-public at web3d.org
>>>
>>> <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>>>
>>
>>
>> --------------------------------------------------------------------------------
>>
>>
>>
>>> _______________________________________________
>>> x3d mailing list
>>> x3d at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d_web3d.org
>>>
>>
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
> -- 
>
> -------------------------------------------------------------------------
> Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH
> Trippstadter Strasse 122, D-67663 Kaiserslautern
>
> Geschäftsführung:
>  Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
>  Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats:
>  Prof. Dr. h.c. Hans A. Aukes
>
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> VAT/USt-Id.Nr.: DE 148 646 973, Steuernummer:  19/673/0060/3
> ---------------------------------------------------------------------------
>