Floating voxels in gravity should turn to pick-up deposits.

Poop da garoomph indeed.

It's simpler if it's only in natural gravity wells and only run the calculation when a player is within the area. Thus the only 'main'object would be the source of the gravity (i.e. the planet) and any voxels inside said gravity well that aren't connected to 'planet' are converted to what you'd get when you dump a bunch of ore out of a connector and dropped by a player. For planets it's a one-time check that simply cleans up the ones that are leftover from game creation. After that it's only a matter when a player is in the area and drilling actively. Anything that gets separated from 'planet' turns into something a player can pick up. i.e. there is some advantage to chopping off that pillar, since the extra stuff would also turn into pick-up-able stuff. From SE1 engine, there is also a risk of these floating falling objects falling on (injuring) your space buddy, which adds a level of risk to such things as well.

It should be sufficient if the check happens once at game start and otherwise only when the player is digging. Voxel damage from weapons fire would count as digging.

The check algorithm could also serve as a debugging tool that helps the devs find those loose voxels an analyze why they are there in the first place.

In SE1, free voxels often appeared when generating asteroids with cavities. It appeared as though an “undesirable part” (presumably an “excess” ore deposit) was removed in the form of a bubble, and free voxels formed where the spherical bubble intersected the asteroid’s surface. Sometimes this resulted in literal lattice structures—thin plates with regularly spaced holes. Similarly, free voxels formed during the creation of boulders floating above the asteroid’s surface—free voxels appeared between such boulders and between groups of boulders and the asteroid’s surface, at the point where the “stem” at the end of which the group of boulders was located had apparently been removed.

The bubble-like cavities in the asteroids seemed very unnatural to me—they didn't match my idea of what an asteroid should look like.

And yes, I agree with the view that when generating voxel objects, greater control over "free voxels" is necessary.

I don't have a clear idea of how this should or could work.

There are two natural ways for an asteroid to form:

the first process involves the aggregation and coalescence of smaller objects into larger ones, much like a snowball or a clump of clay. The forming object isn’t very cohesive; rather, it’s just a loosely bound pile of boulders, rocks, sand, and dust held together by weak gravity and perhaps water ice (i.e., essentially frozen mud).

However, once such an object reaches a sufficient size, its interior can undergo melting and “sintering.”

The second process is fragmentation during collisions. This is apparently quite similar to the collision of water droplets in a weightless state—at low collision speeds, the droplets merge into larger ones; at high speeds, they shatter into smaller droplets. In the process, solid material such as rocks, sand, and dust can heat up significantly—and undergo melting and sintering (including heat-induced chemical reactions, such as the melting of iron and the like). So much for the physics behind it...

I don’t know how it’s supposed to work in an asteroid generator—I’m not a programmer. In any case, the result of the generation process should be roughly “spherical” and “ellipsoidal” objects (albeit with various deformations), or clusters of such objects. Not very many—typically two or three, five at most....

There are already a considerable number of images of real asteroids and cometary nuclei available on the internet. It’s reasonable to assume that they represent a fairly representative sample of “small bodies in the solar system,” and there’s no rational reason to assume that they look significantly different around other stars. So an asteroid generator should produce objects that are mostly similar in appearance.

I get it—it’s a bit boring and monotonous, but space isn’t Disneyland...

Translated with DeepL.com (free version)

You'd only need to check for floating voxels when the drill is activated & the terrain is modified. Searching the octree for orphans (separate groups) should be fairly cheap. Just evaporate the group when it becomes smaller than a certain size.

Hopefully this doesn't affect the creative voxel tool, as it can cause issues for creators working with or intending for floating geometry.

i think the biggest problem is the spikey hollow asteroids, and things that are obviously floating in gravity and shouldnt be there.

Best evaluate the idea on the practical merits of its impact and benefits on gameplay/user experience, and let the devs evaluate how hard it is to do on their new game engine.

As for the drill radius, this suggestion also captures the scenario for say someone drills under a large hill until the whole hill is unsupported by anything 9maybe using some giant vehicle drill setup). All the unsupported stuff should vanish into a puff of programmed logic and fall to the ground as resources.

Tael - In principle, yes, that would be a good, simple, and straightforward solution to the problem of hidden and leftover voxels. The drill function in "voxel destruction" mode (without resource mining) would remain unchanged.

Wilhelm - It's basically the same problem with grids.

You create a support, place a static grid on it, and then dismantle the support... And voilà! You have a levitating palace.

That's a setting in SE1, though, 'allow unsupported grids', in either case, free floating stuff in gravity always breaks my immersion, whether it's grid or voxel.

True, hitting those floating voxels can be quite difficult. Refining the code for that would mostly solve the problem. Perhaps not as satisfyingly, but you could at least get rid of loose voxels.

Well, if you explore verdure (for example) for a little bit you see caves that have hovering voxels also, so it's not just player activity creating them. This baseline logic would clean it all up.

take it further, just make floating voxels get deleted after 20 minutes

yeah, agree. My visal feedback making them pick-upable deposits is the visual when mining and the (slim) possibility that if you don't plan carefully you could get crushed by giant falling rocks of massive iron ore boulders that fall on you if you're carving a ledge away at the base. That too is engineering.

Also, in theory when the explosives get put in place soon, you could blow up the base of some pillar and then alk around and pick up the 'debris' of the rest of the pillar, and maybe any floating voxels that get converted to ore get blasted in every direction as flying debris.

Edit: meant to reply to the whole original post.

I like where you're going with this, but along with the performance problems, there's also the issue of where you draw the line for size. If I dig in a plane under an entire mountain and disconnect it from the planet, should it go "poof" and drop a bajillion loose rocks on the ground? Which part stays and which disappears? Because my second instinct is to troll everyone on a server by drilling to the middle of a planet and carving out the core, which might make the entire planet disappear.

In reality, it is impossible to create a hollow space underground on Earth at a depth greater than approximately 8–10 km. When filled with water or a liquid of similar density, it is possible to drill to a depth of 12–14 km. The pressure from the surrounding rock is so immense (hundreds of MPa) that the borehole would close up in a very short time (and thus cease to exist).

Not suggesting they do stress calculations on the voxels to see if they are 'supported enough'. Simply, if they aren't connected to the main planetary voxel, they they go poof. Feel free to dig your underground base.

In various SE1 scenarios and games, I’ve lost at least six underground bases “due to system mechanics.”

And it wasn’t because the caverns collapsed when the rock massif lost stability. :)

I'm fascinated, I've never seen anything like that, please elaborate.

The cause is usually a combination of several events/phenomena/processes—a prolonged absence of the player from the base and, apparently, from the planet as well; power outages; the system’s “garbage collection”; repeated “manual saving”; and so on.

In just one game, thanks to repeatedly saving the game with new positions (I was saving it for other reasons), I managed to figure out what probably happened... For an unknown reason, uranium consumption spiked/stocks plummeted in the reactors, and in the next save three game hours later, the underground portion of the base no longer existed. The surface installations, however, remained intact.

But I recognize/realize the base had disappeared until only about a hundred hours of gameplay and about forty saves later, so going back to old saave and to rescue the lost base no longer made sense.

By the time the base was destroyed, I had already been off the planet for about 50–70 in-game hours (roughly two weeks of real time), and I found out about the base’s destruction about a month later in real time.

Oh yeah, garbage collection in SE1 (and 2 so far) has issues. I've had grids vanish from garbage collection at various times definitely. Curious if there is extra logic specific to grids that are underground in this case. I've buried bases in the sides of mountains and underground but never noticed different behavior. I've only played solo (or self-hosted) so I can't comment if it's an online shared server.

But yeah... The base was gone, and this pile of debris is left.

There are about three hundred pieces of it — it's a crater filled with debris.

The advantage of playing solo is that I can customize and set up the world to my preferences.

I totally agree about the complexity… How precise does it have to be? A certain threshold diameter? If drilling would cause a large floating voxel, mass should probably be in play (ie fall/collision damage). You probably also do not want the chunk to automatically convert to corresponding ore, that would then become an exploit (ie drill around the ore patch then collect everything).

The voxel already has a material assigned to it. A “free voxel” converted into a piece of rock would therefore retain the voxel’s material—the result would be either a piece of rock or a piece of ore. Or it might disappear… it would depend on the behavior rules. The key is to remove the free voxel, which is practically invisible but very rigid and poses a risk to the movement of ships and characters.

the complexity of it would (or should) just end up as floating items generally ends up. excess of Xnumber of floating ore get cleaned up by the debris filter. a "large" chunk of ore thats thousands of kg could be broken into a given number of component parts and if it exceeds the max number of debris, it can just default to the max.

Premature, I guess, I'm still seeing lots of floaters.

That would help, but depending on spacing, you can still run into the exact same problem.

Exactly, apart from player activity, this logic would need to happen once at load.