Just a quick note .. Waiting for folks in a car in a parking place On 24.10.2013, at 17.16, Philipp Slusallek <Philipp.Slusallek at dfki.de> wrote: > I am not sure I fully understand what you are saying. But then I might not understand the structure you have in mind from the RealXtend side. Can you elaborate a bit? > > From my point of view POIs are not necessarily scene elements themselves but rather data sources that get used in the scene. Maybe that is the main difference between us here. No, there is no difference - that is exactly the same. It was just an observation that the proposed format for the POI data provider is basically identical to what we've been using in the scene server too - just with new component types for the POI data. So it seemed worthwhile to think about the situation. I do find now that it's also an interesting question how the POI data integrates to the scene system too - for example if a scene server queries POI services, does it then only use the data to manipulate the scene using other non-POI components, or does it often make sense also to include POI components in the scene so that the clients get it too automatically with the scene sync and can for example provide POI specific GUI tools. Ofc clients can query POI services directly too but this server centric setup is also one scenario and there the scene integration might make sense. I think this is a different topic, but also with real-virtual interaction for example how to facilitate nice simple authoring of the e.g. real-virtual object mappings seems a fruitful enough angle to think a bit, perhaps as a case to help in understanding the entity system & the different servers etc. For example if there's a component type 'real world link', the Interface Designer GUI shows it automatically in the list of components, ppl can just add them to their scenes and somehow then the system just works.. I don't think these discussions are now hurt by us (currently) having alternative renderers - the entity system, formats, sync and the overall architecture is the same anyway. -Toni > From an XML3D POV things could actually be quite "easy". It should be rather simple to directly interface to the IoT GEs of FI-WARE through REST via a new Xflow element. This would then make the data available through <data> elements. Then you can use all the features of Xflow to manipulate the scene based on the data. For example, we are discussing building a set of visualization nodes that implement common visualization metaphors, such as scatter plots, animations, you name it. A new member of the lab starting soon wants to look into this area. > > For acting on objects we have always used Web services attached to the XML3D objects via DOM events. Eventually, I believe we want a higher level input handling and processing framework but no one knows so far, how this should look like (we have some ideas but they are not well baked, any inpu is highly welcome here). This might or might not reuse some of the Xflow mechanisms. > > But how to implement RealVirtual Interaction is indeed an intersting discussion. Getting us all on the same page and sharing ideas and implementations is very helpful. Doing this on the same SW platform (without the fork that we currently have) would facilitate a powerful implementation even more. > > > Thanks > > Philipp > > Am 23.10.2013 08:02, schrieb Tomi Sarni: >> ->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 <mailto: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 >> <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 >> <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 >> <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 <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>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy