I'm also a bit confused about the KIARA business. I think we have been pretty clear since applying this FIWARE work that we are going to use realXtend Tundra as the server and that imo implies our current protocol and the entity-component system. We have already perfectly good Tundra protocol for what this project is set out to accomplish (performant extendable system). We also have all the experience in the world to implement the whole picture on the Tundra server and the web browser side. We have none of that with KIARA tech. What would be the benefit exactly now to make Tundra server talk to desktop clients with the Tundra protocol and then swap that out for KIARA communication when a websocket client connects? This would require all sorts of ugly code in out Tundra networking layer and the syncmanager involved with it. Surely this CAN be implemented, I just wonder why we should basically re-invent the wheel when we have things in place for the Tundra protocol. I'm no involved in the actual GEs so I haven't either participated in the talks. 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 intent to send the Tundra protocol just via KIARA? If so, I still don't see the benefits. I my opinion we should send everything Tundra offers to the clients and on the client side make decisions what we are going to be pushed to the renderer (may it be xml3d or threejs). Again as Toni said the networking is separated from the DOM interaction and rendering. We can send the Tundra protocol to the client and map the parts that we can and should from our Entity-Component system into the XML3D nodes etc. P.S. We have documented a long time ago what should be found from XML3D so we can map things into it https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi/index.php/RealXtend_Scene_and_EC_model. Granted things like water and sky component is not probably a primitive type that needs to be there, but things like these are important for 3D worlds. There is an easy and fast way Tundra to say "I want water" and it's there and can be configured to your needs. On the web client this can map to creating a XML3D primitive and setting a nice shader and textures to it. But the end user should not have to describe his scene at such low level. P.S.S. These are my personal two cents / thoughts on the things discussed here from how I understand them. I'd like to keep the discussion going so we can all get to the same page. Best regards, Jonne Nauha Meshmoon developer at Adminotech Ltd. www.meshmoon.com 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/97013269/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy