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...
~~~Artiphys~~~
Subscribe to:
Post Comments (Atom)
4 comments:
Nifty - tho one clarification. An object that is controlled by a user isn't necessarily called an avatar... as an avatar might be able to take control of another object.. say.. a vehicle. So that leads to further claification of what an Avatar is.. and, it seems an avatar is a representation of the user in the virtual world. The user may or may not be able to control this representation. The user may be able to control other objects in the virtual world.
good point. I didn't talk about scripting & animation yet -- that's next. In short, I see physics as simply one form of scripting -- it's up to the object to decide what its behavior will be. If it's a physical prim (not attached or controlled), it plays out its physics 'script' -- checking for collisions, moving acc. to dynamic laws.
If the object is an avatar, or a vehicle for that matter -- anything controlled by a user -- it responds to that user's commands rather than just to physics. Similarly, an attached prim responds to the control of its parent object.
Similarly, animated objects follow their animation script, which may or may not have anything to do with physics. Physics is just one modality of object control. In all cases, the object itself decides what to do based on its internal configuration.
I think that makes sense...
Dan, I’m just popping in for a second to observe that you probably have very few people in your life with which you can have meaningful conversation. Being uncommonly intelligent has its drawbacks I guess.
Actually, for my little C thingie, I was thinking of how to distribute the physics (not very practical, as its too early, but still :)
My idea was: you take the initial space - say 256x256x1000, and start to watch the number of objects. As soon as there's a lot of objects (read: lots of calculations), you "cut out" that part of the space and move its simulation off to another server - and on the local server you note about the other objects' trajectories - if they are supposed to cross the boundary between the "realms" then this object needs to be simulated by both - if not - then the other "realm" does not need to know about that.
The advantage is you can simulate large volumes by default and then scale the performance with the increase of density. But indeed the drawback is you need to have a single object in at least 2 engines - and maybe even more...
Post a Comment