[Fiware-miwi] three.js WebComponents

[Jonne Nauha]

Yeah WebComponents are nice. I've already implemented quick tests for
Tundras Entity and IComponent (common interface for all components,
WebComponents has inheritance so it plays nicely into this) like 3-4 months
ago in our WebRocket web client. At that point I left it alone, I wanted to
have my JS code that implements the component in a .js file not inside a
.html polymer template. Currently I'm using requirejs for the whole repo as
the amount of code and dependency tracking started to get out of hand, so I
wanted a modular system where I can tell the system what each module needs
as a dependency. This has been great but will make writing comp
implementations in a WebComponent html template a bit trickier as it would
expect everything to in global scope, requierejs effectively removes
everything from global scope.

I have also a simple DOM integration plugin for WebRocket. If you want to
turn it on (configurable when you construct the client instance) it will
mirror the whole scene/entity/component/attribute chain in to the DOM as my
own
<scene><entity><component><attribute/>...</component>...</entity>...</scene>
nodes. This would be trivial to change to create XML3D nodes, but I cant
test that out before everything on the asset side that has been discussed
are complete. Because nothing would simply render if I wont provide the
Ogre asset loaders for XML3D and it knowing how to used DDS textures. What
I would prefer even more is to just pass you the geometry as data, because
I have my own fully working AssetAPI to fetch the assets, and I have my own
loaders for each asset type I support. I would kind of be duplicate work to
re-implement then as XML3D loaders, when I alreayd have the ready typed gl
arrays to give to you right now.

For my current DOM "mirroring" plugin, if you manipulate the attributes in
the DOM they wont sync up back to the in mem JavaScript attributes. So
currently its read only. I haven't really had the need to implement the
sync the other way as we are perfectly happy living in JS land and using
the WebRocket SDK API to write our application logic. The declarative side
is less important for Meshmoon WebRocket as the scenes are always coming
from our Tundra based servers and not declared on the html page itself. For
FIWARE the declarative and DOM side is more important and more in focus of
course so I understand the direction of the talks and why XML3D is an
valuable asset.

Instantiating Scene, Entity and each of the Component implementation from a
WebComponent template would solve this problem, as its designed to
encapsulate the JS implementation and it has a great way to get callbacks
when any attribute in the DOM node is manipulated. It can also expose DOM
events and fire them, not to mention normal functions eg. $("<placeable>",
entityNode).setPosition(10,20,30); so you dont have to use the raw DOM api
to set string attributes by random. These functions would have type
checking and not let you put carbage into the attributes. I believe the
attribute changed handler can also effectively abort the change if you are
trying to put a boolean to a Vector3 attribute. This all is great and would
just require us WebRocket devs to port our current EC implementations to
WebComponent templates.

But here is where I get confused. So you would be fine by us implementing
Tundra components as WebComponent templates (as said this would be fairly
trivial). How would XML3D then play into this situation? Would it now
monitor our DOM elements instead of the ones you specify (afaik eg. <group>
<mesh>)? Can you open up this a bit?

*UI and WebComponents*

WebComponents are also being looked at in our 2D-UI GE, but to be frank
there is very little to do there. The system is incredibly simple to use.
You include polymer.js to you page, add <link> tags to your Polymer style
.html templates, then you just use the tags declared in them on the markup
or you create the DOM nodes during runtime from JS with your preferred
method. I'm having a bit of hard time figuring out what we should focus on
in the 2D part for WebComponents. I mean they are there and you can use
them, you don't need any kind of special APIs or supporting code from our
side for them to work. Only thing I can think of is implementing some
widgets and maybe 3D related templates for anyone when they use WebTundra.

Best regards,
Jonne Nauha
Meshmoon developer at Adminotech Ltd.
www.meshmoon.com


On Sat, Nov 2, 2013 at 1:21 PM, Philipp Slusallek <Philipp.Slusallek at dfki.de
> wrote:

> Hi Toni, all,
>
> I have now looked at video on the main Polymer page (
> http://www.polymer-project.org/), which is actually very nicely done.
> They make a very good point why its advantageous to put things in the DOM
> compared to pure JS applications (or even Angular, which already uses the
> DOM). They highlight that with WebComponents (Polymer is a polyfill
> implementation of them) this becomes now even easier and creates an
> object-oriented aspect for HTML.
>
> BTW, this aspect is exactly what we were aiming at when we suggested the
> use of WebComponents for the 2D-UI Epic in the objectives of the FI-WARE
> Open Call and I think we should push even more in this direction, similar
> to what I wrote in response to Jonne's email earlier.
>
> Regarding the mapping: We already have the mapping of 3D to the DOM
> (XML3D) as well as many modules that build on top of that mapping (Xflow
> with animation, image processing, and AR; portable materials, etc.). I see
> no reason why we should throw this out just because there is a slightly
> different way of doing it.
>
> I would even speculate that if we would try to offer similar functionality
> that at the end we would end up with something that would pretty much
> resemble XML3D, maybe with a slightly different syntax. There are usually
> not many way to do the same thing in a good way.
>
> What I would support 100%, however, is that we try to use Web*Components*
> to implement the *ECA components* (and possibly entities). Essentially for
> the same reasons explained in the video. That makes a lot of sense in the
> Web context and is fully compatible with the DOM and all the DOM-based
> frameworks that can then be used as well on this data.
>
> I have been saying for a long time that we have had libraries in C/C++.
> Just porting them to JS to run in the Web does not give us any advantages
> at all (likely only disadvantages like performance and an inferior
> language). Its only if we embrace the key elements of the Web -- and the
> runtime DOM arguably is the core of it all -- that we can tap into all the
> benefits of the Web.
>
> And THE key advantage of the DOM is that you get *way more* than the sum
> of the pieces when putting things together. Instead, of making sure that
> one library can talk to all the others (which gets you into an N^2
> complexity problem), each component only needs to work with the DOM
> (constant effort per component and you have to deal with one data structure
> anyway, so its essentially no overhead anyway). Then, you get the benefit
> from all other components *automatically and completely for free* (jquery
> and all the other tools "just work" also with XML3D, and we should be able
> to use XML3D within Polymer also).
>
> Note, that none of the Web technologies discussed here (WebComponents,
> Polymer, Angular, etc.) would work at all if they would not use the DOM at
> their core. Angular for example depends on the DOM and just allows a nicer
> binding of custom functionality (controller implemented in JS) to the DOM.
>
> This all applies exactly the same way also to 3D data -- at least
> logically. However, on the implementation side 3D is special because you
> have to take care of large data structures, typed arrays, and so on. This
> is what the main work in XML3D was all about. Why should someone invest all
> the effort to do it again for likely very similar results in the end?
>
> We can talk about using three.js as a renderer, though, but I would not
> touch the 3D DOM binding and data model that we already have in XML3D
> (unless someone comes with very good reasons to do so).
>
>
> Best,
>
>         Philipp
>
>
> Am 02.11.2013 09:27, schrieb Toni Alatalo:
>
>  On 02 Nov 2013, at 09:09, Philipp Slusallek <Philipp.Slusallek at dfki.de>
>> wrote:
>>
>>> Nice stuff. from my perspective there are two ways to look at this work:
>>> One is to provide high level UI elements on top of a three.js
>>> implementation and the other is the start of creating a declarative layer
>>> on top of the three.js renderer. This seems more along the first line but
>>> both should be similarly interesting to us.
>>>
>>
>> Indeed.
>>
>>  It great to see that other people are coming up with similar ideas now.
>>> It would be good to get the message about our XML3D design and
>>> implementation to these people out there. That way we could improve what we
>>> already have instead of reinventing the wheel.
>>>
>>
>> That was my immediate first thought as well: it seemed like people have
>> started to reinvent declarative 3d for the web from scratch. That’s why I
>> asked whether they knew about the existing work — I understood that this
>> Josh Galvin person (don’t know him from before) who made the Spinner demo,
>> did (am not sure).
>>
>> Thanks for the views and pointers, I’ll keep an eye open for talks about
>> this (actually just joined the #three.js irc channel on freenode yesterday,
>> haven’t been involved in their community before really — Tapani from us has
>> been hanging out there though). They seem to communicate most in the github
>> issue tracker and pull requests (which I think is a great way).
>>
>> I also did not find an e-mail address to the polymer-threejs person, but
>> kaosat.net is his personal site and apparently he made the original
>> announcement of the declarative three.js thing in August in Google+ so I
>> figure e.g. replying there would be one way to comment:
>> https://plus.google.com/112899217323877236232/posts/bUW1hrwHcAW .. I can
>> do that on Monday.
>>
>> BTW it seems that this guy is into hardware and cad and all sorts of
>> things and declarative 3d xml is just a side thing for fun, perhaps related
>> to his work on some cad thing — is not like he’d be pursuing a career or a
>> product or anything out of it.
>>
>> It seems like a straightforward mapping of the three.js API to xml
>> elements: what I struggle to understand now is whether that’s a good
>> abstraction level and how does it correspond to xml3d’s vocabulary.
>>
>> ~Toni
>>
>>  It would be good if you can point people also to our papers from this
>>> year (http://graphics.cg.uni-saarland.de/publications/). They explain a
>>> lot of the background of why we have chose thing to work the way they work.
>>>
>>> More specifically:
>>> -- The "xml3d.js" paper explain a lot about the design of XML3D and its
>>> implementation (https://graphics.cg.uni-saarland.de/2013/xml3djs-
>>> architecture-of-a-polyfill-implementation-of-xml3d/).
>>> -- The "Declarative image processing" paper explains all the advantages
>>> one gets from exposing processing elements to the DOM instead of
>>> implementing them only in some JS libraries (https://graphics.cg.uni-
>>> saarland.de/2013/declarative-ar-and-image-processing-on-
>>> the-web-with-xflow/).
>>> -- And the 2012 paper on "XFlow" shows this usage for animation (
>>> https://graphics.cg.uni-saarland.de/2012/xflow-
>>> declarative-data-processing-for-the-web/)
>>>
>>> Getting into a constructive discussion with some of these three.js
>>> people would be a good thing. I tried to find an email address for the
>>> polymer-threejs person but could not find any. Feel free to farward this
>>> email to him (and maybe others). I would love to get their feedback and
>>> engage in discussions.
>>>
>>>
>>> Best,
>>>
>>>         Philipp
>>>
>>> Am 02.11.2013 00:38, schrieb Toni Alatalo:
>>>
>>>> Apparently some three.js user/dev has gotten inspired by WebComponents &
>>>> the Polymeer and written https://github.com/kaosat-dev/polymer-threejs:)
>>>>
>>>> Now another guy has continued with
>>>> https://github.com/JoshGalvin/three-polymer — there’s a demo of custom
>>>> element (‘spinner’), similar to the Door case discussed here earlier.
>>>>
>>>> Had a brief chat with him, will return to this later but was fun to see
>>>> the minimal webgl web component example there as that has been in our
>>>> agenda.
>>>>
>>>> ~Toni
>>>>
>>>> 01:01 *<* galv*>* https://github.com/JoshGalvin/three-polymer added
>>>> support for more basic geometry types
>>>> 01:02 *<* galv*>* Going to do materials next
>>>> 01:25 *<* *antont**>* galv: hee - are you aware of these btw?
>>>> http://www.w3.org/community/declarative3d/ , e.g.
>>>> https://github.com/xml3d/xml3d.js
>>>> 01:27 *<* galv*>* yeah, different level of abstraction
>>>> 01:27 *<* *antont**>* perhaps
>>>> 01:28 *<* galv*>* I expect people to wrap up their game objects
>>>> 01:28 *<* galv*>* aka "spinner"
>>>> 01:28 *<* galv*>* (index.html)
>>>> 01:29 *<* *antont**>* we've been also planning to enable saying things
>>>> like <door> if that's what you mean
>>>> 01:30 *<* *antont**>* right, seems like the same idea
>>>> 01:31 *<* *antont**>* very cool to see, gotta check the codes etc later
>>>> .. but sleep now, laters
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Fiware-miwi mailing list
>>>> Fiware-miwi at lists.fi-ware.eu
>>>> https://lists.fi-ware.eu/listinfo/fiware-miwi
>>>>
>>>>
>>>
>>> --
>>>
>>> ------------------------------------------------------------
>>> -------------
>>> 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)
>>> USt-Id.Nr.: DE 148646973, Steuernummer:  19/673/0060/3
>>> ------------------------------------------------------------
>>> ---------------
>>> <slusallek.vcf>
>>>
>>
>>
>
> --
>
> -------------------------------------------------------------------------
> 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)
> USt-Id.Nr.: DE 148646973, Steuernummer:  19/673/0060/3
> ------------------------------------------------------------
> ---------------
>
> _______________________________________________
> Fiware-miwi mailing list
> Fiware-miwi at lists.fi-ware.eu
> https://lists.fi-ware.eu/listinfo/fiware-miwi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20131102/5437e34d/attachment.html>