PC Should Structural Integrity (S.I) be buffed?

S

sadpickle

New member
I love playing Minecraft with gravity, but sometimes it feels like I'm building with toothpicks. Certain materials, like Reinforced Concrete and Steel, are imo too flimsy, despite large HP values. Wide cantilevered decks are a disaster waiting to happen. Bridges require frequent supports. And so on.

SI should obviously remain in the game; it's integral to building well and the consequences of not supporting things are part of the fun. But everything feels super flimsy when you're trying to build big, dramatic structures. With A17 coming around the corner now is a perfect time to adjust the relevant values and Make Concrete Great Again.

 
Right now the structural integrity works on the edge of its (as an algorithm) possibilities. So the first buff would be to decrease the computational costs via different optimization techniques. Grouping the collections of blocks into groups of blocks, along with the usage of some heuristics could do the trick - the computations could become much less precise, but would increase the depth of checks and guarantee the collapse even for very big structures.

This would fix the problem of flying blocks, and would speed-up the collapsing process.

 
I think it's an interesting idea to buff, and not one I would oppose anyhow. It does seem to be somewhat flimsy compared to what you would expect.

It's a little like the bridge in the Navezgane canyon, that actually never could exist in the game due to SI, as it's just too far apart. With steel giving you some 15 (or 16?) distance, concrete some 7?, it does feel like re-balancing it higher could be worthwhile to make builds easier.

But I think a larger issue is more than while x blocks works great, x+1 causes a full collapse, and you have no real way of knowing until it all falls down. So a way to tell, whether it's a tool, or creaking/swaying or whatever would be very helpful.

Collapses are also very slow/CPU intensive, so fixing that in some way would also be useful. Dropping a big piece of land will freeze a server, as it soaks up all processing cycles on the drop, rather than gracefully handling it.

/V -

 
Right now the structural integrity works on the edge of its (as an algorithm) possibilities. So the first buff would be to decrease the computational costs via different optimization techniques. Grouping the collections of blocks into groups of blocks, along with the usage of some heuristics could do the trick - the computations could become much less precise, but would increase the depth of checks and guarantee the collapse even for very big structures.
This would fix the problem of flying blocks, and would speed-up the collapsing process.
Click to expand...
Agreed. They shouldn't do nearest neighbor algorithms on the blocks, instead they should fetch the rasterized 3D-structure and do physics calculations on that via Phys-X on the GPU to determine what drops and where, in one big lump. Send this to the framebuffer and then recalculate the voxel grid based on the graphical result.

So in effect, don't even do SI calculations on the voxels at all. Do it on the 3D object.

 
Last edited by a moderator:
Agreed. They shouldn't do nearest neighbor algorithms on the blocks, instead they should fetch the rasterized 3D-structure and do physics calculations on that via Phys-X on the GPU to determine what drops and where, in one big lump. Send this to the framebuffer and then recalculate the voxel grid based on the graphical result.
So in effect, don't even do SI calculations on the voxels at all. Do it on the 3D object.
Click to expand...
Maybe ... it is hard to say if it is possible to do that without overcomplicating everything, especially in the case when the surface gets a very complicated shape. I don't have deep understanding on how Phys-X works, however, I heard that they use some techniques, that are similar (but simpler) to Finite element method ... and this can become computationally intensive as well, if the surface become complicated.

Another idea could be a multigrid, where there could be another couple of layers of pseudo world with pseudo voxels, e.g. 4x4x4 and 16x16x16. This would be cheap and would increase the total number of blocks by less than 2%. However, then a hash technique could be applied: each voxel would register in appropriate pseudo blocks on these layers (easy hash, by coordinates). These voxels would accumulate the properties of each pseudo block - how much mass it can hold from different sides. The calculations on 16x16x16 grid would be 4000 times faster, and could be used in different ways: as an heuristic (in some circumstances used as the final calculation) or as a bound determiner, i.e. it can be determined that even in the best case it is impossible to hold such a structure, so the calculations on 4x4x4 or 1x1x1 are unneeded.

What we would see in the game is that some structures would collapse by parts of sizes, for example 16x6x2 meters at the same speed it was done for 1 voxel before; some parts would fall sized like 3x2x3,4x2x1. As for mountain collapsing - it would drop by 16x16x16 blocks, meaning 1 second instead of an hour.

 
Last edited by a moderator:
I agree steel and reinforced concrete should have a much higher max load, like in the real world, and somehow one should be able to see the stress without the console.

 
The only thing I really don't like about current SI is how there's basically 2 (or 4) tiers of strenght, but it is not a gradual increase of strenght throughout the material upgrades.

Main issue I usually had with this circumstance would be a scrap structure holding up just fine (metal tier) but then collapsing, when upgrading it to concrete (stone tier) without putting temporary supports until the upgrade to steel (back to metal tier) is made.

 
You must log in or register to reply here.
Back
Top