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