Voxel manipulation, roads?
Hey, I’ve long thought and wished for better voxel manipulation, with the implementation of water down the line I believe this could now be possible,
What do I mean by voxel manipulation? Well drills are fun, mining is cool, but, the actual physicality of mining in SE is arcade, in SE 1 I love building excavators, small wheeled / tracked excavators similar to IRL vehicles, but also large scale industrial excavators, rather than just simple auto drills … relating this back to the question at hand, what if we could have better blocks which manipulate voxels, without automatically mining the material? such as earth moving vehicle blocks, I could build a front loading shovel in SE2 quite really, but it has no practical use, what if we could add a block which would manipulate voxels, smooth out terrain, make roads possible, detail the ground around you, shape it how you want instead of simply digging / mining it away, this could be amazing for irl style vehicles such as 360° excavator with a bucket instead of a drill, shovels, loaders, tippers and dumpers, maybe even a road roller? I’m simply proposing more reality, less arcade when it comes to voxel manipulation
I like this feedback
Agree with Semtex about the 3 main issues, although they can mostly be solved with a single "shovel" block and a clever engineering.
When activated, it would work similarly to the box-shaped voxel manipulation tool we have in Creative, but it would add and remove voxels at the same time.
It would depend on how far the shovel is from the surface. If you move the shovel deeper, it removes voxels, while raising it above the surface adds voxels.
However, the voxels are not created nor destroyed. The shovel has a "virtual" range bubble, similar to the range we have for a welder block, for example. When adding voxels, it tries to borrow them from nearby within that range. When removing voxels, it tries to push them to the sides. If there is no room to push the voxels, it stops removing them, and the shovel eventually touches the ground and stops. Similarly, when you raise the shovel, it grabs voxels from nearby until it can't anymore.
So let's see what we can actually do with this shovel.
First, we can finally smooth the terrain easily, filling gaps and holes. With a bit of engineering and skill, you can do much more. You can basically move the ground around like with a real shovel :)
If you need more voxels, you can push them in from the sides. Conversely, if you need to dig down a bit, you can push the excess voxels to the sides or dig with drills.
There might still be challenges if you want to create a perfectly flat surface without "spilling" unnecessary voxels around the shovel. This is where the engineering part starts to play a role. Positioning additional shovel blocks on the sides at certain angles could help you make the voxels behave the way you want. By building specific machines, you could finally make flat surfaces, walls, ramps, and all sorts of different shapes.
And ofc, you could use a shovel to make paths for wheeled vehicles to traverse the terrain much more easily. Not a proper road, but at least you could smooth the terrain, make gentle slopes and ramps, create the voxel sections of bridges, parking areas, and so on. The hanging part of a bridge can still be made out of blocks, while the approaches are formed with voxels.
The goal is not to modify 20km of terrain. This is not good for many reasons. First, loading performance and world save file size. The more changed the terrain, the longer it takes to load those changes and stream in multiplayer. But there is also a practical gameplay reason. Wheeled vehicles in this game are still perfectly capable of traversing slightly uneven terrain. There is no practical need to make perfect roads. You won't be making highways, instead you will most likely try to make a road following the terrain in a way to minimise voxel manipulation and cut through occasional obstacles. You might even have some sort of limit on how many voxels you can manipulate, similarly to how we have a PCU limit for blocks, so you would use your voxel manipulation budget thoughtfully. And of course, not all biomes and planets might be really suitable for wheeled transport. Although I'd like for planet designers to put a little bit more thought into making at least a good portion of them suitable for that, maybe intentionally adding some terrain features to cut through the "jugginess" so you can explore planets on wheels much easier and avoid excessive voxel manipulation for making "roads".
Agree with Semtex about the 3 main issues, although they can mostly be solved with a single "shovel" block and a clever engineering.
When activated, it would work similarly to the box-shaped voxel manipulation tool we have in Creative, but it would add and remove voxels at the same time.
It would depend on how far the shovel is from the surface. If you move the shovel deeper, it removes voxels, while raising it above the surface adds voxels.
However, the voxels are not created nor destroyed. The shovel has a "virtual" range bubble, similar to the range we have for a welder block, for example. When adding voxels, it tries to borrow them from nearby within that range. When removing voxels, it tries to push them to the sides. If there is no room to push the voxels, it stops removing them, and the shovel eventually touches the ground and stops. Similarly, when you raise the shovel, it grabs voxels from nearby until it can't anymore.
So let's see what we can actually do with this shovel.
First, we can finally smooth the terrain easily, filling gaps and holes. With a bit of engineering and skill, you can do much more. You can basically move the ground around like with a real shovel :)
If you need more voxels, you can push them in from the sides. Conversely, if you need to dig down a bit, you can push the excess voxels to the sides or dig with drills.
There might still be challenges if you want to create a perfectly flat surface without "spilling" unnecessary voxels around the shovel. This is where the engineering part starts to play a role. Positioning additional shovel blocks on the sides at certain angles could help you make the voxels behave the way you want. By building specific machines, you could finally make flat surfaces, walls, ramps, and all sorts of different shapes.
And ofc, you could use a shovel to make paths for wheeled vehicles to traverse the terrain much more easily. Not a proper road, but at least you could smooth the terrain, make gentle slopes and ramps, create the voxel sections of bridges, parking areas, and so on. The hanging part of a bridge can still be made out of blocks, while the approaches are formed with voxels.
The goal is not to modify 20km of terrain. This is not good for many reasons. First, loading performance and world save file size. The more changed the terrain, the longer it takes to load those changes and stream in multiplayer. But there is also a practical gameplay reason. Wheeled vehicles in this game are still perfectly capable of traversing slightly uneven terrain. There is no practical need to make perfect roads. You won't be making highways, instead you will most likely try to make a road following the terrain in a way to minimise voxel manipulation and cut through occasional obstacles. You might even have some sort of limit on how many voxels you can manipulate, similarly to how we have a PCU limit for blocks, so you would use your voxel manipulation budget thoughtfully. And of course, not all biomes and planets might be really suitable for wheeled transport. Although I'd like for planet designers to put a little bit more thought into making at least a good portion of them suitable for that, maybe intentionally adding some terrain features to cut through the "jugginess" so you can explore planets on wheels much easier and avoid excessive voxel manipulation for making "roads".
P.s, even if you don’t specifically want these ideas, what about small scale, something as simple as tyres leaving tracks, overtime those tracks become regular routes or roads for you, built a quarry / mine far from base? Drive there enough times and eventually you’ll have your own track / path
P.s, even if you don’t specifically want these ideas, what about small scale, something as simple as tyres leaving tracks, overtime those tracks become regular routes or roads for you, built a quarry / mine far from base? Drive there enough times and eventually you’ll have your own track / path
If the road system was extensive, it may require another planetary data layer. Another layer could carry non-natural non-grid features which could be referenced when showing terrain. This could be farms, roads, and other landscape engineering projects. (may be!) Probably not as detailed as normal voxel mining.
If the road system was extensive, it may require another planetary data layer. Another layer could carry non-natural non-grid features which could be referenced when showing terrain. This could be farms, roads, and other landscape engineering projects. (may be!) Probably not as detailed as normal voxel mining.
With the current terrain, using any Heavy logistics vehicle is inefficient, but having roads that are easily made from voxels instead of blocks could be the way to go. Given its worth the hassle to build a road. Also, having the waste product stone being turned into gravel and used as voxel material, or further processed into concrete for blocks/voxels.
With the current terrain, using any Heavy logistics vehicle is inefficient, but having roads that are easily made from voxels instead of blocks could be the way to go. Given its worth the hassle to build a road. Also, having the waste product stone being turned into gravel and used as voxel material, or further processed into concrete for blocks/voxels.
Great thinking people, glad we’re on the same page about it
Great thinking people, glad we’re on the same page about it
When mining the ground in SE1, you received gravel. By having an alternate mining tool for turning voxels into gravel, we could then make concrete. This could then be re-applied to the terrain with another voxel-hand tool. I think this would be the most straightforward way to have voxel manipulation in survival using the mechanics that already exist in SE2.
When mining the ground in SE1, you received gravel. By having an alternate mining tool for turning voxels into gravel, we could then make concrete. This could then be re-applied to the terrain with another voxel-hand tool. I think this would be the most straightforward way to have voxel manipulation in survival using the mechanics that already exist in SE2.
It would be nice if we could build roads and modify the terrain.
That got me thinking—how complicated is it to describe such terrain modifications in a file storage system?
The planet’s surface (terrain) is described unambiguously in some way so that it appears the same to all players. Similarly, the “underground” areas that players create during the game must be described in some way.
In SE1, I noticed that newly created areas aren’t entirely stable; after several consecutive loads and saves, minor but noticeable changes occurred (as if the area’s description were being optimized in some way with each subsequent save).
I’ve come to the conclusion (though I’m not sure if it’s correct) that the “excavation area” is described in the save file as the surface of some complex “hollow” object. This could completely change the situation when describing underground spaces and paths. An underground space may have a large volume but a relatively small surface area. Conversely, an object such as a road will have a relatively small volume (in many places its height will be less than a meter), but a relatively very large surface area, because the road network will be hundreds of meters—or rather, many kilometers—long.
How does this look from a data perspective?
To cover the surface of an “object” with a grid of points spaced half a meter apart, I need an average of five points per square meter.
Let's assume we have a base—an underground facility consisting of two 10x10x50-meter caverns for storage and production facilities, one 30x30x200-meter underground hangar, and 200 meters of connecting tunnels measuring 3x3 meters. This gives us a surface area of 32,600 m² and 163,000 points.
Let’s consider a road (or road network)—a surface structure with an average height/depth of 1 meter, a trench/road width of 6 meters (a standard two-lane road), and a length of 3 km. The surface area is 42,000 m² and 210,000 points.
And a 3-km-long road network—that’s barely enough for a minimal connection between four objects within a 1-km radius...
We can see, then, that the amount of data required to describe the route created by a player in the terrain tends to grow very quickly. This apparently poses a significant threat to the game's stability.
It would be nice if we could build roads and modify the terrain.
That got me thinking—how complicated is it to describe such terrain modifications in a file storage system?
The planet’s surface (terrain) is described unambiguously in some way so that it appears the same to all players. Similarly, the “underground” areas that players create during the game must be described in some way.
In SE1, I noticed that newly created areas aren’t entirely stable; after several consecutive loads and saves, minor but noticeable changes occurred (as if the area’s description were being optimized in some way with each subsequent save).
I’ve come to the conclusion (though I’m not sure if it’s correct) that the “excavation area” is described in the save file as the surface of some complex “hollow” object. This could completely change the situation when describing underground spaces and paths. An underground space may have a large volume but a relatively small surface area. Conversely, an object such as a road will have a relatively small volume (in many places its height will be less than a meter), but a relatively very large surface area, because the road network will be hundreds of meters—or rather, many kilometers—long.
How does this look from a data perspective?
To cover the surface of an “object” with a grid of points spaced half a meter apart, I need an average of five points per square meter.
Let's assume we have a base—an underground facility consisting of two 10x10x50-meter caverns for storage and production facilities, one 30x30x200-meter underground hangar, and 200 meters of connecting tunnels measuring 3x3 meters. This gives us a surface area of 32,600 m² and 163,000 points.
Let’s consider a road (or road network)—a surface structure with an average height/depth of 1 meter, a trench/road width of 6 meters (a standard two-lane road), and a length of 3 km. The surface area is 42,000 m² and 210,000 points.
And a 3-km-long road network—that’s barely enough for a minimal connection between four objects within a 1-km radius...
We can see, then, that the amount of data required to describe the route created by a player in the terrain tends to grow very quickly. This apparently poses a significant threat to the game's stability.
Would love some kind of tool for this ... I spent over a hundred hours building a road 😅 800 meters+ in elevation and about 2km long, from the top of one biome halfway down the cliff face into a valley. It was painful, but when it was done and the rover was on it ... it sure was full of nice views. Would love to be able to more easily do that kind of thing in the future though.
Would love some kind of tool for this ... I spent over a hundred hours building a road 😅 800 meters+ in elevation and about 2km long, from the top of one biome halfway down the cliff face into a valley. It was painful, but when it was done and the rover was on it ... it sure was full of nice views. Would love to be able to more easily do that kind of thing in the future though.
Road construction in SE faces three main problems:
- The “drilling” equipment cannot produce a sufficiently smooth surface if the machine’s speed changes. It is very difficult to continue road construction seamlessly if the machine stops and / or leaves the route.
- In SE1, a huge amount of “waste” (crushed stone/gravel) is generated, which cannot be effectively removed from the construction site (there is no simple way for a machine to “lift” an entire “free-floating” boulder lying on the ground)
- It is extremely difficult to create a road with uniform ascents and descents or regular curves. There is no practical and functional method for “surveying the route.”
Road construction in SE faces three main problems:
- The “drilling” equipment cannot produce a sufficiently smooth surface if the machine’s speed changes. It is very difficult to continue road construction seamlessly if the machine stops and / or leaves the route.
- In SE1, a huge amount of “waste” (crushed stone/gravel) is generated, which cannot be effectively removed from the construction site (there is no simple way for a machine to “lift” an entire “free-floating” boulder lying on the ground)
- It is extremely difficult to create a road with uniform ascents and descents or regular curves. There is no practical and functional method for “surveying the route.”
Agree with Semtex about the 3 main issues, although they can mostly be solved with a single "shovel" block and a clever engineering.
When activated, it would work similarly to the box-shaped voxel manipulation tool we have in Creative, but it would add and remove voxels at the same time.
It would depend on how far the shovel is from the surface. If you move the shovel deeper, it removes voxels, while raising it above the surface adds voxels.
However, the voxels are not created nor destroyed. The shovel has a "virtual" range bubble, similar to the range we have for a welder block, for example. When adding voxels, it tries to borrow them from nearby within that range. When removing voxels, it tries to push them to the sides. If there is no room to push the voxels, it stops removing them, and the shovel eventually touches the ground and stops. Similarly, when you raise the shovel, it grabs voxels from nearby until it can't anymore.
So let's see what we can actually do with this shovel.
First, we can finally smooth the terrain easily, filling gaps and holes. With a bit of engineering and skill, you can do much more. You can basically move the ground around like with a real shovel :)
If you need more voxels, you can push them in from the sides. Conversely, if you need to dig down a bit, you can push the excess voxels to the sides or dig with drills.
There might still be challenges if you want to create a perfectly flat surface without "spilling" unnecessary voxels around the shovel. This is where the engineering part starts to play a role. Positioning additional shovel blocks on the sides at certain angles could help you make the voxels behave the way you want. By building specific machines, you could finally make flat surfaces, walls, ramps, and all sorts of different shapes.
And ofc, you could use a shovel to make paths for wheeled vehicles to traverse the terrain much more easily. Not a proper road, but at least you could smooth the terrain, make gentle slopes and ramps, create the voxel sections of bridges, parking areas, and so on. The hanging part of a bridge can still be made out of blocks, while the approaches are formed with voxels.
The goal is not to modify 20km of terrain. This is not good for many reasons. First, loading performance and world save file size. The more changed the terrain, the longer it takes to load those changes and stream in multiplayer. But there is also a practical gameplay reason. Wheeled vehicles in this game are still perfectly capable of traversing slightly uneven terrain. There is no practical need to make perfect roads. You won't be making highways, instead you will most likely try to make a road following the terrain in a way to minimise voxel manipulation and cut through occasional obstacles. You might even have some sort of limit on how many voxels you can manipulate, similarly to how we have a PCU limit for blocks, so you would use your voxel manipulation budget thoughtfully. And of course, not all biomes and planets might be really suitable for wheeled transport. Although I'd like for planet designers to put a little bit more thought into making at least a good portion of them suitable for that, maybe intentionally adding some terrain features to cut through the "jugginess" so you can explore planets on wheels much easier and avoid excessive voxel manipulation for making "roads".
Agree with Semtex about the 3 main issues, although they can mostly be solved with a single "shovel" block and a clever engineering.
When activated, it would work similarly to the box-shaped voxel manipulation tool we have in Creative, but it would add and remove voxels at the same time.
It would depend on how far the shovel is from the surface. If you move the shovel deeper, it removes voxels, while raising it above the surface adds voxels.
However, the voxels are not created nor destroyed. The shovel has a "virtual" range bubble, similar to the range we have for a welder block, for example. When adding voxels, it tries to borrow them from nearby within that range. When removing voxels, it tries to push them to the sides. If there is no room to push the voxels, it stops removing them, and the shovel eventually touches the ground and stops. Similarly, when you raise the shovel, it grabs voxels from nearby until it can't anymore.
So let's see what we can actually do with this shovel.
First, we can finally smooth the terrain easily, filling gaps and holes. With a bit of engineering and skill, you can do much more. You can basically move the ground around like with a real shovel :)
If you need more voxels, you can push them in from the sides. Conversely, if you need to dig down a bit, you can push the excess voxels to the sides or dig with drills.
There might still be challenges if you want to create a perfectly flat surface without "spilling" unnecessary voxels around the shovel. This is where the engineering part starts to play a role. Positioning additional shovel blocks on the sides at certain angles could help you make the voxels behave the way you want. By building specific machines, you could finally make flat surfaces, walls, ramps, and all sorts of different shapes.
And ofc, you could use a shovel to make paths for wheeled vehicles to traverse the terrain much more easily. Not a proper road, but at least you could smooth the terrain, make gentle slopes and ramps, create the voxel sections of bridges, parking areas, and so on. The hanging part of a bridge can still be made out of blocks, while the approaches are formed with voxels.
The goal is not to modify 20km of terrain. This is not good for many reasons. First, loading performance and world save file size. The more changed the terrain, the longer it takes to load those changes and stream in multiplayer. But there is also a practical gameplay reason. Wheeled vehicles in this game are still perfectly capable of traversing slightly uneven terrain. There is no practical need to make perfect roads. You won't be making highways, instead you will most likely try to make a road following the terrain in a way to minimise voxel manipulation and cut through occasional obstacles. You might even have some sort of limit on how many voxels you can manipulate, similarly to how we have a PCU limit for blocks, so you would use your voxel manipulation budget thoughtfully. And of course, not all biomes and planets might be really suitable for wheeled transport. Although I'd like for planet designers to put a little bit more thought into making at least a good portion of them suitable for that, maybe intentionally adding some terrain features to cut through the "jugginess" so you can explore planets on wheels much easier and avoid excessive voxel manipulation for making "roads".
I believe that with the right approach to describing excavations and embankments—essentially by optimizing the tessellation of their surfaces—the amount of data needed to describe them need not be particularly large.
Here’s my idea: a road is being built in the terrain. The surface isn’t perfect; depending on the orientation of the voxels, it’s uneven in various places, with small peaks and depressions.
The final step in the construction process is applying a “concrete” layer. From the player’s perspective, this simply involves coloring the road’s voxel surface with a specific shade of gray.
From the engine’s perspective, however, it’s different. It’s a signal to perform an extensive restructuring of the surface description. A large number of vertices are removed from the road surface and the side slopes so that the surface approximates smooth curves as closely as possible—the surface is described as maximally smooth, the triangles are large, and their “height” extends across the entire width of the road (“concrete strip”). The positions of the vertices are adjusted so that they follow the theoretical smooth curves as closely as possible.
Such a surface reconstruction should lead to a significant simplification of the surface shape and, consequently, to a significant simplification of the road’s description.
Large triangles might not look good under variable lighting conditions, but I believe this problem could be solved by choosing appropriate textures and surface reflectivity properties.
Translated with DeepL.com (free version)
I believe that with the right approach to describing excavations and embankments—essentially by optimizing the tessellation of their surfaces—the amount of data needed to describe them need not be particularly large.
Here’s my idea: a road is being built in the terrain. The surface isn’t perfect; depending on the orientation of the voxels, it’s uneven in various places, with small peaks and depressions.
The final step in the construction process is applying a “concrete” layer. From the player’s perspective, this simply involves coloring the road’s voxel surface with a specific shade of gray.
From the engine’s perspective, however, it’s different. It’s a signal to perform an extensive restructuring of the surface description. A large number of vertices are removed from the road surface and the side slopes so that the surface approximates smooth curves as closely as possible—the surface is described as maximally smooth, the triangles are large, and their “height” extends across the entire width of the road (“concrete strip”). The positions of the vertices are adjusted so that they follow the theoretical smooth curves as closely as possible.
Such a surface reconstruction should lead to a significant simplification of the surface shape and, consequently, to a significant simplification of the road’s description.
Large triangles might not look good under variable lighting conditions, but I believe this problem could be solved by choosing appropriate textures and surface reflectivity properties.
Translated with DeepL.com (free version)
Replies have been locked on this page!