[Fiware-miwi] SceneAPI features: original intent of the EPIC vs . current plans?

[Philipp Slusallek]

Hi,

All the best for the new year to all of you!

I am just catching up on some email that got stuck in my inbox over a 
very busy end of the year. So do not be surprised to get responses on 
old email :-). Sorry for the long delays here.

Regarding the SceneAPI. I believe that it is still very much worth 
looking into the original intention of the Epic and not tie it too much 
to the server (however, the server could implement the same interface as 
well).

There are clearly some similarities to the synchronization protocol. But 
that it assumes that a server is in full control over the client (or at 
least parts of it) and knows what to do. With the SceneAPI it may also 
be a matter of finding out things about the target scene first before 
making changes. An AI service could for example find the location to go 
to before starting to move the character. This would not be possible 
with pure Synchronization.

One obvious issue that Toni already talked about is the direction. 
Contacting a browser instance is not possible without a server as we 
know from Server-Based Rendering. But then we could design an interface 
that allows for querying and changing a scene.

There is already is such a suggestion by Behr et, al 
(http://dl.acm.org/citation.cfm?id=1836057&CFID=394541370&CFTOKEN=82263824) 
that may be a good lpace to start. It based on HTTP/REST, though, which 
would not work for a connection towards the browser, so we should use 
WebRTC instead.


Best,

	Philipp

Am 21.11.2013 22:24, schrieb Toni Alatalo:
> On 21 Nov 2013, at 10:54, Lasse Öörni <lasse.oorni at ludocraft.com> wrote:
>> If there is a good concrete plan to how it should be done instead it's not
>> at all too late to change (as any implementation has not began), and if
>> it's administratively OK, for example our architecture pictures now
>> include the REST scene API described.
>
> I talked today with a guy who is working on the vw / visualization front in the university project with the traffic sensors in the city.
>
> We agreed preliminarily that could use their data and system as a use case for this SceneAPI biz on the fi-ware side — if you and others here find it’s a good idea.
>
> Their data currently updates once per hour, though, so http would work :)
>
> But he had already proposed as a next step a visualisation where traffic is simulated / visualized as actual individual cars. We could have that simulation service as a user of the scene api / sync biz to control the cars so we’d get streaming nature for the data and much harder reqs for the usage (in the spirit of the EPIC).
>
> I still have to confirm with the prof whose leading that project that this all would be ok. We could do it so that the actual implementation of the visualization and even the integration comes from the uni and fi-ware (Ludocraft) only provides the API. I can use some of my university time for this as the integration of the city model and the traffic data is good to get there.
>
> This is not a must and I don’t mean to overcomplicate thing but just figured that a real use case would help to make the *concrete plan* that you called for above.
>
> The experience with the quick and simple POI & 3DUI integration (completed yesterday) was great, I’ll post about it tomorrow hopefully (the POI guys checked the demo today on ok’d it as this first minimal step). So I hope more integrations and usage of the GEs takes us well forward.
>
>> Lasse Öörni
>
> 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/20140102/540bf2df/attachment.vcf>