[Fiware-miwi] Oulu bi-weekly tomorrow at 13 again

[Toni Alatalo]

Hi,

welcome again tomorrow for the Oulu bi-weekly, at 13 here at Mäkelininkatu. Just a basic status check in the usually agile style: demos of things done, next plans and informing / discussion of possible problems.

We can at least demo WebTundra client side physics(1) and Lasse just told on IRC that they’ve begun work on the custom components support(2). About others I don’t know of but hopefully we’ll hear latest in the meet then — please do post agenda items or links to code / demos at will beforehand too. A little info about those two items from our standpoint:

(1) Physics: The old standalone three.js Car demo is ported to Tundra & WebTundra now, to be used with the city or any other scene. Is a separate project with a minimal test scene. The idea is that because physics + custom physics code for a lot of objects is known to be a bottleneck in Tundra (from avatar apps & lots of users) it can be useful for mass apps on the web to avoid that by using client side physics. Client side logic & control of the ‘own entity’ (avatar, car, camera, ..) is nice also to avoid network latency with controls. The key is that the client deals with only the own single object, collisions of that with nearby objects, and not every collision in the whole scene (like the server typically does) — that makes it relatively light for each client as well. The physics is ran in a Web worker so doesn’t block rendering. The code is on GitHub but there’s no demo on the web as we still don’t have Tundra servers up for public access (nor Meshmoon integration which would also solve this), https://github.com/playsign/WebTundraCar . 

This is all still custom code in that test app, to be refactored to a physics module for WebTundra in next steps. Then we could add support for reading rigidbody params from XML3D descriptions too to be able to run physics demos standalone (the only way currently to load a scene to WebTundra from a file, instead of a web socket connection to Tundra, is from a XML3D file — like we use TXML with the c++ version). Also, with the physics module we could port the old standalone / offline version of Pong to use WebTundra’s physics abstraction instead of Ammo.js (Bullet) directly.

(2) Custom components: Lasse from LudoCraft said they’ve began work with the previously discussed plan for better custom component support. AFAIK it boils down to JS code becoming able to define new component types: the data definition and a nice way to hook custom handling of the data. The Car from the Physics work seems like a good candidate as a test / demo case for that: WebTundraCar is currently implemented with the DynamicComponent system so that each car entity has a Car component which is handled by the app code to construct the cars from the body + wheels and create the physics etc. They don’t actually even use the Mesh component as the visualisation is a part of the Car component on the client side. So soon we’ll get to see how that works with the new system.

Cheers,
~Toni