gamedev reportback: polyhedra coordinates
so i wanted to take a break from rendering stuff for a while and work on something more theoretical, and decided to try polyhedra coordinates
the goal is to eventually get polyhedra coordinates working with my graph generator, so that instead of making flat 2d maps i can wrap them around the surface of a planet, and use a different set of graph expansions to simulate (in a super rough and simplified way) some geological processes that will end up generating an entire planetary map
that being said, this two week chunk of time did not accomplish that. i have a good idea of where i went wrong and how to fix it, but, out of time so i'm gonna stop working on it for the time being.
(the thing with coordinates on spheres, or polyhedra generally, is that there's curvature. this comes with two general classes of complications: one, the math can't be everywhere-the-same in the way a flat square grid is always going to be
i had this whole idea of using a winged-edge data structure (which i've been using for all those polyhedra renders) for tracking the structure of a world, and mixing coordinate math with graph-traversal code to figure out paths.
so like, specifically, i'm interested in doing coordinate math on G(n,0) goldberg polyhedra. the existing libraries i've seen do this are there are earthgen and hexasphere, and they both handle things with a giant graph: each hexagon (or pentagon) tile is a node, and the six (or five) tiles it's adjacent to are the other nodes it has edges to, and they handle all pathfinding as a pure graph-traversal problem. that's fine for small shapes, but when you get to gigantic planetary-sized ones that's like, a five million node graph you have to keep in memory to do anything. also in a graph representation, there's no real sense of direction; you can't really say "go straight" since there's not a clear way to map edges to "opposite pairs".
my idea had to do with the underlying shape: all G(n,0) polyhedra are fundamentally shaped like dodecahedra/icosahedra (they're duals so it's kind of the same shape). that means that no matter how big the polyhedra gets, it'll still be topologically the same; there will just be more tiles there, but the fundamental shape of its distance metric won't change. so instead of storing a million-part graph, you can just store an icosahedron graph, and that's actually enough.
all that theory still seems sound, it's just when i got into the actual nitty-gritty coordinate math i ended up doing some math wrong and got impatient and kind of lost the thread and ended up with a mess that didn't come close to working. so that's a little disappointing, but, oh well, it's all just practice for the time when i actually get it right.
the goal is to eventually get polyhedra coordinates working with my graph generator, so that instead of making flat 2d maps i can wrap them around the surface of a planet, and use a different set of graph expansions to simulate (in a super rough and simplified way) some geological processes that will end up generating an entire planetary map
that being said, this two week chunk of time did not accomplish that. i have a good idea of where i went wrong and how to fix it, but, out of time so i'm gonna stop working on it for the time being.
(the thing with coordinates on spheres, or polyhedra generally, is that there's curvature. this comes with two general classes of complications: one, the math can't be everywhere-the-same in the way a flat square grid is always going to be
x±1, y±1 for adjacent tiles, everywhere, since due to the nature of a coordinate system the distortion gets pushed around so that it's more present at some locations than others; and two, since the polyhedra wraps around, there's the question of what that looks like in the coordinate system. a wraparound square grid is like a torus, in that you can just say "left and right edges connect; top and bottom edges connect", which leads to some very simple math like if x < 0, x + x_max; if x >= x_max, x - x_max to perform the wraparound. on a polyhedra things like orientation come into play, where directions don't mean the same thing after crossing an edge.)i had this whole idea of using a winged-edge data structure (which i've been using for all those polyhedra renders) for tracking the structure of a world, and mixing coordinate math with graph-traversal code to figure out paths.
so like, specifically, i'm interested in doing coordinate math on G(n,0) goldberg polyhedra. the existing libraries i've seen do this are there are earthgen and hexasphere, and they both handle things with a giant graph: each hexagon (or pentagon) tile is a node, and the six (or five) tiles it's adjacent to are the other nodes it has edges to, and they handle all pathfinding as a pure graph-traversal problem. that's fine for small shapes, but when you get to gigantic planetary-sized ones that's like, a five million node graph you have to keep in memory to do anything. also in a graph representation, there's no real sense of direction; you can't really say "go straight" since there's not a clear way to map edges to "opposite pairs".
my idea had to do with the underlying shape: all G(n,0) polyhedra are fundamentally shaped like dodecahedra/icosahedra (they're duals so it's kind of the same shape). that means that no matter how big the polyhedra gets, it'll still be topologically the same; there will just be more tiles there, but the fundamental shape of its distance metric won't change. so instead of storing a million-part graph, you can just store an icosahedron graph, and that's actually enough.
all that theory still seems sound, it's just when i got into the actual nitty-gritty coordinate math i ended up doing some math wrong and got impatient and kind of lost the thread and ended up with a mess that didn't come close to working. so that's a little disappointing, but, oh well, it's all just practice for the time when i actually get it right.
