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

doug sanden highaspirations at hotmail.com
Fri Jun 10 14:40:59 PDT 2016


> DOM integration: While I do think that good thinking on a spec. is
>  very necessary, I also think it is critical to work from existing
>  implementations or from building new implementation based on Xflow or
>  aframe. It is too easy to get carried away otherwise. My best idea at
>  this point is to work from cobweb but enhance it with a bridge between
>  the x3d graph and a new, constructed DOM graph.
>

I think some of these implementation ideas are very interesting, and it would be a shame if a new spec mandated them excluded.

e1 stability
d1 compiler
e1/d1  From the compiler domain, they would be seen as target technology variants -like ARM vs x86 vs x64- and nothing would be inherently excluded, as long as the upstream high-level LTS (long term stable) technology-agnostic specification was friendly toward downstream technology variants in general, and someone develops a 'compiler' to do the specific transforms.



________________________________
From: x3d-public <x3d-public-bounces at web3d.org> on behalf of Andreas Plesch <andreasplesch at gmail.com>
Sent: June 10, 2016 3:13 PM
To: X3D Graphics public mailing list
Subject: [x3d-public] [x3d] V4.0 Open discussion/workshop on X3D HTML integration

Wow, lots of good discussion and trying to understand the issues happening.

Before I may offer input to some of the discussed points, let me state that I find myself in agreement with many of Leonard's arguments although I do believe that it could be possible to have better backwards compatibility (probably at a performance cost in the web browser).

Time: x3d has a good, strict time model allowing for precise simulations. I do not believe cobweb follows that time model but I may be wrong. With some accounting and overhead it should be possible to implement the x3d time model but I am not sure it is that desirable.

Native, declarative 3d support in web browsers: At this point it would be a mistake to assume that web browser will natively support any declarative 3d scene formats in the near (or far) future. There are too many 3d solutions based on webgl already available. Keep in mind that web browsers even internally use their own javascript engines to implement HTML5 features in javascript, not compiled code. These js engines are actually byte code compilers which is pretty close to the metal. Without keeping performance in mind, it is possible to produce slow js code. But it is also possible to produce very performant js code if written carefully. Having said all this, I believe the way to get into web browsers would be to follow the svg example and define a x3d DOM and interfaces (then come up with a polyfill, and then also come up with a proof of concept implementation in C++ in mozilla, - a huge task which may be rejected).

webgl vs. opengl: webgl is more focused on the shader. This lets the GPU render very fast, potentially faster than the classic opengl pipeline. I do not believe there is any drawback using webgl only. It is all in how to get the data to the GPU.

Render loop: cobweb and x3dom render frames independent of waiting to changes to the scene graph to arrive at a finished state. To keep the web browser responsive, accepted practice is to not render as fast as possible but only as fast as necessary to have a good frame rate. This is accomplished by letting the web browser control when a new frame in a x3d scene needs to be rendered. So instead of a rendering loop, you will just see a requestAnimationFrame invocation with a callback which initiates the rendering of a new frame whenever the web browser requests it. Typically that happens every 1/60 s I believe if not too many other things are happening. This is a major difference between the x3d browser and the html5 web browser environment since in the web browser environment it is necessary to coexist in a friendly manner with other elements controlled by js scripts on the same web page.

plugin vs. js implementation: The traditional web binary plugin container was abandoned for all kinds of content for good reasons. cobweb already provides SAI type html integration. I do not think the spec. needs any changes for this type of integration. cobweb only adds a html <x3d> tag which is different from the x3d <x3d> element. It simply refers to an .x3d file in an url attribute. This html <x3d> tag could be formalized in the spec. DOM integration like in x3dom is very desirable, however, and is what would be expected by web programmers.

DOM integration: While I do think that good thinking on a spec. is  very necessary, I also think it is critical to work from existing implementations or from building new implementation based on Xflow or aframe. It is too easy to get carried away otherwise. My best idea at this point is to work from cobweb but enhance it with a bridge between the x3d graph and a new, constructed DOM graph.

Roughly, I can see that cobweb could construct a DOM graph by adding html elements to the page while parsing the x3d xml. Then, all x3d nodes could be registered as new html elements which allows 'life cycle' management and lets js catch any changes to the constructed x3d DOM graph (this is what x3dom does). Then, changes to the attributes of html elements could be transferred to changes in the fields of the corresponding x3d nodes by SAI methods. In turn, cobweb updates the scene. In the extreme, this means that cobweb could start with an empty scene. It is then populated as the web browser recognizes registered x3d elements on the web page, and the bridge calls the appropriate SAI methods. The bridge could be pretty stupid this way and just needs to maintain a map between the html and x3d graphs.

I may try to explain this to Holger and see if he agrees and if he would be inclined to accept help implementing this. But this would not happen any time soon and would slow down cobweb due to the bridging work. One could have a non-DOM and a DOM cobweb version.

-Andreas

--
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160610/6c4d0db5/attachment-0001.html>


More information about the x3d-public mailing list