[sldev] Sim Size Limits?

[Kent Quirk (Q Linden)]

While all the features you suggest might be nice in a clean-slate  
environment, there are some assumptions that are baked in rather  
deeply to Second Life. One of them is that the world is flat. I agree  
that there are valid use cases for it to be otherwise -- but they're  
not anything we will achieve anytime soon. In Second Life, a sim has  
two coordinates, not three, and there's no reasonably foreseeable  
future that will add a third coordinate. Nor, as Doug implies, are we  
likely to change the 256x256 sim size because of the far-reaching  
effects of such a change, both internally and externally.

I'm sorry, but this is one of those "Won't Finish" sorts of issues.

	Q


On Oct 30, 2008, at 10:52 PM, Ricky wrote:

> 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
>
> _______________________________________________
> 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/20081031/7d4f789e/attachment-0001.htm