[sldev] Sim Size Limits?

SignpostMarv Martin me at signpostmarv.name
Wed Oct 29 16:01:42 PDT 2008


I've given thought to this issue recently:

1) Resource usage-
Making more resources available to fewer instances of the sim code, say
1 or 2 regions running on the same hardware that runs four (class 5/6
uses quad core, right ?). This I assume would be as complex as making
more instances run in the same resources- likely still complex, though
it's probably easier to implement as keeping the region dimensions the
same but improving the capabilities.

2) Sim arrangement-
Given that the Grid is currently only available to be arranged in a
2-dimensional grid, sim blocks would likely have to be in collections of
powers of 2, or at least square (you can just imagine people literally
playing tetris with regions here).

3) Co-ordinate addressing-
The current system relies on integers for grid co-ordinates and though
the function llGetRegionCorner() returns a vector, the values are
practically integers also.
As long as the dimensions of a region were multiples of 256, existing
LSL code based on this function would not break. What would break
however, is any code that calculates grid offsets, as well as any
practical conversational references.
As for object movement code that relies on a 256x256 dimension, I'm not
sure how many there are (with the exception of inter-sim warpPos
teleporters) that make such calculations, since CHANGED_REGION would
still fire correctly.
Be thankful region co-ordinates are specified by the ZERO_VECTOR corner,
and not the center of the sim (else you'd have to have the system
altered to use floats to specify the region position)

4) Increased network traffic-
With a fixed 256x256 limit, sims typically only communicate with the
horizontally and vertically adjacent sims. With a 512x512 sim size,
you'd either have two options:
a) restrict neighbouring sims to identically sized-regions only
b) have to deal with the issue of network traffic increasing with each
multiple of 256 (1 = 4 sims, 2 = 8 sims, 3 = 12 sims, etc)

5) Physics-
People have a hard enough time crossing region borders in vehicles as it
is. I'm sure that should multiple region dimensions be allowed to
co-exist as neighbours, there would be issues occurring that would
result in objects appearing to travel into the wrong sim.


Where I think the issue of multiple region dimensions co-existing might
be addressed is via Region domain, e.g. if it were possible for multiple
regions to be logically addressed as a single region- either for
purposes of load balancing, or for the purposes of increasing region
dimensions. This is analogous to RAID, where at the simplest levels-
RAID 0 and RAID 1, where a RAID 0 type setup would be to produce larger
logical regions, and a RAID 1 setup would be to provide an apparent
increase in resources (higher prim limits, agent capacity etc.).

Arbitrarily allowing a single region to have flexible dimensions
(regardless of whether it's multiples of 256, or a true floating scale)
would be too messy in my opinion- a RAID-like load balancing/splitting
system would sort of solve the increase network traffic issue, as each
of the child Region domains would likely handle the adjoining regions in
the same manner that contemporary regions do, and it would also perhaps
allow for more creative region shapes (e.g. tetrominoes ).


~ Marv.

Ambrosia wrote:
> Well, I presume the number is inspired by the maximum 8bit value :>
>
> That and it's what they started out as, and by now that number is used
> in lots of parts of the viewer code, the sim code, and LSL scripts all
> over the grid. Changing the size now would have to be a very careful
> process, given that all products that check for certain coordinates
> are probably not made to handle anything above 256m.
>
> Just think about it, any product that
>
> On Wed, Oct 29, 2008 at 19:45, Bruce Tong <tongb at ohio.edu> wrote:
>   
>> Just out of curiosity, why are sims always 256m x 256m in size? Is the
>> system running into an issue like a maximum floating point value? Does
>> it have to do with resources used to model the terrain? I wonder if
>> "open space" might be a matter addressed by just letting people define
>> private regions to be larger without getting more prims.
>>
>> Mind you, I still think the issue raging is more a matter of built up
>> demand for inexpensive, small, private sims. That customer demand
>> eventually translates into technical requirements, of course, that are
>> different from providing "open space."
>>
>> --
>> Bruce Tong
>> Software Engineer
>> Office of Information Technology
>> Ohio University
>> _______________________________________________
>> 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3244 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081029/32b3d7d6/smime-0001.bin


More information about the SLDev mailing list