[x3d-public] DOM integration with cobweb

Andreas Plesch andreasplesch at gmail.com
Thu Sep 15 07:16:42 PDT 2016

Ok, I thought about relaying x3d sensor events to html DOM events a bit
more and settled (for now) on requiring a x3d sensor (eg. TouchSensor).

First, it turned out it was not necessary to modify cobweb in order to come
up with a first demonstrator implementation of a x3d event to DOM event


In the HTML each such sensor element would then be able to have listeners
to DOM events with names corresponding the field names such as
'hitPoint_changed' or 'isOver'. So a web page programmer can then use
myhandlerfunction(event)) .The shortcut attributes onhitPoint_changed and
such may be expected to be available as well but it would clutter the x3d
xml and invalidate it. It is also not really necessary.

In addition, it should be possible to also provide events with more
familiar names such as 'click' as aliases for the field events.

After carefully reading through the javascript SAI spec. I found the
field.addFieldCallback() SAI function here:


It does not seem to have a corresponding service in the SAI spec.:


But I was glad to see that the addFieldCallback() function is implemented
in cobweb (although a little different from what the terse spec. suggests)
and is a great way to hook into the field events. This is really what my
relay is based on.

The current implementation is restricted to TouchSensor but should cover
all of its field events. For the event object which is passed to the DOM
handler function, I added a .value property which has the value of the
field, but also a .fields property which is an object containing all of the
nodes fields for easy access. See example, and implementation in

It should be possible to generalize that to all sensor nodes, in fact the
code is designed that way. Perhaps it makes sense to attach these field
callbacks to all fields on all nodes, not just sensor nodes ?  To be able
to pick up on interpolator events, for example ? It feels like this could
affect performance since a lot of DOM events may be dispatched ? Well, it
would come down to trying it.

Any feedback or questions welcome,


On Wed, Sep 14, 2016 at 6:34 PM, Joe D Williams <joedwil at earthlink.net>

> What I have in mind is to require x3d sensor nodes, unlike x3dom which
> dispatches events on any shape.
> Fine, I would like to see that construction rather than the onclick and
> html script.
> All Best,
> Joe
> ----- Original Message ----- From: "Andreas Plesch" <
> andreasplesch at gmail.com>
> To: "X3D Graphics public mailing list" <x3d-public at web3d.org>
> Sent: Wednesday, September 14, 2016 12:58 PM
> Subject: Re: [x3d-public] DOM integration with cobweb
> Hello,
>> thanks to a transcontinental flight I made some progress on my bridge
>> between the cobweb x3d scene graph and the DOM tree with x3d elements.
>> Here are two simple examples:
>> https://andreasplesch.github.io/cobweb_dom/addremoveNode.xhtml
>> This is the x3dom add/remove nodes example (
>> http://examples.x3dom.org/example/x3dom_addRemoveNode.html) with minor
>> adjustments for xhtml but unchanged javascript control code.
>> https://andreasplesch.github.io/cobweb_dom/index.xhtml
>> This demonstrates both how html attribute changes are picked up by the x3d
>> scene graph, and how adding and removing html elements also is reflected
>> in
>> the x3d scene graph. The box trafos are root nodes, and the removable
>> Material node is a field of the Shape node.
>> I put the bridge code in a separate file, so it can now be easily added to
>> any page.
>> The next step would be to translate x3d sensor events into appropriate DOM
>> events. This will require probably more modification of the cobweb code
>> itself and a clear strategy.
>> What I have in mind is to require x3d sensor nodes, unlike x3dom which
>> dispatches events on any shape.
>> -Andreas
>> On Mon, Sep 5, 2016 at 6:09 PM, Andreas Plesch <andreasplesch at gmail.com>
>> wrote:
>> I could generalize the handling of attribute changes by using the cobweb
>>> parser, with only a few lines (but a lot of investigation). This means
>>> that
>>> most field types should be accessible from the DOM now. However, I only
>>> tested with diffuseColor. I also figured out how to immediately apply the
>>> changes by triggering a set event for the changed field.
>>> Adding and removing of nodes is next. I think statements also need
>>> special
>>> treatment. For external statement changes and prototype changes, it may
>>> be
>>> best to reload the whole scene (?) .
>>> I adopted the x3dom basic attribute manipulation example:
>>> https://andreasplesch.github.io/cobweb_dom/jqueryui_cobweb.xhtml
>>> It worked without changes to the control code and demonstrates that the
>>> mutation observer is fast. This means it may be time to provide this as a
>>> simple js library to add on to cobweb pages since there is enough
>>> functionality.
>>> -Andreas
>>> On Sun, Sep 4, 2016 at 12:40 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
>>> --
>>> Andreas Plesch
>>> 39 Barbara Rd.
>>> Waltham, MA 02453
>> --
>> 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

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/20160915/8ff72946/attachment.html>

More information about the x3d-public mailing list