Terrain Voxel Maps

[runner78]

The biggest Planet in Space Engineers has only 120 km in diameter.

No'Man Sky, not official numbers, but also very small.

[steuben]

The slightly strong argument against involves MATH! and computer SCIENCE!  You'd basically have to manage _alot_ of bits to do it. Not just a lot of bits, but an eldritchly large number of bits.

Let's take a look at Kerbin. At 600,000 meters in radius that's 9.05E17 cubic meters. Let's say our voxel represents one cubic meter.  If we have only one terrain type, That would mean roughly 9.05E16 bits would have to be stored, or around 90 million gigabytes of data for the base representation of Kerbin.  And that's before the question of how to represent it getting turning inside out by some mad player.  But, since people want additional detail we'll need more that just the one terrain type. So let's go with a nice round 256 different terrain voxels, which puts us to a nice round 1 billion gigabytes of data to start with.

Ah, but a mere bagatelle, you may say. What if we only represent say the top 100 kilometers, that would be enough for most people. A bit better... but that is still 3.81E17 bytes, assuming up to 256 different terrain voxels. 

So 40 million gigabytes, per planet... I think I just heard two things. The cackle of glee and hand rubbing of hard drive manufacturers, and my wallet whimpering.

Part of the reason that games like Minecraft and No Man's Sky can get away with voxels of such large things is procedural generation. All you need is the seed for that part of the space, a comparatively small amount of data, and you just need to store the difference between the output of that seed and what you've done.

Besides, a game about digging... I have the feeling that would be boring.

[Rejected Spawn]

4 minutes ago, steuben said:

--MATH! and computer SCIENCE!--

Basically sums up why this entire thread is a waste of time. I've been waiting for someone to shoot this thing down with some proper understanding of just how ridiculous the idea is to have voxel terrain on even a single planet out of the (probably) dozens in KSP2, there is no amount of wishful thinking that will make full voxel terrain work acceptably in a game of such a colossal scale until we all sit on brand new year 2029 hardware.

Having said all this I'm going to hate myself for mentioning it but the thread about an asteroid impact event got me thinking about terrain height deformation to show proper cratering, now let's say height deformation eventually actually makes it into the game, it MIGHT be possible to simply lower/delete a region of the terrain and do plastered on voxels in that confined area to avoid running voxels all over the whole planet... never heard of any game using a mashup like this and it would take TONS of work to implement and produce an extremely limited (and nearly unimaginably bug prone) result but would put SOME voxel shenanigans in the realm of "not entirely disproven by everything forever", though still with the unavoidably awful performance-to-quality ratio that voxeling causes by its very nature. Now might be a good time to also mention that merely enabling decent quality height deformation in the game is such a monumental task that it would likely warrant becoming its own DLC to cover the huge development cost. I dunno about the rest of you fine folks but it leaves a bad taste in my digital mouth to make plans about DLC for a game that isn't even released yet. I could go on and on about how underestimating the development cost and performance cost of voxels has KILLED several promising games, but anyone still needing convincing that voxels is an awful idea for KSP2 isn't going to listen to reason anyway so I'd just waste my time and patience.

[Guest]

8 minutes ago, Rejected Spawn said:

Having said all this I'm going to hate myself for mentioning it but the thread about an asteroid impact event got me thinking about terrain height deformation to show proper cratering, now let's say height deformation eventually actually makes it into the game, it MIGHT be possible to simply lower/delete a region of the terrain and do plastered on voxels in that confined area to avoid running voxels all over the whole planet...

I expect you could, but why? Deforming a depth map + changing a texture is more than adequate for that sort of thing, as well as landscaping, underground bases and what have you.

[Pecan]

Someone has got a bit carried away with a technique they've just found out about.  I prefer marching cubes to voxel but more importantly many genres have no need for the concept of terrain, let alone a deformable version of it.  It's like saying every game has to have a fully-working gene-based ecology.

My point: have fun making up reasons why every game is 'crippled' without voxel-based terrain.
Some examples: Choice of Robots, Crusader Kings, Gwent, Human Resources Machine, Orwell, Papers Please, Plague Inc.,  Reigns.

[runner78]

6 minutes ago, Pecan said:

Someone has got a bit carried away with a technique they've just found out about.  I prefer marching cubes to voxel but more importantly many genres have no need for the concept of terrain, let alone a deformable version of it.  It's like saying every game has to have a fully-working gene-based ecology.

I prefer dual contouring over marching cubes, they can have sharp edges.

For large scale voxel terrains, you need only store the chunks which have been changed. The rest is procedural generated on the fly.

[tseitsei89]

2 hours ago, cgw said:

Not in one game there is not what you have, it is a flight trajectory, orbits, real physics.
Space engineers are not that.
Empyrion – Galactic Survival is much better than Space Engineers.
Space Engineers, Empyrion – Galactic Survival, No'Man Sky, Astroneer, they do not have what is in KSP (this is the flight trajectory, orbits, real physics.).

Exactly!! KSP is a game about orbits, trajectories and spaceflight. So obviously it should focus on those things instead of deformable terrain. Terrain is NOT really that important for game that is all about building and flying rockets...

[SpaceFace545]

On 10/8/2019 at 6:00 AM, cgw said:

 

Extraction of ore (drill, pick, shovel, etc.),

 

Hey this isn't minecraft with rockets.

[GoldForest]

32 minutes ago, tseitsei89 said:

Exactly!! KSP is a game about orbits, trajectories and spaceflight. So obviously it should focus on those things instead of deformable terrain. Terrain is NOT really that important for game that is all about building and flying rockets...

And colonization

[cgw]

2 hours ago, steuben said:

The slightly strong argument against involves MATH! and computer SCIENCE!  You'd basically have to manage _alot_ of bits to do it. Not just a lot of bits, but an eldritchly large number of bits.

Let's take a look at Kerbin. At 600,000 meters in radius that's 9.05E17 cubic meters. Let's say our voxel represents one cubic meter.  If we have only one terrain type, That would mean roughly 9.05E16 bits would have to be stored, or around 90 million gigabytes of data for the base representation of Kerbin.  And that's before the question of how to represent it getting turning inside out by some mad player.  But, since people want additional detail we'll need more that just the one terrain type. So let's go with a nice round 256 different terrain voxels, which puts us to a nice round 1 billion gigabytes of data to start with.

Ah, but a mere bagatelle, you may say. What if we only represent say the top 100 kilometers, that would be enough for most people. A bit better... but that is still 3.81E17 bytes, assuming up to 256 different terrain voxels. 

So 40 million gigabytes, per planet... I think I just heard two things. The cackle of glee and hand rubbing of hard drive manufacturers, and my wallet whimpering.

Part of the reason that games like Minecraft and No Man's Sky can get away with voxels of such large things is procedural generation. All you need is the seed for that part of the space, a comparatively small amount of data, and you just need to store the difference between the output of that seed and what you've done.

Besides, a game about digging... I have the feeling that would be boring.

Nobody needs a planet measuring 40,075 km. What for?
Palnet can be small and her physics can be like on earth.
Nobody will even notice this.
Need a small planet that you can dig.

For Example Empyrion - Galactic Survival (Unity) on Steam  About 10 planets

https://empyriononline.com/threads/alpha-8-new-planets-playfield-tech.38165/

SYSTEM REQUIREMENTSSYSTEM REQUIREMENTS
MINIMUM:
OS: Windows (7, 8 and 10), 64-bit system required
Processor: Dual-Core Processor 2.5 GHz or better
Memory: 8 GB RAM
Graphics: NVIDIA GeForce GT 640 or equivalent (at least 1GB VRAM)
DirectX: Version 9.0c
Storage: 2 GB available space
Sound Card: DirectX® compatible

RECOMMENDED:
OS: Windows (7, 8 and 10), 64-bit system required
Processor: Quad-Core 2.8 GHz or better
Memory: 16 GB RAM
Graphics: NVIDIA GeForce GTX 560 or better (with 2GB VRAM)
DirectX: Version 11
Storage: 4 GB available space
Sound Card: DirectX® compatible

So your calculations are wrong.

 

Edited October 9, 2019 by cgw

[GoldForest]

8 minutes ago, cgw said:

Nobody needs a planet measuring 40,075 km. What for?
Palnet can be small and her physics can be like on earth.
Nobody will even notice this.
Need a small planet that you can dig.

Ksp planets already have a set size.

Voxel maps aren't worth it, very few people really want it, and it's a resource hog.

It's just not viable. 

[runner78]

20 minutes ago, cgw said:

Nobody needs a planet measuring 40,075 km. What for?
Palnet can be small and her physics can be like on earth.
Nobody will even notice this.
Need a small planet that you can dig.

For Example Astroneer on Steam  5 Planet + 4 moon = 9 sphere

Astroneer have very very small planets/moon maybe 2-5 km in diameter. The target of the game ist to dig to the cores.

[cgw]

Eleon Game Studios + Squad = Good Game 

 

Edited October 10, 2019 by cgw

[Guest]

28 minutes ago, GoldForest said:

Voxel maps aren't worth it, very few people really want it, and it's a resource hog.

I'm pretty sure it could be done if you're clever enough without making it a complete resource hog. You obviously wouldn't actually store all the voxels, you'd create an algorithm that generated them based on inputs, such as a depth map defining the planetary surface. This algorithm would be deterministic so that you'd get the same voxels every time. Then you'd store any perturbations caused by player activity. You would need a LOD system and all that kind of stuff to make it work and make it scale.

In other words, it would be a lot of work, both to implement in the first place and then to work out the bugs. So I agree that it wouldn't be worth it, depth maps + texture maps are more than adequate for what KSP does. But I don't buy the "resource hog" argument. 

And @cgw, if they shrunk the Kerbolar system by a factor of 10 or so, the uproar would be terrifying to behold. There are already people who think the planets are too small.

[runner78]

If you fly with highspeed near the surface, the voxel system no longer can build the terrain in time. Games like "space engineers" or "no man's sky" have speed limits.

[cgw]

10 minutes ago, runner78 said:

If you fly with highspeed near the surface, the voxel system no longer can build the terrain in time. Games like "space engineers" or "no man's sky" have speed limits.

Yes there is such a problem.
But if you use 2 Map
Hight map (in Cockpit) + Voxel map(outside Cockpit)
This problem can be solved.

Edited October 9, 2019 by cgw

[GoldForest]

7 minutes ago, cgw said:

Yes there is such a problem.
But if you use 2 Map
Hight map (in Cockpit) + Voxel map(outside Cockpit)
This problem can be solved.

No, it can't, because you cant use both maps at the same time. And I mean in the same game. It's either height map or voxel map, not switchable or both.

Edited October 9, 2019 by GoldForest

[cgw]

1 hour ago, Brikoleur said:

And @cgw, if they shrunk the Kerbolar system by a factor of 10 or so, the uproar would be terrifying to behold. There are already people who think the planets are too small.

So what? I do not see the need for a large planet.
Why a big planet is needed if these planets are absolutely empty (There are even no NPC buildings.).
On small planets there is enough space for everyone.
And the small planets will be empty (uninhabited).

8 minutes ago, GoldForest said:

No, it can't, because you cant use both maps at the same time. And I mean in the same game. It's either height map or voxel map, not switchable or both.

Why not, what prevents this problem from being resolved, but you already made KSP beyond the capabilities of the unity engine.

Edited October 9, 2019 by cgw

[runner78]

7 minutes ago, cgw said:

So what? I do not see the need for a large planet.
Why a big planet is needed if these planets are absolutely empty.
On small planets there is enough space for everyone.
And the small planets will be empty (uninhabited).

KSP is a space program simulator, a game focus to build rockets with many boosters and fly very fast. I will KSP 2, not Astroneer 2 with orbit physics.

[GoldForest]

9 minutes ago, cgw said:

So what? I do not see the need for a large planet.
Why a big planet is needed if these planets are absolutely empty (There are even no NPC buildings.).
On small planets there is enough space for everyone.
And the small planets will be empty (uninhabited).

People want real sized planets. They dont want a boulder, they want a planet. The bigger the planet the more exploration they can do, discover new nook and crannies.

 

10 minutes ago, cgw said:

Why not, what prevents this problem from being resolved, but you already made KSP beyond the capabilities of the unity engine.

Because a game cant use both. It has to use one or the other. You cant switch them in cockpit view, you cant switch them at any point.

[runner78]

5 minutes ago, GoldForest said:

Because a game cant use both. It has to use one or the other. You cant switch them in cockpit view, you cant switch them at any point.

Theoretically you can, but only you need build 2 terrain systems, and have a loadingsceen between cockpit view and "outside" view. And if you in cockpit view, you don't see the same terrain as the voxel version. Voxel can have overhangs and other complicated structures.

[GoldForest]

1 minute ago, runner78 said:

Theoretically you can, but only you need build 2 terrain systems, and have a loadingsceen between cockpit view and "outside" view. And if you in cockpit view, you don't see the same terrain as the voxel version. Voxel can have overhangs and other complicated structures.

Okay, but I do not want to sit through a loading screen every time I want to switch camera views. Do you?

[runner78]

2 minutes ago, GoldForest said:

Okay, but I do not want to sit through a loading screen every time I want to switch camera views. Do you?

No.

My dream would actually be a game mix of KSP and Space Engineers. But that would be extremely difficult to develop and probably too much for current consumer PC.

[cgw]

26 minutes ago, runner78 said:

My dream would actually be a game mix of KSP and Space Engineers. But that would be extremely difficult to develop and probably too much for current consumer PC.

KSP and Space Engineers (Empyrion Galactic Survival)
I also dream about it.
But this will not be completed soon (even if they begin to do it now).
But they do not want to do this. They are lazy, or I don’t know what.
By then, you will have time to change the computer on core i16 + 256GbOzu(DDR10) + 1petabyte SSD.

Edited October 9, 2019 by cgw

[steuben]

1 hour ago, cgw said:

SYSTEM REQUIREMENTSSYSTEM REQUIREMENTS
MINIMUM:
OS: Windows (7, 8 and 10), 64-bit system required
Processor: Dual-Core Processor 2.5 GHz or better
Memory: 8 GB RAM
Graphics: NVIDIA GeForce GT 640 or equivalent (at least 1GB VRAM)
DirectX: Version 9.0c
Storage: 2 GB available space
Sound Card: DirectX® compatible

So your calculations are wrong.

 

Game requirement specs are not a very good argument that the calculations are wrong... unless I'm missing a subtlety of the argument. Would you care to point out exactly where the calculations are wrong, or expand on your argument?

For my part, because I did skip the presentation of a number of calculations.

Volume of a sphere -> 4/3 pi r^3
Radius of kerbin: 600,000 m
Pi: 3.14 (no need for more digits given we are working at the piano tuner level of analysis. I could go with 3, but someone would go all foamy at the mouth about that.)
Number of bits to a byte: 8 (I know, but sometimes weird assumptions can be made)
Number of bytes to a gigabyte: 1073741824 (an imperial gigabyte, not one of those smaller metric ones)
Number of voxels per cubic meter: 1

Volume of kerbin: 9.05 E17 cubic meters

If we are merely recording the presence/absence of a block then we will only need 1 bit. This means 9.05 E17 bits, or 1.13 E17 bytes, or 1.05 E8 Gigabytes to record that information. For the moment, we will can exclude recording any changes as a difference map, as that will only increase the amount of information stored.

Now, given that having all the voxels the same will be boring we will need to indicate what kind of terrain that voxel is. We won't need millions or even thousands. Using a "palette" map we can reasonably assume at most 256 different terrain elements. This will take the amount of data required to store a planet up to 8.43 E8 gigabytes.

However, true in _most_ cases the entire planet will not be edited. To give a generous amount of planet to work with lets allow modification to the first 100 kilometers. So for Kerbin:
Uneditable radius: 500,000m
Uneditable volume: 5.24 E17

Editiable volume = 9.05 E17 - 5.24 E17
                              = 3.81 E17 cubic meters

Now, following the previous calculations this means that it will require 3.81 E17 bytes, or 3.55 E8 gigabytes to store the partial planet.

Though, since the number of voxels is proportional to the third power of the radius. What if we shrank the editable radius down to one kilometer. This will reduce the editable volume to 5.00 E15 cubic meters, (the calculation of which is left as an exercise for the reader). This will reduce the data requirements down to a mere bagatelle of 4.66 E6 gigabytes.

We can also assume the following. That the above amounts of data represent the ceiling of the amount of data required to represent a planet. The larger ones are gas giants and have no surface, or at least none that we recognize as such, to edit. So for the Kerbol system, 15 landable bodies, assuming only 1000 editable meters of any planet that means 6.98 E7 gigabytes of data will be required.