Physics

Another good start to learn what we are thinking about physics implementation is this thread on our open dev mailing list.

Plan

a) use the performant and open source Bullet Physics system. Due to active development by game vendors this library is likely to remain relevant and highly tuned for games.

b) Do all authoritative physics simulation at the space level. Space servers should update object hosts with their objects' new positions. At this level aesthetically animating objects (such as objects that have human appearances) should be represented as a ellipsoids with a Popsicle stick. Essentially all objects should be able to present the physics system with simplified geometric proxies that conform to similar bounds as the appearing mesh, assuming the client side will do local fixups.

c) Client side collision detection and slide of various physics components to make sure that aesthetic animations stay above ground and out of walls (i.e. sliding feet and hands to accomplish this on avatars appearing objects) and no random falling objects penetrate a given floor.

Scaling

There are a number of scaling issues with sirikata. Eventually we want to allow for a large number of concurrently connected objects within a given space, and this size could overload even the most performant physics libraries. Splitting this simulation across multiple servers requires careful logic on boarder regions and synchronization protocols there.

Also we want our code to work for extremely large, sparse spaces like solar systems, etc. Making sure computations are kept local for each given server split will be useful and ideally upgrading positions to be doubles could be useful in the longterm (though it's not this simple since many but not all items must be upgraded to doubles to get solar-system level scalability.)