Potential way to improve game performance, if not yet implemented
Originally I sent this by mail directly to support@keenswh bc it is not an idea to vote/debate but rather about game internal programming details from performance standpoint. The support however suggested to add this thing here, too.
I could write here that I am a software developer since 25 years and computer graphics hobbyist, and I like SE so much, but I just don't want to waste your time :)
So let's get to work: :)
I would like to ask the SE dev team about a certain aspect of the game/engine, and if logically merging adjacent blocks is implemented or could improve game performance.
B/c I have seen significant number of players complaining about game performance on forums, I've checked a certain detail of the game that maybe it is an open path toward further optimization, I don't know.
Idea is about internally logically merging adjacent blocks when a block is added to the grid in order to reduce number of triangles/vertices.
I noticed that placing for e.g. 2 conveyor junction blocks on a large grid they increase the number of triangles of the grid they belong to, with the same amount of triangles (at least based on the info exposed on Info tab of the game UI) no matter if the 2 newly blocks are adjacent or not.
It is likely that SE already brainstormed this. So question is what if/does the game internally recalculates the resulting mesh as blocks are added?
Maybe the game keeps an internal representation of the grid that already takes into account adjacent faces so the internal grid mesh already is stripped off of adjacent faces, this internal mesh triangle count is just not exposed to the grid's Info tab in the game.
However, if the mesh resulting after adding a block does not recalculate stuff from adjacent/hidden face/area standpoint then there could be a possible track toward game performance improvements.
- considering just from visual standpoint internal vertices/triangles do not really matter so the resulting grid can be replaced by a recalculated grid with fewer vertices/triangles
- I am not that familiar with non-visual details, but I think that details regarding the physics can also be recalculated for the simpler, resulting grid
- textures should also be remapped I guess
The bigger the grid is the more this potential recalculation getting rid of internal details of the grid reduces the amount of triangles building up the grid, so the potential performance gain increases with the size of the grid, b/c surface is increasing much slower than volume as we know at least for areas not having holes (e.g. floors, walls etc).
If the resulting grid is not recalculated to get rid of the internal details that (at least theoretically) can be dropped, these unneeded details are taken into consideration for every frames generated, again and again, perhaps tens of millions of times during a game session.
Because recalculating the resulting mesh is required just when blocks are added or removed vs. carrying the internal grid details with for every frame, maybe this approach could lead to significant game performance improvement. Especially considering that the recalculation of the resulting grid can be done between the block about to be added and the already simplified internal grid representation. I know that this simplification can be done from visual standpoint regarding number of polys and vertices for e.g. Blender provides this type of mesh simplification at merging meshes. I am less familiar with physics and texture recalculation in such a scenario, but I think these are also possible.
Holding references to the original block info, info about the original adjacent blocks can be re-read when a block is removed, so the approach is not more complicated on block removal either, I guess.
Thanks for reading!
Would be very grateful to know details/info/status of SE from this standpoint if SE is using such an optimization I described.