New world type: finite cubic planet

This is another new GSOC candidate that may hit a bit of a sweet spot for scope and potential. Or I might just be overly optimistic as usual :-)

Objective: Implement our first sensible (so the world doesn't just end) finite world type while making a stab at an interesting style option rather than go with the more realistic but boring sphere type planet that would be tricky (but not impossible) to achieve with blocks.

You can actually render plain old blocks in a spherical fashion, Immortius made that work in a separate project years ago and others have too I'm sure. But it leads to rendering artifacts and other quirks and doesn't really buy you anything other than some visual "huh, neat" moments for either really tiny planets or for when you travel very far away from the planet.

A cubic planet on the other hand goes with the blocky theme, can look really neat, gives you weird edges to build unusual things on, and seems like it would simplify a lot of coding. There is also precedent - see for instance Stellar Overload (Kickstarted under a different name). And I'm sure some modders already did it for MC as well :-)

Some noteworthy areas of consideration:

Gravity would need improvements, since at the moment "up" is always the same way. I don't know how big a deal that is, seems like it can conceptually be tweaked at relatively easily via physics. This would almost certainly be improved by first finalizing #3042. A cubic planet would make for a lot of interesting situations along the planet edges as well as the center
Lighting would need changes as it could suddenly come from different directions. Although maybe that's just a case of varying which side of the planet has the primary sunlight element
Chunk size might need to change. A 32x64x32 made some degree of sense when height (the 64) was picked to better optimize sunlight calculations. But when sunlight can come from different sides a perfect cubic chunk may be worth the simplicity over any performance loss. How would calculations change, especially on an edge chunk?
The user and world authors need a better way to pick the world type/shape when setting up (flat infinite, tourus, etc). Should world generators be specific to the shape, or could some world generators work for multiple shapes? Also see #2774
Some interesting potential exists around the concept of entering space around a planet. You could either allow just building forever, or enforce some sort of height limit, moving the player into a different position tracking system. If you make space a thing you could readily have multiple planets in each their own coordinate system (effectively multi-world - #3146)
- Edit: This reminds me a bit of "grid" in EVE Online. The solar systems are space, players exist on independent grids at given positions around the solar systems that grow and shrink as needed. Hmm that's almost beginning to sound a bit like Sectors ...
And if you can have multiple planets others could be made visible ... how might we simplify the visual representation of a distant planet? This could get into the desire for an improved far rendering approach #319 and lead to moving the far rendered image of a planet across the skysphere (#95 and others)

I imagine this and other world related items would be a large focus of a v3 of the engine aiming to "finalize" world architecture. Wanted to write up this piece to start the design phase :-)

Immortius approach, probably based on vertex shaders, was actually a very sensible one in my opinion, as it doesn't change anything data-side and changes very little rendering-wise - most of the rendering complexity is handled in fragment shaders, vertex shaders are currently fairly basic and are easy to modify.

Is it desirable to have a cubic world? I'd be concerned by the complexity of dealing with the edges unless we use some cheat. Mario-style gravity changes sound intriguing no matter their goal: they could be used in a dungeon, irrespective of the size or finiteness of the world. A Tesseract-like option might be easier: stepping from one face of the cube to another might still be seamlessly flat. Some problem with that are 1) what would the underground look like from the edges down to the core and 2) how to reconcile the cubic geometry with the celestial sphere - altough this should be a relatively straightforward mapping, 3) what to do with the corners of the cube, where three faces of the cube come together.

In this context I've been personally thinking more toward toruses. I'd still render them as spheres from high up and flat worlds from the ground, but data-wise, rendering-wise and geometrically they seem to be more aligned (or align-able) with a block world. That been said, we'd have to work on world generators based on spatially-repeatable noise and spatially repeatable feature generation, so that looping in either directions of the torus does not cause discontinuities.

To respond to some other points more specifically:

I wouldn't worry about lighting, that might be the least of the problems.
Chunk size is, I believe out of indexing performance concerns: 32x64x32 = 65'536 blocks, or the length of a short. I am not sure it is exclusively intended to facilitate sunlight calculations. It might just be that loading, processing and rendering a chunk indexed with integers (4 million blocks) would just be too slow on current machines.
to me the last two points you mention are quite crucial and show the way in my opinion: it'd be best to first approach the issue of how to display long distance landscape. Once we have that sorted in a generalized way, we'll be able to take off from a planet or warp near one without having to deal with the high-detail rendering we currently have. We'd see a low-res version of the planet and only when landing we'd get to see what we see now.

All that been said, I'm very much in favor of finite words, one way or another. From implementing finite resources and the constraints it generates, to simulating whole climates and biosphere, I'd rather achieve infinity with infinite planets/solar systems than with infinite land.

Is it desirable to have a cubic world?

I'd say yes, for sure, and I'm also pretty sure it has already been done in MC, which may ease our work. I remember several gravity tweaking mods that let you walk into a wall that then becomes the floor, in fact the last BTM conference center was built that way: you'd walk into a wall then up it to get to the panel room. Neat :-)

More than just focusing on the neat part instead the idea of a forced sphere rendered but still flat world just sounds ... boring? Not worth its complexity? Since you wouldn't really be able to tell up close anyway. Whereas the idea of wrapping around a world edge would add a whole other dimension (pun intended!) to building :-)

A torus is also great, gets you some of the best from both worlds, you could have finite north/south to get poles and tropics, yet make the other way infinite and keep going forever. Whether it is round or cubic is probably a secondary choice (wonder if there is a name for a cubic torus - also forgot if there is one for an infinite torus)

Good to hear about the lighting! Yeah the total blocks bit being a magic number probably also helps elsewhere. I vaguely remember it being higher to have more space to let sunlight calcs "reset" over fewer chunk layers (a sky island won't cast an everlasting shadow - but how many chunk layers do you check). Maybe 32x32x32 would still be magical enough.

I actually wrote the last two points with them being potential extras / out of scope. You could play around with gravity locally as well as at the world edges without any sort of support for space, leaving a planet, or rendering planets from far away - but it would be really cool if we also get that :-) We could look at Seed of Andromeda again for some inspiration there.

Maybe for this GSOC item the focus should be on the gravity and close-up changes, and the far rendering GSOC item gets the planet view thing as another cool target.

I'm not sure if gravity should purely pull you straight down with down defined as the ... upside down pyramidal face you're on? So maybe that's the Mario gravity. As opposed to making it pull you toward the center of the planet which at the edges would also pull you sideways :D That could make edges (and corners in particular) a challenge. Maybe both, with straight down probably being the simpler option.

What I've done in a past engine is have 65536^3 number of chunks (via a short, each chunk holding 65536^3 blocks, though each renderable chunk is much smaller, it started as 256^3 chunks with 256^3 in each though at first), then I just use overflow semantics to wrap around properly and so if you went off one edge it wrapped around to the other side, rendering and all was handled fine as was physics since I handled that manually (if using a generic physics engine you'd need to do some special casing, but still possible). I actually quite liked by 256^3 chunks with 256^3 in each chunk engine as the worlds were small enough to properly and fully explore but still way to big to build over the entire thing (plus I had multiple worlds, and if you got 'high' enough out of the Y axis (that did not wrap around of course, only x/z) then the planet shifted to a bulk mode render so you got a general 'jist' of the planet from space (along with the other planets) so you could fly between them, that was done by mapping it to a spherical renderer (very flat, not much in the 'y' height so you did not really see oddities appear, and you were far enough way to not care). But doing it this way made calculations fast (simple wrap around instead of needing to modulus everywhere, though that would be more powerful with more sizes available) and gravity was still 'conceptually' down on planets (and in space the planets had gravity so you'd orbit and such).

MovingBlocks / Terasology

New world type: finite cubic planet #3161