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

Zha Ewry zha.ewry at gmail.com
Sat Oct 27 08:46:37 PDT 2007


For a bunch of these issues, it may be important to think about four
separate but closely related things. There's the evolution of the grid's
protocols, the evolution of the current Linden Labs code base, and the
evolution of the actual deployed SecondLife service. Finally, there's the
evolution of related things, such as the OpenSim code base, and non Linden
Labs patches to things like the SecondLife client.

These will largely move together, but when there are places where it would
be trivial to change out an assumption,  it would probably be clever to
capture that in the design, make sure the protocol and architecture support
it, and then, make equally sure that we can detect people who want to deploy
variants. To an extent, I think of this as defensive architecture.

The grid size assumption is a very good example. Its baked into tons of
code, both client and server side. Its implicit in a bunch of places, in the
protocol, in scripts, in people's heads.  Linden is going to change it only
very carefully. to make sure they don't ruin the experience of their
residents. (And, as a resident, and sometime scripter, I want them to be
very careful, than you very much ) But... Even if we don't expose these
assumptions, it would be pretty easy for someone to take the OpenSim code
change it, and patch the client to support a different grid size. If the
protocols and architecture don't have a way of specifying this, then anyone
connecting to a Region server with a different grid size assumption is going
to be in for a very rude surprise. Far better for the protocol to be able to
inform the server, "This Region Simulator supports 64x64 parcels," and have
the client say to the user "Ah, this sim uses a geometry that is unsupported
by this client, enter at your own risk"

One of the many exciting things we can do, if we are careful, is open the
greater eco-system around SecondLife to experimentation and variation. A lot
of this is going to happen, whether the protocol and design of the grid
support it or not. I'm inclined to make sure we identify the spots where it
can happen, and both allow for it to happen. More importantly, allow for it
to happen in a principled, detectable fashion, not through the ad-hoc
arrangements people will be forced to make if we don't design them in. (And,
note, given the history of such things, once the ad-hoc schemes are in use,
we're likely to end up accommodating them in code, and possibly the
protocols  anyway, so.. we gain very little by ignoring them.

- Zha

On 10/27/07, Argent Stonecutter <secret.argent at gmail.com> wrote:
>
> On 27-Oct-2007, at 04:44, Andre Roche wrote:
> > 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.
>
> That doesn't imply using a high latency interface between the physics
> engine and other components. Low latency plugins generally use shared
> libraries.
>
> > 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.
>
> The biggest problem with different sized sims are user scripts that
> have 256 hardcoded into them.
>
> They've also objected to my parcel basement idea for similar reasons:
> scripts that will freak out over negative offsets. The solution to
> THAT would be to adjust the Z of llRegionOffset by a constant (say,
> -1024) and the local Z by the corresponding offset (+1024).
>
> > 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.
>
> They do. That's what you buy when you buy land, you buy a fraction of
> the prim allocation of the server. They originally had them
> completely decoupled but that led to prim hoarding.
>
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071027/faf2dc3c/attachment.htm


More information about the SLDev mailing list