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 <[EMAIL PROTECTED]> 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
