Comments on generality of geometries

The current setup in SL (strictly Euclidean geometry) is very restrictive, and in the interests of allowing as much generality in protocols as possible, here are some possibilities:

Euclidean with different connectivity

• At most basic, as in the current SL, except that sims can be connected in other than a Euclidean grid pattern
  • Already some issues here, any scripts using llGetRegionCorner to calculate distances across sims will get wrong answers. If sims are allowed to have "rotated" connections, e.g. the North side of some sim connects to the East side of another, then this gets worse.
• Next, connections as in Portal (by Valve)
  • Apart from the difficulty of simulating such things (which Portal does seem to do pretty well), here we have different coordinate systems interfacing within one sim. If a script asks for llGetPos, which is the right coordinate system in which to give it?
  • Gravity may not always point in the direction of the negative z axis. This goes beyond scripting issues, e.g. flexi objects should know which way to droop. See also Super Mario Galaxy.
• Next, The Room (by Lionhead), particularly starting around 6:45 demonstrates portals which also alter the scale of objects that go through them.
  • Again, I'm betting this kind of thing would break if assumptions are not set up generally enough.

Non Euclidean

• • Hyperbolic Maze Demo (scroll down a bit) by Bernie Freidin, is a demo of moving around in (2 dimensional) hyperbolic space. Includes source code on the page.
    • Representations of position are (as far as I know) best done using a different system than for Euclidean geometries. Routines for translation and rotation are done differently from in Euclidean space, it's hard to see how any script that deals with geometry would be very happy with this, if it wasn't written with this in mind.
  • Curved Spaces by Jeff Weeks (source code is there too), lets you fly through manifolds with Euclidean, hyperbolic and spherical geometries. Again, the internal representation of positions in geometries other than Euclidean works differently.

Other dimensions

• 2d: There already exist many 2d virtual worlds.
  • This might not be too hard, if the physics engine just tells any 3 dimensional object that its z-coordinate is always 0.
• 0d: IRC can be seen as a meeting space with no geometrical information at all.
  • Presumably all that is needed is a way to turn off any (parts of) scripts that use geometry.
• 4d: 4D Maze Game by John McIntosh.
  • Everything will break.

These are some kinds of geometries we would like to be able to support.

This is of course a huge amount of generality. It would be unrealistic to imagine that a system could be set up such that a script written for vanilla 3d Euclidean geometry would work unchanged in a hyperbolic world. However, there might be ways to mitigate things.

One suggestion: for many purposes it might be sufficient to give a script information in a local frame of reference around the object it is in. If all that is needed is direction data, or small scale effects, then this would be roughly sufficient, likely in any 3 dimensional geometry.