[sldev] Physics Modularity (was: AWG - Scope (Future SL Architecture versus Multiworld Interoperability))

Andre Roche roamingryozu at gmail.com
Sat Oct 27 02:44:43 PDT 2007


On 10/26/07, Argent Stonecutter <secret.argent at gmail.com> wrote:
> On 26-Oct-2007, at 12:49, Matthew Dowd wrote:
> > Yes - there are issues around this. Latency is one, although this
> > may not be a so much an issue if the components are on machines
> > within the same physical LAN.
>
> I strongly believe that even adding the system call latency for
> communicating between separate processes on the same server would be
> an issue for *any* communication in the critical path of the physics
> engine.
>
If LL is ever going to open up the sim server code, there's going to
at least need to be some kind of physics engine interface to plug in
any physics engine a user wants to use.  They're not exactly allowed
to release the Havok code, I don't think.

> > The particular partitioning may not be appropriate - another way
> > might be that the ground area controlled by a sim varies with the
> > load - a quiet 65536sqm region may be looked after by 1 simulator
> > but as it gets busier it may end up being controlled by 4
> > simulators each looking after a 16384sqm quadrant etc. (this of
> > course assumes much smoother transfer between sims and better
> > intercommunication between sim at the boundaries) etc.
>
> Variable sized simulators is something that would be extremely
> useful. You could go the other way, too, and get more efficient
> Openspaces.
>

Sims with different sizes than 256 probably won't come about until
after the sim code is released.  From what I hear, 256 is scattered
around the code too much.

Would be pretty nice though.  Ideally, if region crossings could
become seamless, anything that relies on being in a particular region
could instead be changed into range based, region size wouldn't be
nearly as much of an issue.  Personally, I think LL should stray away
from selling real estate by the square meter and instead sell by the
prim.


More information about the SLDev mailing list