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

Thu Jun 16 22:05:29 PDT 2016

[Resent, as the original email was apparently not relayed through the list]

Hi all,

Am 09.06.2016 um 04:56 schrieb Don Brutzman:
> 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.

Well, I do not think it is unreasonable at least as an option. Node.js
implements a fast JS engine that can be embedded in any application.
Jsdom then adds a DOM implementation that aims at offering a headless
browser (but still has some limitations).

This could be an environment where the proposed approach (a Dec3D core
plus WebComponents layer on top, e.g. for X3D) could simply run. One
could then connect that declarative layer to a custom engine (in the
app), which could be the old native X3D browser engine, a game engine,
or anything else. We plan to look into this for our server-based
rendering engine later this year.

Essentially, any of these would have the same Dec3D layer on top, which
could make Dec3D much more appealing in general.

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

It certainly has a lot of value.

On the other hand, WebComponents offer a lot of the value (if not more)
and are now  a very appealing, standardized way for this in the DOM. I
am not sure there is a need to implement something else -- except for
backward compatibility. And then this might be possible to implement in
a WebComponent itsef (have not looked into this). There is a lot of
value in staying close to the Web technology stack and use what is
already provided and use by many.

Best,

	Philipp

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

-- 

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

-- 

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