Hi,
Sounds really good. I would suggest that we start defining the
WebComponent components and their interfaces soon (of course, based on
what you already use, but have a quick process to discuss if there could
be improvements) and then go from there. In parallel we can check that
XML3D works well with WebComponents and Polmer.
I believe we have talked about that a bit already but I am not sure we
have a specification for the WebComponents yet. Torsten, can you work
with whoever feels responsible on the Finish side to come up with a
common specification (somewhere on the private pages for now)?
Sounds like we are all working in the same direction -- which is great!
I can't wait to see the first avatars walking to Oulu city (or some
other place) in any Web browser :-).
Best,
Philipp
Am 03.11.2013 08:23, schrieb Toni Alatalo:
> Again a brief note about a single point:
>
> On 03 Nov 2013, at 09:12, Philipp Slusallek <Philipp.Slusallek at dfki.de
> <mailto:Philipp.Slusallek at dfki.de>> wrote:
>> Also there might be convenient components that would make 3D app
>> programming with XML3D and WebComponents much easier. So for instance
>> having the XML3D-based components automatically define the set of
>> variable that need to be synchronized, registering them with the
>> networking module (if available), and making sure this all gets done
>> in the background would be excellent. Also providing an 3D avatar
>> WebComponent with embedded animations and such would be ideal. It
>> would be excellent if we could provide to Web developers a whole set
>> of predefined and modular WebComponents that they could just use to
>> create 3D worlds with behaviour.
>
> This is what realXtend has been doing for several years — just outside
> the Web — and plan is to continue doing the same on the Web as well :)
>
> That’s how it works in the native Tundra, and plan for this fi-ware work
> to produce the web client (which also works standalone, like the native
> one does too) is to implement the same. That’s also how it works in
> Chiru-WebClient and WebRocket, i.e. the pre-existing WebTundra’s.
>
> ~Toni
>
>> The one really big issue where I still see a lot of work on finding
>> new solutions (not just implementation but real conceptual work) is
>> dealing with the hugely varying set of input devices. One person has
>> mouse and keyboard, the next has only a multi-touch surface, the next
>> is using a Kinect, while yet another other is using a Wii Remote, etc.
>> A single Web app will have to work with all of those situations
>> simultaneously (on different devices, though). Letting Web application
>> and their developers handle this in their apps will simply not work
>> and be frustrating for developer and users.
>>
>> We have started to work on a concept for this but this has not gone
>> very far yet. The coarse idea is that applications use virtual
>> interaction elements to say what kind of input (metaphor) they are
>> expected (e.g. selection of an object, moving an object). These are
>> modules that can be configured and instantiated. They can also be
>> nested within/on top each other (like non-visible dialog boxes)
>> dynamically to have a hierarchical finite state machine of interactions.
>>
>> These interaction elements would consist of the interaction logic as
>> well as (optionally) some interaction gadgets that visually represent
>> the possible interactions (like handles to move and rotate an object).
>> The key thing is that these interaction elements would be independent
>> of the application, anyone can use them, and we could develop a whole
>> library of them to cover the wide range of input metaphors that
>> applications use (but applications can extend them with their own if
>> needed).
>>
>> There are two extensions to this approach: (i) instead of having a
>> single interaction element for each interaction metaphor we could have
>> interfaces for them and develop entire user interface libraries that
>> each have a different look and feel but still implement the same basic
>> interaction metaphor. (ii) One could also design them such that users
>> can change the mapping of the devices used for certain actions. Think
>> of it as a reconfigurable gamer mouse, where the user can assign
>> different action to certain buttons, gestures, or such. So a user can
>> say, I will use the mouse to select objects but move them with the
>> cursor keys (for a stupid simple example). These would be optional
>> extensions for later, though.
>>
>> It would be great to work on those aspects together if this would be
>> interesting to anyone of you. You probably have quite some experience
>> in terms of good UI for 3D games/apps. Identifying, generalizing, and
>> implementing them as a reusable set of components would a great step
>> forward for 3D apps on the Web (or elsewhere). This would make great
>> papers for conferences as well!
>>
>> If you want to go that way, we should probably set up a special
>> session for discussing this in more detail.
>>
>>
>> Best,
>>
>> Philipp
>>
>> Am 02.11.2013 17:35, schrieb 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 <http://www.meshmoon.com/><http://www.meshmoon.com
>>> <http://www.meshmoon.com/>>
>>>
>>>
>>> On Sat, Nov 2, 2013 at 1:21 PM, Philipp Slusallek
>>> <Philipp.Slusallek at dfki.de
>>> <mailto:Philipp.Slusallek at dfki.de><mailto: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/
>>> <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
>>> <mailto:Philipp.Slusallek at dfki.de><mailto: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, butkaosat.net <http://kaosat.net/><http://kaosat.net
>>> <http://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
>>> <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/
>>> <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/
>>> <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/
>>> <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/
>>> <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
>>> <https://github.com/kaosat-dev/polymer-threejs> :)
>>>
>>> Now another guy has continued with
>>> https://github.com/JoshGalvin/__three-polymer
>>> <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
>>> <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/
>>> <http://www.w3.org/community/declarative3d/> , e.g.
>>> https://github.com/xml3d/__xml3d.js
>>> <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 <mailto:Fiware-miwi at lists.fi-ware.eu>
>>> <mailto:Fiware-miwi at lists.fi-ware.eu>
>>> https://lists.fi-ware.eu/__listinfo/fiware-miwi
>>> <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
>>> <mailto:Fiware-miwi at lists.fi-ware.eu><mailto: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
---------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slusallek.vcf
Type: text/x-vcard
Size: 441 bytes
Desc: not available
URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20131103/9bade592/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy