Ye Olde Planet Thread

[jstenholt]

Jesus, Planr, you can only tell us how against this idea you are so many times, take a break.

Your qualifications are dubious at best for determining what is and isn't possible in this game, and the idea itself would only improve Starmade.

I'm certain it CAN be done, and I would love it if it was done.

If the OP asks you to stop plastering your opinion all over their thread, just be a decent person and listen to them.

 

[Psy_commando]

This would be good for rendering from orbit and could be used for that, but this approach falls short when you land on the surface in a voxel game. That part is tricky.

The idea is that the atmosphere, sphere would have a projection of the planet plane, and that only that sphere would be visible from space. anything that goes through the sphere would be teleported to the off-map planet plane, a little like the portals in Portal.

The actual planet would be a plane inside your typical skybox. All interactions with the surface from space would be translated over, converting between both coordinate spaces. So if you'd drop a ball into a crater on a planet from space, it would fall right into the crater in the planet's skybox, completely seamlessly.

And ships or anything whose bounding box wouldn't fit inside the skybox, and would end up only having a part of them within the planet's atmosphere would have proxy blocks instantiated for the part that fits in the planet plane's space. That's because simply copying over the blocks would generate issues with things that depend on adjacent blocks. With a proxy, interactions are forwarded to the actual blocks of the ship, still in space clipping into the planet sphere. Adding/Removing blocks on the proxy ship would also be properly carried over to the actual ship.

Since the actual planet surface is not a sphere but a plane, there is no issues with voxels at all, and no distortion. The only thing of note is that the curvature of the planet won't be noticeable from the surface when looking at distant objects, on the surface. Unless, an extra effect is applied around the player to simulate planetary curvature. But you'd have to add another interface to modify the trajectory of rays traced against that effect, to compensate for the distortion.

It sounds kinda hacky, because it is, but there are far more hacky things going on in most games. Like in portal, that effect where objects that are half-way into a portal and appear at 2 places at the same time? Those only involve a copy of the mesh, clipped in the wall halfway. The portal effect is just a render target texture.

I've thought about loading FLAT chunks client side around the player, orienting them using the angle that the player would have if standing on a perfect sphere. That makes things easy, right? Just store the planet as a large, edge-wrapping square and load portions onto parts of the sphere for each client. There would be distortions, but that would be a small price to pay... I thought until I realized at the poles a whole edge of the square would pull down to a single point, making entering the atmosphere wonky even though walking across the surface would feel fine (and honestly would make more sense to navigate than real life earth does).

And, I don't know about rotating chunks like that. Because blocks would clip through eachothers, as you'd dig deeper.

But, I think it might be possible to use a trick to actually "wrap around" the voxel plane on the sphere. while also making sure that blocks within a certain range around the player aren't warped by the sphere's angle. I just gotta do some research on that particular thing before saying anything.
Actually, I know someone that might just figure that one out...

Odd. It seemed like my client was fine on lower graphics settings up to the mid-400s radii. How big were the planets you tested this on? Oh, I am using integrated graphics, not a graphics card. I wonder if that has anything to do with this... I'm too sleepy to think though the inner workings of computers. I'll be back tomorrow.

I didn't change the default settings. I actually, just did a fresh install before testing this today. It was a standard sized planet planet between 100 and 175. I know that it tends to happen a little randomly, and that some planet types are more likely to trigger this, like ice planets and red planets.

What is your CPU anyway ? Maybe it has to do with brand exclusive optimizations ?

 

[Viridis00]

I don't see the harm about exploring more ideas for how planets work. I remember when we still had the disc worlds and Schema was dead set on "oreo" style planets, but then that one guy came along with the dodecahedron suggestion and here we are today. Nothing is set completely in stone.

I especially support a new rendering method, but in terms of grouping with voxels I think that the game already uses a similar method to speed things up with large chunks already. Would replacing voxels temporarily with low-poly meshes make a difference? Because the problem with planets at a glance doesn't seem to be the core since that loads fairly fast, but rather all the chunks that need to be displayed. Having a LOD level variable with distance decide on displaying actual blocks or a dummy mesh doesn't sound like a bad idea on the surface if a solution with similar results wasn't already done with the further optimization of planets a couple months ago.

 

[jath]

The question is, how?

How :

Don't make a planet out of blocks. Make it like any other 3d game and generate a topographical point based map. I've seen enormous worlds using that method. When you shoot at a part or pick something up, it regenerates some of it. When you place a block, the block would orient to face the middle of the planet, or the closest block according to a threshold. If the planets ate made big enough, the curvature wouldn't even be noticeable. You'd draw all objects in gravity toward the center of the planet, but the planet itself wouldn't be a warped plane, but a3d rendered object that only loads the closest 200 meters or so of the surface. Saving projectiles headed for unloaded chunks is a good idea. Atmosphere stopping attacks is a good idea to (you'd just have to make the atmosphere a bit higher). It wouldn't effect gameplay a lot, but would help reduce the need for loaded chunks. Hell, you wouldn't even call them chunks anymore.

 

[WaffulMann]

There's that one game that uses topography to generate planet-sized planets without any load screens. Forgot its name.
Anyway, in my opinion, the perfect planet is:
a) at LEAST 100km radius - A reminder that, no matter how massive your empire, how rich your coalition, you still will never match the might of the universe
b) topography mapping, so basically that means nill lag, unless you build massive multikilometre spikes all over the surface
c) orbitable and has an atmosphere, so helmets can actually do something
d) with (a) in place, terrain generation like you can see in Minecraft: mountains, plains, oceans... etc
e) have an abundance of resouces you can't find in asteroids (the kind of ore that only forms under pressure n shit)
So yeah, just my 2 cents , cheers ^^

 

[AtraUnam]

In Schema's old planet post the main issue with spherical planets was that they fish eyed everything around them wasn't it? Tall towers getting wider higher up and 'orbiting' ships being horribly distorted. My dumb suggestion for a fix was to use this broken system anyway and then fisheye each players view independently in such a way that it counteracts the distortion caused by the planet.

 

[Valiant70]

It's hard to make topographical maps work with voxels, even on a very large scale. Unless the squares get smaller as you go from the equator to the poles, you're eventually going to have to reduce the number of blocks longitude-wise, which means that when traveling laterally, you'll start to notice blocks that don't line up.

And, I don't know about rotating chunks like that. Because blocks would clip through eachothers, as you'd dig deeper.

But, I think it might be possible to use a trick to actually "wrap around" the voxel plane on the sphere. while also making sure that blocks within a certain range around the player aren't warped by the sphere's angle. I just gotta do some research on that particular thing before saying anything.
Actually, I know someone that might just figure that one out...

If done right they wouldn't clip. This would be sort of like an instance that isn't really an instance but is moving around in 3d space. I'll see if I can throw together a diagram later to demonstrate this properly.

 

[Psy_commando]

I don't see the harm about exploring more ideas for how planets work. I remember when we still had the disc worlds and Schema was dead set on "oreo" style planets, but then that one guy came along with the dodecahedron suggestion and here we are today. Nothing is set completely in stone.

Well said.

I especially support a new rendering method, but in terms of grouping with voxels I think that the game already uses a similar method to speed things up with large chunks already. Would replacing voxels temporarily with low-poly meshes make a difference? Because the problem with planets at a glance doesn't seem to be the core since that loads fairly fast, but rather all the chunks that need to be displayed. Having a LOD level variable with distance decide on displaying actual blocks or a dummy mesh doesn't sound like a bad idea on the surface if a solution with similar results wasn't already done with the further optimization of planets a couple months ago.

And , it wouldn't be just a rendering method, it would probably involve messing with the way voxels/chunks are arranged, depending on the method. But, using an actual voxel "plane"/grid would still be the most compatible with most common chunk systems. I'd really like to know how Schema implemented chunks in this game... Is it a simple array, an octree, an aligned tree with an hash table or something else ? That could help determining what's easier to do..

As for the low-poly and level of detail idea, there's only so much you can do with voxels to reduce the polycount. A cube has only 6 polygons (or 12 triangles) and 4 vertex indexes(overlapping vertices), out of those, only those not obfuscated are drawn. In the best case, only a single polygon per top level voxel is drawn, which makes it hard to go any lower. But even then, that can be a lot, and it can be taken a step further.
One of the common ways to reduce the amount of polys is to fuse as many adjacent voxels faces together into a low-poly plane dynamically. It could be expansive though. Again, I don't have access to the source, so its hard to tell.

But really, I don't think the issue with planets is purely a rendering one. As the CPU, and not the GPU, is overloaded until you land on said planet.

And if you're interested, here's an excellent article on how to optimize voxel chunks for minecraft like games. It also explains some of the challenges that comes with working with those : http://0fps.net/2012/01/14/an-analysis-of-minecraft-like-engines/

How :

Don't make a planet out of blocks. Make it like any other 3d game and generate a topographical point based map. I've seen enormous worlds using that method. When you shoot at a part or pick something up, it regenerates some of it. When you place a block, the block would orient to face the middle of the planet, or the closest block according to a threshold. If the planets ate made big enough, the curvature wouldn't even be noticeable. You'd draw all objects in gravity toward the center of the planet, but the planet itself wouldn't be a warped plane, but a3d rendered object that only loads the closest 200 meters or so of the surface. Saving projectiles headed for unloaded chunks is a good idea. Atmosphere stopping attacks is a good idea to (you'd just have to make the atmosphere a bit higher). It wouldn't effect gameplay a lot, but would help reduce the need for loaded chunks. Hell, you wouldn't even call them chunks anymore.

But wouldn't a topology map introduce inconsistency with the blocky artstyle of the game ?
I'm not sure what you're trying to explain.

There's that one game that uses topography to generate planet-sized planets without any load screens. Forgot its name.
Anyway, in my opinion, the perfect planet is:
a) at LEAST 100km radius - A reminder that, no matter how massive your empire, how rich your coalition, you still will never match the might of the universe
b) topography mapping, so basically that means nill lag, unless you build massive multikilometre spikes all over the surface
c) orbitable and has an atmosphere, so helmets can actually do something
d) with (a) in place, terrain generation like you can see in Minecraft: mountains, plains, oceans... etc
e) have an abundance of resouces you can't find in asteroids (the kind of ore that only forms under pressure n shit)
So yeah, just my 2 cents , cheers ^^

There are a lot of those actually!
Spore is one of them. Then, there's Infinity, and etc..

Spore is actually a technical masterpiece, even if its an average game XD
There's a lot to be learned from their slides and presentations from SIGGRAPH and etc!

Now, I think 100km planets would be a little too much. Mainly because we'd have to scale up everything else too to keep things proportionate. It would probably make ships look a bit less huge though, which is a good thing IMO, because even the Isanth fighters feels ridiculously large ^^;

And, as for topography mapping, I'm still wondering how people are planning to make it play nice with voxels at lower and higher altitudes. Because of the angle of a sphere's surface, a stack of block would have to be squashed the closer to the core you'd get, and stretched the further away from it you'd get.

In Schema's old planet post the main issue with spherical planets was that they fish eyed everything around them wasn't it? Tall towers getting wider higher up and 'orbiting' ships being horribly distorted. My dumb suggestion for a fix was to use this broken system anyway and then fisheye each players view independently in such a way that it counteracts the distortion caused by the planet.

Yeah, but the thing is there are other ways than the fish-eye effect to accomplish the same thing. That's what I was explaining earlier. And in that suggestion, towers and anything half-way in the planet's atmosphere would look just right.

But yeah, that could be a solution with the fish eye effect, but, the warping around planets wouldn't be easy to get rid of using only that. That's why I was suggesting something a little more flexible that would essentially do the same, but without distortion issues.

 

[jath]

The purpose of the blocks is for building. Throw them out completely when thinking about natural objects. Voxel makes giant structures slow. Who cares how they overlap and lay closer to the center. 2 reasons, there are no blocks anyway before the dirt is picked up, and if the planets are big enough, you'd never even notice the curvature of the planets while standing on them, going deeper would eventually result in merging, but it would be so deep most people would never get there.

 

[QuinnSquared]

So, I've been trying to think of ways to phrase this so as to not sound like a complete nay-sayer, but really, this idea holds no water.

You can't hold up the picture of the planet segment mock up that became our current dodecahedron planets as a similar example to the spherification of planets through coordinate mapping. Firstly because schema has already tried it, and said it didn't work followed by posting evidence it didn't work.

Calling Planr out on telling you this isn't helping your cause.

Now here are some reasons why this is not a "suggestion," you can't as a player arbitrarily decide what should and should not be saved by the computer or handled by the engine. The game takes place in a consistent and constant universe, saying that attacks burn up in atmosphere, or neglecting to save segments that have been modified from mining/removal of blocks leads to:

A: Segmented gameplay in which space and planets are separate systems. (This is basically the opposite of what the dev team has stated should be the case)
and B: Infinite free resources for anyone with half a brain and a couple hours.

All of the "solutions" posted thus far make that problem worse, not better. The segmented gameplay isn't solved by adding a distance at which the planet stops being mapped to a sphere and starts being rendered as a planar object to be manipulated because that is the same thing as simply adding a loading screen to a planet.

This is what is actually beating a dead horse, and what Planr was trying to get at. The segmented gameplay arising from adding a pseudo-loading screen for interaction with planet surfaces is something that has been completely vetoed by schema.

As a side note. In my personal opinion, planets are plenty large if you consider the sheer volume you have to work with.

TL;DR: You guys missed Planr's point, you're asking for something schema has said is against the game's design, and your solutions create gameplay or performance issues that you seem to be all but ignoring.

 

[Planr]

Thank you for helping to clarify that Quinn.

On another note, I talked with schema about it on Skype real quick today and here's what he said:

"generally not undoable. Huge sizes as well as more spherical. however there is a gameplay aspect to it that kind of makes it something that will have to be thought about a lot more."

The way he worded it is kind of confusing, but I think he meant to say it's not do-able, though he does appear to like the idea. We'll just have to ask him about it some more.

 

[Psy_commando]

The purpose of the blocks is for building. Throw them out completely when thinking about natural objects. Voxel makes giant structures slow.

You know, voxels were mainly used in medical imagery before, as ironic that may sound :P
And yes, of course they're slower to handle, but that's pretty much the core of the game. I'm not sure if an hybrid between both would work too well really. Because, the blocks need a grid to align properly, and the terrain doesn't. Leading to clipping and etc..
Not to mention, how would digging work in this case ? And caves and etc?

Who cares how they overlap and lay closer to the center. 2 reasons, there are no blocks anyway before the dirt is picked up, and if the planets are big enough, you'd never even notice the curvature of the planets while standing on them, going deeper would eventually result in merging, but it would be so deep most people would never get there.

Actually, there are blocks everywhere, they're just not rendered, because it would be very slow to render them all every frames otherwise. And one of the main issue with them overlapping is coincidentally that occlusion culling, what gives you the impression no blocks are there, wouldn't work properly. Then collisions, for things like mining, or walking wouldn't work properly. There would also be Z-fighting/flickering, making overlapping blocks look quite ugly.

So, I've been trying to think of ways to phrase this so as to not sound like a complete nay-sayer, but really, this idea holds no water.

Well, this sounds promising..
First, I'll ask, who are you referring to ? reading the content of your message, you refer to a lot of things I've said. Yet, you're talking as if you're arguing against OP's idea. And even yet, you're talking in general as if we were all the same people... You can't just disprove things I've brought and make them automatically count as invalidating OP's ideas. That's not logical.

I'll assume you're talking to me for the rest of this post, given you didn't precise.

You can't hold up the picture of the planet segment mock up that became our current dodecahedron planets as a similar example to the spherification of planets through coordinate mapping. Firstly because schema has already tried it, and said it didn't work followed by posting evidence it didn't work.

Calling Planr out on telling you this isn't helping your cause.

Yes, Schema said it didn't work. We know this already. What does it do ? Are you appealing to Schema's authority to prove your point ? Because that's bad reasoning. Schema can be wrong, he can also change his mind on things. Problems can be fixed as well.

And, I'd really like to see that "evidence" you're talking about. Because, coincidentally I was looking for exactly that. Schema only said it didn't work, for x reason. He didn't go into details, or anything sadly. I'd have liked to have gotten a peek at the algorithm and logic behind it.

And to top it off, I'm not sure if you truly read what I wrote. Because, the approach I suggested was something different than what Schema did. Something that actually addresses the issues he mentioned.
Yet, you're criticizing me for wanting to re-implement the same idea, which is just rude. I actually read your post, you could take the time to read mine properly?

I called out Planr for the same reason I'm calling you out now. Bad reasoning, making judgement calls that exceeds your authority/abilities, and not being to back up what you're saying.

Now here are some reasons why this is not a "suggestion," you can't as a player arbitrarily decide what should and should not be saved by the computer or handled by the engine. The game takes place in a consistent and constant universe, saying that attacks burn up in atmosphere, or neglecting to save segments that have been modified from mining/removal of blocks leads to:

No, actually, I'm quite sure this is a suggestion. Its in the suggestion forum, the mods didn't say it was in the wrong section either.

And what are you even talking about ? Players would never have control over that in-game.
But what's your point ?

See, it turns out some of use are a little tech savy or programer ourselves, so discussing technicalities and bringing them up might be actually contructive to the discussion.
The same can't be said about coming in and claiming everyone is wrong because because you declared so. With nothing really to back that up other than repeating things that were already addressed earlier in the thread, I might add..

A: Segmented gameplay in which space and planets are separate systems. (This is basically the opposite of what the dev team has stated should be the case)
and B: Infinite free resources for anyone with half a brain and a couple hours.

I'm really stumped here.

We already addressed that separating gameplay with loading screens and barrier was a bad idea earlier. We moved on from there.

You'll have to explain your infinite resource thing. I might not even have half a brain, but I got enough to understand and demand explanation when someone come up with something without backing it up, or explaining it.
For one, I could replace your point B, with "because banana" and it would have the exact same meaning, because no explanation were given at all in either cases.

All of the "solutions" posted thus far make that problem worse, not better.

How can you tell ? Please share, we won't bite if you make a good point.

The segmented gameplay isn't solved by adding a distance at which the planet stops being mapped to a sphere and starts being rendered as a planar object to be manipulated because that is the same thing as simply adding a loading screen to a planet.

No, actually its not. That system runs in real time. And its been done in several forms for years in many games. Its possible you didn't understand what I meant though. Did you even read the ball falling in one of the planet's crater example I mentioned ? Because the point was to demonstrate the process is seamless.
Did you ever play Portal, or any source engine based game ? Because, you don't get a loading screen when passing through portals. And the skybox in most source game is actually not really over the map, but in a tiny box outside within the game space, that is scaled up and mapped to the skybox of the actual map area.

This is what is actually beating a dead horse, and what Planr was trying to get at. The segmented gameplay arising from adding a pseudo-loading screen for interaction with planet surfaces is something that has been completely vetoed by schema.
As a side note. In my personal opinion, planets are plenty large if you consider the sheer volume you have to work with.

You know, I find this all a little silly you're trying to tell people in a suggestion forum that they're being repetitive and bringing back old stuff up.. Its also a little ironic around here considering it seems pretty popular to go in suggestion thread and tell people that "simpsons did it", or actually proceed to be needlessly inhospitable.

And once again, the loading screen thing has been handled before. We're not even talking about that anymore. Speaking of beating a dead horse..
And that's great, you have your opinion about it. It doesn't mean everyone else should be content with it.

TL;DR: You guys missed Planr's point, you're asking for something schema has said is against the game's design, and your solutions create gameplay or performance issues that you seem to be all but ignoring.

When ? What is Schema's game design ?
Besides, isn't the point of suggesting something, to ask to add something that isn't already in the game ?
And, any changes to the game will cause performance and gameplay issues really. The question is, which compromises are acceptable. And given we're in no position of testing those things, not having access to the source of the game, we can't really guess what are the actual impact of those things, which is why we're not saying much on those...

You on the other hand seems to have no issues extrapolating on the cataclysmic ravage that some people throwing ideas around would create if it were to ever be integrated in the game.. You don't think you're exaggerating a little ?

And no need to write a TL;DR, it wasn't long enough, I read it all !
[DOUBLEPOST=1431295990,1431295636][/DOUBLEPOST]

On another note, I talked with schema about it on Skype real quick today and here's what he said:

The way he worded it is kind of confusing, but I think he meant to say it's not do-able, though he does appear to like the idea. We'll just have to ask him about it some more.

That's pretty interesting ! Did you link him the thread ? Or if not what did you tell him ?

I wonder what he's planning. He seems to be implying either to revisit this, or that there would be some gameplay related issue. But since we don't know yet what you told him, we can't hazard a guess really.

 

[Ithirahad]

Orbital bombardments, by your account, should not be a thing, even though they've been a fun part of this game for years.

Yeah, sure... They also render any potential advantages of building on planets null and void, turning them into nothing more than laggier stations with annoying automatic gravity that makes ships tip over and roll all over the place if they aren't built right.

In Schema's old planet post the main issue with spherical planets was that they fish eyed everything around them wasn't it? Tall towers getting wider higher up and 'orbiting' ships being horribly distorted.

The rather interesting suggestion to make planets not normal voxel grids would dispose of this issue quite neatly. When you place a block on the surface, it would become the start and origin of its own entity... And suddenly we'd have no strange fisheyeing, nor even any odd hacks, to make it work. However, non-voxel terrain, would be really weird and I don't necessarily support it. Additionally, you'd eventually get the opposite problem to fisheyeing - You couldn't really make a large city without it ending up kind of balanced on top of the planet, rather than being properly on it.

 

[Planr]

That's pretty interesting ! Did you link him the thread ? Or if not what did you tell him ?

I wonder what he's planning. He seems to be implying either to revisit this, or that there would be some gameplay related issue. But since we don't know yet what you told him, we can't hazard a guess really.

Yeah I linked him but I doubt he'll contribute to this thread. SCHINE's probably got him tied up another one of duke's NDA's or something.

This is what I told him:

hey schema
how do-able are spherical planets in starmade right now
im just curious
also what about multi-sector planets?
er,
erm
multi-kilometer planets

 

[Ithirahad]

Maximum planet size should definitely be tied to sector size, for the record. Otherwise things can potentially mess up pretty terribly...

 

[Psy_commando]

Yeah I linked him but I doubt he'll contribute to this thread. SCHINE's probably got him tied up another one of duke's NDA's or something.

This is what I told him:

Thanks!
He might not join in, but that was still a nice little tidbit of info !

 

[jayman38]

I was thinking of a solution for larger planets that would not change the system much and would not increase lag too much.

1. New "bedrock" mesh. Can't build or dig this. Could be the core mesh with a new, dull texture. If this has its HP reduced to 0, delete the mesh object and eject the voxel "plates" that we already have. Scaled to the size of however big the planet is, minus the normal thickness of a plate.

2. Multiple different "global planet type" meshes. Global ocean. Global bedrock. Global gas. Global dust. Whatever. If this has its HP reduced to 0, the voxel "plates" remain in place and this mesh disappears. Hollow: Holes in it to accommodate voxel plates and the bedrock and planet core underneath. Water and gas meshes should allow travel through them, with greatly increased friction.

3. Voxel plates will be in random locations around the planet. The bounding box of the entire plate cuts a hole in the "global planet type" mesh so that things like underground caves are not immediately flooded or filled with bedrock. This makes each plate a diggable, mineable, buildable island on the planet. Most plates would rise above the surface of the global-planet-type mesh, so they are uncovered, but there could be under-water or buried plates, that you'd need to go underwater or destroy the outer mesh to mine. Completely mined plates disappear, and the global-planet-type mesh is filled in at that area. Can new plates be built, or can the outer mesh be built upon? That's a discussion for another time.

Theoretically, you can use a vehicle on the surface of the outer global-planet-type mesh to travel from one voxel plate to another. This makes each plate a strategic point on the planet, and allows mining, building, and everything else you can do on a planet now, except for drilling down to the core, simply at a larger scale with more distance between plates, without getting trapped between them. Although, now you'd get trapped between the outer mesh and the plate. That's resolved by somehow making the planet type climbable. Plus, there's the oddness of an ocean forming a water wall at the outer bounding box of a plate, but hey, that's the price of less lag.

 

[Valiant70]

I was thinking of a solution for larger planets that would not change the system much and would not increase lag too much.

1. New "bedrock" mesh. Can't build or dig this. Could be the core mesh with a new, dull texture. If this has its HP reduced to 0, delete the mesh object and eject the voxel "plates" that we already have. Scaled to the size of however big the planet is, minus the normal thickness of a plate.

2. Multiple different "global planet type" meshes. Global ocean. Global bedrock. Global gas. Global dust. Whatever. If this has its HP reduced to 0, the voxel "plates" remain in place and this mesh disappears. Hollow: Holes in it to accommodate voxel plates and the bedrock and planet core underneath. Water and gas meshes should allow travel through them, with greatly increased friction.

3. Voxel plates will be in random locations around the planet. The bounding box of the entire plate cuts a hole in the "global planet type" mesh so that things like underground caves are not immediately flooded or filled with bedrock. This makes each plate a diggable, mineable, buildable island on the planet. Most plates would rise above the surface of the global-planet-type mesh, so they are uncovered, but there could be under-water or buried plates, that you'd need to go underwater or destroy the outer mesh to mine. Completely mined plates disappear, and the global-planet-type mesh is filled in at that area. Can new plates be built, or can the outer mesh be built upon? That's a discussion for another time.

Theoretically, you can use a vehicle on the surface of the outer global-planet-type mesh to travel from one voxel plate to another. This makes each plate a strategic point on the planet, and allows mining, building, and everything else you can do on a planet now, except for drilling down to the core, simply at a larger scale with more distance between plates, without getting trapped between them. Although, now you'd get trapped between the outer mesh and the plate. That's resolved by somehow making the planet type climbable. Plus, there's the oddness of an ocean forming a water wall at the outer bounding box of a plate, but hey, that's the price of less lag.

Just wait a few minutes until I get my idea up here with graphs. This sounds like it could be adapted into a solution to my idea's one critical flaw. To do that, one detail needs ironed out: how do you deal with a plate on the north pole getting connected to a plate on the equator if someone builds something to connect the two (Like a train) ? EDIT: I actually found my own solution to the problem I had (the section below about sphere distortion being relative).
[DOUBLEPOST=1431365466,1431362186][/DOUBLEPOST]It might seem half-baked and crazy at first, but bear with me.

I propose that planets can be seamless and large without distortions or very much strangeness by allowing clients to perceive certain things relative to themselves rather than experiencing an exact copy of an absolute model shared across all clients.

The idea is to create a landscape similar to Minecraft in appearance and feel and fit it onto a sphere using some very cool tricks. The entire map of a planet would be a square grid "bent" onto a sphere. This obviously presents some problems, especially around the planet's poles. In other words you can't do it like this:

Because of this:

Spoiler: WUT

Believe it or not, there is a way around this. I hadn't realized it until shortly before I started this post, but the distortion of the square grids can be rendered relative to each client as shown below:

Spoiler: Relativity of sphere distortion

Confused yet? Good. Let's undo that. To make this work, a modified barrel distortion is applied across the square map, and you see the part of the map closest to you (since you can't render that many voxels at once, it would be seen as a flat texture projection from orbit as explained in the OP).

Furthermore, a three-dimensional distortion like this might be applied to the whole sector to make the positions of other ships feel less strange... but I'll leave that to a real mathematician to figure out in more detail.

So, we can land now, right? NOPE. If we land now, the voxels will be bent and weird like Schema's first attempt at a spherical planet (which he didn't like). So to fix the bending, add more relativity. This time it's angle relativity. From orbit, you see a texture: (EDIT: by "flat" in the figure I mean smooth and bent across the sphere)

Spoiler

When we enter the atmosphere, the surface begins to load. Here's the part that makes it work: the surface portion being loaded is FLAT. The bottom of the flat segment is tangent to the sphere of the planet.

Spoiler: Tangent

When you walk across the surface, chucks load in front of you, unload behind you, and the surface angle changes to match your new location on the sphere:

Spoiler: Moving tangent

Ok, so now it feels like Minecraft. The next problem is, what happens when a ship comes in? The other player isn't in the same place as you on the sphere so his/her angle is different and... boy that's confusing. So here's where some more relativity comes in. The ship begins at a universe-relative position outside the influence of the planet's gravity:

Spoiler: Out of gravity

Upon entering the atmosphere, all radar and visual contact is briefly lost in a mess of plasma as the ship burns through the upper atmosphere. The radar blip could be made wider, disappear, or made to bounce randomly around in an area to simulate loss of sensor precision. This masks a discrepancy in the position of the craft as the client transitions from viewing it in a universe-relative position to a surface-relative position (relative to the flat plane you're standing on).

Spoiler: The transition

We see the other guy's space ship as being above the same part of the surface that he sees himself above. He sees us in the same fashion. We have successfully transferred from a 3D environment to a flat surface, and it is very nearly seamless. Someone who is better at math than I am may be able to come up with a way to smooth out the discrepancy of universe and surface relative positions without the abrupt transition.

This idea might just be crazy enough to work, though. We already have ROTATING sectors for pete's sake. Maybe distorted ones can work too.

EDIT: It turns out that this would result in a torus-like planet with two equators. In a later post I outline a new kind of map that has two poles and one equator.

 

[Ithirahad]

This actually sounds like a good idea - as you said, "crazy enough to work."

 

[Psy_commando]

Someone should try implementing that in a traditional 3d environment.

Because, I sense figuring out the movement traveled on the sphere and on the voxel grid might be a tad bit tricky. Especially the deeper you are down in the voxel grid. But I never saw a system like that in action.. So I can't really say anything with certainty..

Mainly because, in the example, you assume the grid is perfectly flat, but the terrain on planets is jagged and filled with holes and etc..
And basically, the closer you get to the center/core of the sphere, the less diameter it has. So you have to account for that on your "faked" voxel grid, and make the player/ship travel less the deeper you get.

And, I'm not sure what you mean with the distortion getting into the atmosphere. Not to mention, actual atmosphere is not a requirement on planets. Some, like moons, have hardly any.
And I'm not sure what you're implying with player positions being different between clients. Because, interactions between players might be a bit complicated, no ?

But, you brought something pretty neat and refreshing.