->Philipp *I did not get the idea why POIs are similar to ECA. At a very high level I see it, but I am not sure what it buys us. Can someone sketch that picture in some more detail?* Well I suppose it becomes relevant at point when we are combining our GEs together. If the model can be applied in level of scene then down to POI in a scene and further down in sensor level, things can be more easily visualized. Not just in terms of painting 3D models but in terms of handling big data as well, more specifically handling relationships/inheritance. It also makes it easier to design a RESTful API as we have a common structure which to follow and also provides more opportunities for 3rd party developers to make use of the data for their own purposes. For instance ->Toni >From point of sensors, the entity-component becomes device-sensors/actuators. A device may have an unique identifier and IP by which to access it, but it may also contain several actuators and sensors that are components of that device entity. Sensors/actuators themselves are not aware to whom they are interesting to. One client may use the sensor information differently to other client. Sensor/actuator service allows any other service to query using request/response method either by geo-coordinates (circle,square or complex shape queries) or perhaps through type+maxresults and service will return entities and their components from which the reqester can form logical groups(array of entity uuids) and query more detailed information based on that logical group. I guess there needs to be similar thinking done on POI level. I guess POI does not know which scene it belongs to. It is up to scene server to form a logical group of POIs (e.g. restaurants of oulu 3d city model). Then again the problem is that scene needs to wait for POI to query for sensors and form its logical groups before it can pass information to scene. This can lead to long wait times. But this sequencing problem is also something that could be thought. Anyways this is a common problem with everything in web at the moment in my opinnion. Services become intertwined. When a client loads a web page there can be queries to 20 different services for advertisment and other stuff. Web page handles it by painting stuff to the client on receive basis. I think this could be applied in Scene as well. On Wed, Oct 23, 2013 at 8:00 AM, Philipp Slusallek < Philipp.Slusallek at dfki.de> wrote: > Hi, > > First of all, its certainly a good thing to also meet locally. I was just > a bit confused whether that meeting somehow would involve us as well. > Summarizing the results briefly for the others would definitely be > interesting. > > I did not get the idea why POIs are similar to ECA. At a very high level I > see it, but I am not sure what it buys us. Can someone sketch that picture > in some more detail? > > 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. > > BTW, as part of our shading work (which is shaping up nicely) Felix has > been looking lately at a way to describe rendering stages (passes) > essentially through Xflow. It is still very experimental but he is using it > to implement shadow maps right now. > > @Felix: Once this has converged into a bit more stable idea, it would be > good to post this here to get feedback. The way we discussed it, this > approach could form a nice basis for a modular design of advanced > rasterization techniques (reflection maps, adv. face rendering, SSAO, lens > flare, tone mapping, etc.), and (later) maybe also describe global > illumination settings (similar to our work on LightingNetworks some years > ago). > > > Best, > > Philipp > > 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 > ------------------------------**------------------------------** > --------------- > > _______________________________________________ > 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/20131023/757c72b8/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy