Coordinate Confusion

Hi,

I am getting into such a mental muddle with coordinates, I hope someone can blow the clouds away.

My understanding of the layout of a sim, and the vector coordinates used, is this (but please, please, correct me if I am wrong):

a) A sim is 256m x 256m, = 65,536sqm

b) The reference point in a sim is the SW corner, which has a vector coordinate of <0, 0, 0>

c) If the above are true, then regional coordinates (in 2D only) should go from <0,0> to <256, 256>

Then why does The Knowledge Base ( http://secondlife.com/knowledgebase/article.php?id=288) say:

"The grid has a resolution of 1m in each direction, resulting in 256x256 grid points (0 to 255) per Simulator."??

Surely this should say "257 x 257 grid points, (0 to 256 inclusive) per Simulator"
After all, if you take a simpler grid of 2m x 2m, that would result in 4 squares of 1sqm each, and have coords that go <0,0>, <0,1>, <0,2> in the x-axis, and <0,0>, <1,0>, <1,1> in the y-axis, ie.e 3x3 grid points.

As the same article then speaks of a resolution of 1sqm = 1 pixel, then I get more confused, because it appears to be comparing area (sqm) with points <0,0>.

If you want to look at the height of a every 1 sqm in a sim, surely that can only be done in the middle of the 1sqm. If we go back to the 2x2 grid, there should only be four heights to be measured, but where to measure them?? Instinct tells me to measure in the middle of each square, ie at points <0.5,0.5>, <1.5, 0.5>, <0.5, 1.5>, <1.5, 1.5>, because if I measure using grid points I would end up with 9 measurements, instead of 4.

I also read somewhere (but as luck would have it I cannot for the life of me find it now) that the height of sim borders are equal, i.e that SimLeft's eastern edge was the same height as SimRight's western edge, as they were sharing the same coord in effect. This also troubles me, as who then decides the height of the boundary?

Ohhhhhhhh, help me please

Welcome to geek world sims are 256 m by 256 but numbering of each part runs 0 thru 255. its a coding thing. Part (0,0) exists. numbering 0 thru 256 would give you 257 coords in total.

But 257 is exactly what I would expect. If I have a small grid of 2m x 2m I would have 3 coords, numbered 0, 1, 2, not 2 coords. For all squares (n) you need (n+1) sides to bind them in each plane. So 1 square needs 2 sides in each plane, NOT 1 side. 256 squares need 257 sides in each plane to bind them, NOT 256 sides. To get 257 sides, you need coords that are numbered 0-256 (257 in total), but 0-255 can only bind 255 squares.

I think I am right, but I stand to be corrected.

This is kind of a grey area in my understanding, as well. I'm pretty sure I tested once, and coordinate positions in a region go from 0-256.999 in the X and Y axes. That doesn't jive so well with the fact that RAW terrain files are only 256x256, not 257x257. And, in fact, when my friend and I applied a raw terrain file recently, there's a 1m strip along two of the sim borders that's at 0 elevation! Things get even more confusing because, when a sim's got a neighbor, one set of gridpoints is shared with the neighbor along the edge.

Maybe someone should do some in-depth research and really catalog precisely what's going on.

Actually (255,255) is not the exact coordinate of the NE corner, but the SW corner of the square meter in the NE corner. The coord of the square centimeter in the NE corner would be (255.99, 255.99). The coord of the square millimeter in the NE corner would be (255.999, 255.999).

If there was a coord for the inaccessible point in the NE corner, it would be (256, 256), but there is no such point in the world. The world "approaches" that point. Mathematically speaking, this is the interval "[0, 256)". That is, inclusive of the zero, but exclusive of the 256.

As mentioned above, welcome to nerd-dome, where precision matters.

HTH
Jeff

[Edit] Lex asserts that the (256,256) point actually does exist and is shared with the neighbor sim. I wonder what testable consequences this assertion would have. I would assume that (256,256) does NOT exist in this sim, any more than (300,300) does. There is no need for sims to share points from an abstract viewpoint. Whether they do in practice is another matter entirely.

a simple test would be to use two sensors, one in each sim, have your object set at the 256,256 mark with an avatar sitting on it (this way the avatar is at exactly that location) and see which sim each sensor detects the avatar in (I think this is possible with a sensor). if the coordinate is shared I would speculate that both sensors would return that the avatar's location to be in the same sim as the sensor's location; Sensor is sim A says the avatar is in sim A. sensor in sim B says the avatar is in sim B. I don't have an opportunity to log in and check this though.

Interesting suggestion, Senuka.

BTW, the adjective form of "necrophilia" is "necrophilic", not "necrophiliac", and the comma should be a semicolon. I'll assume these are forgivable typos, of course.

The Wiki is not clear either. Nowhere does it mention what the upper limits are for region coordinates. Example code given does use coords of 256,256, and then they say this:

Now to complicate things. Say you want to move a prim from one sim into another sim that is diagonal from it. An example situation would be calling llSetPos(<257,257,50>; from <254,254,50>. Your prim will first transfer into the sim on the x axis of the move and then into the sim on the y axis. If there is no sim on the x axis your prim will go offworld. So if you move a prim from Tan to Kissling it will go off world. But if you move a prim from Kissling to Tan it won't. -BW

This seems to suggest that intersim movement can be achieved without the use of global coordinates, by simply not stopping at 256.

As anyone tried to move an object to coords greater than 256,256? Is an error produced?

I also see that the terragen terrain program, which produces heightfields which can be imported into Bailiwick, informs you that if you set the terrain size to 256m by 256 m, you are using 257 grid points in each axis, which is exactly what we both figured.

Still cannot figure that if the 257 (East-side) coordinate in one sim is the same as the 0 (West-side) coordinate in the sim to its right, then who gets to set the height there?

Duely noted.



I have, and it does not produce an error. using an llMoveToTarget based AI that randomly autonavigates the grid while avoiding no-script land, it will rez a probe the next sim over feeding coordinates such as <-1,165,54> or <54,259,72> and have the probe report land status back to the AI

As any 2D coordinate or vector is a point, not an area, how does llGround() do its work? If I wanted the 1sqm starting from 0,0 to be 10m high, what vector should be given to llGround()? 0,0? 0.5, 0.5? 1,1? Any value from 0-0.99999, 0-0.99999?

Sorry, of course I meant llModifyland() not llGround()

The grid is a set of 256 x 256 height points starting from SW at 0,0 and finishing at 255, 255 NE. The final meter going N and going E meet the void sea at 20 m or the next sim.
We asked LL (when Linden Answers was still active) how the interpolation worked but did not get any real answers. I suspect that those who programmed this have moved on or have forgotten how this works. Since this must be calculated on the client, the answer can now be gained by examining the open source client. When I get the time I'll start examining, but I don't expect that to be a quick process. Hopefully, people smarter than me will dig out the real situation.

llModifyLand does not quite behave the way it is advertised. Sure, you can specify a 2 x 2 M shovel, and you can use that shovel to raise a 2 x 2 area by 20 cM per call, but the surrounding 2 x 2 squares are also raised by a smaller amount, about 10 cm, and the squares further out are also affected, albeit by a still smaller amount. I have not investigated what happens if you change the focus of llModifyLand by less than a meter, but I suspect it would have no effect.

let's look at a smaller number, let's say a 4x4 grid.



Technically.. if a square "owns" it's SW corner coordinate, then it cannot "own" the NE corner coordinate. If a prim was placed at 0,0, it would exist in square "<0,0>". if a prim were placed at coordinate 1,1, then it would be "in" grid square "<1,1>" It is therefore safe to assume that the actual bounding box of grid square <0,0> is in fact:

0,0
0,0.99999999
0.99999999, 0
0.99999999,0.99999999

that may not seem terribly intuitive, but it's something to take into consideration.

Now, in our example above, out grid is really only 3.99999999 wide and 3.99999999 tall.
But the "identity" of each square, only goes up to 3.

Therefore, a grid that is 256m wide, that starts with a "SQUARE" named 0,0, can only have 255 more squares in any direction.

But <0,0> is not a square, it is a point. Which makes an interesting point in itself. If <0,0> is simply a point, of no area, then how is it possible to put a prim there (this is rhetorical, so bear with me)? Prims do have area, and there is a limit on how small can make them. But no matter how small you make a prim, providing it is a cube, sphere, or other asymetrical shape, placing it at <0,0> should make 1/4 of it appear in four different sims at the same time (in a contiguous sim area of course), shouldn't it? In the foregoing case, and in the case of a single sim, such as a private island, why isn't the prim in 4 sims simultaneously, or why doesn't it go off world? The answer is because it is the centre of the Root prim ONLY that is taken into consideration, not the full size of the prim(s). A centre point has no area, it is a point, so it can happily sit on another point, in this case, <0,0>.

So where is the prim? It can exist in all four sims simultaneously when placed at <0,0>. the answer is the coordinates that were passed to it when it was placed determine it's current location. In the case of four sims together making a larger square. The centre of this square has a point that can be referenced in any of the four squares that touch at that point. So is the prim at <256,256>, <0,256>, <256,0> or <0,0>? the answer is that physically it is sitting over all four, but in its properties you will only see the coordinates that were used to place it there to begin with.

I think a better way to think of this is to forget about the 259.999999, the coordinates of a sim run from <0,0> to <260,260>, and the sims next to it share the same boundary on all four sides. But how wide is the boundary? A boundary or side is a line, and by definition, it has no width, so all four sides can exist in harmony with those of its neighbours, with no conflict, and no ambiguity.

No, Winter, the distance along the interval [0,4) -- meaning, from 0 up to but not including 4, is exactly4. It's the same distance as the interval (0,4). That may seem nonintuitive, but it's because the difference is an infinitesimal, and infinitesimals only matter when there are an infinite number of them (and even then they can add up to zero!)

The above is using real numbers, of course. However, if we change to integers, then if we have 4 squares labeled 0, 1, 2, and 3, then the width of our territory is exactly 4 squares.

OK, now let's move up to fixed point, which is what SL is. Let's assume SL uses decimal numbers, and that locations, distances, and sizes are only specified down to the centimeter level. Then we have (in our 4-square world) the range from 0.000 to 3.999. HOWEVER, that centimeter starting at3.999[/b] still exists. So does the one at 0.000. Count them all along an edge, and you'll count 4000 of them. So clearly, the width is exactly 4 meters.

We programmers deal with this sort of stuff all the time. There's nothing fishy going on here.

I also think that the question of whether the 0 point on one sim is shared as the 256 point on the neighboring sim is insignificant. After thinking about the llSensor test, I realize that since sensors go over sim boundaries, it tells us nothing. Since we get the results in local coords, not global ones, clearly the answers would go over 255 and below zero, simply meaning that the objects are in another sim.

Finally, forget 257. A 256x256 square is not 257 squares wide, by definition. A coordinate system to represent them does not need 257 points. Some program for doing so might use an extra point to represent "past the boundary" to help with certain operations, but that doesn't prove anything. (It's not terribly unusual for programs to have arrays that are one longer than the objects they need to hold. It's never necessary but sometimes it simplifies things. I've never found the need, but I've seen perfectly good code that does this. It wastes a little memory, but when done correctly, not enough to matter.)

With a 256x256 grid, you don't need 257 points to identify the squares in the grid. If you WANT a way to specify "just past the end of the grid", you CAN use 257, and you can also use -1.

Whether you need the 257th point depends on the program designer's choices for the user interface. If all intervals (ranges) are specified as first coord inclusive, last coord exclusive (like ranges in Python), then you DO need the 257th coord. That is, the only way to specify the range of the rightmost two squares in a row would be [255,257). Meaning, starting with 255, and up to but not including 257.

Note that this user interface choice has NOTHING to do with the underlying world. It's just a choice on how you specify a range. The designer could have chosen to specify ranges as both ends inclusive, like ranges in LSL's list functions. In this case, the range specifying the rightmost two squares in a row would be [255,256].

Some folks like the first form because you can find the length of the range by subtracting the end from the beginning. With the second form, you have to add one. I prefer the second form, though, because (a) it's more intuitive, and (b) I keep having to add one to the end range in my Python lists, far more often than I would have to add one when calculating the length. But that's just a preference; either system is perfectly capable.

So, let's just forget 257, it's a red herring. With the possible exception of folks using the terraforming tool and needing to calculate and endpoint -- but I would assum you select the squares via the GUI, in which case you don't care how the interval is represented internally.

Rock, <0,0> can be used to identify either a point and a square. Yes, it identifies a point. It also, for certain purposes, identifies the square meter whose SW corner is at that point. That doesn't detract from the point you're trying to make (no pun intended).

The rest of your text is correct except for one minor issue. Each object is a child of exactly ONE sim, and possibly a remote child of neighboring sims. (I'm using the wrong terms here, can't remember the exact LL terminology.) My guess is if you moved an object to <256,256>, it would be a child of the sim to the NE, sitting at <0,0>. All the prims would be children of this sim, and remote children of the 3 neighboring sims.

Not that any of this really matters to users of the world. Not even to LSL programmers, or builders.

How many angels can dance on the tip of a 1-prim needle?

If you've ever been pushed or done a bad tp you may have noticed that the x and y coordinates at the top of the screen go well beyond the 0/255 imits, Ive seen it go in bot dimensions. I guess the sim is stretching its reach without passing on to the next sim.

Also, there is supposed to be a 10 M area either side of the sim boundary where objects are registered in both sims, making it easier to do the actual crossing and also requiring prims to be less than 10 m in any direction (I think).

Actually, no it can't. As far as those other 3 sims are concerned, that prim doesn't exist. It appears to "exist" in them only because it is drawn over their territory. Put a 10x10 non-phantom box at < 0, 0, x > in a sim which borders 3 others on it's west and south sides. You will collide with it in the northwest sim, but walk right through it in the other 3.


I think that's just the client continuing the agent's last-known velocity until it receives a "corrected" position and velocity from the new sim. As I understand it, some things, like av movement, aren't purely run on the sim, because that would require the client to get an updated position for every frame drawn on your screen, which would use way too much bandwidth, be very un-smooth, or likely both. The client will simulate movement itself, but update that info if it receives something different from the sim. This is why walking under heavy lag will "stutter." You'll start moving, which the client does on it's own to some extent, then it will get a position update from the sim, which hasn't caught up with what you were doing yet, and you end up "snapping" to another position, like somewhere between your starting postion and where you thought you'd reached.

I get something similar when building if I have something running in the background which uses a lot of bandwidth. I'll change a texture or prim property, and while the update is made in the client, that update might not reach the sim as expected. So, a few seconds later, the sim sends an update which "undoes" the change I just made. Very annoying.