AWG: Core simulator exploration

Zha's thoughts on 'the core business of simulators'

Raw thoughts warning

This is an early draft, of some raw thoughts. Please feel free to comment on them, ask questions and such. This is not a collective work product at the moment, but rather an atttempt to share my thinking. I do think that a more formal, collectively mulled over version of this page would be a good thing. This isn't it, at least not yet. - Zha

This is a companion to my notes on state melding AWG: state melding exploration. It attempts to explore what the core activities of a region simulator might be, in terms of the rough language of the evolving second generation grid activity being pursued by the AWG. It focuses, as much as possible, not on precise implementation details, but broad, technical approaches, rooted in the AWG's assumptions. It is, again, very much an attempt to get some ideas out and talked about. Feedback, and discussion on this is deeply appreciated and desired.

So, once again, we start with the base terms. We have a region, being hosted in a Region Simulator. This is a second generation deployment, so, the region simulator is only running the simulation. The agent specific portions of activity are assumed to be split off to agent servers running in a separate agent domain, per the proposed design. We will also, for the moment, model scripts slightly oddly, attempting to not make any locality assumptions about where the scripts are run.

The simulator holds:

• A static landscape
• A set of prims:
  • Some physical
  • Some in linksets
  • Some attached to avatars
  • Some running scripts
• A set of avatars
  • The avatars are coupled to
    • Agents in the agent domain
    • Clients
• A physical simulation program

We start at a given moment, with a frame. The frame is a momentary snapshot of the region, corresponding to the last state all the observers have seen. Our goal is to step forward from the current frame to the next frame, noting what needs to occur as we create the new frame.

We accept a set of sets of inputs: (Some of which may be null sets)

• Motion requests from the clients associated with our avatars
• Chat utterances from the clients associated with our avatars
• Avatar appearance updates
• Changes in the avatar's linksets
• Changes in objects due to scripting inputs
• New objects created in the region due to requests made on the region
• Requests to delete objects due to requests made on the region
• The addition of Avatars
• The subtraction of Avatars

We run a frame of physical simulation. this:

• Moves a set of objects
• Causes some collisions to occur
• May move some objects or avatars out of the region

At this point, we now have a new frame. We now face the challenge of letting all the relevant observers know about the new frame. Each client needs to know, as does every scripted object with a sensor. If we have any viewpoints looking into the region from outside, they too need to be updated.

What needs to be reported?

We could just send the entire new frame. But.. In practice, we deeply don't want to do that. What we want, in fact, most likely, is to send all the changes, from each viewpoint's perspective.