Comments on generality of geometries
The current setup in SL (strictly Euclidean geometry) is very restrictive. In the interests of allowing as much generality in protocols as possible, here are some possibilities for types of space to support. These are worth thinking about both for extending the variety of spaces an avatar can inhabit, but also in interfacing with clients or systems with lower power capabilities than the kinds of machines that currently run Second Life. For instance, should one be able to login an avatar that is naturally 3d to talk to avatars in a 2d world? What if someone on a low power machine (a cell phone, or a OLPC type machine) wants to login to a high powered 3d graphical world?
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.
- Many assumptions could break if things are not set up in enough generality.
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.
- 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.
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 for instance.
- 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/clients 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/client/physics engine 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 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.