[x3d-public] DOM integration with cobweb

Andreas Plesch andreasplesch at gmail.com
Sun Sep 4 05:53:31 PDT 2016

Yeah, I am pretty excited although one does need an appreciation for these
abstract concepts of DOM vs. scene graph.

The idea is have both in parallel with synchronization. In my example I use
the DOM MutationObserver facility to trigger x3d updates after changes to
the DOM which seems to be a good fit especially since it works for unknown
HTML elements.

The practical goal is to make Cobweb easy to use for JS web programmers.


On Sep 4, 2016 1:20 AM, "John Carlson" <yottzumm at gmail.com> wrote:

> On Sep 4, 2016 12:41 AM, "Andreas Plesch" <andreasplesch at gmail.com> wrote:
>> Here is a thought experiment which developed into a strawman
>> implementation.
>> First the result:
>> https://andreasplesch.github.io/cobweb_dom/index.xhtml
>> After clicking the new color button, and moving the mouse, the color of
>> the box should change.
>> The interesting feature here is that the color change is triggered by a
>> modification of the diffuseColor _attribute_ of the Material _html_
>> element, in a way that should be possible to generalize to most (all)
>> fields in x3d nodes.
>> This is the x3dom pattern of controlling a x3d scene. But here I use
>> cobweb as the x3d browser. Cobweb has very good coverage of the x3d
>> standard including Prototypes, scripting and the SAI. Being able to use
>> both, internal x3d scripting and external control using the DOM could be
>> quite fruitful.
>> I had to modify cobweb only slightly based on an idea developed during
>> the discussion around the id attribute inspired by x3dom. The main change
>> is to attach a reference to the generated x3d scene graph node from the DOM
>> element during parsing. This then enables access from the DOM to the x3d
>> node.
>> The next step would be to expand to all field types, perhaps reusing the
>> cobweb parser, or SAI functions. and to allow for removal and addition of
>> nodes.
>> [If all works, there is the issue of <script> being claimed by the web
>> browser. I think the only solution may be to break backward compatibility
>> and allow <x3dScript> as an alias to <script>]
>> The examples also shows how to use inline x3d rather than an url with
>> cobweb. Since cobweb is strict about XML, this is only possible if the html
>> page has xhtml encoding. xhtml in turn triggered an issue with the fps
>> counter display and the context menu, as a side note.
>> The code is all on github: https://github.com/andreasplesch/cobweb_dom
>> I had to learn a lot about cobweb (and jquery and AMD...) and look
>> forward to any feedback or even hands-on contributions ? Perhaps the cobweb
>> team is also interested ?
>> -Andreas
>> --
>> Andreas Plesch
>> 39 Barbara Rd.
>> Waltham, MA 02453
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160904/b2411b3d/attachment.html>

More information about the x3d-public mailing list