Hi Toni, Jonne, Let me support this statement from Toni. There is need to change your realXtend server or even its network code in any way. Since we need to create the mapping code to XML3D on the browser side anyway, my point was to use the KIARA API on the Web/JS side as the interface to the networking code and share the mapping code that comes after it (seen from the network). The KIARA API would then simply deliver the (jointly agreed upon) JS representation of the ECA components (or used them for sending). For connecting to realXtend, KIARA would internally reuse the JS networking code that you already have. Also see me email from earlier today. If you later like KIARA (it should have a few advantages over knet) then there is the option of switching to it even on the realXtend (server and/or client) side. But that is your decision! Our job is it to deliver a version of KIARA that will make you want to switch :-). Best, Philipp Am 26.10.2013 19:04, schrieb Toni Alatalo: > Again just a brief note about one point: > > On 26 Oct 2013, at 17:46, Jonne Nauha <jonne at adminotech.com > <mailto:jonne at adminotech.com>> wrote: > >> I don't know enough about what is intended to be sent via the KIARA >> networking. But if its the node types etc. that XML3D seems to support >> today. We are going to drop most of the nice components from the >> Tundra EC model to the floor and basically only communicate the ones >> that can be found from XML3D to the web clients. Is this the intent? >> Or was the > > I think I’ve said this to you many times already :) > > No we are not dropping any components and we are definitely keeping the > support to have whatever components in the application data. > > The xml3d set is just a set of components, like Tundra core also has a > set, and some of those are the same (like mesh). > > Having those components around does not mean that use of other > components would be harmed in any way. > > Xml by itself supports this easily as in any xml you can just add <door> > or <sittarget> or whatever component you may want. > > The net protocol must remain generic to work for those in the future as > well (like it does in Tundra now) — and afaik the outcome from the > miwi-kiara session (where i didn’t participate) was that for miwi tundra > protocol is kept (at least for now). Does not stop us from further > considering possible benefits of Kiara but in any case I think everyone > is for keeping the support for arbitrary components > >> Jonne Nauha > > ~Toni > >> On Fri, Oct 25, 2013 at 6:02 AM, Toni Alatalo <toni at playsign.net >> <mailto:toni at playsign.net>> wrote: >> >> On 24 Oct 2013, at 16:28, Philipp Slusallek >> <Philipp.Slusallek at dfki.de <mailto:Philipp.Slusallek at dfki.de>> wrote: >> >> Continuing the, so far apparently successful, technique of >> clarifying a single point at a time a note about scene >> declarations and description of the scalability work: >> >> > I am not too happy that we are investing the FI-WARE resources >> into circumventing the declarative layer completely. >> >> We are not doing that. realXtend has had a declarative layer for >> the past 4-5 years(*) and we totally depend on it — that’s not >> going away. The situation is totally the opposite: it is assumed >> to always be there. There’s absolutely no work done anywhere to >> circumvent it somehow. [insert favourite 7th way of saying this]. >> >> In my view the case with the current work on scene rendering >> scalability is this: We already have all the basics implemented >> and tested in some form - realXtend web client implementations >> (e.g. ‘WebTundra’ in form of Chiru-Webclient on github, and other >> works) have complete entity systems integrated with networking and >> rendering. XML3d.js is the reference implementation for XML3d >> parsing, rendering etc. But one of the identified key parts >> missing was managing larger complex scenes. And that is a pretty >> hard requirement from the Intelligent City use case which has been >> the candidate for the main integrated larger use case. IIRC >> scalability was also among the original requirements and >> proposals. Also Kristian stated here that he finds it a good area >> to work on now so the basic motivation for the work seemed clear. >> >> So we tackled this straight on by first testing the behaviour of >> loading & unloading scene parts and then proceeded to implement a >> simple but effective scene manager. We’re documenting that >> separately so I won’t go into details here. So far it works even >> surprisingly well which has been a huge relief during the past >> couple of days — not only for us on the platform dev side but also >> for the modelling and application companies working with the city >> model here (I demoed the first version in a live meet on Wed), >> we’ll post demo links soon (within days) as soon as can confirm a >> bit more that the results seem conclusive. Now in general for the >> whole 3D UI and nearby GEs I think we have most of the parts (and >> the rest are coming) and ‘just’ need to integrate.. >> >> The point here is that in that work the focus is on the memory >> management of the rendering and the efficiency & non-blockingness >> of loading geometry data and textures for display. In my >> understanding that is orthogonal to scene declaration formats — or >> networking for that matter. In any case we get geometry and >> texture data to load and manage. An analogue (just to illustrate, >> not a real case): When someone works on improving the CPU process >> scheduler in Linux kernel he/she does not touch file system code. >> That does not mean that the improved scheduler proposes to remove >> file system support from Linux. Also, it is not investing >> resources into circumventing (your term) file systems — even if in >> the scheduler dev it is practical to just create competing >> processes from code, and not load applications to execute from the >> file system. It is absolutely clear for the scheduler developer >> how filesystems are a part of the big picture but they are just >> not relevant to the task at hand. >> >> Again I hope this clarifies what’s going on. Please note that I’m >> /not/ addressing renderer alternatives and selection here *at all* >> — only the relationship of the declarative layer and of the >> scalability work that you seemed to bring up in the sentence >> quoted in the beginning. >> >> > I suggest that we start to work on the shared communication >> layer using the KIARA API (part of a FI-WARE GE) and add the code >> to make the relevant components work in XML3D. Can someone put >> together a plan for this. We are happy to help where necessary -- >> but from my point of view we need to do this as part of the Open Call. >> >> I’m sorry I don’t get how this is related. Then again I was not in >> the KIARA session that one Wed morning — Erno and Lasse were so I >> can talk with them to get an understanding. Now I can’t find a >> thought-path from renderer to networking here yet.. :o >> >> Also, I do need to (re-)read all these posts — so far have had >> mostly little timeslots to quickly clarify some basic >> miscommunications (like the poi data vs. poi data derived >> visualisations topic in the other thread, and the case with the >> declarative layer & scalability work in this one). I’m mostly not >> working at all this Friday though (am with kids) and also in >> general only work on fi-ware 50% of my work time (though I don’t >> mind when both the share and the total times are more, this is >> business development!) so it can take a while from my part. >> >> > Philipp >> >> Cheers, >> ~Toni >> >> (*) "realXtend has had a declarative layer for the past 4-5 >> years(*)": in the very beginning in 2007-2008 we didn’t have it in >> the same way, due to how the first prototype was based on >> Opensimulator and Second Life (tm) viewer. Only way to create a >> scene was to, in technical terms, to send object creation commands >> over UDP to the server. Or write code to run in the server. That >> is how Second Life was originally built: people use the GUI client >> to build the worlds one object at a time and there was no support >> for importing nor exporting objects or scenes (people did write >> scripts to generate objects etc.). For us that was a terrible >> nightmare (ask anyone from Ludocraft who worked on the Beneath the >> Waves demo scene for reX 0.3 — I was fortunate enough to not be >> involved in that period). As a remedy to that insanity I first >> implemented importing from Ogre’s very simple .scene (‘dotScene’) >> format in the new Naali viewer (which later became the Tundra >> codebase). Then we could finally bring full scenes from Blender >> and Max. We were still using Opensimulator as the server then and >> after my client-side prototype Mikko Pallari implemented dotScene >> import to the server side and we got an ok production solution. >> Nowadays Opensimulator has OAR files and likewise the community >> totally depends on those. On reX side, Jukka Jylänki & Lasse wrote >> Tundra and we switched to it and the TXML & TBIN support there >> which still seem ok as machine authored formats. We do support >> Ogre dotScene import in current Tundra too. And even Linden (the >> Second Life company) has gotten to support COLLADA import, I think >> mostly meant for single objects but IIRC works for scenes too. >> >> Now XML3d seems like a good next step to get a human friendly (and >> perhaps just a more sane way to use xml in general) declarative >> format. It actually addresses an issue I created in our tracker 2 >> years ago, "xmlifying txml” >> https://github.com/realXtend/naali/issues/215 .. the draft in the >> gist linked from there is a bit more like xml3d than txml. I’m >> very happy that you’ve already made xml3d so we didn’t have to try >> to invent it :) >> >> > Am 23.10.2013 09:51, schrieb Toni Alatalo: >> >> On Oct 23, 2013, at 8:00 AM, Philipp Slusallek >> <Philipp.Slusallek at dfki.de <mailto: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 >> <mailto: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 >> <mailto: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 >> <mailto:Fiware-miwi at lists.fi-ware.eu> >> >>>> https://lists.fi-ware.eu/listinfo/fiware-miwi >> >>>> >> >>> >> >>> >> >>> -- >> >>> >> >>> >> ------------------------------------------------------------------------- >> >>> Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH >> >>> Trippstadter Strasse 122, D-67663 Kaiserslautern >> >>> >> >>> Geschäftsführung: >> >>> Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) >> >>> Dr. Walter Olthoff >> >>> Vorsitzender des Aufsichtsrats: >> >>> Prof. Dr. h.c. Hans A. Aukes >> >>> >> >>> Sitz der Gesellschaft: Kaiserslautern (HRB 2313) >> >>> USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 >> >>> >> --------------------------------------------------------------------------- >> >>> <slusallek.vcf> >> >> >> >> _______________________________________________ >> >> Fiware-miwi mailing list >> >> Fiware-miwi at lists.fi-ware.eu <mailto:Fiware-miwi at lists.fi-ware.eu> >> >> https://lists.fi-ware.eu/listinfo/fiware-miwi >> >> >> > >> > >> > -- >> > >> > >> ------------------------------------------------------------------------- >> > Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH >> > Trippstadter Strasse 122, D-67663 Kaiserslautern >> > >> > Geschäftsführung: >> > Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) >> > Dr. Walter Olthoff >> > Vorsitzender des Aufsichtsrats: >> > Prof. Dr. h.c. Hans A. Aukes >> > >> > Sitz der Gesellschaft: Kaiserslautern (HRB 2313) >> > USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 >> > >> --------------------------------------------------------------------------- >> > <slusallek.vcf> >> >> _______________________________________________ >> Fiware-miwi mailing list >> Fiware-miwi at lists.fi-ware.eu <mailto: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: 456 bytes Desc: not available URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20131027/9df02fc5/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy