[Fiware-miwi] POI -> 3DUI integration

[Philipp Slusallek]

Hi Toni,

Nice work!

 From my POV both cases (a) and (b) are both perfectly valid way of 
implementing apps that use POIs and since we are providing tools for 
developers to choose from, we should actually provide both (or at least 
not prohibit one of them even if we only provide the other).

One thing that would be very useful in this context is the definition of 
a base POI WebComponent. This could receive the POI data, handle the 
display and interaction part, and offer to be configurable and stylable 
through CSS.


Best,

	Philipp

Am 22.11.2013 13:09, schrieb Toni Alatalo:
> A first test for the integration of POI & 3DUI GEs is finished now.
>
> Live demo: http://playsign.tklapp.com:8000/POIThreeJS/POI.html
> Code & docs: https://github.com/playsign/POIThreeJS
>
> Developed with Chrome. I saw Ari Okkonen running it ok with Firefox yesterday with a small glitch: mouse clicks to turn camera opened browser context menu or so.
>
> Known issue, copy pasted from the readme:
> - mouse clicks can go through the 2d UI elements to the 3d UI. This is reportedly solved by Adminotech's 2DUI GE / input system. So the solution is to integrate with that somehow.
>
> The main motivation for this effort was to learn in practice about the integration of 3DUI and other GEs. What kind of APIs they require, how they work together etc. Brief points about main observations:
>
> 1. It seems ok to handle POIs separately, they don’t necessarily need to a part of the entity system data. What I mean is: this client-side solution works so that it gets the 3d scene from 3DUI, and fetches the POI data itself. It has those as two separate sets of data. This seems fine as the POIs are handled specifically anyways: the visualisations and interactions are created for them. OTOH if this was a client-server setup, the server could do the same as this client does, and at that point the client would receive only the visualisations + interaction definitions normally as a part of the scene and would not necessarily need to know that they are POIs .. they’d just work using basic features (meshes, billboards, click handling). I try to clarify this with pseudocode still:
>
> /* a) attempt to unify everything to the same data container somehow */
> myscene = 3dui.load(“oulu”);
> myscene.extendFromUrl("http://poi.com/oulu“); //fetches pois and adds the data from them to the scene / dom / generic overall container
> pois = myscene.entitiesWithComponent(POI); //gets the entities that the previous fetch created
> //.. handle the pois
>
> /* b) current code with 3d scene & poi data separately */
> myscene = 3dui.load(“oulu”);
> pois = poi.searchPOIs("http://poi.com/oulu“)
> //.. handle the pois
>
> This is debatable and I’m not sure of my own stand either yet, certainly come kind of POI component might well be a nice way etc. Anyhow now we at least have concrete basis to think of that more.
>
> 2. It would be nice for the service backend type of GEs to provide client side libraries for easy access to the services. Even though doing http requests is trivial from anywhere, it is still even nicer to just call an existing JS func from a lib. In this case, CIE POI folks’ ‘demo4’ (featured at F2F & video, the google maps integration) was a nice enough up-to-date client side code we could adopt here. Just needed to clean the searchPOIs function from the few places that depended on google maps, result of that cleaned 'function searchPOIs(lat, lng)’ is at https://github.com/playsign/POIThreeJS/blob/master/POI.js#L369
>
> 3. Good solutions for integrating 2d elements to 3d scene would be nice to provide as components, here Tapani reused the html (jquery.ui) 2d widget to 3d scene placing code from the twitter thing prepared for London earlier. Also we now encountered a concrete need to integrate Adminotech’s 2D UI input management biz I think, to know whether clicks hit 2d elements or the 3d scene.
>
> Final note: the POI schema & backend supports having more data, pictures, urls etc. and those are populated in the DB for some test points at university. Unfortunately for the city center for which we have the 3d model there is no content yet apart from the poi names. The 3d client already supports showing the data, we talked with POI folks about populating something to the center. However I did not want to further delay informing the MIWI group about this as the dev work was already completed and we’ve moved to other things (asset pipe & net sync integration) .. you’re all programmers so can imagine it :p
>
> Cheers,
> ~Toni
> _______________________________________________
> 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
---------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slusallek.vcf
Type: text/x-vcard
Size: 441 bytes
Desc: not available
URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20131123/e5bbe00b/attachment.vcf>