On Oct 23, 2013, at 8:00 AM, Philipp Slusallek <Philipp.Slusallek at dfki.de> wrote: > BTW, what is the status with the Rendering discussion (Three.js vs. xml3d.js)? I still have the feeling that we are doing parallel work here that should probably be avoided. I'm not aware of any overlapping work so far -- then again I'm not fully aware what all is up with xml3d.js. For the rendering for 3D UI, my conclusion from the discussion on this list was that it is best to use three.js now for the case of big complex fully featured scenes, i.e. typical realXtend worlds (e.g. Ludocraft's Circus demo or the Chesapeake Bay from the LVM project, a creative commons realXtend example scene). And in miwi in particular for the city model / app now. Basically because that's where we already got the basics working in the August-September work (and had earlier in realXtend web client codebases). That is why we implemented the scalability system on top of that too now -- scalability was the only thing missing. Until yesterday I thought the question was still open regarding XFlow integration. Latest information I got was that there was no hardware acceleration support for XFlow in XML3d.js either so it seemed worth a check whether it's better to implement it for xml3d.js or for three. Yesterday, however, we learned from Cyberlightning that work on XFlow hardware acceleration was already on-going in xml3d.js (I think mostly by DFKI so far?). And that it was decided that work within fi-ware now is limited to that (and we also understood that the functionality will be quite limited by April, or?). This obviously affects the overall situation. At least in an intermediate stage this means that we have two renderers for different purposes: three.js for some apps, without XFlow support, and xml3d.js for others, with XFlow but other things missing. This is certain because that is the case today and probably in the coming weeks at least. For a good final goal I think we can be clever and make an effective roadmap. I don't know yet what it is, though -- certainly to be discussed. The requirements doc -- perhaps by continuing work on it -- hopefully helps. > Philipp ~Toni > > Am 22.10.2013 23:03, schrieb toni at playsign.net: >> Just a brief note: we had some interesting preliminary discussion >> triggered by how the data schema that Ari O. presented for the POI >> system seemed at least partly similar to what the Real-Virtual >> interaction work had resulted in too -- and in fact about how the >> proposed POI schema was basically a version of the entity-component >> model which we’ve already been using for scenes in realXtend (it is >> inspired by / modeled after it, Ari told). So it can be much related to >> the Scene API work in the Synchronization GE too. As the action point we >> agreed that Ari will organize a specific work session on that. >> I was now thinking that it perhaps at least partly leads back to the >> question: how do we define (and implement) component types. I.e. what >> was mentioned in that entity-system post a few weeks back (with links >> to reX IComponent etc.). I mean: if functionality such as POIs and >> realworld interaction make sense as somehow resulting in custom data >> component types, does it mean that a key part of the framework is a way >> for those systems to declare their types .. so that it integrates nicely >> for the whole we want? I’m not sure, too tired to think it through now, >> but anyhow just wanted to mention that this was one topic that came up. >> I think Web Components is again something to check - as in XML terms reX >> Components are xml(3d) elements .. just ones that are usually in a group >> (according to the reX entity <-> xml3d group mapping). And Web >> Components are about defining & implementing new elements (as Erno >> pointed out in a different discussion about xml-html authoring in the >> session). >> BTW Thanks Kristian for the great comments in that entity system >> thread - was really good to learn about the alternative attribute access >> syntax and the validation in XML3D(.js). >> ~Toni >> P.S. for (Christof &) the DFKI folks: I’m sure you understand the >> rationale of these Oulu meets -- idea is ofc not to exclude you from the >> talks but just makes sense for us to meet live too as we are in the same >> city afterall etc -- naturally with the DFKI team you also talk there >> locally. Perhaps is a good idea that we make notes so that can post e.g. >> here then (I’m not volunteering though! 😜) . Also, the now agreed >> bi-weekly setup on Tuesdays luckily works so that we can then summarize >> fresh in the global Wed meetings and continue the talks etc. >> *From:* Erno Kuusela >> *Sent:* Tuesday, October 22, 2013 9:57 AM >> *To:* Fiware-miwi >> >> Kari from CIE offered to host it this time, so see you there at 13:00. >> >> Erno >> _______________________________________________ >> 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 > --------------------------------------------------------------------------- > <slusallek.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy