While I don't agree that what you propose would be the correct development process for MIWI -- mostly based on the time-to-market and other business considerations discussed in the earlier thread -- I think it is totally fair for you to ask about the shortcomings in XML3d.js. Unfortunately it is not an easy question for us to answer completely. This requirements driven analysis was exactly what I started in that one MIWI reqs doc which has a subsection for rendering requirements, however that's mostly a stub still: https://docs.google.com/document/d/1P03BgfEG1Ly2dI2Cs9ODVDmBhH4A438Ynlaxc4vXn1o/edit#heading=h.8wiyysq665rx But in the asset session on Monday in the great discussion with xml3d.js developers we learned 2 new concrete missing parts which the large city model handling / paging scene manager code we have now depends on: 1. Ability to free memory: currently xml3d.js never frees memory 2. Ability to load data in the background (parse meshes in worker): currently xml3d.js loading can be synchronous only (already known: 3. Support for gpu-supported texture compression (speeds up the loading to mem too)) With three.js 1. needed a bit of figuring out (there was a demo for it though), 2. was already well implemented in a worker-using CTM loader and 3. has been there for long and most realXtend usage of three has depended on it (was also discussed within miwi regarding xml3d.js earlier). I am fairly certain that utilizing the already existing and working technology was the correct decision here. Main reason is that it was uncertain whether the whole idea can actually work: can we frequently load&unload city blocks with the UI remaining responsive and without the browsers getting choked. So far it seems even surprisingly good, is totally fluent (though there are some caveats: these are optimized blocks, heavier are coming soon, and possibly the textures are reused now (gotta check with Erno whether his texture cache is in use in the on-line version)). This way we learned it quickly -- and have been able to demonstrate it to other companies who work on businesses around the city model. Those 3 points are simple and easy to add xml3d.js, the DFKI guys took notes of them and already had ideas how to add support (there is already a resource manager which keeps track of usage counts so there's a way to free unused resources etc). However these are not an exhaustive list, only a couple simple points encountered in the scalability work. And besides technical features there are business and community aspects. But that's another discussion, this post was just to a) remind about the rendering part in the requirements doc and b) inform about those little findings discussed in the asset meet (I added them to the reqs doc too). Cheers, ~Toni On Thu, Oct 24, 2013 at 4:28 PM, Philipp Slusallek < Philipp.Slusallek at dfki.de> wrote: > Hi, > > Well, I think you identified the overlaping quite well :-). The goal of > Miwi always has been to provide the tools for declarative 3D in the Web. > While we agreed that there might be value (to be evaluated) in adding > three.js to XML3D, I am not too happy that we are investing the FI-WARE > resources into circumventing the declarative layer completely. > > When you are saying that there are limitation in XML3D, it would be good > to know what they are explicitly and jointly work on removing them. Only if > that should fail should we be looking at alternatives. > > My suggestion of adding a wrapper around the communication is exactly such > that we can evaluate XML3D against any three.js version that might be > there. There is a lot of novel stuff coming from our side that we will not > be able to integrate across this "fork" in our code base, which is a pitty. > And again, we would like to know where limitations are in XML3D -- please > tell us straight away. > > 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. > > > Best, > > Philipp > > > 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<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<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<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 -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20131030/eac6c0e2/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy