Again just a brief note about one point: On 26 Oct 2013, at 17:46, Jonne Nauha <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> wrote: > On 24 Oct 2013, at 16:28, Philipp Slusallek <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> 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> > >> > >> _______________________________________________ > >> 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> > > _______________________________________________ > Fiware-miwi mailing list > Fiware-miwi at lists.fi-ware.eu > https://lists.fi-ware.eu/listinfo/fiware-miwi > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20131026/ed322309/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy