From Philipp.Slusallek at dfki.de Sun Sep 1 08:43:22 2013 From: Philipp.Slusallek at dfki.de (Philipp Slusallek) Date: Sun, 01 Sep 2013 08:43:22 +0200 Subject: [Fiware-miwi] Campus Party Europe (FI-WARE) - Workshop 3 In-Reply-To: <1775AEE2-1AF3-4A55-99E8-A7EC3AB52214@playsign.net> References: <883b96a108f34a759b50cf85cd572f19@SRV-MAIL-001.zhaw.ch> <521DFA36.4040807@tid.es> <20130829061959.GD62563@ee.oulu.fi> <521EF037.7010605@tid.es> <521F60E7.3000104@tid.es> <20130829155344.GH62563@ee.oulu.fi> <52202C89.40509@dfki.de> <1775AEE2-1AF3-4A55-99E8-A7EC3AB52214@playsign.net> Message-ID: <5222E20A.4040109@dfki.de> Hi, Am 01.09.2013 06:59, schrieb Toni Alatalo: > just a brief note that all that sounds very cool, and about some of > the work done here so far: > > Besides the campus party preparations, we have started the actual > platform implementation work from the opposite end: > > 1. by implementing one of the technical use cases, the dynamic > n-player Pong. With three.js & ammo.js (bullet compiled with > emscripten) without any entity-model first. There's also an > experimental networked version using WebRTC for the bat & ball > positions sync. Idea is to then keep porting the use case to the > generations of the platform which should make the game implementation > both easier and better. I think we could have many this kind of > minimal technical use cases / tests, even 10-20 (many could be much > simpler than even the pong is). We are using WebRTC already for cloud rendering which works nicely as well. We have not used it for the synchronization yet, but this is certainly on the list of things to do. > and 2. by making a performance test for using DOM vs. pure JS for all > the synchronised application/scene data. First result is that using > the DOM is ~300x slower but the question whether it's still fast > enough needs more analysis still. Can you make your test cases available? There are very different things that need to be done to a scene graph and depending on the operation the overhead will be very different. 300x seems way off -- unless you may be doing something like geometry manipulation through DOM string attributes (which we obviously are not doing because we use Xflow). We should resolve this quickly. > Outside FI-WARE, the new version of the high-detail Oulu 3d city > model has progressed a lot during the past months and weeks, we > (well the modelling companies doing it) are integrating it together > starting Monday so we can use it for rendering performance & > scalability etc. testing and improvements on the platform side soon. > We probably get to start the tests next week anyhow at least with the > old much smaller & simpler model now that the campus party > preparations are mostly done AFAIK. It would be great to also get access to these models (in whatever format). As you know, we have integrated loading of external resources directly from XML3D, with the option of converting between different formats on the fly. So, while one could convert the entire model into a format that XML3D can read, the best option would be to store it somewhere and provide a RESTful interface. Then any XML3D scene could simply reference these models directly and asynchronously load them when needed. Another option this enables is the inclusion of such models into the new POI we could also see that we reference such models from our new POI scheme we are developing, which allows to directly reference arbitrary (even animated) 3D scenes. > We'll put more info about these and the pointers to the codes > available before the meeting using the new mifi-list, let's continue > the discussion there. Yes, we should move the discussion over, now that it seems to be active. Actually, I am copying this email also to this list. Anyone who is not getting two copies of this email should talk to Christof to get added to the list. Also see his other email about administrative things that need to be done -- if you have not done so yet. One issues that I have contemplated with Christof is to add smaller, more targeted lists. There are many people on the list that not all will be interested in everything. KIARA already has a separate email list, obviously. A WeX specific list and maybe even some even more targeted (e.g. server/client and core/app, or even a GE-specific one each) might make sense. Even more importantly: Now that we also have the Wiki up and running we need to urgently start writing up our architecture and definition of the GEs. The deadline is end of this month. Since there will certainly be discussion on how to best organize it, we need to get early versions up and running as fast as possible. Christof is setting up a template that we can then build upon and fill in with content. Best, Philipp > > Cheers, > ~Toni > > On Aug 30, 2013, at 8:24 AM, Philipp Slusallek wrote: > >> Hi all, >> >> Sorry but I had other meetings yesterday and could not joint on such a >> short notice (morning would have worked for me, though). >> >> I appreciate the work into doing this competition but would suggest that >> we also make clear that the FI-WARE goal is a fully integrated version >> of the Adv-UI technology using our service-oriented approach and a >> modular architecture with all the different Epics of our Adv-UI. >> >> Over the last months we have been very active on our side and now have a >> first synchronization framework that uses the ECA model (based on the >> realXtend model) for its data and uses the KIARA framework for the >> network synchronization. We are currently connecting this to XML3D such >> that a demos/competition like the one that is planned for London will be >> very easily possible and be fully integrated with HTML-5 and XML3D on >> the client side. >> >> We also have some very interesting new POI technology (that we developed >> for FI-C2) that brings together GIS and GPS location, various forms of >> AR markers, XML3D based, animated, and interactive 3D models, as well as >> IoT data streams (not implemented yet). >> >> We also have our own very light-weight sync server now but the framework >> should be easily usable also from realXtend such that we should be able >> use it as a server as well. Thus, we would already have two independent >> instances of a synch server for WP13. >> >> We also are still planning to integrate the highly scalable Intel DSG >> technology into our server once the basic functionality is done. This is >> also where we want to connect the sync functionality/server with other, >> independent services such as server-based rendering, etc. >> >> After London we should set up a (virtual?) meeting and see how we can >> best integrate all the pieces that we have so far. Hopefully we will >> finally have the Wiki infrastructure and email lists working by then. >> >> >> Best, >> >> Philipp >> >> P.S.: Please also keep Torsten Spieldenner in the loop (in CC, you know >> him from Winterthur) as he will be helping me from the technical side in >> WP13. >> >> Am 29.08.2013 17:53, schrieb Erno Kuusela: >>> Here are my notes from the confcall, biased toward >>> workshop part 1 people. Maybe others can correct if i misunderstood >>> or missed something. >>> >>> - the onsite challenge most relevant for us is "best web based ui", >>> (reads also @ http://www.campus-party.eu/2013/fi-ware.html) >>> >>> - campuseros can participate/get prizes with same entry for global compo >>> as well as the onsite challenge >>> >>> - network: no wifi - wired only >>> >>> - 9 am friday is the challenge entry deadline, after that evaluation/judging >>> >>> - workshop area takes 50 ppl and 40 (or 14?) ppl already - possible >>> that have to implement a waiting list or other measures for dealing >>> with overcrowding >>> >>> - there's an area reserved for the hackathon >>> >>> - meeting about workshop tuesday ~ 19:00? >>> >>> other challenge catagories onsite (in this hackathon) >>> - best cloud app >>> - best iot related app >>> - best developer under 21 >>> >>> same entry can compete in multiple categories so we should >>> look into building apps that talk to the iot sensor based stuff, >>> will find out onsite what kind of sensor things are available. >>> >>> other hackathons >>> - hacking for something better >>> http://www.campus-party.eu/2013/H4SB.html >>> >>> Erno >>> >> >> >> -- >> >> ------------------------------------------------------------------------- >> 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 >> --------------------------------------------------------------------------- >> > -- ------------------------------------------------------------------------- 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: From toni at playsign.net Mon Sep 2 13:37:22 2013 From: toni at playsign.net (Toni Alatalo) Date: Mon, 2 Sep 2013 14:37:22 +0300 Subject: [Fiware-miwi] massive DOM manipulation benchmark Message-ID: Ok so here is info about the DOM manipulation performance test that we recently started working on. I totally agree with the idea of having small targeted groups for specific topics, such as this 3d web client architecture. However as those don't exist yet let's use this list now for the first communications before the conf call that's being scheduled for this week. This benchmark is really simple and by no means fancy at this point but already gives some information. 'Massive' in the email subject refers to the fact that it can do a massive amount of DOM manipulations, not that the test code would be massive at all :) The code and little documentation is available at: https://github.com/playsign/wex-experiments/tree/master/domBenchmark The rationale is that in the current native realXtend implementation in Tundra SDK we have a similar mechanism: the core scene has all the data is in entity-attributes, and for example incoming network messages that move objects are handled so that the net part modifies that scene, which the renderer observes and updates the graphics engine scene accordingly. In the FI-WARE goals and plans, and in the declarative 3d web movement in general, there are good reasons for having all the data in the DOM -- for example being able to use the browser debugger to see and modify the values. We have the same in native Tundra SDK's scene & entity editor GUIs. I drew a first sketch of an architecture diagram about how this could work in the browser client, in a minimally modified WebTundra first where using a JS array for the scene data is just switched to using the DOM document instead: https://rawgithub.com/realXtend/doc/master/dom/rexdom.svg (in case someone wants to edit it, the source is at https://github.com/realXtend/doc/tree/master/dom - I used Inkscape where SVG is the native format). To examine the feasibility of this design I wanted to know how it performs. We don't have conclusive analysis nor any final verdict yet. We test with quite large numbers because we can have quite a lot happening in the scenes -- at least tens or hundreds of constantly moving objects etc. In this design every change in every object position would go via the DOM. To contrast, we have the similar mechnism implemented in pure JS - just an array with the data and a reference to the observing callback function. It is much simpler in functionality than what the DOM and Mutation Observers provide -- can be perhaps considered as an upper bound how fast an optimized solution could work. So not a fair comparison. Some early figures: Creating DOM elements is quite fast, I now created 10k elements in 0.136 seconds. Manipulating is quite fast too, 10k attribute modifications were made in 84ms for me now. Erno did a little better benchmarking with a 100 repeated runs, both for the DOM using and pure JS versions. His figures are on the benchmark projects website but I paste to here too: "running the test for 10k elements 100 times in a row, the pure-js version takes 19 ms. The DOM version of same takes 4700 ms. So a 250x difference." We are aware that this is a microbenchmark with all kinds of fallacies, can be improved if real benchmarking is necessary. But now I think the first question is: what are the real application requirements? How much DOM manipulations do we really need? We talked a bit about that and I think we can construct a few scenarios for that. Then we can calculate whether the performance is ok. I wrote that question to the stub overall doc that plan to continue in https://github.com/realXtend/doc/tree/master/dom This whole track was overridden a bit by the campus party preparations recently but I think now is good time to continue. I hope this clarified the situation, am sorry for the confusion that the quick '300x diff' pre-info during the weekend caused.. And to make it clear: we haven't done this with a real 3d client or networking or anything like that but decided to benchmark first in isolation. About the performance difference, we suspect that it is due to the internal machinery that the browser executes for every DOM change, and possibly also something in the C++ <-> JS interfacing. I looked a bit and found that to optimize large DOM manipulations web folks batch e.g. element creations etc. and don't do them individually. Do ask for any further info, and please bear with us and the early & bit cumbersome to use test case (we mostly just made it for ourselves for now at least). Cheers, ~Toni -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian.sons at dfki.de Mon Sep 2 15:37:15 2013 From: kristian.sons at dfki.de (Kristian Sons) Date: Mon, 02 Sep 2013 15:37:15 +0200 Subject: [Fiware-miwi] massive DOM manipulation benchmark In-Reply-To: References: Message-ID: <5224948B.5020307@dfki.de> Dear Toni, I had a very short look into your benchmark (sorry, I just don't have the time currently for an exhaustive look). On my laptop I was able to reproduce your numbers: 10k DOM creations: ~80ms 10k DOM modifications: ~40ms (25ms - 55ms) Seems, my (very new) laptop is a little faster, but it's in the same range. I saw that the JS modification in the test were just calling a function that sets the data of the object (something the JS engine has inlined quickly). To make it a little better comparable, I added a callback that sums up the ids. The DOM mutation events are clustered and scheduled in a separate phase: 10k DOM modifications: ~40ms + 6ms in callback 10k JS modifications: ~19ms Now we have _2.5x_ difference! Of course these results are just based on one iteration and using the very fuzzy Date.now() mechanism (just a tip: There is window.performance to do better performance measurements). I don't want to put into question that using specialized data structures in JavaScript is faster than using a generic general purpose data structure like the DOM. But comparing is very hard since the variance is very high, depending on how well JS can optimize, which JS engine you use and which platform you use (for instance on mobiles, the JS performance is still very bad). The DOM is meant as in interface to the user. That's how we designed XML3D. All medium-range modification (a few hundereds per frame) are okay. One must not forget that users will use jQuery etc, which can -- used the wrong way -- slow down the whole application (not only for 3D content). For all other operations, we have concept like Xflow, where the calculation is hidden behind the DOM interface. Also the rendering is also hidden behind the DOM structure. We even have our own memory management to get a better JS performance. Thus it really depends on the use case and the design of the DOM interface. The proposed benchmark might be too simple and one should be carefully with statements... Best regards, Kristian > Ok so here is info about the DOM manipulation performance test that we > recently started working on. I totally agree with the idea of having > small targeted groups for specific topics, such as this 3d web client > architecture. However as those don't exist yet let's use this list now > for the first communications before the conf call that's being > scheduled for this week. > > This benchmark is really simple and by no means fancy at this point > but already gives some information. 'Massive' in the email subject > refers to the fact that it can do a massive amount of DOM > manipulations, not that the test code would be massive at all :) > > The code and little documentation is available at: > https://github.com/playsign/wex-experiments/tree/master/domBenchmark > > The rationale is that in the current native realXtend implementation > in Tundra SDK we have a similar mechanism: the core scene has all the > data is in entity-attributes, and for example incoming network > messages that move objects are handled so that the net part modifies > that scene, which the renderer observes and updates the graphics > engine scene accordingly. > > In the FI-WARE goals and plans, and in the declarative 3d web movement > in general, there are good reasons for having all the data in the DOM > -- for example being able to use the browser debugger to see and > modify the values. We have the same in native Tundra SDK's scene & > entity editor GUIs. > > I drew a first sketch of an architecture diagram about how this could > work in the browser client, in a minimally modified WebTundra first > where using a JS array for the scene data is just switched to using > the DOM document instead: > https://rawgithub.com/realXtend/doc/master/dom/rexdom.svg (in case > someone wants to edit it, the source is at > https://github.com/realXtend/doc/tree/master/dom - I used Inkscape > where SVG is the native format). > > To examine the feasibility of this design I wanted to know how it > performs. We don't have conclusive analysis nor any final verdict yet. > We test with quite large numbers because we can have quite a lot > happening in the scenes -- at least tens or hundreds of constantly > moving objects etc. In this design every change in every object > position would go via the DOM. > > To contrast, we have the similar mechnism implemented in pure JS - > just an array with the data and a reference to the observing callback > function. It is much simpler in functionality than what the DOM and > Mutation Observers provide -- can be perhaps considered as an upper > bound how fast an optimized solution could work. So not a fair comparison. > > Some early figures: > > Creating DOM elements is quite fast, I now created 10k elements in > 0.136 seconds. > > Manipulating is quite fast too, 10k attribute modifications were made > in 84ms for me now. > > Erno did a little better benchmarking with a 100 repeated runs, both > for the DOM using and pure JS versions. His figures are on the > benchmark projects website but I paste to here too: > > "running the test for 10k elements 100 times in a row, the pure-js > version takes 19 ms. The DOM version of same takes 4700 ms. So a 250x > difference." > > We are aware that this is a microbenchmark with all kinds of > fallacies, can be improved if real benchmarking is necessary. > > But now I think the first question is: what are the real application > requirements? How much DOM manipulations do we really need? > > We talked a bit about that and I think we can construct a few > scenarios for that. Then we can calculate whether the performance is > ok. I wrote that question to the stub overall doc that plan to > continue in https://github.com/realXtend/doc/tree/master/dom > > This whole track was overridden a bit by the campus party preparations > recently but I think now is good time to continue. > > I hope this clarified the situation, am sorry for the confusion that > the quick '300x diff' pre-info during the weekend caused.. And to make > it clear: we haven't done this with a real 3d client or networking or > anything like that but decided to benchmark first in isolation. > > About the performance difference, we suspect that it is due to the > internal machinery that the browser executes for every DOM change, and > possibly also something in the C++ <-> JS interfacing. I looked a bit > and found that to optimize large DOM manipulations web folks batch > e.g. element creations etc. and don't do them individually. > > Do ask for any further info, and please bear with us and the early & > bit cumbersome to use test case (we mostly just made it for ourselves > for now at least). > > Cheers, > ~Toni > > > _______________________________________________ > Fiware-miwi mailing list > Fiware-miwi at lists.fi-ware.eu > https://lists.fi-ware.eu/listinfo/fiware-miwi -- _______________________________________________________________________________ Kristian Sons Deutsches Forschungszentrum f?r K?nstliche Intelligenz GmbH, DFKI Agenten und Simulierte Realit?t Campus, Geb. D 3 2, Raum 0.77 66123 Saarbr?cken, Germany Phone: +49 681 85775-3833 Phone: +49 681 302-3833 Fax: +49 681 85775--2235 kristian.sons at dfki.de http://www.xml3d.org 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 Amtsgericht Kaiserslautern, HRB 2313 _______________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From toni at playsign.net Mon Sep 2 16:02:14 2013 From: toni at playsign.net (Toni Alatalo) Date: Mon, 2 Sep 2013 17:02:14 +0300 Subject: [Fiware-miwi] massive DOM manipulation benchmark In-Reply-To: <5224948B.5020307@dfki.de> References: <5224948B.5020307@dfki.de> Message-ID: On Sep 2, 2013, at 4:37 PM, Kristian Sons wrote: > I saw that the JS modification in the test were just calling a function that sets the data of the object (something the JS engine has inlined quickly). To make it a little better comparable, I added a callback that sums up the ids. The DOM mutation events are clustered and scheduled in a separate phase: > 10k DOM modifications: ~40ms + 6ms in callback > 10k JS modifications: ~19ms > Now we have _2.5x_ difference! Yes, we also figured that the most simple minimal JS thing there is the 'upper bound' and understood that what is going on with the DOM is much more complex. Please do feel free to fork/share if you want to show how you did the clustering & scheduling, we also assumed that for real code to do the DOM manipulations efficiently we need that. Of course we can also study it further in the xml3d.js codebase where I figure you have it in action. This first version of the benchmark was basically to see quickly how well the naive usage of the DOM performs. I thought that it's quite good actually. > The DOM is meant as in interface to the user. That's how we designed XML3D. All medium-range modification (a few hundereds per frame) are okay. One must not forget that users will use jQuery etc, which can -- used the wrong way -- slow down the whole application (not only for 3D content). For all other operations, we have concept like Xflow, where the calculation is hidden behind the DOM interface. Also the rendering is also hidden behind the DOM structure. We even have our own memory management to get a better JS performance. > Thus it really depends on the use case and the design of the DOM interface. The proposed benchmark might be too simple and one should be carefully with statements? Yes, I think that is the question exactly for the overall design of the architecture: what the usage of the DOM should be like, with respect to network sync, rendering, scripts, input handling etc. And further in how much and what kind of DOM manipulations that results in and how they would be good to handle. Thanks for the quick and well informed feedback! And certainly this naive test was not meant as an end-all-be-all benchmark for any final conclusions but as I tried to emphasise the total opposite: just a starting point and also us a way to learn about the mutation observers (we'd never used them before). > Best regards, > Kristian Cheers, ~Toni >> Ok so here is info about the DOM manipulation performance test that we recently started working on. I totally agree with the idea of having small targeted groups for specific topics, such as this 3d web client architecture. However as those don't exist yet let's use this list now for the first communications before the conf call that's being scheduled for this week. >> >> This benchmark is really simple and by no means fancy at this point but already gives some information. 'Massive' in the email subject refers to the fact that it can do a massive amount of DOM manipulations, not that the test code would be massive at all :) >> >> The code and little documentation is available at: >> https://github.com/playsign/wex-experiments/tree/master/domBenchmark >> >> The rationale is that in the current native realXtend implementation in Tundra SDK we have a similar mechanism: the core scene has all the data is in entity-attributes, and for example incoming network messages that move objects are handled so that the net part modifies that scene, which the renderer observes and updates the graphics engine scene accordingly. >> >> In the FI-WARE goals and plans, and in the declarative 3d web movement in general, there are good reasons for having all the data in the DOM -- for example being able to use the browser debugger to see and modify the values. We have the same in native Tundra SDK's scene & entity editor GUIs. >> >> I drew a first sketch of an architecture diagram about how this could work in the browser client, in a minimally modified WebTundra first where using a JS array for the scene data is just switched to using the DOM document instead: https://rawgithub.com/realXtend/doc/master/dom/rexdom.svg (in case someone wants to edit it, the source is at https://github.com/realXtend/doc/tree/master/dom - I used Inkscape where SVG is the native format). >> >> To examine the feasibility of this design I wanted to know how it performs. We don't have conclusive analysis nor any final verdict yet. We test with quite large numbers because we can have quite a lot happening in the scenes -- at least tens or hundreds of constantly moving objects etc. In this design every change in every object position would go via the DOM. >> >> To contrast, we have the similar mechnism implemented in pure JS - just an array with the data and a reference to the observing callback function. It is much simpler in functionality than what the DOM and Mutation Observers provide -- can be perhaps considered as an upper bound how fast an optimized solution could work. So not a fair comparison. >> >> Some early figures: >> >> Creating DOM elements is quite fast, I now created 10k elements in 0.136 seconds. >> >> Manipulating is quite fast too, 10k attribute modifications were made in 84ms for me now. >> >> Erno did a little better benchmarking with a 100 repeated runs, both for the DOM using and pure JS versions. His figures are on the benchmark projects website but I paste to here too: >> >> "running the test for 10k elements 100 times in a row, the pure-js version takes 19 ms. The DOM version of same takes 4700 ms. So a 250x difference." >> >> We are aware that this is a microbenchmark with all kinds of fallacies, can be improved if real benchmarking is necessary. >> >> But now I think the first question is: what are the real application requirements? How much DOM manipulations do we really need? >> >> We talked a bit about that and I think we can construct a few scenarios for that. Then we can calculate whether the performance is ok. I wrote that question to the stub overall doc that plan to continue in https://github.com/realXtend/doc/tree/master/dom >> >> This whole track was overridden a bit by the campus party preparations recently but I think now is good time to continue. >> >> I hope this clarified the situation, am sorry for the confusion that the quick '300x diff' pre-info during the weekend caused.. And to make it clear: we haven't done this with a real 3d client or networking or anything like that but decided to benchmark first in isolation. >> >> About the performance difference, we suspect that it is due to the internal machinery that the browser executes for every DOM change, and possibly also something in the C++ <-> JS interfacing. I looked a bit and found that to optimize large DOM manipulations web folks batch e.g. element creations etc. and don't do them individually. >> >> Do ask for any further info, and please bear with us and the early & bit cumbersome to use test case (we mostly just made it for ourselves for now at least). >> >> Cheers, >> ~Toni >> >> >> _______________________________________________ >> Fiware-miwi mailing list >> Fiware-miwi at lists.fi-ware.eu >> https://lists.fi-ware.eu/listinfo/fiware-miwi > > > -- > _______________________________________________________________________________ > > Kristian Sons > Deutsches Forschungszentrum f?r K?nstliche Intelligenz GmbH, DFKI > Agenten und Simulierte Realit?t > Campus, Geb. D 3 2, Raum 0.77 > 66123 Saarbr?cken, Germany > > Phone: +49 681 85775-3833 > Phone: +49 681 302-3833 > Fax: +49 681 85775?2235 > kristian.sons at dfki.de > http://www.xml3d.org > > 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 > Amtsgericht Kaiserslautern, HRB 2313 > _______________________________________________________________________________ > _______________________________________________ > 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: From kristian.sons at dfki.de Mon Sep 2 16:20:19 2013 From: kristian.sons at dfki.de (Kristian Sons) Date: Mon, 02 Sep 2013 16:20:19 +0200 Subject: [Fiware-miwi] massive DOM manipulation benchmark In-Reply-To: References: <5224948B.5020307@dfki.de> Message-ID: <52249EA3.9010804@dfki.de> Dear Toni, I didn't modify the DOM version (though there are some minor things one could optimize). I just executed the callback attached to the JS object and gave this callback a real workload (summing up the ids in a global variable) that can't be optimized very well by the interpreter. In the original there was no callback in the 'set_ent_attribute'. The additional 10k function calls that can't be optimized very well slow down the JS version. BTW, there is an initiative from Google to add a pattern similar to MutationObserver to JS objects to allow efficient monitoring of JS data structures: http://updates.html5rocks.com/2012/11/Respond-to-change-with-Object-observe But I guess it will take some time until it's widely avialable. Best, Kristian > On Sep 2, 2013, at 4:37 PM, Kristian Sons > wrote: >> I saw that the JS modification in the test were just calling a >> function that sets the data of the object (something the JS engine >> has inlined quickly). To make it a little better comparable, I added >> a callback that sums up the ids. The DOM mutation events are >> clustered and scheduled in a separate phase: >> 10k DOM modifications: ~40ms + 6ms in callback >> 10k JS modifications: ~19ms >> Now we have _2.5x_ difference! > > Yes, we also figured that the most simple minimal JS thing there is > the 'upper bound' and understood that what is going on with the DOM is > much more complex. > > Please do feel free to fork/share if you want to show how you did the > clustering & scheduling, we also assumed that for real code to do the > DOM manipulations efficiently we need that. Of course we can also > study it further in the xml3d.js codebase where I figure you have it > in action. > > This first version of the benchmark was basically to see quickly how > well the naive usage of the DOM performs. I thought that it's quite > good actually. > >> The DOM is meant as in interface to the user. That's how we designed >> XML3D. All medium-range modification (a few hundereds per frame) are >> okay. One must not forget that users will use jQuery etc, which can >> -- used the wrong way -- slow down the whole application (not only >> for 3D content). For all other operations, we have concept like >> Xflow, where the calculation is hidden behind the DOM interface. Also >> the rendering is also hidden behind the DOM structure. We even have >> our own memory management to get a better JS performance. >> Thus it really depends on the use case and the design of the DOM >> interface. The proposed benchmark might be too simple and one should >> be carefully with statements... > > Yes, I think that is the question exactly for the overall design of > the architecture: what the usage of the DOM should be like, with > respect to network sync, rendering, scripts, input handling etc. And > further in how much and what kind of DOM manipulations that results in > and how they would be good to handle. > > Thanks for the quick and well informed feedback! > > And certainly this naive test was not meant as an end-all-be-all > benchmark for any final conclusions but as I tried to emphasise the > total opposite: just a starting point and also us a way to learn about > the mutation observers (we'd never used them before). > >> Best regards, >> Kristian > > Cheers, > ~Toni > >>> Ok so here is info about the DOM manipulation performance test that >>> we recently started working on. I totally agree with the idea of >>> having small targeted groups for specific topics, such as this 3d >>> web client architecture. However as those don't exist yet let's use >>> this list now for the first communications before the conf call >>> that's being scheduled for this week. >>> >>> This benchmark is really simple and by no means fancy at this point >>> but already gives some information. 'Massive' in the email subject >>> refers to the fact that it can do a massive amount of DOM >>> manipulations, not that the test code would be massive at all :) >>> >>> The code and little documentation is available at: >>> https://github.com/playsign/wex-experiments/tree/master/domBenchmark >>> >>> The rationale is that in the current native realXtend implementation >>> in Tundra SDK we have a similar mechanism: the core scene has all >>> the data is in entity-attributes, and for example incoming network >>> messages that move objects are handled so that the net part modifies >>> that scene, which the renderer observes and updates the graphics >>> engine scene accordingly. >>> >>> In the FI-WARE goals and plans, and in the declarative 3d web >>> movement in general, there are good reasons for having all the data >>> in the DOM -- for example being able to use the browser debugger to >>> see and modify the values. We have the same in native Tundra SDK's >>> scene & entity editor GUIs. >>> >>> I drew a first sketch of an architecture diagram about how this >>> could work in the browser client, in a minimally modified WebTundra >>> first where using a JS array for the scene data is just switched to >>> using the DOM document instead: >>> https://rawgithub.com/realXtend/doc/master/dom/rexdom.svg (in case >>> someone wants to edit it, the source is at >>> https://github.com/realXtend/doc/tree/master/dom - I used Inkscape >>> where SVG is the native format). >>> >>> To examine the feasibility of this design I wanted to know how it >>> performs. We don't have conclusive analysis nor any final verdict >>> yet. We test with quite large numbers because we can have quite a >>> lot happening in the scenes -- at least tens or hundreds of >>> constantly moving objects etc. In this design every change in every >>> object position would go via the DOM. >>> >>> To contrast, we have the similar mechnism implemented in pure JS - >>> just an array with the data and a reference to the observing >>> callback function. It is much simpler in functionality than what the >>> DOM and Mutation Observers provide -- can be perhaps considered as >>> an upper bound how fast an optimized solution could work. So not a >>> fair comparison. >>> >>> Some early figures: >>> >>> Creating DOM elements is quite fast, I now created 10k elements in >>> 0.136 seconds. >>> >>> Manipulating is quite fast too, 10k attribute modifications were >>> made in 84ms for me now. >>> >>> Erno did a little better benchmarking with a 100 repeated runs, both >>> for the DOM using and pure JS versions. His figures are on the >>> benchmark projects website but I paste to here too: >>> >>> "running the test for 10k elements 100 times in a row, the pure-js >>> version takes 19 ms. The DOM version of same takes 4700 ms. So a >>> 250x difference." >>> >>> We are aware that this is a microbenchmark with all kinds of >>> fallacies, can be improved if real benchmarking is necessary. >>> >>> But now I think the first question is: what are the real application >>> requirements? How much DOM manipulations do we really need? >>> >>> We talked a bit about that and I think we can construct a few >>> scenarios for that. Then we can calculate whether the performance is >>> ok. I wrote that question to the stub overall doc that plan to >>> continue in https://github.com/realXtend/doc/tree/master/dom >>> >>> This whole track was overridden a bit by the campus party >>> preparations recently but I think now is good time to continue. >>> >>> I hope this clarified the situation, am sorry for the confusion that >>> the quick '300x diff' pre-info during the weekend caused.. And to >>> make it clear: we haven't done this with a real 3d client or >>> networking or anything like that but decided to benchmark first in >>> isolation. >>> >>> About the performance difference, we suspect that it is due to the >>> internal machinery that the browser executes for every DOM change, >>> and possibly also something in the C++ <-> JS interfacing. I looked >>> a bit and found that to optimize large DOM manipulations web folks >>> batch e.g. element creations etc. and don't do them individually. >>> >>> Do ask for any further info, and please bear with us and the early & >>> bit cumbersome to use test case (we mostly just made it for >>> ourselves for now at least). >>> >>> Cheers, >>> ~Toni >>> >>> >>> _______________________________________________ >>> Fiware-miwi mailing list >>> Fiware-miwi at lists.fi-ware.eu >>> https://lists.fi-ware.eu/listinfo/fiware-miwi >> >> >> -- >> _______________________________________________________________________________ >> >> Kristian Sons >> Deutsches Forschungszentrum f?r K?nstliche Intelligenz GmbH, DFKI >> Agenten und Simulierte Realit?t >> Campus, Geb. D 3 2, Raum 0.77 >> 66123 Saarbr?cken, Germany >> >> Phone: +49 681 85775-3833 >> Phone: +49 681 302-3833 >> Fax: +49 681 85775--2235 >> kristian.sons at dfki.de >> http://www.xml3d.org >> >> 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 >> Amtsgericht Kaiserslautern, HRB 2313 >> _______________________________________________________________________________ >> _______________________________________________ >> Fiware-miwi mailing list >> Fiware-miwi at lists.fi-ware.eu >> https://lists.fi-ware.eu/listinfo/fiware-miwi > > > > _______________________________________________ > Fiware-miwi mailing list > Fiware-miwi at lists.fi-ware.eu > https://lists.fi-ware.eu/listinfo/fiware-miwi -- _______________________________________________________________________________ Kristian Sons Deutsches Forschungszentrum f?r K?nstliche Intelligenz GmbH, DFKI Agenten und Simulierte Realit?t Campus, Geb. D 3 2, Raum 0.77 66123 Saarbr?cken, Germany Phone: +49 681 85775-3833 Phone: +49 681 302-3833 Fax: +49 681 85775--2235 kristian.sons at dfki.de http://www.xml3d.org 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 Amtsgericht Kaiserslautern, HRB 2313 _______________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Philipp.Slusallek at dfki.de Mon Sep 2 21:45:29 2013 From: Philipp.Slusallek at dfki.de (Philipp Slusallek) Date: Mon, 02 Sep 2013 21:45:29 +0200 Subject: [Fiware-miwi] massive DOM manipulation benchmark In-Reply-To: References: <5224948B.5020307@dfki.de> Message-ID: <5224EAD9.3070309@dfki.de> Hi, I suggest that we drive this discussion from the requirements side: Let's take you current interface and look at what are the basic operations (add object, move object, etc.) that happen and how often they happen per frame. Then we look at how this would be implemented in XML3D (which is the target) and some other SceneGraph and create a small benchmark that does some synthetic test of the relevant operations. This should give us a better option of what the performance differences between the two version is for realistic workloads. I would assume that most of these operations might actually bypass the generic DOM interfaces and go straight to XML3D in JS (e.g. via typed arrays), which should not be much slower than directly using JS. All the internal XML3D/Xflow operations like rendering, animation, and similar operate in pure JS anyway (as we explained with the layered model in Winterthus), so there should not be a big difference for those operations anyway (other than differences in the rendering strategy itself. Since Sergiy and Torsten are implementing our sync server right now, we should be able to recreate a very similar setup to basic realXtend on our side and do some real live measurements there as well. Depending on how fast this will work, we may be able to go straight to this version for comparisons. Nothing is optimized much there, but its may be a good reference point. Since our implementation is based on the ECA model of realXtend, it might not be too hard to create common network layer (we use a very simple and inefficient protocol right now) and drive XML3D also from realXtend. This would be a great step forward (plus a perfect way for performance comparisons and tuning). Best, Philipp Am 02.09.2013 16:02, schrieb Toni Alatalo: > On Sep 2, 2013, at 4:37 PM, Kristian Sons > wrote: >> I saw that the JS modification in the test were just calling a >> function that sets the data of the object (something the JS engine has >> inlined quickly). To make it a little better comparable, I added a >> callback that sums up the ids. The DOM mutation events are clustered >> and scheduled in a separate phase: >> 10k DOM modifications: ~40ms + 6ms in callback >> 10k JS modifications: ~19ms >> Now we have _2.5x_ difference! > > Yes, we also figured that the most simple minimal JS thing there is the > 'upper bound' and understood that what is going on with the DOM is much > more complex. > > Please do feel free to fork/share if you want to show how you did the > clustering & scheduling, we also assumed that for real code to do the > DOM manipulations efficiently we need that. Of course we can also study > it further in the xml3d.js codebase where I figure you have it in action. > > This first version of the benchmark was basically to see quickly how > well the naive usage of the DOM performs. I thought that it's quite good > actually. > >> The DOM is meant as in interface to the user. That's how we designed >> XML3D. All medium-range modification (a few hundereds per frame) are >> okay. One must not forget that users will use jQuery etc, which can -- >> used the wrong way -- slow down the whole application (not only for 3D >> content). For all other operations, we have concept like Xflow, where >> the calculation is hidden behind the DOM interface. Also the rendering >> is also hidden behind the DOM structure. We even have our own memory >> management to get a better JS performance. >> Thus it really depends on the use case and the design of the DOM >> interface. The proposed benchmark might be too simple and one should >> be carefully with statements? > > Yes, I think that is the question exactly for the overall design of the > architecture: what the usage of the DOM should be like, with respect to > network sync, rendering, scripts, input handling etc. And further in how > much and what kind of DOM manipulations that results in and how they > would be good to handle. > > Thanks for the quick and well informed feedback! > > And certainly this naive test was not meant as an end-all-be-all > benchmark for any final conclusions but as I tried to emphasise the > total opposite: just a starting point and also us a way to learn about > the mutation observers (we'd never used them before). > >> Best regards, >> Kristian > > Cheers, > ~Toni > >>> Ok so here is info about the DOM manipulation performance test that >>> we recently started working on. I totally agree with the idea of >>> having small targeted groups for specific topics, such as this 3d web >>> client architecture. However as those don't exist yet let's use this >>> list now for the first communications before the conf call that's >>> being scheduled for this week. >>> >>> This benchmark is really simple and by no means fancy at this point >>> but already gives some information. 'Massive' in the email subject >>> refers to the fact that it can do a massive amount of DOM >>> manipulations, not that the test code would be massive at all :) >>> >>> The code and little documentation is available at: >>> https://github.com/playsign/wex-experiments/tree/master/domBenchmark >>> >>> The rationale is that in the current native realXtend implementation >>> in Tundra SDK we have a similar mechanism: the core scene has all the >>> data is in entity-attributes, and for example incoming network >>> messages that move objects are handled so that the net part modifies >>> that scene, which the renderer observes and updates the graphics >>> engine scene accordingly. >>> >>> In the FI-WARE goals and plans, and in the declarative 3d web >>> movement in general, there are good reasons for having all the data >>> in the DOM -- for example being able to use the browser debugger to >>> see and modify the values. We have the same in native Tundra SDK's >>> scene & entity editor GUIs. >>> >>> I drew a first sketch of an architecture diagram about how this could >>> work in the browser client, in a minimally modified WebTundra first >>> where using a JS array for the scene data is just switched to using >>> the DOM document >>> instead: https://rawgithub.com/realXtend/doc/master/dom/rexdom.svg (in case >>> someone wants to edit it, the source is >>> at https://github.com/realXtend/doc/tree/master/dom - I used Inkscape >>> where SVG is the native format). >>> >>> To examine the feasibility of this design I wanted to know how it >>> performs. We don't have conclusive analysis nor any final verdict >>> yet. We test with quite large numbers because we can have quite a lot >>> happening in the scenes -- at least tens or hundreds of constantly >>> moving objects etc. In this design every change in every object >>> position would go via the DOM. >>> >>> To contrast, we have the similar mechnism implemented in pure JS - >>> just an array with the data and a reference to the observing callback >>> function. It is much simpler in functionality than what the DOM and >>> Mutation Observers provide -- can be perhaps considered as an upper >>> bound how fast an optimized solution could work. So not a fair >>> comparison. >>> >>> Some early figures: >>> >>> Creating DOM elements is quite fast, I now created 10k elements in >>> 0.136 seconds. >>> >>> Manipulating is quite fast too, 10k attribute modifications were made >>> in 84ms for me now. >>> >>> Erno did a little better benchmarking with a 100 repeated runs, both >>> for the DOM using and pure JS versions. His figures are on the >>> benchmark projects website but I paste to here too: >>> >>> "running the test for 10k elements 100 times in a row, the pure-js >>> version takes 19 ms. The DOM version of same takes 4700 ms. So a 250x >>> difference." >>> >>> We are aware that this is a microbenchmark with all kinds of >>> fallacies, can be improved if real benchmarking is necessary. >>> >>> But now I think the first question is: what are the real application >>> requirements? How much DOM manipulations do we really need? >>> >>> We talked a bit about that and I think we can construct a few >>> scenarios for that. Then we can calculate whether the performance is >>> ok. I wrote that question to the stub overall doc that plan to >>> continue in https://github.com/realXtend/doc/tree/master/dom >>> >>> This whole track was overridden a bit by the campus party >>> preparations recently but I think now is good time to continue. >>> >>> I hope this clarified the situation, am sorry for the confusion that >>> the quick '300x diff' pre-info during the weekend caused.. And to >>> make it clear: we haven't done this with a real 3d client or >>> networking or anything like that but decided to benchmark first in >>> isolation. >>> >>> About the performance difference, we suspect that it is due to the >>> internal machinery that the browser executes for every DOM change, >>> and possibly also something in the C++ <-> JS interfacing. I looked a >>> bit and found that to optimize large DOM manipulations web folks >>> batch e.g. element creations etc. and don't do them individually. >>> >>> Do ask for any further info, and please bear with us and the early & >>> bit cumbersome to use test case (we mostly just made it for ourselves >>> for now at least). >>> >>> Cheers, >>> ~Toni >>> >>> >>> _______________________________________________ >>> Fiware-miwi mailing list >>> Fiware-miwi at lists.fi-ware.eu >>> https://lists.fi-ware.eu/listinfo/fiware-miwi >> >> >> -- >> _______________________________________________________________________________ >> >> Kristian Sons >> Deutsches Forschungszentrum f?r K?nstliche Intelligenz GmbH, DFKI >> Agenten und Simulierte Realit?t >> Campus, Geb. D 3 2, Raum 0.77 >> 66123 Saarbr?cken, Germany >> >> Phone: +49 681 85775-3833 >> Phone: +49 681 302-3833 >> Fax: +49 681 85775?2235 >> kristian.sons at dfki.de >> http://www.xml3d.org >> >> 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 >> Amtsgericht Kaiserslautern, HRB 2313 >> _______________________________________________________________________________ >> _______________________________________________ >> Fiware-miwi mailing list >> Fiware-miwi at lists.fi-ware.eu >> https://lists.fi-ware.eu/listinfo/fiware-miwi > > > > _______________________________________________ > 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 --------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: slusallek.vcf Type: text/x-vcard Size: 441 bytes Desc: not available URL: From toni at playsign.net Mon Sep 2 22:41:06 2013 From: toni at playsign.net (Toni Alatalo) Date: Mon, 2 Sep 2013 23:41:06 +0300 Subject: [Fiware-miwi] massive DOM manipulation benchmark In-Reply-To: <5224EAD9.3070309@dfki.de> References: <5224948B.5020307@dfki.de> <5224EAD9.3070309@dfki.de> Message-ID: <2DE48525-4376-40C3-9759-2097F6D1A74F@playsign.net> On Sep 2, 2013, at 10:45 PM, Philipp Slusallek wrote: > I suggest that we drive this discussion from the requirements side: Yes, that's what I suggested too (this part: "I think the first question is: what are the real application requirements? How much DOM manipulations do we really need? We talked a bit about that and I think we can construct a few scenarios for that."). > Let's take you current interface and look at what are the basic > operations (add object, move object, etc.) that happen and how often > they happen per frame. Then we look at how this would be implemented in The first rough figures we had for these were approximately: 1. Creating a few thousand objects at start. In a networked setup when a client enters a new scene - in that case takes a while for the data to arrive, I'm not sure how long exactly, Lasse probably has some estimate and I think we can measure too. When reading the scene from a local file, getting the data is very fast of course (excluding the loading of the assets which can take time even locally, I mean just the elements/entities and the attribute data with references to assets). 2. A couple of hundred constantly moving objects. In the current net sync we use max 20Hz, and then the client scene code inter(- and extra)polates the movement with the max 60fps used for drawing A local script for e.g. a swarm can (ideally) do much more manipulations with the scene than what we typically can get over the net. > XML3D (which is the target) and some other SceneGraph and create a small > benchmark that does some synthetic test of the relevant operations. This > should give us a better option of what the performance differences > between the two version is for realistic workloads. Agreed. Thanks for the clarification and further info about how you've made it, seems that that's the strategy for dealing with the data flows instead of going via the DOM document. ~Toni > I would assume that most of these operations might actually bypass the > generic DOM interfaces and go straight to XML3D in JS (e.g. via typed > arrays), which should not be much slower than directly using JS. All the > internal XML3D/Xflow operations like rendering, animation, and similar > operate in pure JS anyway (as we explained with the layered model in > Winterthus), so there should not be a big difference for those > operations anyway (other than differences in the rendering strategy itself. > > Since Sergiy and Torsten are implementing our sync server right now, we > should be able to recreate a very similar setup to basic realXtend on > our side and do some real live measurements there as well. Depending on > how fast this will work, we may be able to go straight to this version > for comparisons. Nothing is optimized much there, but its may be a good > reference point. > > Since our implementation is based on the ECA model of realXtend, it > might not be too hard to create common network layer (we use a very > simple and inefficient protocol right now) and drive XML3D also from > realXtend. This would be a great step forward (plus a perfect way for > performance comparisons and tuning). > > > Best, > > Philipp > > Am 02.09.2013 16:02, schrieb Toni Alatalo: >> On Sep 2, 2013, at 4:37 PM, Kristian Sons > > wrote: >>> I saw that the JS modification in the test were just calling a >>> function that sets the data of the object (something the JS engine has >>> inlined quickly). To make it a little better comparable, I added a >>> callback that sums up the ids. The DOM mutation events are clustered >>> and scheduled in a separate phase: >>> 10k DOM modifications: ~40ms + 6ms in callback >>> 10k JS modifications: ~19ms >>> Now we have _2.5x_ difference! >> >> Yes, we also figured that the most simple minimal JS thing there is the >> 'upper bound' and understood that what is going on with the DOM is much >> more complex. >> >> Please do feel free to fork/share if you want to show how you did the >> clustering & scheduling, we also assumed that for real code to do the >> DOM manipulations efficiently we need that. Of course we can also study >> it further in the xml3d.js codebase where I figure you have it in action. >> >> This first version of the benchmark was basically to see quickly how >> well the naive usage of the DOM performs. I thought that it's quite good >> actually. >> >>> The DOM is meant as in interface to the user. That's how we designed >>> XML3D. All medium-range modification (a few hundereds per frame) are >>> okay. One must not forget that users will use jQuery etc, which can -- >>> used the wrong way -- slow down the whole application (not only for 3D >>> content). For all other operations, we have concept like Xflow, where >>> the calculation is hidden behind the DOM interface. Also the rendering >>> is also hidden behind the DOM structure. We even have our own memory >>> management to get a better JS performance. >>> Thus it really depends on the use case and the design of the DOM >>> interface. The proposed benchmark might be too simple and one should >>> be carefully with statements? >> >> Yes, I think that is the question exactly for the overall design of the >> architecture: what the usage of the DOM should be like, with respect to >> network sync, rendering, scripts, input handling etc. And further in how >> much and what kind of DOM manipulations that results in and how they >> would be good to handle. >> >> Thanks for the quick and well informed feedback! >> >> And certainly this naive test was not meant as an end-all-be-all >> benchmark for any final conclusions but as I tried to emphasise the >> total opposite: just a starting point and also us a way to learn about >> the mutation observers (we'd never used them before). >> >>> Best regards, >>> Kristian >> >> Cheers, >> ~Toni >> >>>> Ok so here is info about the DOM manipulation performance test that >>>> we recently started working on. I totally agree with the idea of >>>> having small targeted groups for specific topics, such as this 3d web >>>> client architecture. However as those don't exist yet let's use this >>>> list now for the first communications before the conf call that's >>>> being scheduled for this week. >>>> >>>> This benchmark is really simple and by no means fancy at this point >>>> but already gives some information. 'Massive' in the email subject >>>> refers to the fact that it can do a massive amount of DOM >>>> manipulations, not that the test code would be massive at all :) >>>> >>>> The code and little documentation is available at: >>>> https://github.com/playsign/wex-experiments/tree/master/domBenchmark >>>> >>>> The rationale is that in the current native realXtend implementation >>>> in Tundra SDK we have a similar mechanism: the core scene has all the >>>> data is in entity-attributes, and for example incoming network >>>> messages that move objects are handled so that the net part modifies >>>> that scene, which the renderer observes and updates the graphics >>>> engine scene accordingly. >>>> >>>> In the FI-WARE goals and plans, and in the declarative 3d web >>>> movement in general, there are good reasons for having all the data >>>> in the DOM -- for example being able to use the browser debugger to >>>> see and modify the values. We have the same in native Tundra SDK's >>>> scene & entity editor GUIs. >>>> >>>> I drew a first sketch of an architecture diagram about how this could >>>> work in the browser client, in a minimally modified WebTundra first >>>> where using a JS array for the scene data is just switched to using >>>> the DOM document >>>> instead: https://rawgithub.com/realXtend/doc/master/dom/rexdom.svg (in case >>>> someone wants to edit it, the source is >>>> at https://github.com/realXtend/doc/tree/master/dom - I used Inkscape >>>> where SVG is the native format). >>>> >>>> To examine the feasibility of this design I wanted to know how it >>>> performs. We don't have conclusive analysis nor any final verdict >>>> yet. We test with quite large numbers because we can have quite a lot >>>> happening in the scenes -- at least tens or hundreds of constantly >>>> moving objects etc. In this design every change in every object >>>> position would go via the DOM. >>>> >>>> To contrast, we have the similar mechnism implemented in pure JS - >>>> just an array with the data and a reference to the observing callback >>>> function. It is much simpler in functionality than what the DOM and >>>> Mutation Observers provide -- can be perhaps considered as an upper >>>> bound how fast an optimized solution could work. So not a fair >>>> comparison. >>>> >>>> Some early figures: >>>> >>>> Creating DOM elements is quite fast, I now created 10k elements in >>>> 0.136 seconds. >>>> >>>> Manipulating is quite fast too, 10k attribute modifications were made >>>> in 84ms for me now. >>>> >>>> Erno did a little better benchmarking with a 100 repeated runs, both >>>> for the DOM using and pure JS versions. His figures are on the >>>> benchmark projects website but I paste to here too: >>>> >>>> "running the test for 10k elements 100 times in a row, the pure-js >>>> version takes 19 ms. The DOM version of same takes 4700 ms. So a 250x >>>> difference." >>>> >>>> We are aware that this is a microbenchmark with all kinds of >>>> fallacies, can be improved if real benchmarking is necessary. >>>> >>>> But now I think the first question is: what are the real application >>>> requirements? How much DOM manipulations do we really need? >>>> >>>> We talked a bit about that and I think we can construct a few >>>> scenarios for that. Then we can calculate whether the performance is >>>> ok. I wrote that question to the stub overall doc that plan to >>>> continue in https://github.com/realXtend/doc/tree/master/dom >>>> >>>> This whole track was overridden a bit by the campus party >>>> preparations recently but I think now is good time to continue. >>>> >>>> I hope this clarified the situation, am sorry for the confusion that >>>> the quick '300x diff' pre-info during the weekend caused.. And to >>>> make it clear: we haven't done this with a real 3d client or >>>> networking or anything like that but decided to benchmark first in >>>> isolation. >>>> >>>> About the performance difference, we suspect that it is due to the >>>> internal machinery that the browser executes for every DOM change, >>>> and possibly also something in the C++ <-> JS interfacing. I looked a >>>> bit and found that to optimize large DOM manipulations web folks >>>> batch e.g. element creations etc. and don't do them individually. >>>> >>>> Do ask for any further info, and please bear with us and the early & >>>> bit cumbersome to use test case (we mostly just made it for ourselves >>>> for now at least). >>>> >>>> Cheers, >>>> ~Toni >>>> >>>> >>>> _______________________________________________ >>>> Fiware-miwi mailing list >>>> Fiware-miwi at lists.fi-ware.eu >>>> https://lists.fi-ware.eu/listinfo/fiware-miwi >>> >>> >>> -- >>> _______________________________________________________________________________ >>> >>> Kristian Sons >>> Deutsches Forschungszentrum f?r K?nstliche Intelligenz GmbH, DFKI >>> Agenten und Simulierte Realit?t >>> Campus, Geb. D 3 2, Raum 0.77 >>> 66123 Saarbr?cken, Germany >>> >>> Phone: +49 681 85775-3833 >>> Phone: +49 681 302-3833 >>> Fax: +49 681 85775?2235 >>> kristian.sons at dfki.de >>> http://www.xml3d.org >>> >>> 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 >>> Amtsgericht Kaiserslautern, HRB 2313 >>> _______________________________________________________________________________ >>> _______________________________________________ >>> Fiware-miwi mailing list >>> Fiware-miwi at lists.fi-ware.eu >>> https://lists.fi-ware.eu/listinfo/fiware-miwi >> >> >> >> _______________________________________________ >> 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 > --------------------------------------------------------------------------- > From mach at zhaw.ch Tue Sep 3 08:18:16 2013 From: mach at zhaw.ch (Christof Marti) Date: Tue, 3 Sep 2013 07:18:16 +0100 Subject: [Fiware-miwi] WP13 Architecture Telco and on-boarding In-Reply-To: References: Message-ID: Hi Regarding the Architecture telco we have no time where all can attend. The three preferred options are: (Today) Tue 13:00 BST / 14:00 CEST / 15:00 EEST (Tomorrow) Wed 08:00 BST / 09:00 CEST / 10:00 EEST (Today) Tue 14:00 BST / 15:00 CEST / 16:00 EEST (Hope you all calculated the timezones correctly :) if not please correct your availability: http://www.doodle.com/e5qnirudzcc734ye @Toni, Jarkko: according to the doodle only one of you is available at these dates. Do you see a chance to find a common date within these 3 options? I'm heading for campus party to see when the meeting room is here is available and come back to you later. Cheers Christof Am 30.08.2013 um 15:08 schrieb Marti Christof (mach) : > Hello > > Hope you all had good summer vacation and are ready for some action :) > The WP13 Tools (forge, tracker, mailing-lists, wiki) are ready now and we need to go on with the onbording and architecture process. > > Telco: WP13 Architecture Kick-off > Philipp and I would like to start this with a telco, were we define the basic structure and process of the architecture definition. > Please fill this doodle until tomorrow Saturday 18:00 with the dates you are available next week. For the people in London we can try to get the FI-WARE meeting room. This telco is addressing primarily the GEs of the new Advanced WebUI partners, but KIARA partners are free to join. > > Mailing-Lists > I added you all to the fiware-miwi at lists.fi-ware.eu mailing list. I added a list of all current members at the end of this mail. If somebody of your organization is missing please let me know. > There are two additional mailing lists: > fiware-3d-lib at lists.fi-ware.eu for the 3D JavaScript Library task force > fiware-vw-mapping at lists.fi-ware.eu for the virtual world data mapping and translation task force > I have added all people I found an email to join one of the task forces. Please send me an email which list you want to join if you did not get a confirmation email. > > Forge (http://forge.fi-ware.eu) > If you did not create your forge account yet, please do so before you can continue with the following tasks. > See instructions: How to create a FusionForge account > > Once you created your account you have to join the different FI-WARE Projects. > See Instructions: How to join a FI-WARE project in FusionForge > > You should at least join the following projects: > * FIWARE (the public site) > * FI-WARE MIWI (the WP13 Project) > * FI-WARE PPP-Restricted (the FI-PPP partner Project) > And depending on your activities also to: > * FI-WARE Testbed (for testbed setup/support WP10) > * FI-WARE Exploitation (WP11) > You should be added automatically to > * FI-WARE privat (privat project for all FI-WARE partners) > if not, let me know. > > How-Tos & Instructions > You find all the HowTo descriptions on the FI-WARE main wiki page http://wiki.fi-ware.eu > Instructions on how to use FI-WARE Forge and Collaborative Tools has already been sent by Miguel. > I added his presentation as an attachment and here is also the link to Miguels introduction video: > https://dl.dropboxusercontent.com/u/25916180/FI_WARE/Forge_Induction_OpenCall1_partners.mp4 > (This is for FI-WARE partners only!! Do not disseminate outside of FI-WARE!!) > > Wiki > I will add all the relevant WP13 infos and the basic structure for the architecture pages to the WP13 wiki in the upcoming days. > https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi > You have to be logged into forge and be a member of the FI-WARE MIWI Project to access these pages. > > Members of the fiware-miwi mailing list: > Here the current members of the WP13 mailing-list. If somebody of your organisation is missing please let me know. > > Erno Kuusela > Toni Alatalo > Hanna Tiuraniemi > tapani at playsign.net > Tommi Hollstr?m > Jonne Nauha > Lasse ??rni > Tonny Manninen > Jarkko Vatjus-Anttila > Esa Posio > Kari Autio > Johannes Peltola > Philipp Slusallek > Torsten Spieldenner > Stefan Denne > Oliver Keller > Werner Stepan > Tizian Schneider > Felix Klein > Kristian Sons > Stefan Lemme > Andreas Nonnengart > Dmitri Rubinstein > Sergiy Byelozyorov > Christof Marti > Thomas Michael Bohnert > Philipp Aeschlimann > Sandro Brunner > Mathias Habl?tzel > Irena Trajkovska > Jaime Martin Losa > Ricardo Gonzalez > Rafael Lara > Ricardo Gonzalez > RubenRubio > Luis L?pez URJC > Javier Lopez Fernandez > > > Best regards > Christof > ---- > Christof Marti > InIT Cloud Computing Lab - ICCLab http://cloudcomp.ch > Institut of Applied Information Technology - InIT > Zurich University of Applied Sciences - ZHAW > School of Engineering > P.O.Box, CH-8401 Winterthur > Office:TD O3.18, Obere Kirchgasse 2 > Phone: +41 58 934 70 63 > Mail: mach at zhaw.ch > Skype: christof-marti > > Sent from my iPad > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: not available URL: From toni at playsign.net Tue Sep 3 09:24:01 2013 From: toni at playsign.net (Toni Alatalo) Date: Tue, 3 Sep 2013 10:24:01 +0300 Subject: [Fiware-miwi] WP13 Architecture Telco and on-boarding In-Reply-To: References: Message-ID: I am trying to arrange so that could join tomorrow on Wed (the 9 CEST / 10 EEST slot) -- don't know yet whether it's possible but will tell when do. ~Toni On Sep 3, 2013, at 9:18 AM, Christof Marti wrote: > Hi > > Regarding the Architecture telco we have no time where all can attend. > > The three preferred options are: > (Today) Tue 13:00 BST / 14:00 CEST / 15:00 EEST > (Tomorrow) Wed 08:00 BST / 09:00 CEST / 10:00 EEST > (Today) Tue 14:00 BST / 15:00 CEST / 16:00 EEST > (Hope you all calculated the timezones correctly :) if not please correct your availability: http://www.doodle.com/e5qnirudzcc734ye > > @Toni, Jarkko: according to the doodle only one of you is available at these dates. Do you see a chance to find a common date within these 3 options? > > I'm heading for campus party to see when the meeting room is here is available and come back to you later. > > Cheers > Christof > > Am 30.08.2013 um 15:08 schrieb Marti Christof (mach) : > >> Hello >> >> Hope you all had good summer vacation and are ready for some action :) >> The WP13 Tools (forge, tracker, mailing-lists, wiki) are ready now and we need to go on with the onbording and architecture process. >> >> Telco: WP13 Architecture Kick-off >> Philipp and I would like to start this with a telco, were we define the basic structure and process of the architecture definition. >> Please fill this doodle until tomorrow Saturday 18:00 with the dates you are available next week. For the people in London we can try to get the FI-WARE meeting room. This telco is addressing primarily the GEs of the new Advanced WebUI partners, but KIARA partners are free to join. >> >> Mailing-Lists >> I added you all to the fiware-miwi at lists.fi-ware.eu mailing list. I added a list of all current members at the end of this mail. If somebody of your organization is missing please let me know. >> There are two additional mailing lists: >> fiware-3d-lib at lists.fi-ware.eu for the 3D JavaScript Library task force >> fiware-vw-mapping at lists.fi-ware.eu for the virtual world data mapping and translation task force >> I have added all people I found an email to join one of the task forces. Please send me an email which list you want to join if you did not get a confirmation email. >> >> Forge (http://forge.fi-ware.eu) >> If you did not create your forge account yet, please do so before you can continue with the following tasks. >> See instructions: How to create a FusionForge account >> >> Once you created your account you have to join the different FI-WARE Projects. >> See Instructions: How to join a FI-WARE project in FusionForge >> >> You should at least join the following projects: >> * FIWARE (the public site) >> * FI-WARE MIWI (the WP13 Project) >> * FI-WARE PPP-Restricted (the FI-PPP partner Project) >> And depending on your activities also to: >> * FI-WARE Testbed (for testbed setup/support WP10) >> * FI-WARE Exploitation (WP11) >> You should be added automatically to >> * FI-WARE privat (privat project for all FI-WARE partners) >> if not, let me know. >> >> How-Tos & Instructions >> You find all the HowTo descriptions on the FI-WARE main wiki page http://wiki.fi-ware.eu >> Instructions on how to use FI-WARE Forge and Collaborative Tools has already been sent by Miguel. >> I added his presentation as an attachment and here is also the link to Miguels introduction video: >> https://dl.dropboxusercontent.com/u/25916180/FI_WARE/Forge_Induction_OpenCall1_partners.mp4 >> (This is for FI-WARE partners only!! Do not disseminate outside of FI-WARE!!) >> >> Wiki >> I will add all the relevant WP13 infos and the basic structure for the architecture pages to the WP13 wiki in the upcoming days. >> https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi >> You have to be logged into forge and be a member of the FI-WARE MIWI Project to access these pages. >> >> Members of the fiware-miwi mailing list: >> Here the current members of the WP13 mailing-list. If somebody of your organisation is missing please let me know. >> >> Erno Kuusela >> Toni Alatalo >> Hanna Tiuraniemi >> tapani at playsign.net >> Tommi Hollstr?m >> Jonne Nauha >> Lasse ??rni >> Tonny Manninen >> Jarkko Vatjus-Anttila >> Esa Posio >> Kari Autio >> Johannes Peltola >> Philipp Slusallek >> Torsten Spieldenner >> Stefan Denne >> Oliver Keller >> Werner Stepan >> Tizian Schneider >> Felix Klein >> Kristian Sons >> Stefan Lemme >> Andreas Nonnengart >> Dmitri Rubinstein >> Sergiy Byelozyorov >> Christof Marti >> Thomas Michael Bohnert >> Philipp Aeschlimann >> Sandro Brunner >> Mathias Habl?tzel >> Irena Trajkovska >> Jaime Martin Losa >> Ricardo Gonzalez >> Rafael Lara >> Ricardo Gonzalez >> RubenRubio >> Luis L?pez URJC >> Javier Lopez Fernandez >> >> >> Best regards >> Christof >> ---- >> Christof Marti >> InIT Cloud Computing Lab - ICCLab http://cloudcomp.ch >> Institut of Applied Information Technology - InIT >> Zurich University of Applied Sciences - ZHAW >> School of Engineering >> P.O.Box, CH-8401 Winterthur >> Office:TD O3.18, Obere Kirchgasse 2 >> Phone: +41 58 934 70 63 >> Mail: mach at zhaw.ch >> Skype: christof-marti >> >> Sent from my iPad >> > > _______________________________________________ > 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: From lasse.oorni at ludocraft.com Tue Sep 3 10:07:23 2013 From: lasse.oorni at ludocraft.com (=?iso-8859-1?Q?=22Lasse_=D6=F6rni=22?=) Date: Tue, 3 Sep 2013 11:07:23 +0300 Subject: [Fiware-miwi] massive DOM manipulation benchmark In-Reply-To: <2DE48525-4376-40C3-9759-2097F6D1A74F@playsign.net> References: <5224948B.5020307@dfki.de> <5224EAD9.3070309@dfki.de> <2DE48525-4376-40C3-9759-2097F6D1A74F@playsign.net> Message-ID: <5dbcba900a5ced2ef24d4141f6b5710b.squirrel@urho.ludocraft.com> > The first rough figures we had for these were approximately: > > 1. Creating a few thousand objects at start. In a networked setup when a > client enters a new scene - in that case takes a while for the data to > arrive, I'm not sure how long exactly, Lasse probably has some estimate > and I think we can measure too. When reading the scene from a local file, > getting the data is very fast of course (excluding the loading of the > assets which can take time even locally, I mean just the elements/entities > and the attribute data with references to assets). A typical Tundra entity with Mesh, Name, Placeable and RigidBody components takes about 256 bytes to initially transmit (strangely even number, and in fact I was surprised how high this data amount is, certainly there is room for optimization), so if we assume a bandwidth of 100 KB/s, which is on the low side, we would take 2.5 seconds to synchronize 1000 such entities. - Lasse > 2. A couple of hundred constantly moving objects. In the current net sync > we use max 20Hz, and then the client scene code inter(- and extra)polates > the movement with the max 60fps used for drawing > > A local script for e.g. a swarm can (ideally) do much more manipulations > with the scene than what we typically can get over the net. > >> XML3D (which is the target) and some other SceneGraph and create a small >> benchmark that does some synthetic test of the relevant operations. This >> should give us a better option of what the performance differences >> between the two version is for realistic workloads. > > Agreed. > > Thanks for the clarification and further info about how you've made it, > seems that that's the strategy for dealing with the data flows instead of > going via the DOM document. > > ~Toni > >> I would assume that most of these operations might actually bypass the >> generic DOM interfaces and go straight to XML3D in JS (e.g. via typed >> arrays), which should not be much slower than directly using JS. All the >> internal XML3D/Xflow operations like rendering, animation, and similar >> operate in pure JS anyway (as we explained with the layered model in >> Winterthus), so there should not be a big difference for those >> operations anyway (other than differences in the rendering strategy >> itself. >> >> Since Sergiy and Torsten are implementing our sync server right now, we >> should be able to recreate a very similar setup to basic realXtend on >> our side and do some real live measurements there as well. Depending on >> how fast this will work, we may be able to go straight to this version >> for comparisons. Nothing is optimized much there, but its may be a good >> reference point. >> >> Since our implementation is based on the ECA model of realXtend, it >> might not be too hard to create common network layer (we use a very >> simple and inefficient protocol right now) and drive XML3D also from >> realXtend. This would be a great step forward (plus a perfect way for >> performance comparisons and tuning). >> >> >> Best, >> >> Philipp >> >> Am 02.09.2013 16:02, schrieb Toni Alatalo: >>> On Sep 2, 2013, at 4:37 PM, Kristian Sons >> > wrote: >>>> I saw that the JS modification in the test were just calling a >>>> function that sets the data of the object (something the JS engine has >>>> inlined quickly). To make it a little better comparable, I added a >>>> callback that sums up the ids. The DOM mutation events are clustered >>>> and scheduled in a separate phase: >>>> 10k DOM modifications: ~40ms + 6ms in callback >>>> 10k JS modifications: ~19ms >>>> Now we have _2.5x_ difference! >>> >>> Yes, we also figured that the most simple minimal JS thing there is the >>> 'upper bound' and understood that what is going on with the DOM is much >>> more complex. >>> >>> Please do feel free to fork/share if you want to show how you did the >>> clustering & scheduling, we also assumed that for real code to do the >>> DOM manipulations efficiently we need that. Of course we can also study >>> it further in the xml3d.js codebase where I figure you have it in >>> action. >>> >>> This first version of the benchmark was basically to see quickly how >>> well the naive usage of the DOM performs. I thought that it's quite >>> good >>> actually. >>> >>>> The DOM is meant as in interface to the user. That's how we designed >>>> XML3D. All medium-range modification (a few hundereds per frame) are >>>> okay. One must not forget that users will use jQuery etc, which can -- >>>> used the wrong way -- slow down the whole application (not only for 3D >>>> content). For all other operations, we have concept like Xflow, where >>>> the calculation is hidden behind the DOM interface. Also the rendering >>>> is also hidden behind the DOM structure. We even have our own memory >>>> management to get a better JS performance. >>>> Thus it really depends on the use case and the design of the DOM >>>> interface. The proposed benchmark might be too simple and one should >>>> be carefully with statements >>> >>> Yes, I think that is the question exactly for the overall design of the >>> architecture: what the usage of the DOM should be like, with respect to >>> network sync, rendering, scripts, input handling etc. And further in >>> how >>> much and what kind of DOM manipulations that results in and how they >>> would be good to handle. >>> >>> Thanks for the quick and well informed feedback! >>> >>> And certainly this naive test was not meant as an end-all-be-all >>> benchmark for any final conclusions but as I tried to emphasise the >>> total opposite: just a starting point and also us a way to learn about >>> the mutation observers (we'd never used them before). >>> >>>> Best regards, >>>> Kristian >>> >>> Cheers, >>> ~Toni >>> >>>>> Ok so here is info about the DOM manipulation performance test that >>>>> we recently started working on. I totally agree with the idea of >>>>> having small targeted groups for specific topics, such as this 3d web >>>>> client architecture. However as those don't exist yet let's use this >>>>> list now for the first communications before the conf call that's >>>>> being scheduled for this week. >>>>> >>>>> This benchmark is really simple and by no means fancy at this point >>>>> but already gives some information. 'Massive' in the email subject >>>>> refers to the fact that it can do a massive amount of DOM >>>>> manipulations, not that the test code would be massive at all :) >>>>> >>>>> The code and little documentation is available at: >>>>> https://github.com/playsign/wex-experiments/tree/master/domBenchmark >>>>> >>>>> The rationale is that in the current native realXtend implementation >>>>> in Tundra SDK we have a similar mechanism: the core scene has all the >>>>> data is in entity-attributes, and for example incoming network >>>>> messages that move objects are handled so that the net part modifies >>>>> that scene, which the renderer observes and updates the graphics >>>>> engine scene accordingly. >>>>> >>>>> In the FI-WARE goals and plans, and in the declarative 3d web >>>>> movement in general, there are good reasons for having all the data >>>>> in the DOM -- for example being able to use the browser debugger to >>>>> see and modify the values. We have the same in native Tundra SDK's >>>>> scene & entity editor GUIs. >>>>> >>>>> I drew a first sketch of an architecture diagram about how this could >>>>> work in the browser client, in a minimally modified WebTundra first >>>>> where using a JS array for the scene data is just switched to using >>>>> the DOM document >>>>> instead: https://rawgithub.com/realXtend/doc/master/dom/rexdom.svg >>>>> (in case >>>>> someone wants to edit it, the source is >>>>> at https://github.com/realXtend/doc/tree/master/dom - I used Inkscape >>>>> where SVG is the native format). >>>>> >>>>> To examine the feasibility of this design I wanted to know how it >>>>> performs. We don't have conclusive analysis nor any final verdict >>>>> yet. We test with quite large numbers because we can have quite a lot >>>>> happening in the scenes -- at least tens or hundreds of constantly >>>>> moving objects etc. In this design every change in every object >>>>> position would go via the DOM. >>>>> >>>>> To contrast, we have the similar mechnism implemented in pure JS - >>>>> just an array with the data and a reference to the observing callback >>>>> function. It is much simpler in functionality than what the DOM and >>>>> Mutation Observers provide -- can be perhaps considered as an upper >>>>> bound how fast an optimized solution could work. So not a fair >>>>> comparison. >>>>> >>>>> Some early figures: >>>>> >>>>> Creating DOM elements is quite fast, I now created 10k elements in >>>>> 0.136 seconds. >>>>> >>>>> Manipulating is quite fast too, 10k attribute modifications were made >>>>> in 84ms for me now. >>>>> >>>>> Erno did a little better benchmarking with a 100 repeated runs, both >>>>> for the DOM using and pure JS versions. His figures are on the >>>>> benchmark projects website but I paste to here too: >>>>> >>>>> "running the test for 10k elements 100 times in a row, the pure-js >>>>> version takes 19 ms. The DOM version of same takes 4700 ms. So a 250x >>>>> difference." >>>>> >>>>> We are aware that this is a microbenchmark with all kinds of >>>>> fallacies, can be improved if real benchmarking is necessary. >>>>> >>>>> But now I think the first question is: what are the real application >>>>> requirements? How much DOM manipulations do we really need? >>>>> >>>>> We talked a bit about that and I think we can construct a few >>>>> scenarios for that. Then we can calculate whether the performance is >>>>> ok. I wrote that question to the stub overall doc that plan to >>>>> continue in https://github.com/realXtend/doc/tree/master/dom >>>>> >>>>> This whole track was overridden a bit by the campus party >>>>> preparations recently but I think now is good time to continue. >>>>> >>>>> I hope this clarified the situation, am sorry for the confusion that >>>>> the quick '300x diff' pre-info during the weekend caused.. And to >>>>> make it clear: we haven't done this with a real 3d client or >>>>> networking or anything like that but decided to benchmark first in >>>>> isolation. >>>>> >>>>> About the performance difference, we suspect that it is due to the >>>>> internal machinery that the browser executes for every DOM change, >>>>> and possibly also something in the C++ <-> JS interfacing. I looked a >>>>> bit and found that to optimize large DOM manipulations web folks >>>>> batch e.g. element creations etc. and don't do them individually. >>>>> >>>>> Do ask for any further info, and please bear with us and the early & >>>>> bit cumbersome to use test case (we mostly just made it for ourselves >>>>> for now at least). >>>>> >>>>> Cheers, >>>>> ~Toni >>>>> >>>>> >>>>> _______________________________________________ >>>>> Fiware-miwi mailing list >>>>> Fiware-miwi at lists.fi-ware.eu >>>>> https://lists.fi-ware.eu/listinfo/fiware-miwi >>>> >>>> >>>> -- >>>> _______________________________________________________________________________ >>>> >>>> Kristian Sons >>>> Deutsches Forschungszentrum f?r K?nstliche Intelligenz GmbH, DFKI >>>> Agenten und Simulierte Realit?t >>>> Campus, Geb. D 3 2, Raum 0.77 >>>> 66123 Saarbr?cken, Germany >>>> >>>> Phone: +49 681 85775-3833 >>>> Phone: +49 681 302-3833 >>>> Fax: +49 681 85775?2235 >>>> kristian.sons at dfki.de >>>> http://www.xml3d.org >>>> >>>> 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 >>>> Amtsgericht Kaiserslautern, HRB 2313 >>>> _______________________________________________________________________________ >>>> _______________________________________________ >>>> Fiware-miwi mailing list >>>> Fiware-miwi at lists.fi-ware.eu >>>> https://lists.fi-ware.eu/listinfo/fiware-miwi >>> >>> >>> >>> _______________________________________________ >>> 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 >> --------------------------------------------------------------------------- >> > > _______________________________________________ > Fiware-miwi mailing list > Fiware-miwi at lists.fi-ware.eu > https://lists.fi-ware.eu/listinfo/fiware-miwi > -- Lasse ??rni Game Programmer LudoCraft Ltd. From toni at playsign.net Tue Sep 3 10:39:08 2013 From: toni at playsign.net (Toni Alatalo) Date: Tue, 3 Sep 2013 11:39:08 +0300 Subject: [Fiware-miwi] WP13 Architecture Telco and on-boarding In-Reply-To: References: Message-ID: Success! I'm now actually available for any of the potential slots, updated Doodle accordingly too. On Sep 3, 2013, at 10:24 AM, Toni Alatalo wrote: > I am trying to arrange so that could join tomorrow on Wed (the 9 CEST / 10 EEST slot) -- don't know yet whether it's possible but will tell when do. > > ~Toni > > On Sep 3, 2013, at 9:18 AM, Christof Marti wrote: > >> Hi >> >> Regarding the Architecture telco we have no time where all can attend. >> >> The three preferred options are: >> (Today) Tue 13:00 BST / 14:00 CEST / 15:00 EEST >> (Tomorrow) Wed 08:00 BST / 09:00 CEST / 10:00 EEST >> (Today) Tue 14:00 BST / 15:00 CEST / 16:00 EEST >> (Hope you all calculated the timezones correctly :) if not please correct your availability: http://www.doodle.com/e5qnirudzcc734ye >> >> @Toni, Jarkko: according to the doodle only one of you is available at these dates. Do you see a chance to find a common date within these 3 options? >> >> I'm heading for campus party to see when the meeting room is here is available and come back to you later. >> >> Cheers >> Christof >> >> Am 30.08.2013 um 15:08 schrieb Marti Christof (mach) : >> >>> Hello >>> >>> Hope you all had good summer vacation and are ready for some action :) >>> The WP13 Tools (forge, tracker, mailing-lists, wiki) are ready now and we need to go on with the onbording and architecture process. >>> >>> Telco: WP13 Architecture Kick-off >>> Philipp and I would like to start this with a telco, were we define the basic structure and process of the architecture definition. >>> Please fill this doodle until tomorrow Saturday 18:00 with the dates you are available next week. For the people in London we can try to get the FI-WARE meeting room. This telco is addressing primarily the GEs of the new Advanced WebUI partners, but KIARA partners are free to join. >>> >>> Mailing-Lists >>> I added you all to the fiware-miwi at lists.fi-ware.eu mailing list. I added a list of all current members at the end of this mail. If somebody of your organization is missing please let me know. >>> There are two additional mailing lists: >>> fiware-3d-lib at lists.fi-ware.eu for the 3D JavaScript Library task force >>> fiware-vw-mapping at lists.fi-ware.eu for the virtual world data mapping and translation task force >>> I have added all people I found an email to join one of the task forces. Please send me an email which list you want to join if you did not get a confirmation email. >>> >>> Forge (http://forge.fi-ware.eu) >>> If you did not create your forge account yet, please do so before you can continue with the following tasks. >>> See instructions: How to create a FusionForge account >>> >>> Once you created your account you have to join the different FI-WARE Projects. >>> See Instructions: How to join a FI-WARE project in FusionForge >>> >>> You should at least join the following projects: >>> * FIWARE (the public site) >>> * FI-WARE MIWI (the WP13 Project) >>> * FI-WARE PPP-Restricted (the FI-PPP partner Project) >>> And depending on your activities also to: >>> * FI-WARE Testbed (for testbed setup/support WP10) >>> * FI-WARE Exploitation (WP11) >>> You should be added automatically to >>> * FI-WARE privat (privat project for all FI-WARE partners) >>> if not, let me know. >>> >>> How-Tos & Instructions >>> You find all the HowTo descriptions on the FI-WARE main wiki page http://wiki.fi-ware.eu >>> Instructions on how to use FI-WARE Forge and Collaborative Tools has already been sent by Miguel. >>> I added his presentation as an attachment and here is also the link to Miguels introduction video: >>> https://dl.dropboxusercontent.com/u/25916180/FI_WARE/Forge_Induction_OpenCall1_partners.mp4 >>> (This is for FI-WARE partners only!! Do not disseminate outside of FI-WARE!!) >>> >>> Wiki >>> I will add all the relevant WP13 infos and the basic structure for the architecture pages to the WP13 wiki in the upcoming days. >>> https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi >>> You have to be logged into forge and be a member of the FI-WARE MIWI Project to access these pages. >>> >>> Members of the fiware-miwi mailing list: >>> Here the current members of the WP13 mailing-list. If somebody of your organisation is missing please let me know. >>> >>> Erno Kuusela >>> Toni Alatalo >>> Hanna Tiuraniemi >>> tapani at playsign.net >>> Tommi Hollstr?m >>> Jonne Nauha >>> Lasse ??rni >>> Tonny Manninen >>> Jarkko Vatjus-Anttila >>> Esa Posio >>> Kari Autio >>> Johannes Peltola >>> Philipp Slusallek >>> Torsten Spieldenner >>> Stefan Denne >>> Oliver Keller >>> Werner Stepan >>> Tizian Schneider >>> Felix Klein >>> Kristian Sons >>> Stefan Lemme >>> Andreas Nonnengart >>> Dmitri Rubinstein >>> Sergiy Byelozyorov >>> Christof Marti >>> Thomas Michael Bohnert >>> Philipp Aeschlimann >>> Sandro Brunner >>> Mathias Habl?tzel >>> Irena Trajkovska >>> Jaime Martin Losa >>> Ricardo Gonzalez >>> Rafael Lara >>> Ricardo Gonzalez >>> RubenRubio >>> Luis L?pez URJC >>> Javier Lopez Fernandez >>> >>> >>> Best regards >>> Christof >>> ---- >>> Christof Marti >>> InIT Cloud Computing Lab - ICCLab http://cloudcomp.ch >>> Institut of Applied Information Technology - InIT >>> Zurich University of Applied Sciences - ZHAW >>> School of Engineering >>> P.O.Box, CH-8401 Winterthur >>> Office:TD O3.18, Obere Kirchgasse 2 >>> Phone: +41 58 934 70 63 >>> Mail: mach at zhaw.ch >>> Skype: christof-marti >>> >>> Sent from my iPad >>> >> >> _______________________________________________ >> 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: From mach at zhaw.ch Tue Sep 3 13:40:29 2013 From: mach at zhaw.ch (Christof Marti) Date: Tue, 3 Sep 2013 12:40:29 +0100 Subject: [Fiware-miwi] WP13 Architecture Hangout Wed Sept 4th 09:00 CEST In-Reply-To: <54427f0f53454ac5b9117af86665285c@SRV-MAIL-001.zhaw.ch> References: <54427f0f53454ac5b9117af86665285c@SRV-MAIL-001.zhaw.ch> Message-ID: Hi again It took really long to get into CampusParty. FI-WARE booth finally opened at 11 and it took me another 90 minutes to find out which meeting rooms are available are suitable for telcos. Because the space here is very open and noisy, the only option is to have the meeting tomorrow morning 08:00 BST / 09:00 CEST / 10:00 EEST, because at this time it will be more silent (presentations start at 10:00 BST). I will open a hangout at 09:00 CEST and send you the URL by email. See you then Christof Am 03.09.2013 um 09:39 schrieb Toni Alatalo : > Success! I'm now actually available for any of the potential slots, updated Doodle accordingly too. > > On Sep 3, 2013, at 10:24 AM, Toni Alatalo wrote: > >> I am trying to arrange so that could join tomorrow on Wed (the 9 CEST / 10 EEST slot) -- don't know yet whether it's possible but will tell when do. >> >> ~Toni >> >> On Sep 3, 2013, at 9:18 AM, Christof Marti wrote: >> >>> Hi >>> >>> Regarding the Architecture telco we have no time where all can attend. >>> >>> The three preferred options are: >>> (Today) Tue 13:00 BST / 14:00 CEST / 15:00 EEST >>> (Tomorrow) Wed 08:00 BST / 09:00 CEST / 10:00 EEST >>> (Today) Tue 14:00 BST / 15:00 CEST / 16:00 EEST >>> (Hope you all calculated the timezones correctly :) if not please correct your availability: http://www.doodle.com/e5qnirudzcc734ye >>> >>> @Toni, Jarkko: according to the doodle only one of you is available at these dates. Do you see a chance to find a common date within these 3 options? >>> >>> I'm heading for campus party to see when the meeting room is here is available and come back to you later. >>> >>> Cheers >>> Christof >>> >>> Am 30.08.2013 um 15:08 schrieb Marti Christof (mach) : >>> >>>> Hello >>>> >>>> Hope you all had good summer vacation and are ready for some action :) >>>> The WP13 Tools (forge, tracker, mailing-lists, wiki) are ready now and we need to go on with the onbording and architecture process. >>>> >>>> Telco: WP13 Architecture Kick-off >>>> Philipp and I would like to start this with a telco, were we define the basic structure and process of the architecture definition. >>>> Please fill this doodle until tomorrow Saturday 18:00 with the dates you are available next week. For the people in London we can try to get the FI-WARE meeting room. This telco is addressing primarily the GEs of the new Advanced WebUI partners, but KIARA partners are free to join. >>>> >>>> Mailing-Lists >>>> I added you all to the fiware-miwi at lists.fi-ware.eu mailing list. I added a list of all current members at the end of this mail. If somebody of your organization is missing please let me know. >>>> There are two additional mailing lists: >>>> fiware-3d-lib at lists.fi-ware.eu for the 3D JavaScript Library task force >>>> fiware-vw-mapping at lists.fi-ware.eu for the virtual world data mapping and translation task force >>>> I have added all people I found an email to join one of the task forces. Please send me an email which list you want to join if you did not get a confirmation email. >>>> >>>> Forge (http://forge.fi-ware.eu) >>>> If you did not create your forge account yet, please do so before you can continue with the following tasks. >>>> See instructions: How to create a FusionForge account >>>> >>>> Once you created your account you have to join the different FI-WARE Projects. >>>> See Instructions: How to join a FI-WARE project in FusionForge >>>> >>>> You should at least join the following projects: >>>> * FIWARE (the public site) >>>> * FI-WARE MIWI (the WP13 Project) >>>> * FI-WARE PPP-Restricted (the FI-PPP partner Project) >>>> And depending on your activities also to: >>>> * FI-WARE Testbed (for testbed setup/support WP10) >>>> * FI-WARE Exploitation (WP11) >>>> You should be added automatically to >>>> * FI-WARE privat (privat project for all FI-WARE partners) >>>> if not, let me know. >>>> >>>> How-Tos & Instructions >>>> You find all the HowTo descriptions on the FI-WARE main wiki page http://wiki.fi-ware.eu >>>> Instructions on how to use FI-WARE Forge and Collaborative Tools has already been sent by Miguel. >>>> I added his presentation as an attachment and here is also the link to Miguels introduction video: >>>> https://dl.dropboxusercontent.com/u/25916180/FI_WARE/Forge_Induction_OpenCall1_partners.mp4 >>>> (This is for FI-WARE partners only!! Do not disseminate outside of FI-WARE!!) >>>> >>>> Wiki >>>> I will add all the relevant WP13 infos and the basic structure for the architecture pages to the WP13 wiki in the upcoming days. >>>> https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi >>>> You have to be logged into forge and be a member of the FI-WARE MIWI Project to access these pages. >>>> >>>> Members of the fiware-miwi mailing list: >>>> Here the current members of the WP13 mailing-list. If somebody of your organisation is missing please let me know. >>>> >>>> Erno Kuusela >>>> Toni Alatalo >>>> Hanna Tiuraniemi >>>> tapani at playsign.net >>>> Tommi Hollstr?m >>>> Jonne Nauha >>>> Lasse ??rni >>>> Tonny Manninen >>>> Jarkko Vatjus-Anttila >>>> Esa Posio >>>> Kari Autio >>>> Johannes Peltola >>>> Philipp Slusallek >>>> Torsten Spieldenner >>>> Stefan Denne >>>> Oliver Keller >>>> Werner Stepan >>>> Tizian Schneider >>>> Felix Klein >>>> Kristian Sons >>>> Stefan Lemme >>>> Andreas Nonnengart >>>> Dmitri Rubinstein >>>> Sergiy Byelozyorov >>>> Christof Marti >>>> Thomas Michael Bohnert >>>> Philipp Aeschlimann >>>> Sandro Brunner >>>> Mathias Habl?tzel >>>> Irena Trajkovska >>>> Jaime Martin Losa >>>> Ricardo Gonzalez >>>> Rafael Lara >>>> Ricardo Gonzalez >>>> RubenRubio >>>> Luis L?pez URJC >>>> Javier Lopez Fernandez >>>> >>>> >>>> Best regards >>>> Christof >>>> ---- >>>> Christof Marti >>>> InIT Cloud Computing Lab - ICCLab http://cloudcomp.ch >>>> Institut of Applied Information Technology - InIT >>>> Zurich University of Applied Sciences - ZHAW >>>> School of Engineering >>>> P.O.Box, CH-8401 Winterthur >>>> Office:TD O3.18, Obere Kirchgasse 2 >>>> Phone: +41 58 934 70 63 >>>> Mail: mach at zhaw.ch >>>> Skype: christof-marti >>>> >>>> Sent from my iPad >>>> >>> >>> _______________________________________________ >>> Fiware-miwi mailing list >>> Fiware-miwi at lists.fi-ware.eu >>> https://lists.fi-ware.eu/listinfo/fiware-miwi >> > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: not available URL: From tapani.jamsa at gmail.com Tue Sep 3 15:16:38 2013 From: tapani.jamsa at gmail.com (=?ISO-8859-1?B?VGFwYW5pIErkbXPk?=) Date: Tue, 3 Sep 2013 16:16:38 +0300 Subject: [Fiware-miwi] Use case: online multiplayer pong Message-ID: Hi, PongThreeJS is an online multiplayer pong game. It's designed to be used as a use case for fi-ware mifi platform dev. You can try the game directly here: https://dl.dropboxusercontent.com/u/60485425/Playsign/GitHub/PongThreeJS/Pong.html (Use the top right sliders to change player amount and ball's speed!) I made the source code available at github and wrote the readme for it: https://github.com/playsign/PongThreeJS Read the description(readme.md) for more info. Note that the multiplayer branch is not available in the github repository at the moment. -Tapani -- Tapani J?ms? Tarkka-ampujankatu 14 D 68 90120 Oulu Cell: 0407597153 Email: tapani.jamsa at gmail.com Linkedin: http://fi.linkedin.com/pub/tapani-j%C3%A4ms%C3%A4/6a/265/bb2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From toni at playsign.net Wed Sep 4 07:26:08 2013 From: toni at playsign.net (Toni Alatalo) Date: Wed, 4 Sep 2013 08:26:08 +0300 Subject: [Fiware-miwi] massive DOM manipulation benchmark In-Reply-To: <5dbcba900a5ced2ef24d4141f6b5710b.squirrel@urho.ludocraft.com> References: <5224948B.5020307@dfki.de> <5224EAD9.3070309@dfki.de> <2DE48525-4376-40C3-9759-2097F6D1A74F@playsign.net> <5dbcba900a5ced2ef24d4141f6b5710b.squirrel@urho.ludocraft.com> Message-ID: Hi all, I made an update to the client arch diagram draft, illustrating the 'The DOM is meant as in interface to the user' structure that Kristian discussed: https://rawgithub.com/realXtend/doc/master/dom/rexdom-dom_as_ui.svg Quite possibly not very accurate yet but at least has that idea somehow. Cheers, ~Toni On Tue, Sep 3, 2013 at 11:07 AM, "Lasse ??rni" wrote: > > The first rough figures we had for these were approximately: > > > > 1. Creating a few thousand objects at start. In a networked setup when a > > client enters a new scene - in that case takes a while for the data to > > arrive, I'm not sure how long exactly, Lasse probably has some estimate > > and I think we can measure too. When reading the scene from a local file, > > getting the data is very fast of course (excluding the loading of the > > assets which can take time even locally, I mean just the > elements/entities > > and the attribute data with references to assets). > > A typical Tundra entity with Mesh, Name, Placeable and RigidBody > components takes about 256 bytes to initially transmit (strangely even > number, and in fact I was surprised how high this data amount is, > certainly there is room for optimization), so if we assume a bandwidth of > 100 KB/s, which is on the low side, we would take 2.5 seconds to > synchronize 1000 such entities. > > - Lasse > > > > > > 2. A couple of hundred constantly moving objects. In the current net sync > > we use max 20Hz, and then the client scene code inter(- and extra)polates > > the movement with the max 60fps used for drawing > > > > A local script for e.g. a swarm can (ideally) do much more manipulations > > with the scene than what we typically can get over the net. > > > >> XML3D (which is the target) and some other SceneGraph and create a small > >> benchmark that does some synthetic test of the relevant operations. This > >> should give us a better option of what the performance differences > >> between the two version is for realistic workloads. > > > > Agreed. > > > > Thanks for the clarification and further info about how you've made it, > > seems that that's the strategy for dealing with the data flows instead of > > going via the DOM document. > > > > ~Toni > > > >> I would assume that most of these operations might actually bypass the > >> generic DOM interfaces and go straight to XML3D in JS (e.g. via typed > >> arrays), which should not be much slower than directly using JS. All the > >> internal XML3D/Xflow operations like rendering, animation, and similar > >> operate in pure JS anyway (as we explained with the layered model in > >> Winterthus), so there should not be a big difference for those > >> operations anyway (other than differences in the rendering strategy > >> itself. > >> > >> Since Sergiy and Torsten are implementing our sync server right now, we > >> should be able to recreate a very similar setup to basic realXtend on > >> our side and do some real live measurements there as well. Depending on > >> how fast this will work, we may be able to go straight to this version > >> for comparisons. Nothing is optimized much there, but its may be a good > >> reference point. > >> > >> Since our implementation is based on the ECA model of realXtend, it > >> might not be too hard to create common network layer (we use a very > >> simple and inefficient protocol right now) and drive XML3D also from > >> realXtend. This would be a great step forward (plus a perfect way for > >> performance comparisons and tuning). > >> > >> > >> Best, > >> > >> Philipp > >> > >> Am 02.09.2013 16:02, schrieb Toni Alatalo: > >>> On Sep 2, 2013, at 4:37 PM, Kristian Sons >>> > wrote: > >>>> I saw that the JS modification in the test were just calling a > >>>> function that sets the data of the object (something the JS engine has > >>>> inlined quickly). To make it a little better comparable, I added a > >>>> callback that sums up the ids. The DOM mutation events are clustered > >>>> and scheduled in a separate phase: > >>>> 10k DOM modifications: ~40ms + 6ms in callback > >>>> 10k JS modifications: ~19ms > >>>> Now we have _2.5x_ difference! > >>> > >>> Yes, we also figured that the most simple minimal JS thing there is the > >>> 'upper bound' and understood that what is going on with the DOM is much > >>> more complex. > >>> > >>> Please do feel free to fork/share if you want to show how you did the > >>> clustering & scheduling, we also assumed that for real code to do the > >>> DOM manipulations efficiently we need that. Of course we can also study > >>> it further in the xml3d.js codebase where I figure you have it in > >>> action. > >>> > >>> This first version of the benchmark was basically to see quickly how > >>> well the naive usage of the DOM performs. I thought that it's quite > >>> good > >>> actually. > >>> > >>>> The DOM is meant as in interface to the user. That's how we designed > >>>> XML3D. All medium-range modification (a few hundereds per frame) are > >>>> okay. One must not forget that users will use jQuery etc, which can -- > >>>> used the wrong way -- slow down the whole application (not only for 3D > >>>> content). For all other operations, we have concept like Xflow, where > >>>> the calculation is hidden behind the DOM interface. Also the rendering > >>>> is also hidden behind the DOM structure. We even have our own memory > >>>> management to get a better JS performance. > >>>> Thus it really depends on the use case and the design of the DOM > >>>> interface. The proposed benchmark might be too simple and one should > >>>> be carefully with statements? > >>> > >>> Yes, I think that is the question exactly for the overall design of the > >>> architecture: what the usage of the DOM should be like, with respect to > >>> network sync, rendering, scripts, input handling etc. And further in > >>> how > >>> much and what kind of DOM manipulations that results in and how they > >>> would be good to handle. > >>> > >>> Thanks for the quick and well informed feedback! > >>> > >>> And certainly this naive test was not meant as an end-all-be-all > >>> benchmark for any final conclusions but as I tried to emphasise the > >>> total opposite: just a starting point and also us a way to learn about > >>> the mutation observers (we'd never used them before). > >>> > >>>> Best regards, > >>>> Kristian > >>> > >>> Cheers, > >>> ~Toni > >>> > >>>>> Ok so here is info about the DOM manipulation performance test that > >>>>> we recently started working on. I totally agree with the idea of > >>>>> having small targeted groups for specific topics, such as this 3d web > >>>>> client architecture. However as those don't exist yet let's use this > >>>>> list now for the first communications before the conf call that's > >>>>> being scheduled for this week. > >>>>> > >>>>> This benchmark is really simple and by no means fancy at this point > >>>>> but already gives some information. 'Massive' in the email subject > >>>>> refers to the fact that it can do a massive amount of DOM > >>>>> manipulations, not that the test code would be massive at all :) > >>>>> > >>>>> The code and little documentation is available at: > >>>>> https://github.com/playsign/wex-experiments/tree/master/domBenchmark > >>>>> > >>>>> The rationale is that in the current native realXtend implementation > >>>>> in Tundra SDK we have a similar mechanism: the core scene has all the > >>>>> data is in entity-attributes, and for example incoming network > >>>>> messages that move objects are handled so that the net part modifies > >>>>> that scene, which the renderer observes and updates the graphics > >>>>> engine scene accordingly. > >>>>> > >>>>> In the FI-WARE goals and plans, and in the declarative 3d web > >>>>> movement in general, there are good reasons for having all the data > >>>>> in the DOM -- for example being able to use the browser debugger to > >>>>> see and modify the values. We have the same in native Tundra SDK's > >>>>> scene & entity editor GUIs. > >>>>> > >>>>> I drew a first sketch of an architecture diagram about how this could > >>>>> work in the browser client, in a minimally modified WebTundra first > >>>>> where using a JS array for the scene data is just switched to using > >>>>> the DOM document > >>>>> instead: https://rawgithub.com/realXtend/doc/master/dom/rexdom.svg > >>>>> (in case > >>>>> someone wants to edit it, the source is > >>>>> at https://github.com/realXtend/doc/tree/master/dom - I used > Inkscape > >>>>> where SVG is the native format). > >>>>> > >>>>> To examine the feasibility of this design I wanted to know how it > >>>>> performs. We don't have conclusive analysis nor any final verdict > >>>>> yet. We test with quite large numbers because we can have quite a lot > >>>>> happening in the scenes -- at least tens or hundreds of constantly > >>>>> moving objects etc. In this design every change in every object > >>>>> position would go via the DOM. > >>>>> > >>>>> To contrast, we have the similar mechnism implemented in pure JS - > >>>>> just an array with the data and a reference to the observing callback > >>>>> function. It is much simpler in functionality than what the DOM and > >>>>> Mutation Observers provide -- can be perhaps considered as an upper > >>>>> bound how fast an optimized solution could work. So not a fair > >>>>> comparison. > >>>>> > >>>>> Some early figures: > >>>>> > >>>>> Creating DOM elements is quite fast, I now created 10k elements in > >>>>> 0.136 seconds. > >>>>> > >>>>> Manipulating is quite fast too, 10k attribute modifications were made > >>>>> in 84ms for me now. > >>>>> > >>>>> Erno did a little better benchmarking with a 100 repeated runs, both > >>>>> for the DOM using and pure JS versions. His figures are on the > >>>>> benchmark projects website but I paste to here too: > >>>>> > >>>>> "running the test for 10k elements 100 times in a row, the pure-js > >>>>> version takes 19 ms. The DOM version of same takes 4700 ms. So a 250x > >>>>> difference." > >>>>> > >>>>> We are aware that this is a microbenchmark with all kinds of > >>>>> fallacies, can be improved if real benchmarking is necessary. > >>>>> > >>>>> But now I think the first question is: what are the real application > >>>>> requirements? How much DOM manipulations do we really need? > >>>>> > >>>>> We talked a bit about that and I think we can construct a few > >>>>> scenarios for that. Then we can calculate whether the performance is > >>>>> ok. I wrote that question to the stub overall doc that plan to > >>>>> continue in https://github.com/realXtend/doc/tree/master/dom > >>>>> > >>>>> This whole track was overridden a bit by the campus party > >>>>> preparations recently but I think now is good time to continue. > >>>>> > >>>>> I hope this clarified the situation, am sorry for the confusion that > >>>>> the quick '300x diff' pre-info during the weekend caused.. And to > >>>>> make it clear: we haven't done this with a real 3d client or > >>>>> networking or anything like that but decided to benchmark first in > >>>>> isolation. > >>>>> > >>>>> About the performance difference, we suspect that it is due to the > >>>>> internal machinery that the browser executes for every DOM change, > >>>>> and possibly also something in the C++ <-> JS interfacing. I looked a > >>>>> bit and found that to optimize large DOM manipulations web folks > >>>>> batch e.g. element creations etc. and don't do them individually. > >>>>> > >>>>> Do ask for any further info, and please bear with us and the early & > >>>>> bit cumbersome to use test case (we mostly just made it for ourselves > >>>>> for now at least). > >>>>> > >>>>> Cheers, > >>>>> ~Toni > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Fiware-miwi mailing list > >>>>> Fiware-miwi at lists.fi-ware.eu > >>>>> https://lists.fi-ware.eu/listinfo/fiware-miwi > >>>> > >>>> > >>>> -- > >>>> > _______________________________________________________________________________ > >>>> > >>>> Kristian Sons > >>>> Deutsches Forschungszentrum f?r K?nstliche Intelligenz GmbH, DFKI > >>>> Agenten und Simulierte Realit?t > >>>> Campus, Geb. D 3 2, Raum 0.77 > >>>> 66123 Saarbr?cken, Germany > >>>> > >>>> Phone: +49 681 85775-3833 > >>>> Phone: +49 681 302-3833 > >>>> Fax: +49 681 85775?2235 > >>>> kristian.sons at dfki.de > >>>> http://www.xml3d.org > >>>> > >>>> 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 > >>>> Amtsgericht Kaiserslautern, HRB 2313 > >>>> > _______________________________________________________________________________ > >>>> _______________________________________________ > >>>> Fiware-miwi mailing list > >>>> Fiware-miwi at lists.fi-ware.eu > >>>> https://lists.fi-ware.eu/listinfo/fiware-miwi > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > >> > --------------------------------------------------------------------------- > >> > > > > _______________________________________________ > > Fiware-miwi mailing list > > Fiware-miwi at lists.fi-ware.eu > > https://lists.fi-ware.eu/listinfo/fiware-miwi > > > > > -- > Lasse ??rni > Game Programmer > LudoCraft Ltd. > > > _______________________________________________ > 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: From mach at zhaw.ch Wed Sep 4 08:01:13 2013 From: mach at zhaw.ch (Christof Marti) Date: Wed, 4 Sep 2013 07:01:13 +0100 Subject: [Fiware-miwi] WP13 Architecture Hangout Wed Sept 4th 09:00 CEST In-Reply-To: References: <54427f0f53454ac5b9117af86665285c@SRV-MAIL-001.zhaw.ch> Message-ID: Good morning I created an agenda/minutes document for todays meeting: https://docs.google.com/document/d/1AmytwwWn1MKYkhhhhaN_bYNuNxYoZNsTjnOIbtwiW2U/edit See you at 09:00 CEST Christof Am 03.09.2013 um 12:40 schrieb Marti Christof (mach) : > Hi again > > It took really long to get into CampusParty. FI-WARE booth finally opened at 11 and it took me another 90 minutes to find out which meeting rooms are available are suitable for telcos. > > Because the space here is very open and noisy, the only option is to have the meeting tomorrow morning 08:00 BST / 09:00 CEST / 10:00 EEST, because at this time it will be more silent (presentations start at 10:00 BST). > > I will open a hangout at 09:00 CEST and send you the URL by email. > > See you then > > Christof > > > Am 03.09.2013 um 09:39 schrieb Toni Alatalo : > >> Success! I'm now actually available for any of the potential slots, updated Doodle accordingly too. >> >> On Sep 3, 2013, at 10:24 AM, Toni Alatalo wrote: >> >>> I am trying to arrange so that could join tomorrow on Wed (the 9 CEST / 10 EEST slot) -- don't know yet whether it's possible but will tell when do. >>> >>> ~Toni >>> >>> On Sep 3, 2013, at 9:18 AM, Christof Marti wrote: >>> >>>> Hi >>>> >>>> Regarding the Architecture telco we have no time where all can attend. >>>> >>>> The three preferred options are: >>>> (Today) Tue 13:00 BST / 14:00 CEST / 15:00 EEST >>>> (Tomorrow) Wed 08:00 BST / 09:00 CEST / 10:00 EEST >>>> (Today) Tue 14:00 BST / 15:00 CEST / 16:00 EEST >>>> (Hope you all calculated the timezones correctly :) if not please correct your availability: http://www.doodle.com/e5qnirudzcc734ye >>>> >>>> @Toni, Jarkko: according to the doodle only one of you is available at these dates. Do you see a chance to find a common date within these 3 options? >>>> >>>> I'm heading for campus party to see when the meeting room is here is available and come back to you later. >>>> >>>> Cheers >>>> Christof >>>> >>>> Am 30.08.2013 um 15:08 schrieb Marti Christof (mach) : >>>> >>>>> Hello >>>>> >>>>> Hope you all had good summer vacation and are ready for some action :) >>>>> The WP13 Tools (forge, tracker, mailing-lists, wiki) are ready now and we need to go on with the onbording and architecture process. >>>>> >>>>> Telco: WP13 Architecture Kick-off >>>>> Philipp and I would like to start this with a telco, were we define the basic structure and process of the architecture definition. >>>>> Please fill this doodle until tomorrow Saturday 18:00 with the dates you are available next week. For the people in London we can try to get the FI-WARE meeting room. This telco is addressing primarily the GEs of the new Advanced WebUI partners, but KIARA partners are free to join. >>>>> >>>>> Mailing-Lists >>>>> I added you all to the fiware-miwi at lists.fi-ware.eu mailing list. I added a list of all current members at the end of this mail. If somebody of your organization is missing please let me know. >>>>> There are two additional mailing lists: >>>>> fiware-3d-lib at lists.fi-ware.eu for the 3D JavaScript Library task force >>>>> fiware-vw-mapping at lists.fi-ware.eu for the virtual world data mapping and translation task force >>>>> I have added all people I found an email to join one of the task forces. Please send me an email which list you want to join if you did not get a confirmation email. >>>>> >>>>> Forge (http://forge.fi-ware.eu) >>>>> If you did not create your forge account yet, please do so before you can continue with the following tasks. >>>>> See instructions: How to create a FusionForge account >>>>> >>>>> Once you created your account you have to join the different FI-WARE Projects. >>>>> See Instructions: How to join a FI-WARE project in FusionForge >>>>> >>>>> You should at least join the following projects: >>>>> * FIWARE (the public site) >>>>> * FI-WARE MIWI (the WP13 Project) >>>>> * FI-WARE PPP-Restricted (the FI-PPP partner Project) >>>>> And depending on your activities also to: >>>>> * FI-WARE Testbed (for testbed setup/support WP10) >>>>> * FI-WARE Exploitation (WP11) >>>>> You should be added automatically to >>>>> * FI-WARE privat (privat project for all FI-WARE partners) >>>>> if not, let me know. >>>>> >>>>> How-Tos & Instructions >>>>> You find all the HowTo descriptions on the FI-WARE main wiki page http://wiki.fi-ware.eu >>>>> Instructions on how to use FI-WARE Forge and Collaborative Tools has already been sent by Miguel. >>>>> I added his presentation as an attachment and here is also the link to Miguels introduction video: >>>>> https://dl.dropboxusercontent.com/u/25916180/FI_WARE/Forge_Induction_OpenCall1_partners.mp4 >>>>> (This is for FI-WARE partners only!! Do not disseminate outside of FI-WARE!!) >>>>> >>>>> Wiki >>>>> I will add all the relevant WP13 infos and the basic structure for the architecture pages to the WP13 wiki in the upcoming days. >>>>> https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi >>>>> You have to be logged into forge and be a member of the FI-WARE MIWI Project to access these pages. >>>>> >>>>> Members of the fiware-miwi mailing list: >>>>> Here the current members of the WP13 mailing-list. If somebody of your organisation is missing please let me know. >>>>> >>>>> Erno Kuusela >>>>> Toni Alatalo >>>>> Hanna Tiuraniemi >>>>> tapani at playsign.net >>>>> Tommi Hollstr?m >>>>> Jonne Nauha >>>>> Lasse ??rni >>>>> Tonny Manninen >>>>> Jarkko Vatjus-Anttila >>>>> Esa Posio >>>>> Kari Autio >>>>> Johannes Peltola >>>>> Philipp Slusallek >>>>> Torsten Spieldenner >>>>> Stefan Denne >>>>> Oliver Keller >>>>> Werner Stepan >>>>> Tizian Schneider >>>>> Felix Klein >>>>> Kristian Sons >>>>> Stefan Lemme >>>>> Andreas Nonnengart >>>>> Dmitri Rubinstein >>>>> Sergiy Byelozyorov >>>>> Christof Marti >>>>> Thomas Michael Bohnert >>>>> Philipp Aeschlimann >>>>> Sandro Brunner >>>>> Mathias Habl?tzel >>>>> Irena Trajkovska >>>>> Jaime Martin Losa >>>>> Ricardo Gonzalez >>>>> Rafael Lara >>>>> Ricardo Gonzalez >>>>> RubenRubio >>>>> Luis L?pez URJC >>>>> Javier Lopez Fernandez >>>>> >>>>> >>>>> Best regards >>>>> Christof >>>>> ---- >>>>> Christof Marti >>>>> InIT Cloud Computing Lab - ICCLab http://cloudcomp.ch >>>>> Institut of Applied Information Technology - InIT >>>>> Zurich University of Applied Sciences - ZHAW >>>>> School of Engineering >>>>> P.O.Box, CH-8401 Winterthur >>>>> Office:TD O3.18, Obere Kirchgasse 2 >>>>> Phone: +41 58 934 70 63 >>>>> Mail: mach at zhaw.ch >>>>> Skype: christof-marti >>>>> >>>>> Sent from my iPad >>>>> >>>> >>>> _______________________________________________ >>>> Fiware-miwi mailing list >>>> Fiware-miwi at lists.fi-ware.eu >>>> https://lists.fi-ware.eu/listinfo/fiware-miwi >>> >> >> _______________________________________________ >> Fiware-miwi mailing list >> Fiware-miwi at lists.fi-ware.eu >> https://lists.fi-ware.eu/listinfo/fiware-miwi > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: not available URL: From mach at zhaw.ch Wed Sep 4 08:56:16 2013 From: mach at zhaw.ch (Christof Marti) Date: Wed, 4 Sep 2013 07:56:16 +0100 Subject: [Fiware-miwi] WP13 Architecture Hangout Wed Sept 4th 09:00 CEST In-Reply-To: References: <54427f0f53454ac5b9117af86665285c@SRV-MAIL-001.zhaw.ch> Message-ID: <83B7F0CD-C440-460E-BD90-92483F4C3E3C@zhaw.ch> Hi I already opened the hangout. So you can join anytime here: https://plus.google.com/hangouts/_/7397616e956412ae108b4a80f8eb6ba45e2837d1?hl=de Cheers Christof Am 04.09.2013 um 07:01 schrieb Marti Christof (mach) : > Good morning > > I created an agenda/minutes document for todays meeting: https://docs.google.com/document/d/1AmytwwWn1MKYkhhhhaN_bYNuNxYoZNsTjnOIbtwiW2U/edit > > See you at 09:00 CEST > > Christof > > > Am 03.09.2013 um 12:40 schrieb Marti Christof (mach) : > >> Hi again >> >> It took really long to get into CampusParty. FI-WARE booth finally opened at 11 and it took me another 90 minutes to find out which meeting rooms are available are suitable for telcos. >> >> Because the space here is very open and noisy, the only option is to have the meeting tomorrow morning 08:00 BST / 09:00 CEST / 10:00 EEST, because at this time it will be more silent (presentations start at 10:00 BST). >> >> I will open a hangout at 09:00 CEST and send you the URL by email. >> >> See you then >> >> Christof >> >> >> Am 03.09.2013 um 09:39 schrieb Toni Alatalo : >> >>> Success! I'm now actually available for any of the potential slots, updated Doodle accordingly too. >>> >>> On Sep 3, 2013, at 10:24 AM, Toni Alatalo wrote: >>> >>>> I am trying to arrange so that could join tomorrow on Wed (the 9 CEST / 10 EEST slot) -- don't know yet whether it's possible but will tell when do. >>>> >>>> ~Toni >>>> >>>> On Sep 3, 2013, at 9:18 AM, Christof Marti wrote: >>>> >>>>> Hi >>>>> >>>>> Regarding the Architecture telco we have no time where all can attend. >>>>> >>>>> The three preferred options are: >>>>> (Today) Tue 13:00 BST / 14:00 CEST / 15:00 EEST >>>>> (Tomorrow) Wed 08:00 BST / 09:00 CEST / 10:00 EEST >>>>> (Today) Tue 14:00 BST / 15:00 CEST / 16:00 EEST >>>>> (Hope you all calculated the timezones correctly :) if not please correct your availability: http://www.doodle.com/e5qnirudzcc734ye >>>>> >>>>> @Toni, Jarkko: according to the doodle only one of you is available at these dates. Do you see a chance to find a common date within these 3 options? >>>>> >>>>> I'm heading for campus party to see when the meeting room is here is available and come back to you later. >>>>> >>>>> Cheers >>>>> Christof >>>>> >>>>> Am 30.08.2013 um 15:08 schrieb Marti Christof (mach) : >>>>> >>>>>> Hello >>>>>> >>>>>> Hope you all had good summer vacation and are ready for some action :) >>>>>> The WP13 Tools (forge, tracker, mailing-lists, wiki) are ready now and we need to go on with the onbording and architecture process. >>>>>> >>>>>> Telco: WP13 Architecture Kick-off >>>>>> Philipp and I would like to start this with a telco, were we define the basic structure and process of the architecture definition. >>>>>> Please fill this doodle until tomorrow Saturday 18:00 with the dates you are available next week. For the people in London we can try to get the FI-WARE meeting room. This telco is addressing primarily the GEs of the new Advanced WebUI partners, but KIARA partners are free to join. >>>>>> >>>>>> Mailing-Lists >>>>>> I added you all to the fiware-miwi at lists.fi-ware.eu mailing list. I added a list of all current members at the end of this mail. If somebody of your organization is missing please let me know. >>>>>> There are two additional mailing lists: >>>>>> fiware-3d-lib at lists.fi-ware.eu for the 3D JavaScript Library task force >>>>>> fiware-vw-mapping at lists.fi-ware.eu for the virtual world data mapping and translation task force >>>>>> I have added all people I found an email to join one of the task forces. Please send me an email which list you want to join if you did not get a confirmation email. >>>>>> >>>>>> Forge (http://forge.fi-ware.eu) >>>>>> If you did not create your forge account yet, please do so before you can continue with the following tasks. >>>>>> See instructions: How to create a FusionForge account >>>>>> >>>>>> Once you created your account you have to join the different FI-WARE Projects. >>>>>> See Instructions: How to join a FI-WARE project in FusionForge >>>>>> >>>>>> You should at least join the following projects: >>>>>> * FIWARE (the public site) >>>>>> * FI-WARE MIWI (the WP13 Project) >>>>>> * FI-WARE PPP-Restricted (the FI-PPP partner Project) >>>>>> And depending on your activities also to: >>>>>> * FI-WARE Testbed (for testbed setup/support WP10) >>>>>> * FI-WARE Exploitation (WP11) >>>>>> You should be added automatically to >>>>>> * FI-WARE privat (privat project for all FI-WARE partners) >>>>>> if not, let me know. >>>>>> >>>>>> How-Tos & Instructions >>>>>> You find all the HowTo descriptions on the FI-WARE main wiki page http://wiki.fi-ware.eu >>>>>> Instructions on how to use FI-WARE Forge and Collaborative Tools has already been sent by Miguel. >>>>>> I added his presentation as an attachment and here is also the link to Miguels introduction video: >>>>>> https://dl.dropboxusercontent.com/u/25916180/FI_WARE/Forge_Induction_OpenCall1_partners.mp4 >>>>>> (This is for FI-WARE partners only!! Do not disseminate outside of FI-WARE!!) >>>>>> >>>>>> Wiki >>>>>> I will add all the relevant WP13 infos and the basic structure for the architecture pages to the WP13 wiki in the upcoming days. >>>>>> https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi >>>>>> You have to be logged into forge and be a member of the FI-WARE MIWI Project to access these pages. >>>>>> >>>>>> Members of the fiware-miwi mailing list: >>>>>> Here the current members of the WP13 mailing-list. If somebody of your organisation is missing please let me know. >>>>>> >>>>>> Erno Kuusela >>>>>> Toni Alatalo >>>>>> Hanna Tiuraniemi >>>>>> tapani at playsign.net >>>>>> Tommi Hollstr?m >>>>>> Jonne Nauha >>>>>> Lasse ??rni >>>>>> Tonny Manninen >>>>>> Jarkko Vatjus-Anttila >>>>>> Esa Posio >>>>>> Kari Autio >>>>>> Johannes Peltola >>>>>> Philipp Slusallek >>>>>> Torsten Spieldenner >>>>>> Stefan Denne >>>>>> Oliver Keller >>>>>> Werner Stepan >>>>>> Tizian Schneider >>>>>> Felix Klein >>>>>> Kristian Sons >>>>>> Stefan Lemme >>>>>> Andreas Nonnengart >>>>>> Dmitri Rubinstein >>>>>> Sergiy Byelozyorov >>>>>> Christof Marti >>>>>> Thomas Michael Bohnert >>>>>> Philipp Aeschlimann >>>>>> Sandro Brunner >>>>>> Mathias Habl?tzel >>>>>> Irena Trajkovska >>>>>> Jaime Martin Losa >>>>>> Ricardo Gonzalez >>>>>> Rafael Lara >>>>>> Ricardo Gonzalez >>>>>> RubenRubio >>>>>> Luis L?pez URJC >>>>>> Javier Lopez Fernandez >>>>>> >>>>>> >>>>>> Best regards >>>>>> Christof >>>>>> ---- >>>>>> Christof Marti >>>>>> InIT Cloud Computing Lab - ICCLab http://cloudcomp.ch >>>>>> Institut of Applied Information Technology - InIT >>>>>> Zurich University of Applied Sciences - ZHAW >>>>>> School of Engineering >>>>>> P.O.Box, CH-8401 Winterthur >>>>>> Office:TD O3.18, Obere Kirchgasse 2 >>>>>> Phone: +41 58 934 70 63 >>>>>> Mail: mach at zhaw.ch >>>>>> Skype: christof-marti >>>>>> >>>>>> Sent from my iPad >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Fiware-miwi mailing list >>>>> Fiware-miwi at lists.fi-ware.eu >>>>> https://lists.fi-ware.eu/listinfo/fiware-miwi >>>> >>> >>> _______________________________________________ >>> Fiware-miwi mailing list >>> Fiware-miwi at lists.fi-ware.eu >>> https://lists.fi-ware.eu/listinfo/fiware-miwi >> >> _______________________________________________ >> Fiware-miwi mailing list >> Fiware-miwi at lists.fi-ware.eu >> https://lists.fi-ware.eu/listinfo/fiware-miwi > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: not available URL: From Philipp.Slusallek at dfki.de Thu Sep 5 07:37:30 2013 From: Philipp.Slusallek at dfki.de (Philipp Slusallek) Date: Thu, 05 Sep 2013 07:37:30 +0200 Subject: [Fiware-miwi] xflow + WebCL In-Reply-To: References: Message-ID: <5228189A.8000009@dfki.de> [I am CCing to the MiWi list, as this may be interesting also in a wider architectural context.] Hi Jouni, Welcome in the team! Integration of optimal HW support is a very important aspect of WP13, so your looking into this is very much appreciated. Here are the possible options that we see for implementing support for WebCL: 1. You should be able to implement individual kernels directly in Xflow, similar to the already existing support for glsl computations in Xflow nodes. Thanks to the modular design of Xflow this should be a a rather small change to Xflow and would already be a great first step. Felix (in CC) can point you to the right part of Xflow and get you a head start for implementing it. 2. Currently Xflow assumes that the results of Xflow nodes are available in JS after each node. This is obviously inefficient, if the next node is also implemented on the GPU as data would be up and downloaded after each node. There is no support for this in Xflow yet but it should not be very hard to implement this in the Xflow core. Again Felix would be the right person to talk to about that. 3. As yet another optimization one could even merge the code from two (or more) successive Xflow kernels into one and execute it as a single kernel. We already have implemented this (text-based) merging of code for the composition of vertex shaders. It would be an option to extend this scheme to also apply to WebCL code but it could be a bit more complicated here and programmers would have to follow a certain programming style and format. It might not be necessary to do this as we might have Option 4 available in time before you would get to this. 4. Kristian is currently developing a very nice framework for specifying shaders in JS ("shader.js"). It allows to write completely generic shaders in JS and uses a small compiler framework (also in JS) to cross-compile this code to different concrete shading languages. We are developing this to be able to have portable and platform neutral shaders that can be used with any rendering system. We are targeting feed-forward renderers (glsl), deferred renderer (glsl, OpenCL), and real-time ray-tracing renderers (Intel's Embree, for a start). The language features are compatible with those from the OpenSL (Sony) and MDL (Nvidia), they are compatible with (real-time) global illumination algorithms, and should work everywhere. So we should be able to target also high-end rendering with a single shader/material library. We have formed a small initial small consortium with the German industry to promote this idea. This last option is very general and uses a "real" compiler (in JS). With some additional effort it should be possible to extend this compiler to also support computational kernels and generate WebCL (or any other: CUDA, RiverTrail, C/C++ with intrinsics) code. Since the compiler "understands" the code, it should ideally be able to fully merge kernels without any formatting conventions that the programmer has to follow. Because we can do all sort of optimizations at the high level (in addition to the low-level optimizations that are still done by the glsl/WebCL/etc backend compiler) this will be the most performant and most general option. However, this is still work in progress and we plan to focus exclusively on shaders for now (upcoming paper deadline). Kristian is the contact person for this work. In terms of schedule, I suggest that you look at the options (1) and (2) first as low-hanging fruits that will give us most of the performance optimizations already. You can then still look at (3) or we might skip this and go straight to (4) depending on how far we are ready by that time. Feel free to contact Felix and Kristian as needed so they can point you in the right direction. We have lots of use cases for any speedup that we can achieve and so are looking forward to your work! Hope this helps, Philipp Am 04.09.2013 11:46, schrieb Jouni Mietola: > Adding our CTO, Jarkko Vatjus-Anttila as cc recipient. > > > On Wed, Sep 4, 2013 at 11:43 AM, Jouni Mietola > > wrote: > > Prof. Dr. Philipp Slusallek, > > > I am a software engineer from Cyberlightning Ltd. We are currently > working on EU's FI-WARE project and we are trying to turn the xflow > modules into accelerated ones. Do you have recommendations how to > approach this issue and are you planning to use webCL in near > future? I have found out that you are using rivertrail for parallel > computing. We are looking forward to use webCL. > > Currently we are planning to use Nokia's webCL prototype for firefox > which seems to be the starting point for the webCL's future > development. > > About the ongoing FI-WARE project: > http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.Epic.AdvUI.AdvWebUI.DataflowProcessing > > WebCL Working Draft: > https://cvs.khronos.org/svn/repos/registry/trunk/public/webcl/spec/latest/index.html > > Nokia WebCL Prototype: > http://webcl.nokiaresearch.com/ > > Respectfully, > Jouni Mietola > Software Engineer > Cyberlightning Ltd. > > > > > > > > -- ------------------------------------------------------------------------- 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: From Philipp.Slusallek at dfki.de Thu Sep 5 10:13:12 2013 From: Philipp.Slusallek at dfki.de (Philipp Slusallek) Date: Thu, 05 Sep 2013 10:13:12 +0200 Subject: [Fiware-miwi] Fwd: Rejection of people joining the list In-Reply-To: <52282727.6060903@tid.es> References: <52282727.6060903@tid.es> Message-ID: <52283D18.8010902@dfki.de> Hi, Does anyone know this person? If yes, please ask him/her to subscribe through a mailing address that is part of one of the partners. Best, Philipp -------- Original-Nachricht -------- Betreff: Rejection of people joining the list Datum: Thu, 05 Sep 2013 08:39:35 +0200 Von: Miguel Carrillo An: JUAN JOSE HIERRO SUREDA , Philipp Slusallek Juanjo, Philipp, I have rejected a request to join * fiware-user-interface at lists.fi-ware.eu coming from * j.salkevicius at gmail.com I do not know if this is a legitimate request but for safety reasons, we want corporate addresses only. Gmail, yahoo, etc will not be accepted on our lists or on the forge. Best regards, Miguel -- ---------------------------------------------------------------------- _/ _/_/ Miguel Carrillo Pacheco _/ _/ _/ _/ Telef?nica Distrito Telef?nica _/ _/_/_/ _/ _/ Investigaci?n y Edifico Oeste 1, Planta 9 _/ _/ _/ _/ Desarrollo Ronda de la Comunicaci?n S/N _/ _/_/ 28050 Madrid (Spain) Tel: (+34) 91 483 26 77 e-mail: mcp at tid.es Follow FI-WARE on the net Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: http://twitter.com/Fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ---------------------------------------------------------------------- ------------------------------------------------------------------------ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx -- ------------------------------------------------------------------------- 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: From jonne at adminotech.com Fri Sep 6 09:32:22 2013 From: jonne at adminotech.com (Jonne Nauha) Date: Fri, 6 Sep 2013 08:32:22 +0100 Subject: [Fiware-miwi] XML3D hangout Message-ID: We were under the impression that we had a meeting 30 minutes ago. We here at London and guys here in Finland are standing by, here is out hangout. Let us know if we have the meeting or not. https://plus.google.com/hangouts/_/25da0487240d4ef9a0525d032f4be1007ae58d17?hl=en Best regards, Jonne Nauha Meshmoon developer at Adminotech Ltd. www.meshmoon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From erno at playsign.net Fri Sep 6 09:52:38 2013 From: erno at playsign.net (Erno Kuusela) Date: Fri, 6 Sep 2013 10:52:38 +0300 Subject: [Fiware-miwi] XML3D hangout In-Reply-To: References: Message-ID: <20130906075238.GR62563@ee.oulu.fi> Hello all, I guess there was a misunderstanding about the time, Toni saw that the minutes say 10:00 CET and not 09:00 like we thought :) But we're still here at the same hangout. Erno From jarkko at cyberlightning.com Fri Sep 6 10:13:14 2013 From: jarkko at cyberlightning.com (Jarkko Vatjus-Anttila) Date: Fri, 6 Sep 2013 11:13:14 +0300 Subject: [Fiware-miwi] XML3D hangout In-Reply-To: <20130906075238.GR62563@ee.oulu.fi> References: <20130906075238.GR62563@ee.oulu.fi> Message-ID: Is there confirmation whether the jurying will affect this. At least there are no replies to the schedule proposal. I am in network reach in 30mins roughly. Jarkko 6.9.2013 10.53 "Erno Kuusela" kirjoitti: > Hello all, > > I guess there was a misunderstanding about the time, Toni saw that the > minutes say 10:00 CET and not 09:00 like we thought :) But we're > still here at the same hangout. > > Erno > _______________________________________________ > 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: From toni at playsign.net Fri Sep 6 11:22:29 2013 From: toni at playsign.net (Toni Alatalo) Date: Fri, 6 Sep 2013 12:22:29 +0300 Subject: [Fiware-miwi] oulu3d city model Message-ID: (was discussed in the meeting now) This is the old small & even optimised version from >year ago, for use for first performance tests now: http://www.ee.oulu.fi/~antont/download/oulu3dlive-lofi.zip There's the source blends, with a Masterscene blend where everything is integrated so it's easy to export to whatever you can export to from Blender. With DDS textures at least, runs fine with Ogre and I think with three.js too (others (especially CIE) have done that earlier, we are repeating now at Playsign too). Would be really interesting to know how xml3d.js runs it so please tell if you test on the DFKI side -- otherwise we can give it a shot too. It is nothing special and also quite small, 9 blocks, with somewhat high detail (is an optimised version though for low end machines). The new version with some ~30 blocks is being worked on in an SVN now - we'll share that later. With that we'll really need managing resources sensibly, loading & unloading based on distance/visibility etc., perhaps using image placeholders instead of the geometry so much etc. This is creative commons material by the Oulu smart city consortium / University of Oulu NIMO EU & internal infrastructure projects. Not really published for big audiences yet (launch with applications on top is being prepared) so not something to publish widely, but is fine to use in research and experiments and project protos etc. It is Creative Commons share alike so if you somehow improve the original base model we ask you to share the improvements. ~Toni -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasse.oorni at ludocraft.com Fri Sep 6 12:58:29 2013 From: lasse.oorni at ludocraft.com (=?iso-8859-1?Q?=22Lasse_=D6=F6rni=22?=) Date: Fri, 6 Sep 2013 13:58:29 +0300 Subject: [Fiware-miwi] Tundra scene synchronization protocol Message-ID: <8ef3741cd6da5e427487b7d11806742e.squirrel@urho.ludocraft.com> Hi, the initial version of the realXtend Tundra scene sync protocol description is online in the Forge miwi wiki. This is the same document that I sent by email earlier. See here: https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi/index.php/RealXtend_Tundra_protocol -- Lasse ??rni Game Programmer LudoCraft Ltd. From jonne at adminotech.com Fri Sep 6 14:03:26 2013 From: jonne at adminotech.com (Jonne Nauha) Date: Fri, 6 Sep 2013 13:03:26 +0100 Subject: [Fiware-miwi] Tundra Scene and EC model Message-ID: My initial writeup on the Scene/Entity/Component/Attribute model of realXtend Tundra: https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi/index.php/RealXtend_Scene_and_EC_model Best regards, Jonne Nauha Meshmoon developer at Adminotech Ltd. www.meshmoon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonne at adminotech.com Fri Sep 6 15:22:13 2013 From: jonne at adminotech.com (Jonne Nauha) Date: Fri, 6 Sep 2013 14:22:13 +0100 Subject: [Fiware-miwi] Tundra AssetAPI and XML3D asset system Message-ID: Here is my initial writeup on the Tundra AssetAPI and the asset system in general. Should list all the relevant interfaces and how they tie together. Let me know if you want more clarification on something. There is lots of pseudo-code that i tried to keep as simple as possible while still conveying the intent of the interfaces. They do now map 1:1 to the current Tundra implementation but should capture the idea for you. https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi/index.php/RealXtend_AssetAPI This is essentially what we now have with our current WebTundra prototype. So if I could just plug-in my storage/provider implementation somehow to XML3D it would be great. At the same time you would not need to start implementing complex asset providers and can leave that to the app developer. Ofc your basic HTTP provider should be there always but it should be possible to replace it with a custom impl. I think this would make XML3D more generic in terms of how it loads assets and extend its capabilities further. Not sure how big of an development effort this is, surely we can also fork XML3D and see if we can implement it in a way that you would accept that code to upstream. Best regards, Jonne Nauha Meshmoon developer at Adminotech Ltd. www.meshmoon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mach at zhaw.ch Fri Sep 6 17:11:47 2013 From: mach at zhaw.ch (Christof Marti) Date: Fri, 6 Sep 2013 17:11:47 +0200 Subject: [Fiware-miwi] Doodle to find time slot for weekly WP13 meeting Message-ID: Hi I created a doodle to find the best time slot for the weekly WP13 coordination meeting. Please select all possible dates asap. You can also add comments to suggest alternative slots. http://doodle.com/if67g2rmk6p4xaz7 Cheers --Christof -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: not available URL: From Philipp.Slusallek at dfki.de Sun Sep 8 08:21:12 2013 From: Philipp.Slusallek at dfki.de (Philipp Slusallek) Date: Sun, 08 Sep 2013 08:21:12 +0200 Subject: [Fiware-miwi] Tundra scene synchronization protocol In-Reply-To: <8ef3741cd6da5e427487b7d11806742e.squirrel@urho.ludocraft.com> References: <8ef3741cd6da5e427487b7d11806742e.squirrel@urho.ludocraft.com> Message-ID: <522C1758.6090604@dfki.de> Hi Lasse, all, Thanks you very much. Some comments and questions from my side (adding Dmitri in CC, who is our main KIARA person): -- From the document: > The sync protocol supports creating and removing attributes in > components on the fly, but for most components such as EC_Mesh or > EC_Placeable, the set of attributes is fixed. Are you actually making use of adding attributes at runtime? I can easily see that some attributes may be optional. But what would be a case where attributes get added to a compoenent. How would a remote node make use of this info, if it does not know about the attribute. In KIARA we try to allow strong optimization of the communication. Optional data is easily dealt with here (just a flag) but adding random new data, would defeat most optimizations. Its currently not planned to be supported. So I would like to understand, how its is being used and what alternatives might be there for these usecases (I would like not to give up optimization). Regarding the encoding, as I mentioned, this is not fixed in KIARA. The app describes its data structures (such as in Jonne's component document) and KIARA would negotiate/choose a proper encoding/protocol when establishing the connection (which allows us to optimize depending on the clients, network, and other conditions at run time). This would include possibly choosing a smaller network representation for smaller int values. -- It seems there needs to be some encoding also for the commands, as well as things like authentification and such? -- Is there any notion of security? Best, Philipp Am 06.09.2013 12:58, schrieb "Lasse ??rni": > the initial version of the realXtend Tundra scene sync protocol > description is online in the Forge miwi wiki. This is the same document > that I sent by email earlier. > > See here: > https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi/index.php/RealXtend_Tundra_protocol > -- ------------------------------------------------------------------------- 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: From Philipp.Slusallek at dfki.de Sun Sep 8 10:24:50 2013 From: Philipp.Slusallek at dfki.de (Philipp Slusallek) Date: Sun, 08 Sep 2013 10:24:50 +0200 Subject: [Fiware-miwi] Tundra Scene and EC model In-Reply-To: References: Message-ID: <522C3452.1030401@dfki.de> Hi, Thanks a lot for putting this info together. THis looks much easier than I had originally thought from our discussions in Winterthur. I have put together a quick first discussion of the mapping and a few questions and comments. I am putting all comments together into one email, but if there are further comments on specific components, it might make sense to break those into separate email per topic so we can keep those discussions focused on the separate component types. please feel free to correct, extend, and comment on my suggestions. I am simply trying to get us started here. > The Tundra component system is extendable, so anyone can define a > component and add it to the system. Usually outside of the Tundra > core SDK this happens by loading C++ plugins during runtime that > declare/register the component structure to both the server and > client. We take a very similar approach here except that we are not using C++ classes but KIARA services. They can map directly to C/C++ entities but could also refer to external services available through KIARA. > Main attributes: name (String), description (String) and group (String). It seems there needs to be at least some conventions of how to use these strings. XML3D has a hierarchical group system mainly for transformations. In Winterthur you indicated that you are want to introduce a hierarchy into your ECA system as well. How would that look like? -- EC_Placeable In the Network protocol Lasse writes that position, orientation, and velocity are most often updated. I wonder if it does not make sense to include velocity here as well and not just put it to the physics component. Each could have a default value and be optional, such that a very efficient encoding could be found for this data set. Anything else that would need to be here? BTW, is rot a 2D or a 3D orientation? This would most likely map well to a (special?) group node in XML3D. -- EC_Mesh This obviously maps well to our mesh element. We have separate shader elements (that Kristian and Felix are just expanding significantly). Our mesh pretty directly corresponds to a Vertex Array Object (VAO) and can have exactly one shader attached to it. I understand that your mesh is a complex Ogre object, which apparently can have many submeshes, which each have a material. So the best option would probably be to have a (sub-)group and put in there all the sub-meshes (so there would be a direct mapping from mesh->submesh to an XML3D mesh + shader). In XML3D textures are parameters of shaders (if I am not mistaken, we do not support textures as geometry attributes, which Ogre seems to do). We already support arbitrary other attributes and this does make sense to me. We might even be able to support texture arrays (which Ogre does not have). The mapping of textures would obviously not be per vertex but per VAO. Animation and Skeleton infos are completely separate from the mesh and are handled in Xflow. We consider LOD a purely application specific thing as there is no general notion of what a specific LOD level is and when to switch between them. It would be easy to have a group for each LOD level and have the client application switch between them as needed (e.g. based on distance). We currently have no support for attributes regarding shadow casting/receiving but this may be something that we should discuss as part of the shader work from Kristian/Felix. -- EC_Camera Seems to mapp directly. We currently handle near/far automatically based on the BBbox (right?). It seems a mixed approach where the given values are the min/max and we might be able to optimize beyond that might be interesting. Do you allow non-orthogonal cameras (e.g. for VR/stereo)? -- EC_Light We are aiming for a general approach where any 3D object can become a light source by assigning a light/emission shader to it. Not sure if we still support dedicated point light objects (the original idea was to do so via meshes consisting of one or more points that the shader gets assigned to). Kristian/Felix: What is the situation/plan here? -- EC_ParticleSystem Planned but not yet implemented, I believe. The goal is to do this through Xflow, where an particle update function is applied to a bunch of points which are then rendered through a mesh (possibly with shaders/texture arrays assigned to them). Will probably not happen until the shader stuff works. Felix? -- EC_Billboard Should easy to create simply in JS on top of existing assets, with JS taking care of orienting the object correctly. Unless there are thousands of billboards this should not be a performance issue. -- EC_Sky As discussed on the Hangout this should be easily possible with a procedural XFlow node or prototype that creates the necessary geometry with textures etc. -- EC_Water Again something that we would do through Xflow (there are some easy examples already). -- EC_WebBrowser Often discussed but not yet implemented, AFAIK. I let Kristian/Felix comment on the technical issues here. -- EC_Script This is probably the main issue here as the language and the runtime environment will be very different. We use JS both on the client and our (new) server, which shuld simplify things considerably. We probably need to discuss this in separately. A key element of our server is that a KIARA service description can directly be handed to the scripting engine which integrates it into the languages in a suitable and consistent manner. We should even be able to pass them through to a client and so have consistency. One main issue will be how to support HTML/DOM functionality on the server component. Again an important question in the scripting context. -- List of Attribute types Mostly straight forward, AFAIKT. Asset/Entity references would simply be (relative) URLs into the scene itself or into an external scene (which then gets loaded and referred to). QVariant: This corresponds to a Any type in middleware systems. We have postponed implementing this in KIARA but it seems we need to support this at least for DynamicComponents. We will discuss this. Again thanks a lot, Philipp Am 06.09.2013 14:03, schrieb Jonne Nauha: > My initial writeup on the Scene/Entity/Component/Attribute model of > realXtend Tundra: > > https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi/index.php/RealXtend_Scene_and_EC_model > > Best regards, > Jonne Nauha > Meshmoon developer at Adminotech Ltd. > www.meshmoon.com > > > _______________________________________________ > 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 --------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: slusallek.vcf Type: text/x-vcard Size: 441 bytes Desc: not available URL: From Philipp.Slusallek at dfki.de Sun Sep 8 10:57:59 2013 From: Philipp.Slusallek at dfki.de (Philipp Slusallek) Date: Sun, 08 Sep 2013 10:57:59 +0200 Subject: [Fiware-miwi] oulu3d city model In-Reply-To: References: Message-ID: <522C3C17.4020907@dfki.de> Hi, Thanks a lot, Toni. We will definitely give it a try and Torsten can report the results, once we did. This may also be a data set that we can use for benchmarking. I actually just tried loading the scene into Blender (Version 266a under Linux) but did not really know where to start. All the readmes are in Finnish and the Masterscene file just shows a few markers (but then I am not a Blender expert either :-). Any hints at how to load the entire scene into Blender to look at it? One aspect that we on our side should be looking into a bit more is support for compressed textures (so they do not get expanded along the way but are passed through to the HW directly). This is related to the shading work we are doing right now. Might take a bit to get there, though. Any ideas Kristian/Felix? We have some similar models that we used in our XML3D-REPO project, you can look at them at http://verser2.cs.ucl.ac.uk/xml3drepo/ (this is a tiny server at UCL, so be careful with it please :-). Works best with Chrome for me. It should give you a good idea for the rendering performance of XML3D. Also please keep them confidential. Not everything in the table works, but you can try some non-trivial scenes like -- UT4_Austria -- Arabic_City -- Sumerian_City -- UT4_WildWest -- UT4_Beijing_B1 -- UT4_IB -- UT4_Maximus_v1 -- UT4_Poland_B10 -- UT4_Paradise Within the table you find different versions of the models in various formats (see the paper at https://graphics.cg.uni-saarland.de/2013/xml3drepo/). The default view is often in the middle of the scene: Use the left mouse button to rotate a bit upwards and then retrat with the right mouse button. Note that there is no scheduling of the loading yet and that textures are at the every end right now, so be patient. Best, Philipp Am 06.09.2013 11:22, schrieb Toni Alatalo: > (was discussed in the meeting now) > > This is the old small & even optimised version from >year ago, for use > for first performance tests now: > http://www.ee.oulu.fi/~antont/download/oulu3dlive-lofi.zip > > There's the source blends, with a Masterscene blend where everything is > integrated so it's easy to export to whatever you can export to from > Blender. > > With DDS textures at least, runs fine with Ogre and I think with > three.js too (others (especially CIE) have done that earlier, we are > repeating now at Playsign too). Would be really interesting to know how > xml3d.js runs it so please tell if you test on the DFKI side -- > otherwise we can give it a sho v> > It is nothing special and also quite small, 9 blocks, with somewhat high > detail (is an optimised version though for low end machines). > > The new version with some ~30 blocks is being worked on in an SVN now - > we'll share that later. With that we'll really need managing resources > sensibly, loading & unloading based on distance/visibility etc., perhaps > using image placeholders instead of the geometry so much etc. > > This is creative commons material by the Oulu smart city consortium / > University of Oulu NIMO EU & internal infrastructure projects. Not > really published for big audiences yet (launch with applications on top > is being prepared) so not something to publish widely, but is fine to > use in research and experiments and project protos etc. > > It is Creative Commons share alike so if you somehow improve the > original base model we ask you to share the improvements. > > ~Ton i > < > > > _______________________________________________ > 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 --------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: slusallek.vcf Type: text/x-vcard Size: 441 bytes Desc: not available URL: From jonne at adminotech.com Sun Sep 8 17:05:20 2013 From: jonne at adminotech.com (Jonne Nauha) Date: Sun, 8 Sep 2013 18:05:20 +0300 Subject: [Fiware-miwi] Tundra scene synchronization protocol In-Reply-To: <522C1758.6090604@dfki.de> References: <8ef3741cd6da5e427487b7d11806742e.squirrel@urho.ludocraft.com> <522C1758.6090604@dfki.de> Message-ID: On Sun, Sep 8, 2013 at 9:21 AM, Philipp Slusallek wrote: > Hi Lasse, all, > > Thanks you very much. Some comments and questions from my side (adding > Dmitri in CC, who is our main KIARA person): > > -- From the document: > > The sync protocol supports creating and removing attributes in > > components on the fly, but for most components such as EC_Mesh or > > EC_Placeable, the set of attributes is fixed. > > Are you actually making use of adding attributes at runtime? I can > easily see that some attributes may be optional. But what would be a > case where attributes get added to a compoenent. How would a remote node > make use of this info, if it does not know about the attribute. > Currently all components except EC_DynamicComponent's structure is static and known/locked down during build time. You cannot add attributes to any other component during runtime than EC_DynamicComponent. This could in theory be supported for any component, but as the C++ logic operates on the build time knowledge of attributes the logic code could not do anything sensible with these runtime attributes. EC_DynamicComponent is mostly useful for scripts that can write custom handling logic for the apps custom attributes that it wants to synchronize over the network. For EC_DynamicComponent when a new attributes are added on either the client or server side during runtime, a "CreateAttributes" message is sent and replicated to everyone. This will also send the initial value of the new attribute. After this if the value is changed the normal "EditAttributes" is sent. If a attribute is removed during runtime the "RemoveAttributes" message it sent. A remote node (essentially a application script running on the server and/or client) can detect new attributes and react to changes by hooking to the signals in IComponent http://doc.meshmoon.com/doxygen/class_i_component.html#signals > > In KIARA we try to allow strong optimization of the communication. > Optional data is easily dealt with here (just a flag) but adding random > new data, would defeat most optimizations. Its currently not planned to > be supported. So I would like to understand, how its is being used and > what alternatives might be there for these usecases (I would like not to > give up optimization). > Regarding the encoding, as I mentioned, this is not fixed in KIARA. The > app describes its data structures (such as in Jonne's component > document) and KIARA would negotiate/choose a proper encoding/protocol > when establishing the connection (which allows us to optimize depending > on the clients, network, and other conditions at run time). This would > include possibly choosing a smaller network representation for smaller > int values. > The protocol tries to do its best sending a little bytes as it can. This is the VLE encoding mentioned in Lasses doc page. So in practice if the an Entity ID in the message is 5, it will be sent as u8 instead of u32. The details on the VLE encoding can be found from http://clb.demon.fi/knet/_immediate_mode_serialization.html. This is already implemented in the current Web Tundra prototype by me, so the bit-fiddling is not a problem :) As the bulk of Tundras network messages in an usual scene are moving objects there is a special "RigidBodyUpdateMessage" that is not currently on the wiki page, but is referenced by Lasse here https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi/index.php/RealXtend_Tundra_protocol#Optimizations. Using this message reduces the bandwidth costs a lot in most cases, eg if you move pos.x in EC_Placeable, the generic sync would send the whole transform attribute (9x4bytes), but this is where the specialized message kicks in an only 4 bytes is sent. > -- It seems there needs to be some encoding also for the commands, as > well as things like authentification and such? > The protocol has other messages in addition to the Scene synchronization messages. LoginMessage sent from the client to the server and LoginReplyMessage that is a reply for this message. The LoginMessage is, again a generic message, which is just a set of login properties the client wants to send to the server. This data can be anything from only "username" to "username" + "password" + "authtoken", you name it. All these login properties persist in the servers memory for the whole time this client is logged in, and applications have full access to these login properties. Applications (scripts or custom C++ plugins) can act on the login properties and if sees fit reject the login attempt. This login message is for example used in Meshmoon to validate a authentication token (our client puts this token to the login properties when used logs in to a scene) which gets validated by the Meshmoon server side logic from our backend. So essentially the login/authentication step can be fully customized by the application using Tundra. By default Tundra SDK will let anyone in with any login properties, again either C++ logic or server side script needs to implement the auth/login model of the scene. It can range from simple username/password checks to more elaborate backend validations against a user database etc. > > -- Is there any notion of security? > Yes, again this is very generic. The Tundra SDK does not decide what security model you have. It provides signals to application logic (C++ or script) to tell it if a scene change should be allowed. This has proven to be enough in Meshmoon as we use it to determine who can make client side scene changes. If the Meshmoon user has "basic" permission on the scene we will reject any changes it tries to do to the scene model on the client side. These users can still interact with the scene via the scripts in that scene, whatever the apps there might be. You can send custom messages via EntityActions (not yet documented on the wiki). Basically its a way for the client to send messages with custom data variables and the server side logic can act on it. With this mechanism you can move the scene manipulation to the server side and thus the change is allowed also for "basic" users. The change requests can be catched in server side app logic from http://doc.meshmoon.com/doxygen/class_scene_sync_state.html#signals. At some point we will need to extend this to provide information what component and attribute the change was targeted to. Currently it will tell what entity the client tried to manipulate. > > > Best, > > Philipp > Lasse: Please step in if I made an factual errors :) Best regards, Jonne Nauha Meshmoon developer at Adminotech Ltd. www.meshmoon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Philipp.Slusallek at dfki.de Sun Sep 8 18:13:22 2013 From: Philipp.Slusallek at dfki.de (Philipp Slusallek) Date: Sun, 08 Sep 2013 18:13:22 +0200 Subject: [Fiware-miwi] Tundra scene synchronization protocol In-Reply-To: References: <8ef3741cd6da5e427487b7d11806742e.squirrel@urho.ludocraft.com> <522C1758.6090604@dfki.de> Message-ID: <522CA222.5040108@dfki.de> Hi, Am 08.09.2013 17:05, schrieb Jonne Nauha: > Currently all components except EC_DynamicComponent's structure is > static and known/locked down during build time. You cannot add > attributes to any other component during runtime than > EC_DynamicComponent. This could in theory be supported for any > component, but as the C++ logic operates on the build time knowledge of > attributes the logic code could not do anything sensible with these > runtime attributes. EC_DynamicComponent is mostly useful for scripts > that can write custom handling logic for the apps custom attributes that > it wants to synchronize over the network. > > For EC_DynamicComponent when a new attributes are added on either the > client or server side during runtime, a "CreateAttributes" message is > sent and replicated to everyone. This will also send the initial value > of the new attribute. After this if the value is changed the normal > "EditAttributes" is sent. If a attribute is removed during runtime the > "RemoveAttributes" message it sent. > > A remote node (essentially a application script running on the server > and/or client) can detect new attributes and react to changes by hooking > to the signals in > IComponent http://doc.meshmoon.com/doxygen/class_i_component.html#signals Thanks for clarifying. It actually become clear to me as I was reading the other documents that Lasse sent. The failure to be able to operate on the data with C++ was my main concern, but I see the issue from the scripting components. Using KIARA however, even they could define their own components up front and then KIARA wold generate the necessary (and optimized code) to send those components. However, dynamically adding new attributes during run-time would then no longer work (or be much slower). C++ might still be able to look at it (if needed) but this would not be a fast option. > The protocol tries to do its best sending a little bytes as it can. This > is the VLE encoding mentioned in Lasses doc page. So in practice if the > an Entity ID in the message is 5, it will be sent as u8 instead of u32. This optimizes for bandwidth but could make en/decoding quite a bit slower. KIARA will allow both strategies and still generate efficient code for both. > As the bulk of Tundras network messages in an usual scene are moving > objects there is a special "RigidBodyUpdateMessage" that is not > currently on the wiki page, but is referenced by Lasse > here https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi/index.php/RealXtend_Tundra_protocol#Optimizations. > Using this message reduces the bandwidth costs a lot in most cases, eg > if you move pos.x in EC_Placeable, the generic sync would send the whole > transform attribute (9x4bytes), but this is where the specialized > message kicks in an only 4 bytes is sent. This definitely makes sense. I still think that moving the relevant field into a single component can simplify things even more. The two are orthogonal. > The protocol has other messages in addition to the Scene synchronization > messages. LoginMessage sent from the client to the server and > LoginReplyMessage that is a reply for this message. > > The LoginMessage is, again a generic message, which is just a set of > login properties the client wants to send to the server. This data can > be anything from only "username" to "username" + "password" + > "authtoken", you name it. All these login properties persist in the > servers memory for the whole time this client is logged in, and > applications have full access to these login properties. Applications > (scripts or custom C++ plugins) can act on the login properties and if > sees fit reject the login attempt. > > This login message is for example used in Meshmoon to validate a > authentication token (our client puts this token to the login properties > when used logs in to a scene) which gets validated by the Meshmoon > server side logic from our backend. So essentially the > login/authentication step can be fully customized by the application > using Tundra. By default Tundra SDK will let anyone in with any login > properties, again either C++ logic or server side script needs to > implement the auth/login model of the scene. It can range from simple > username/password checks to more elaborate backend validations against a > user database etc. Sounds good. Maybe you can add a pointer to those aspect to the Wiki as well? > -- Is there any notion of security? I actually meant communication security. SSL/TLS, certificatesm ensuring the client is talking to the right server and vice versa, etc. But the other info is very interesting as well! Thanks a lot and have a nice Sunday evening, Philipp > Yes, again this is very generic. The Tundra SDK does not decide what > security model you have. It provides signals to application logic (C++ > or script) to tell it if a scene change should be allowed. This has > proven to be enough in Meshmoon as we use it to determine who can make > client side scene changes. If the Meshmoon user has "basic" permission > on the scene we will reject any changes it tries to do to the scene > model on the client side. These users can still interact with the scene > via the scripts in that scene, whatever the apps there might be. > > You can send custom messages via EntityActions (not yet documented on > the wiki). Basically its a way for the client to send messages with > custom data variables and the server side logic can act on it. With this > mechanism you can move the scene manipulation to the server side and > thus the change is allowed also for "basic" users. > > The change requests can be catched in server side app logic > from http://doc.meshmoon.com/doxygen/class_scene_sync_state.html#signals. At > some point we will need to extend this to provide information what > component and attribute the change was targeted to. Currently it will > tell what entity the client tried to manipulate. > > > > > Best, > > Philipp > > > Lasse: Please step in if I made an factual errors :) > > Best regards, > Jonne Nauha > Meshmoon developer at Adminotech Ltd. > www.meshmoon.com -- ------------------------------------------------------------------------- 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: From jonne at adminotech.com Sun Sep 8 20:11:16 2013 From: jonne at adminotech.com (Jonne Nauha) Date: Sun, 8 Sep 2013 21:11:16 +0300 Subject: [Fiware-miwi] Tundra scene synchronization protocol In-Reply-To: <522CA222.5040108@dfki.de> References: <8ef3741cd6da5e427487b7d11806742e.squirrel@urho.ludocraft.com> <522C1758.6090604@dfki.de> <522CA222.5040108@dfki.de> Message-ID: > The protocol tries to do its best sending a little bytes as it can. This > > is the VLE encoding mentioned in Lasses doc page. So in practice if the > > an Entity ID in the message is 5, it will be sent as u8 instead of u32. > > This optimizes for bandwidth but could make en/decoding quite a bit > slower. KIARA will allow both strategies and still generate efficient > code for both. > Yeah this can be the case. We haven't ran any profiling on the performance of the VLE decoding or the websocket binary frame parsing in general on the javascript side. We will certainly need to do that going forward. On the server C++ this is a non-issue, at least under the usual world scale we are operating on. > > > As the bulk of Tundras network messages in an usual scene are moving > > objects there is a special "RigidBodyUpdateMessage" that is not > > currently on the wiki page, but is referenced by Lasse > > here > https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi/index.php/RealXtend_Tundra_protocol#Optimizations > . > > Using this message reduces the bandwidth costs a lot in most cases, eg > > if you move pos.x in EC_Placeable, the generic sync would send the whole > > transform attribute (9x4bytes), but this is where the specialized > > message kicks in an only 4 bytes is sent. > > This definitely makes sense. I still think that moving the relevant > field into a single component can simplify things even more. The two are > orthogonal. > Strictly from a design standpoint I think our intent is that EC_Placeable that is responsible for 3D scene nodes should not (need to) know about physics/velocities and vice versa for EC_RigidBody. Usually our components have a very specific task/feature they add to the entity. How I see it the RigidBodyUpdateMessage consolidates both these components into a single efficient network message about the changes in both. I see how this might be confusing for someone who is implementing the protocol on a client, we can certain think about it a little more. > > > The protocol has other messages in addition to the Scene synchronization > > messages. LoginMessage sent from the client to the server and > > LoginReplyMessage that is a reply for this message. > > > > The LoginMessage is, again a generic message, which is just a set of > > login properties the client wants to send to the server. This data can > > be anything from only "username" to "username" + "password" + > > "authtoken", you name it. All these login properties persist in the > > servers memory for the whole time this client is logged in, and > > applications have full access to these login properties. Applications > > (scripts or custom C++ plugins) can act on the login properties and if > > sees fit reject the login attempt. > > > > This login message is for example used in Meshmoon to validate a > > authentication token (our client puts this token to the login properties > > when used logs in to a scene) which gets validated by the Meshmoon > > server side logic from our backend. So essentially the > > login/authentication step can be fully customized by the application > > using Tundra. By default Tundra SDK will let anyone in with any login > > properties, again either C++ logic or server side script needs to > > implement the auth/login model of the scene. It can range from simple > > username/password checks to more elaborate backend validations against a > > user database etc. > > Sounds good. Maybe you can add a pointer to those aspect to the Wiki as > well? > I've added the login and loginreply messages to the wiki page. Also added the message ID for each. > > > -- Is there any notion of security? > > I actually meant communication security. SSL/TLS, certificatesm ensuring > the client is talking to the right server and vice versa, etc. > > But the other info is very interesting as well! > Ah sorry, I misunderstood. No afaik we don't havea any security on that level. It would probably be up to the kNet implementation to provide it, if it already does we are not using afaik using it. > > > Thanks a lot and have a nice Sunday evening, > > Philipp Best regards, Jonne Nauha Meshmoon developer at Adminotech Ltd. www.meshmoon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Philipp.Slusallek at dfki.de Sun Sep 8 20:29:26 2013 From: Philipp.Slusallek at dfki.de (Philipp Slusallek) Date: Sun, 08 Sep 2013 20:29:26 +0200 Subject: [Fiware-miwi] Tundra scene synchronization protocol In-Reply-To: References: <8ef3741cd6da5e427487b7d11806742e.squirrel@urho.ludocraft.com> <522C1758.6090604@dfki.de> <522CA222.5040108@dfki.de> Message-ID: <522CC206.8080408@dfki.de> Hi, Am 08.09.2013 20:11, schrieb Jonne Nauha: > Strictly from a design standpoint I think our intent is that > EC_Placeable that is responsible for 3D scene nodes should not (need to) > know about physics/velocities and vice versa for EC_RigidBody. Usually > our components have a very specific task/feature they add to the entity. > How I see it the RigidBodyUpdateMessage consolidates both these > components into a single efficient network message about the changes in > both. I see how this might be confusing for someone who is implementing > the protocol on a client, we can certain think about it a little more. But why is position not a physical parameter but velocity is? This is essentially the same thing (the second is simply change of the first over time). This is why in my thinking they belong together. Density, friction, mass, and other stuff is very different and this is what I would consider under a physics component. Yes, you need the velocity for a lot of the physics computation but this is also true for the position and orientation. > I've added the login and loginreply messages to the wiki page. Also > added the message ID for each. Thanks! > Ah sorry, I misunderstood. No afaik we don't havea any security on that > level. It would probably be up to the kNet implementation to provide it, > if it already does we are not using afaik using it. Thanks, Philipp > > > > > Thanks a lot and have a nice Sunday evening, > > Philipp > > > > Best regards, > Jonne Nauha > Meshmoon developer at Adminotech Ltd. > www.meshmoon.com > -- ------------------------------------------------------------------------- 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: From toni at playsign.net Mon Sep 9 03:36:57 2013 From: toni at playsign.net (toni at playsign.net) Date: Mon, 9 Sep 2013 01:36:57 +0000 Subject: [Fiware-miwi] =?utf-8?q?Tundra_scene_synchronization_protocol?= In-Reply-To: <522CA222.5040108@dfki.de> References: <8ef3741cd6da5e427487b7d11806742e.squirrel@urho.ludocraft.com> <522C1758.6090604@dfki.de> , <522CA222.5040108@dfki.de> Message-ID: <20130909021538.EB78B18003E@dionysos.netplaza.fi> just a brief note: ---From: Philipp Slusallek Am 08.09.2013 17:05, schrieb Jonne Nauha: >> Currently all components except EC_DynamicComponent's structure is >> static and known/locked down during build time. You cannot add >> attributes to any other component during runtime than >> EC_DynamicComponent. This could in theory be supported for any >> component, but as the C++ logic operates on the build time knowledge of >> attributes the logic code could not do anything sensible with these >> runtime attributes. EC_DynamicComponent is mostly useful for scripts >> that can write custom handling logic for the apps custom attributes that >> it wants to synchronize over the network. >Using KIARA however, even they could define their own components up >front and then KIARA wold generate the necessary (and optimized code) to >send those components. However, dynamically adding new attributes during >run-time would then no longer work (or be much slower). C++ might still >be able to look at it (if needed) but this would not be a fast option. When I started to work on the DynamicComponent thing the idea was not actually to implement dynamically added&removed attributes, but a way for define *static* i.e. normal component types from what were we calling dynamic languages (javascript, python, lua and such). I had a first test thing for that running when the Ludo guys also worked on it and implemented the dynamic components thing. I found it a bit weird as was working on a different thing, but it did work also for my purpose -- it does enable defining and working with your own component data from JS -- so I just started using it too. We?ve discussed this often since then and at one point I learned that the guys had found it a useful mechanism to be able to just add some data easily, IIRC Ludocraft was using it from c++ modules too really early on and told that found it handy sometimes. But for network efficiency reasons, and I think also for robustness (defined sets of attributes for the component type) to avoid bugs in the programming, being able to declare EC types from scripts would be nice still. A big bonus I?ve thought would be that they?d work right in the graphical EC GUI editor used for authoring - adding your component would have the attributes pre-populated, now we often just add them by hand there (a script can ofc populate them too - and often they are completely only handled by scripts and not touched manually. but there can be nice for manual use too, like some nice camera and light setups perhaps, or door functionality .. you just add the Door EC to the object you want to work as a door, it can be a simple script and doesn?t need an UI even if just setting some parameter in the editor suffices). I?ve been calling it CustomComponent support now. Jonne has been calling it ?the thing that Toni wants? ? Defining network messages would be good too, like you can with c++ with kNet and with many languages using something like Protobufs -- so yes KIARA can be really nice for us, as I understand it has that too.. right? In scripts, we now use these text string based entity actions - sometimes being able to specify real optimized normal network messages would be good I suppose .. for example a custom movement message for your movement system perhaps? > This definitely makes sense. I still think that moving the relevant > field into a single component can simplify things even more. The two are > orthogonal. This is an interesting point - also Placeable can be used to move objects, by setting position. RigidBody features the nice movement sync. But not all moving objects need the RigidBody otherwise, I mean the Bullet physics things. I wonder whetherthe RigidBody movement sync in Tundra is not only about velocity based intra- & extrapolation .. Jukka at least tested falling to client side physics upon network probs etc. iirc. > Thanks a lot and have a nice Sunday evening, The 1st Annual Opensimulator Community Conference #OSCC13 was great - Intel DSG guys etc. were there too and many nice VW dev folks. And Grady Booch even ? . There was healthy interest for realXtend too and we were talking about these web client efforts related to that, some knew xml3d from before which was very cool. That virtual conference running on opensimulator itself was quite an achievement by those folks -- a landmark really, very well organized and on a completely open source stack. They had a nice simple customized client app for it (just a preconfigured slviewer basically but good). > Philipp ~Toni > Yes, again this is very generic. The Tundra SDK does not decide what > security model you have. It provides signals to application logic (C++ > or script) to tell it if a scene change should be allowed. This has > proven to be enough in Meshmoon as we use it to determine who can make > client side scene changes. If the Meshmoon user has "basic" permission > on the scene we will reject any changes it tries to do to the scene > model on the client side. These users can still interact with the scene > via the scripts in that scene, whatever the apps there might be. > > You can send custom messages via EntityActions (not yet documented on > the wiki). Basically its a way for the client to send messages with > custom data variables and the server side logic can act on it. With this > mechanism you can move the scene manipulation to the server side and > thus the change is allowed also for "basic" users. > > The change requests can be catched in server side app logic > from http://doc.meshmoon.com/doxygen/class_scene_sync_state.html#signals. At > some point we will need to extend this to provide information what > component and attribute the change was targeted to. Currently it will > tell what entity the client tried to manipulate. > > > > > Best, > > Philipp > > > Lasse: Please step in if I made an factual errors :) > > Best regards, > Jonne Nauha > Meshmoon developer at Adminotech Ltd. > www.meshmoon.com -- ------------------------------------------------------------------------- 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 -------------- An HTML attachment was scrubbed... URL: From toni at playsign.net Mon Sep 9 05:15:40 2013 From: toni at playsign.net (Toni Alatalo) Date: Mon, 9 Sep 2013 06:15:40 +0300 Subject: [Fiware-miwi] oulu3d city model In-Reply-To: <522C3C17.4020907@dfki.de> References: <522C3C17.4020907@dfki.de> Message-ID: <218A65E8-D33D-4C03-904B-578657BD8FEC@playsign.net> On Sep 8, 2013, at 11:57 AM, Philipp Slusallek wrote: > We will definitely give it a try and Torsten can report the results, > once we did. This may also be a data set that we can use for benchmarking. Cool, and yes that's what we planned as one of the tests. > I actually just tried loading the scene into Blender (Version 266a under > Linux) but did not really know where to start. All the readmes are in > Finnish and the Masterscene file just shows a few markers (but then I am > not a Blender expert either :-). Any hints at how to load the entire > scene into Blender to look at it? Masterscene has it - apparently you need to move the camera closer and change to a shaded viewport mode to see more .. the 'few markers' looks is from being afar and in wireframe mode, sorry about that :) > One aspect that we on our side should be looking into a bit more is > support for compressed textures (so they do not get expanded along the > way but are passed through to the HW directly). This is related to the > shading work we are doing right now. Might take a bit to get there, > though. Any ideas Kristian/Felix? AFAIK it is basically trivial with WebGL - just call the function to load a compressed texture when you encounter an asset of that type. > We have some similar models that we used in our XML3D-REPO project, you > can look at them at http://verser2.cs.ucl.ac.uk/xml3drepo/ (this is a > tiny server at UCL, so be careful with it please :-). Works best with > Chrome for me. It should give you a good idea for the rendering > performance of XML3D. Also please keep them confidential. Great, we'll test. Cheers, ~Toni > Not everything in the table works, but you can try some non-trivial > scenes like > -- UT4_Austria > -- Arabic_City > -- Sumerian_City > -- UT4_WildWest > -- UT4_Beijing_B1 > -- UT4_IB > -- UT4_Maximus_v1 > -- UT4_Poland_B10 > -- UT4_Paradise > > Within the table you find different versions of the models in various > formats (see the paper at > https://graphics.cg.uni-saarland.de/2013/xml3drepo/). > > The default view is often in the middle of the scene: Use the left mouse > button to rotate a bit upwards and then retrat with the right mouse button. > > Note that there is no scheduling of the loading yet and that textures > are at the every end right now, so be patient. > > > > Best, > > Philipp > > Am 06.09.2013 11:22, schrieb Toni Alatalo: >> (was discussed in the meeting now) >> >> This is the old small & even optimised version from >year ago, for use >> for first performance tests now: >> http://www.ee.oulu.fi/~antont/download/oulu3dlive-lofi.zip >> >> There's the source blends, with a Masterscene blend where everything is >> integrated so it's easy to export to whatever you can export to from >> Blender. >> >> With DDS textures at least, runs fine with Ogre and I think with >> three.js too (others (especially CIE) have done that earlier, we are >> repeating now at Playsign too). Would be really interesting to know how >> xml3d.js runs it so please tell if you test on the DFKI side -- >> otherwise we can give it a sho v> >> It is nothing special and also quite small, 9 blocks, with somewhat high >> detail (is an optimised version though for low end machines). >> >> The new version with some ~30 blocks is being worked on in an SVN now - >> we'll share that later. With that we'll really need managing resources >> sensibly, loading & unloading based on distance/visibility etc., perhaps >> using image placeholders instead of the geometry so much etc. >> >> This is creative commons material by the Oulu smart city consortium / >> University of Oulu NIMO EU & internal infrastructure projects. Not >> really published for big audiences yet (launch with applications on top >> is being prepared) so not something to publish widely, but is fine to >> use in research and experiments and project protos etc. >> >> It is Creative Commons share alike so if you somehow improve the >> original base model we ask you to share the improvements. >> >> ~Ton i >> < >> >> >> _______________________________________________ >> 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 > --------------------------------------------------------------------------- > From Philipp.Slusallek at dfki.de Mon Sep 9 07:59:11 2013 From: Philipp.Slusallek at dfki.de (Philipp Slusallek) Date: Mon, 09 Sep 2013 07:59:11 +0200 Subject: [Fiware-miwi] oulu3d city model In-Reply-To: <218A65E8-D33D-4C03-904B-578657BD8FEC@playsign.net> References: <522C3C17.4020907@dfki.de> <218A65E8-D33D-4C03-904B-578657BD8FEC@playsign.net> Message-ID: <522D63AF.2090607@dfki.de> Hi, Am 09.09.2013 05:15, schrieb Toni Alatalo: >> One aspect that we on our side should be looking into a bit more is >> support for compressed textures (so they do not get expanded along the >> way but are passed through to the HW directly). This is related to the >> shading work we are doing right now. Might take a bit to get there, >> though. Any ideas Kristian/Felix? > > AFAIK it is basically trivial with WebGL - just call the function to > load a compressed texture when you encounter an asset of that type. I know, WebGL is the easy part. The issue is how to pass these compressed data sets through XML3D and what does this mean in the more general sense -- within Xflow for example. We currently use the existing and