[Fiware-miwi] Tundra scene synchronization protocol

[toni at playsign.net]

just a brief note:



---From: Philipp Slusallek
Am 08.09.2013 17:05, schrieb Jonne Nauha:
>> Currently all components except EC_DynamicComponent's structure is
>> static and known/locked down during build time. You cannot add
>> attributes to any other component during runtime than
>> EC_DynamicComponent. This could in theory be supported for any
>> component, but as the C++ logic operates on the build time knowledge of
>> attributes the logic code could not do anything sensible with these
>> runtime attributes. EC_DynamicComponent is mostly useful for scripts
>> that can write custom handling logic for the apps custom attributes that
>> it wants to synchronize over the network.
>Using KIARA however, even they could define their own components up
>front and then KIARA wold generate the necessary (and optimized code) to
>send those components. However, dynamically adding new attributes during
>run-time would then no longer work (or be much slower). C++ might still
>be able to look at it (if needed) but this would not be a fast option.


When I started to work on the DynamicComponent thing the idea was not actually to implement dynamically added&removed attributes, but a way for define *static* i.e. normal component types from what were we calling dynamic languages (javascript, python, lua and such). I had a first test thing for that running when the Ludo guys also worked on it and implemented the dynamic components thing. I found it a bit weird as was working on a different thing, but it did work also for my purpose -- it does enable defining and working with your own component data from JS -- so I just started using it too. We’ve discussed this often since then and at one point I learned that the guys had found it a useful mechanism to be able to just add some data easily, IIRC Ludocraft was using it from c++ modules too really early on and told that found it handy sometimes.


But for network efficiency reasons, and I think also for robustness (defined sets of attributes for the component type) to avoid bugs in the programming, being able to declare EC types from scripts would be nice still. A big bonus I’ve thought would be that they’d work right in the graphical EC GUI editor used for authoring - adding your component would have the attributes pre-populated, now we often just add them by hand there (a script can ofc populate them too - and often they are completely only handled by scripts and not touched manually. but there can be nice for manual use too, like some nice camera and light setups perhaps, or door functionality .. you just add the Door EC to the object you want to work as a door, it can be a simple script and doesn’t need an UI even if just setting some parameter in the editor suffices).


I’ve been calling it CustomComponent support now. Jonne has been calling it ‘the thing that Toni wants’ 😊


Defining network messages would be good too, like you can with c++ with kNet and with many languages using something like Protobufs -- so yes KIARA can be really nice for us, as I understand it has that too.. right? In scripts, we now use these text string based entity actions - sometimes being able to specify real optimized normal network messages would be good I suppose .. for example a custom movement message for your movement system perhaps?


> This definitely makes sense. I still think that moving the relevant
> field into a single component can simplify things even more. The two are
> orthogonal.


This is an interesting point - also Placeable can be used to move objects, by setting position. RigidBody features the nice movement sync. But not all moving objects need the RigidBody otherwise, I mean the Bullet physics things.


I wonder whetherthe RigidBody movement sync in Tundra is not only about velocity based intra- & extrapolation .. Jukka at least tested falling to client side physics upon network probs etc. iirc.

> Thanks a lot and have a nice Sunday evening,


The 1st Annual Opensimulator Community Conference #OSCC13 was great - Intel DSG guys etc. were there too and many nice VW dev folks. And Grady Booch even 😊 . There was healthy interest for realXtend too and we were talking about these web client efforts related to that, some knew xml3d from before which was very cool. That virtual conference running on opensimulator itself was quite an achievement by those folks -- a landmark really, very well organized and on a completely open source stack. They had a nice simple customized client app for it (just a preconfigured slviewer basically but good).

> Philipp


~Toni


> Yes, again this is very generic. The Tundra SDK does not decide what
> security model you have. It provides signals to application logic (C++
> or script) to tell it if a scene change should be allowed. This has
> proven to be enough in Meshmoon as we use it to determine who can make
> client side scene changes. If the Meshmoon user has "basic" permission
> on the scene we will reject any changes it tries to do to the scene
> model on the client side. These users can still interact with the scene
> via the scripts in that scene, whatever the apps there might be.
> 
> You can send custom messages via EntityActions (not yet documented on
> the wiki). Basically its a way for the client to send messages with
> custom data variables and the server side logic can act on it. With this
> mechanism you can move the scene manipulation to the server side and
> thus the change is allowed also for "basic" users. 
> 
> The change requests can be catched in server side app logic
> from http://doc.meshmoon.com/doxygen/class_scene_sync_state.html#signals. At
> some point we will need to extend this to provide information what
> component and attribute the change was targeted to. Currently it will
> tell what entity the client tried to manipulate.
>  
> 
> 
> 
>     Best,
> 
>             Philipp
> 
> 
> Lasse: Please step in if I made an factual errors :)
> 
> Best regards,
> Jonne Nauha
> Meshmoon developer at Adminotech Ltd.
> www.meshmoon.com <http://www.meshmoon.com/> 


-- 

-------------------------------------------------------------------------
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/20130909/d6c9b5a9/attachment.html>