Technical Explanation of New Round Voxel Planet Mapping Scheme in SoA

Yes definitely! The transitions in the video are brand new and quite rough, and there is a lot of room for tweaking and fine tuning. A camera shake with blur and maybe a flame effect would be excellent for further hiding the shift, probably to the point to where casual users will never notice it.

Yup I have indeed seen starmade and it is a big inspiration for how we want to do ship building, though we want to make ours more realistic and difficult.

The reason Starmade's dodecahedron planets work for them is because they are small enough that they can all be loaded into memory at once. In games like SoA or Minecraft, where the planet is incredibly large, we need the ability to page voxels in 32 x 32 x 32 cubic clusters called "Chunks". As you can see by the shape of a dodecahedron face, this would be difficult to implement for a dodecahedron, though probably not impossible with special case logic at the edges. Not to mention it has the same problem of three faces connecting at a corner, except even more so than a cube. Also, if you tried something like loading each face with as separate voxel grid and transitioning seamlessly between them without a fade transition, the cubic voxels wouldn't line up right at all.

A cylinder is a viable option if you don't care about the poles. When you say cylinder, you are probably talking about one of two cases.

1. A hollow cylinder, with a single face. The problem with this is that as you go north or south toward the poles, distortion increases for the same reason you get distortion at the edges of cube faces on the cube approach, except its MUCH more drastic, to the point of basically infinite distortion at the poles.

2. An actual cylinder with 3 faces. At first glance this seems like a much better solution, but two of the cylinder faces are circles, and mapping cubes to a circle is just as geometrically impossible as mapping it to a sphere. That said, if you did the same fading transition that we do now when going between faces you could probably still make it work, though you would have to rotate the voxel local camera since the grids aren't aligned. I would like to see a mockup of this! Maybe I will play with it if I get the time, though I am still happy with the cube solution.

Edit: forgot to answer this:

Also, you might have hinted at this before, but why can't you move the geometry with respect to the texture from far away? you would always have it consistent with what you see on the ground coming in that way.

I'm not sure exactly what you mean here but I think this is exactly what we are doing with the shader that distorts the far terrain to line up with the voxels.

Sounds like they are using the advantages of an icosphere but going low-res by choosing a dodecahedron as a dual graph. But that would create issues around the edges as stated by DubstepCoder. BUT this wouldn't be a huge problem if your voxels were triangular/tetrahedra in shape, then your icosphere can be as round it you want, and have edges coherent with the voxel layout with no distortion. Has anyone attempted a tetrahedron voxel engine? (I'm guessing not, due to its packing problems) That would be interesting to see.

Not to be rude but you explained this in a very jargon filled convoluted way.

and rendering the final induced "voxel" (polytope: generalized convex 3d object)

This is jargon to an unintelligible level. When you use uncommon field specific nomenclature you end up creating the "translator effect" in which the individual has to translate what you said, instead of actually read it. The processes are different where reading lends itself to be remembered and be understood, translating in this case requires constructing in your own mind what you think the other person meant in words of your own, remembering those translations for that sentence, and then attempting to read the sentence over and over until it is possible to "read" the sentence, however this often isn't 100% possible depending on how many mistakes you make with the jargon (in terms of grammar and syntax) that you attempt to use.

Unfortunately you didn't just use words that had to be looked up, you put them in an order such that it was hard to derive what you were actually trying to say. Lets go back to that part of the first sentence I was looking at.

Perhaps I don't understand game-development very well, but it seems that just using an finite-element-method (FEM) and rendering the final induced "voxel" (polytope: generalized convex 3d object)

Here is what I assume you mean.

Perhaps I don't understand game-development very well, but it seems that just using an finite-element-method (FEM) and rendering the final voxel as some sort of convex 3D polygon, or polytope would be far easier than this stuff.

Here are some other hard to understand/mis-use of jargon

some crystallographic tiling of the volume

If you look up the term crystallographic it does not exist in the form that you are using it. What I assume you meant is

some 3D polytope tiling of the volume (the planet you are trying to make)

however, all crys tilings are necessarily P1, at their limit (nothing but 'cubes', if you will).

P1 is ambiguous, it looks like you say the description of the "type" of P1 (the description of the thing it represents, IE red, hard, flat etc) but you never actually qualify what that "type" is. Additionally you use "instead" in the next sentence but you don't actually lead into that "instead" in this sentence

however a problem is that all 3D polytope tiles become P1, a polytope that you determine, at their limit (in this example it would be cubes).

Instead, you could just consider the "centroid" of the volume to be the 'voxel', then fill the voxels into the volume you're creating

I have this feeling you are not using centroid correctly here, as it makes no sense no matter how I wrap my head around it, regardless the way you are trying to communicate the idea is flawed in some manner. A centroid is not a center, it is the average of all points in an object, saying "the centroid of the volume to be the voxel" makes no sense, it defines no position of the centroid. It is especially convoluted when you try to say "then fill the voxels into the volume you're creating" this is incredibly hard not to treat as nonsequitr. From having to read ahead, this is what I assume you meant.

To solve this problem, you could just consider the "centroid" of any given volume to be the 'voxel' in itself, then fill these voxels into the planet volume you're creating

Gravity and, thus, the principle normal surface, is always away from the centroid of the average of the centroids making up the volume.

Principal Unit Normal Vector, is that what you mean?

Gravity and thus the principal unit normal vector always point away from the centriod of the volume, which in our case is also the average of the centroids of the voxels making up our planet.

The only part I'm not certain about is if splitting the centroids into polytopes can be done 'without seams' both performantly and stabily.

No, a centroid cannot be described or used in such a way, a centroid can't be split up into polytypes the same way you can't split democracy up into fish and 74, it just doesn't make sense and is not covered under the definition of the concept. Here I will describe a problem that these kinds of mistakes make when any body reads this.

The only part I'm not certain about in using FEM for this is if

Divergent interpretation, a huge problem in comprehension and will result in multiple interpretations, none of which are necessarily right or similar to each other.

splitting the voxels up into connecting surfaces can be done with out seams in a consistent and optimized fashion

Or

making all the centroids of the voxels into polytypes can be done with out visible seams in a consistent and optimized fashion.

Now note, none of these interpretations are what I claim to be correct, you decide that, nor do I think these are necessarily the most obvious, nor the only interpretations, nor the only interpretations I could make, just that what you wanted to say cannot be interpreted, or is hard to extract from this.

What you've said is very hard to understand, not because of the subject matter but because of how you said it.

The only part I'm not certain about is if splitting the centroids into polytopes can be done 'without seams' both performantly and stabily.

The generic answer to that are Voronoi diagrams. You won't get cubes (not even "cubes" in all cases), but you're free to do whatever sphere sampling you like: any solution to the Thomson problem, random Poisson disc sampling, NASA's HEALPix, or just continue with the distorted cube if you like.

Disclaimer: I really don't know anything about FEM other than what I just googled, so correct me if I am horribly wrong.

The reason we can't use this is because we want to accurately persist data between sessions. Given a certain point on the sphere, I need to know exactly which voxel exists at that point, and given a certain voxel, I need to know exactly where it is on a grid in order to correctly persist it. Otherwise when you blow holes in the ground or build a house, when you circle the planet or log out, it might not be there when you get back.

Either that, or your voxels won't be cubes, and we want cubes!

This is roughly akin to what the Red Faction series did under the hood. There was even a technical interview in which one of the devs explained that this idea was the inspiration for the Geo-Mod engine they developed for this game series.

http://www.eurogamer.net/articles/digitalfoundry-red-faction-tech-part-two-interview

"But as with many things in game development, our physical model is a very rough approximation of reality. Civil engineers use something called matrix finite-element analysis to examine the true forces acting on a complex structure." ... "So, we came up with some approximations that don't look much like the real thing under the hood."

I've never understood why more voxel-based games don't use this kind of mechanism to build round planets, since it would clearly solve a lot of the issues surrounding the problems of trying to map cube-based voxel maps to a round planet.

Yeah the corner distortion basically makes the game unplayable over a large portion of the world :(

The infinite planar world with wraparound is basically a torus world, which I talk about in the video. The problem with that is it doesn't realistically map to an actual planet. You can't have two poles without also having two equators (which makes no sense) and figuring out the space-space position from the grid-space position is also really weird and doesn't make much sense. If you want to see a torus world in action, Untold Universe uses one.

It sure is! I should have specified that my method is specifically for cubic voxels.

However, with this the isosurface extraction method I think there might be some issues with directional artifacts which may or may not be a big deal, since the "up" of the player is often not perpendicular or parallel to the "up" of the voxel grid. Maybe that's why No Man's Sky doesn't do it that way, or maybe they do but they do the transition for an LOD reason. I wish No Man's Sky would just make a blog about it.

Thanks!

It's pretty damn weird! Right now, each face is a separate coordinate space that is infinite in the Y direction. Because of this, some interesting things happen.

1. The deeper you go, the ratio of voxel-space movement to world-space movement decreases, until you pass through the center, then it begins to increase. At the core of the world, you could walk for hundreds of miles on the voxel terrain, but your actual world space position wouldn't change at all. When you get higher, the opposite happens, causing a sort of sliding effect between the terrain and the voxels, since the positions are not changing at equal rate. Luckily, with the scale of our planets, even on the highest mountains you won't notice the sliding.

2. Once you cross the core, the direction of your space-space movement reverses, while your voxel-space movement stays the same.

3. Since it's infinite in the Y direction, you can dig down forever. Meaning, through the world and out the other side! You can keep tunneling beyond the other side of the planet. It's weird.

Luckily, our constraints make none of this a problem.

• Once the player is a certain height in the atmosphere, disconnect him from the voxel grid completely and make him a space object.

• Don't allow players to go deeper than N meters. We'll probably limit the player after the mantle by a wall lava and high pressure that will kill you if you venture beyond.

Edit: Terrible formatting