Sunday, February 24, 2008
Monday, February 18, 2008
Friday, February 01, 2008
distributed physics
These are some quick notes on my crazy ideas on how to create a scalable, distributed, shared artificial reality:
* Everything in the system is an object, with a bunch of attributes, some static (not normally changed) and some dynamic. Static ones include size, shape and mass; dynamic attributes include position, orientation, linear and angular velocity.
* Every object has an authoritative server who manages that object
* An avatar is a type of object that happens to be controlled by a user
* Region servers keep track of the objects in their volume of influence (overlapping?)
* Objects compute their own dynamics, based on their attributes, internal state, and information they acquire about their environment. The result is a trajectory -- the object's motion plan based on present information (maybe .5 or 1 second into the future -- enough to cover maximum network lag).
* Collisions are handled as follows: an object queries the objects near it (how does it know who is near? ask the region server). The other object returns information about its planned trajectory (as well as size & shape if we haven't seen that object before, or it's been modified). If the trajectories of the two objects indicate a collision, our object modifies its trajectory accordingly. In most cases, the other object will do the same (query our trajectory, compute whether it needs to deflect).
* A viewer is a piece of code that queries objects and visualizes them for a user. In practice, there will probably be some sort of registration system: a viewer registers with an object (through its server, or proxied through the region server) to get updates. The object will then send a stream of time-stamped messages with its present trajectory (velocity, rotation over some time period -- possibly buffered like an audio stream? smoothness vs. latency, ala VOIP). The trajectory is good for its specified time period, or until a new trajectory message supersedes it. The viewer can choose how to handle missing data (trajectory completes, no new message); it could extrapolate (ala Second Life viewer), just freeze the object, or even run client-side physics to try to guess what the object might do.
A system like this should allow a large world with many objects to be distributed over a number of servers in a scalable fashion. The region server's job is minimal -- it just keeps track of who is 'in' the region (subtlety involves large objects whose center of mass may be in an adjacent region; the region size must be a few times larger than maximum object size). The dynamics and collision detection responsibilities are spread among the active objects, which can be on any number of servers. The region server may also proxy the objects messaging, so viewers don't need point-to-point connections with each object's server -- though perhaps a multi-connection setup would work, and the region server just manages resolving the connection. I'm not enough of a network expert to think this through completely.
The advantage of this sort of architecture, aside from the obvious scalability, is that there is minimal coupling between the parts of the system. The viewer doesn't have to know anything about the physical properties of the objects, or the underlying dynamics used, collision etc; it just presents its stream of object updates as best it can. Different objects can use different physics engines or collision logic; in the end, each object is authoritative for itself, so there can be no long-term discrepancies. The trade-off is probably increased net traffic compared to an SL-style architecture; but I suspect this will be more than offset by the advantages of a distributed topology, and by the ability of viewer clients to make choices about how much data they can handle. You could have 10,000 avatars in a stadium, and each client may choose to fully visualize only the closest 50 people. The rest might be rendered at low resolution, with low-frequency updates; using crowd simulation; or not at all. A viewer with a big pipe might render more of the crowd; a client on a limited bit budget could choose to get less frequent updates and do its own extrapolation.
that's all for now, more to come...
* Everything in the system is an object, with a bunch of attributes, some static (not normally changed) and some dynamic. Static ones include size, shape and mass; dynamic attributes include position, orientation, linear and angular velocity.
* Every object has an authoritative server who manages that object
* An avatar is a type of object that happens to be controlled by a user
* Region servers keep track of the objects in their volume of influence (overlapping?)
* Objects compute their own dynamics, based on their attributes, internal state, and information they acquire about their environment. The result is a trajectory -- the object's motion plan based on present information (maybe .5 or 1 second into the future -- enough to cover maximum network lag).
* Collisions are handled as follows: an object queries the objects near it (how does it know who is near? ask the region server). The other object returns information about its planned trajectory (as well as size & shape if we haven't seen that object before, or it's been modified). If the trajectories of the two objects indicate a collision, our object modifies its trajectory accordingly. In most cases, the other object will do the same (query our trajectory, compute whether it needs to deflect).
* A viewer is a piece of code that queries objects and visualizes them for a user. In practice, there will probably be some sort of registration system: a viewer registers with an object (through its server, or proxied through the region server) to get updates. The object will then send a stream of time-stamped messages with its present trajectory (velocity, rotation over some time period -- possibly buffered like an audio stream? smoothness vs. latency, ala VOIP). The trajectory is good for its specified time period, or until a new trajectory message supersedes it. The viewer can choose how to handle missing data (trajectory completes, no new message); it could extrapolate (ala Second Life viewer), just freeze the object, or even run client-side physics to try to guess what the object might do.
A system like this should allow a large world with many objects to be distributed over a number of servers in a scalable fashion. The region server's job is minimal -- it just keeps track of who is 'in' the region (subtlety involves large objects whose center of mass may be in an adjacent region; the region size must be a few times larger than maximum object size). The dynamics and collision detection responsibilities are spread among the active objects, which can be on any number of servers. The region server may also proxy the objects messaging, so viewers don't need point-to-point connections with each object's server -- though perhaps a multi-connection setup would work, and the region server just manages resolving the connection. I'm not enough of a network expert to think this through completely.
The advantage of this sort of architecture, aside from the obvious scalability, is that there is minimal coupling between the parts of the system. The viewer doesn't have to know anything about the physical properties of the objects, or the underlying dynamics used, collision etc; it just presents its stream of object updates as best it can. Different objects can use different physics engines or collision logic; in the end, each object is authoritative for itself, so there can be no long-term discrepancies. The trade-off is probably increased net traffic compared to an SL-style architecture; but I suspect this will be more than offset by the advantages of a distributed topology, and by the ability of viewer clients to make choices about how much data they can handle. You could have 10,000 avatars in a stadium, and each client may choose to fully visualize only the closest 50 people. The rest might be rendered at low resolution, with low-frequency updates; using crowd simulation; or not at all. A viewer with a big pipe might render more of the crowd; a client on a limited bit budget could choose to get less frequent updates and do its own extrapolation.
that's all for now, more to come...
Subscribe to:
Posts (Atom)