How to arrange faces of a quad sphere to simplify neighbour lookup? - graphics

Question

I'm working on a procedural planet generator that uses a quad sphere, or quadrilateralized spherical cube, to represent its surface.
Most authors seem to number and arrange the faces arbitrarily, and so did I. For example, this is the arrangement that Wikipedia shows for cube maps (apparently the Direct3D convention, although Wikipedia presents it as "the way" without mentioning the zillion alternatives):
But this leads to an issue when you want to know the neighbours of a given pixel, for example for normal mapping, or all sorts of simulations. Given a triple (face, u, v) that identifies a pixel (where u and v are integer indices, not texture coordinates), the task is to find the four triples that identify its four neighbours.
In the face interior, this is easy. But on the edges, you have to take 24 cases of wrapping into account: 6 cube faces × 4 edges per face. In pseudo-C:
Index neighbor(idx: Index, direction: Direction) -> Index {
switch (direction) {
case UP: if (idx.v < SIZE - 1) {
return Index { face: idx.face, u: idx.u, v: idx.v + 1 };
} else {
switch (face) {
case 0: return Index { face: 2, u: SIZE - 1, v: u };
// And so on for the other five faces
}
}
// And so on for the other three directions
}
}
It's tedious and error-prone, and the branching makes it potentially slower than needed.
Then I found the 2007 SIGGRAPH sketch Creating Spherical Worlds (sap_0251) by Compton et al., which mentions:
Further, by choosing face mappings to be permutations of the corresponding axes, it is possible to formulate efficient algorithms for wrapping between faces, and projecting a 3D point into a chart.
This tantalizing sentence is all we get; there's no further explanation, and I can't find any follow-up articles by these authors either.
How can we choose the face mapping to allow for efficient wrapping?

Answer 1

UPDATE
Adding a separate answer because of the difference in approach.
(This answer assumes that the UV coordinates are per-face in the range 0..<SIZE, with SIZE being constant for all faces.)
I can't think of a good way of efficiently computing the the neighbouring (face, u, v) across the boundaries for arbitrary cuboid mappings, but it should be relatively easy to just store a mapping of it for each face. For each face, store four mappings, one for each primary direction in UV space (i.e, +U, -U, +V, -V). Each of these mappings should contain a reference to the next face in that direction along with mapping coefficients for transform (u0, v0) -> (u1, v1).
For the example mapping above, face 2 (the top one) would have the following mappings:
up:
faceID: 5
u: SIZE-u
v: SIZE-1
down:
faceID: 4
u: u
v: SIZE-1
left:
faceID: 1
u: SIZE-v
v: SIZE-1
right:
faceID: 0
u: v
v: SIZE-1
When doing a neighbour lookup, check if the lookup falls outside the dimensions (0..<SIZE) and if it does, use the lookup structure defined above. So if you're looking up the next position along the U dimension on the boundary of face 2, just check the mapping for 'right': face 0, with a u value equal to the original v value, and a v value equal to SIZE-1.
You will need some method for precomputing this data when creating the geometry.
OLD ANSWER
Assuming the following:
This is for doing texture lookups.
You have control over the way textures are generated.
Then I propose an alternate solution.
Instead of finding an efficient way of mapping the neighbour relationship across the discontinuity, simply make the texel value outside the UV map region the same as the value in its corresponding neighbour polygon.

Answer 2

After some quality time with pencil and paper, I figured out a reasonably elegant way to do this. We still need to distinguish between even and odd faces, but that can be done with a modulo operation (compiled down to a bitwise AND), so it doesn't need branching.
The arrangement is as follows:
The mapping of global axes to local axes:
u v normal
+X +Y +Z
-X +Z +Y
-Y -Z +X
+Y +X -Z
+Z -X -Y
-Z -Y -X
Each global axis is used once in each column, so this is indeed a permutation. Whether it's the same one that the Spore developers designed, remains an open question.
There are certain rules now, for example, moving UP from face f,
if f is even (0, 2, 4), we always find face (f + 1) % 6 (1, 3, 5),
if f is odd (1, 3, 5), we always find face (f + 5) % 6 (0, 2, 4).
So the neighbour lookup becomes much simpler:
Index neighbor(idx: Index, direction: Direction) -> Index {
switch (direction) {
case UP: if (idx.v < SIZE - 1) {
return Index { face: idx.face, u: idx.u, v: idx.v + 1 };
} else {
return Index { face: (face + 1 + 4 * (face % 2)) % 6, u: SIZE - 1 - u, v: SIZE - 1 }
}
// And similar for the other three directions
}
}
There might still be room for improvement, so better answers are quite welcome!