[sldev] Sim Size Limits?

[Ricky]

Getting a function defined that returns the size of the simulator would make
any future transition a little easier.  Also note that code (read: server,
client, and script code,) should not assume that simulators are always going
to have their Z0 matched to the world's Z0.  In the future it would be
really nice to have different sized sims, and even stacked sims.  A use case
for stacked sims is underground, aboveground, high-altitude, and "space"
sims.

On a side note, physics for a space sim might be made easier making the sim
capable of being larger without hurting the physics engine.  Simply reduce
prim-level collisions to only sphere-sphere collisions.  Most space sims
would be about flying craft at insane velocities... :D

Does anybody have a JIRA link for a function to request the sim size?
Ricky

On Thu, Oct 30, 2008 at 7:10 AM, Douglas Soo <doug at lindenlab.com> wrote:

> Actually, there are a few good reasons why 256 is probably a reasonable
> number, mostly relating to floating-point and fixed point precision:
>
> - 32 bit floating point gets you around 7 decimal points of precisions -
> this means that once you hit a distance of about 256 meters, you're looking
> at somewhere around millimeter to centimeter precision.  So once you go too
> much beyond 256 meters, you're going to start having precision issues when
> tightly positioning objects in the world reference frame.  Note that if we
> had been thinking further ahead at the time, we would have positioned 0,0,0
> at center of the region, and doubled our precision at the edges.
> - Until we hit the highest precision level, we will often send object
> positions in 16-bit fixed point representations (I believe).  Increasing the
> size of a region would increase the distance at which we would start having
> to send full-precision 32-bit data down to the client.  This could have some
> impact on bandwidth utilization, and possibly rezzing speed of distant
> objects.
> - The larger the area of the region, the more objects we need to support in
> order to be able to maintain a reasonable density of content across an
> entire simulator node.  I think with the 512MB initial constraint on memory
> usage at the time that we started, this was probably a reasonable number.
> - The smaller the region, the more regions an individual viewer needs to
> connect to at a certain draw distance. Since the renderer in its current
> implementation can realistically use only a 512 meter draw distance at best,
> this generally limits a viewer to talking to around half a dozen regions
> right now.  Reducing that size would cause you to have to connect to a much
> larger number of regions.  Also, as you reduce size of a region, the
> boundary zones where you have to start sharing simulation (which someday we
> will eventually do properly) increase, which means that you generate more
> edge traffic on the simulation side.
>
> This is not to say that there was necessarily a HUGE amount of conscious
> thought put into this (if there was, we would have put the origin at the
> center as mentioned above) - but 256 meters is not actually an unreasonable
> value.
>
> In any case, this is an incredibly difficult constant to change in the
> system - it would require lots of protocol changes, as well as a fairly
> major overhaul of the server side, so it's a somewhat moot discussion right
> now. :)
>
> - Doug
>
>
> On Thu, 30 Oct 2008 05:16:26 -0700, Argent Stonecutter <
> secret.argent at gmail.com> wrote:
>
>  I think it was just an arbitrary power of 2: 128 was too small and 512 was
>>> too big.
>>>
>>
>> 512 isn't too big.
>>
>> 1024 would have been about right.
>>
>> Imagine a more open, less cramped Second Life.
>>
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
>
> --
> Douglas Soo
> Engineering Director
> Linden Lab
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081030/19a46cf1/attachment.htm