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.
I like this feedback
I have been wanting this for years!
If im not mistaken, this is how the armor blocks are supposed to work so that making a plane of armor results in one square textured face with the faces in between not rendering.
I have wanted this to be implemented for blocks such as thrusters, reactors, jump drives, and refineries since they are more often used in groups. By placing multiple side by side they could merge into a single unit thus simplifying ships and increasing the diversity of blocks. Thus from a UPS/FPS standpoint the server would only track the processes of one or two giant refineries as opposed to 20 and render it as such.
The way I had pictured it in my head is every block has 3 different shapes: Flat, Long, and Equilateral. An example of Flat would be the Jump drives, Long would be the refineries, and Equilateral would be the reactors. When the proportions match one of the three, it uses that geometry scaled to the appropriate size.
Ideas for features to engineer around could be requiring a minimum size or locked proportions. Possibilities are endless.
I have been wanting this for years!
If im not mistaken, this is how the armor blocks are supposed to work so that making a plane of armor results in one square textured face with the faces in between not rendering.
I have wanted this to be implemented for blocks such as thrusters, reactors, jump drives, and refineries since they are more often used in groups. By placing multiple side by side they could merge into a single unit thus simplifying ships and increasing the diversity of blocks. Thus from a UPS/FPS standpoint the server would only track the processes of one or two giant refineries as opposed to 20 and render it as such.
The way I had pictured it in my head is every block has 3 different shapes: Flat, Long, and Equilateral. An example of Flat would be the Jump drives, Long would be the refineries, and Equilateral would be the reactors. When the proportions match one of the three, it uses that geometry scaled to the appropriate size.
Ideas for features to engineer around could be requiring a minimum size or locked proportions. Possibilities are endless.
I've suggested the concept of multiblock for block combination merging into a simple block to not only reduce vertices but for create machines like minecraft did. But i was treated like a fool in forums
I've suggested the concept of multiblock for block combination merging into a simple block to not only reduce vertices but for create machines like minecraft did. But i was treated like a fool in forums
Armor blocks already merge, both the visual bits and the physics models. Given that entity blocks (non-armor blocks) can be virtually any shape and size, the very operation to remove such polygons would very likely be much slower than just rendering the polygons in the first place. Modern GPUs can push a fair number of polys quite nicely. This kind of removal is easy for armor blocks, because either the direct neighbor is blocking you completely, or it does not. There's only 6 positions to check. It's very very fast, and the armor models are already set up to easily and quickly cull faces. For entity blocks, there isn't even necessarily a "direct neighbor", so you'll have to scan further off.
Armor blocks already merge, both the visual bits and the physics models. Given that entity blocks (non-armor blocks) can be virtually any shape and size, the very operation to remove such polygons would very likely be much slower than just rendering the polygons in the first place. Modern GPUs can push a fair number of polys quite nicely. This kind of removal is easy for armor blocks, because either the direct neighbor is blocking you completely, or it does not. There's only 6 positions to check. It's very very fast, and the armor models are already set up to easily and quickly cull faces. For entity blocks, there isn't even necessarily a "direct neighbor", so you'll have to scan further off.
@Malware thx for your comment glad to get feedback from someone how knows the game details so well.
"the very operation to remove such polygons would very likely be much slower than just rendering the polygons in the first place." - this is true for sure, however what could be potentially a game changer is that:
- you need to remove these polys just when your grid is changed (block is added or removed) and not several tens of times per second endlessly like when rendering them
- the bigger your grid is the benefit of recalculating its internal representation is more and more significant as volume increases much faster than surface
I am sure the generic recalculation process would not be simple, but what I am more worried about in this context are the textures. How can textures applied to the resulting grid, having less vertices/voxels/polys? Any thoughts on that?
BTW, thx for the marvelous malware-dev/MDK-SE tutorial! I am programming like I said since 25 years and I have read many-many tutorials, and this one is among the bests I have ever read. I think you have an intrinsic talent to teach.
@Malware thx for your comment glad to get feedback from someone how knows the game details so well.
"the very operation to remove such polygons would very likely be much slower than just rendering the polygons in the first place." - this is true for sure, however what could be potentially a game changer is that:
- you need to remove these polys just when your grid is changed (block is added or removed) and not several tens of times per second endlessly like when rendering them
- the bigger your grid is the benefit of recalculating its internal representation is more and more significant as volume increases much faster than surface
I am sure the generic recalculation process would not be simple, but what I am more worried about in this context are the textures. How can textures applied to the resulting grid, having less vertices/voxels/polys? Any thoughts on that?
BTW, thx for the marvelous malware-dev/MDK-SE tutorial! I am programming like I said since 25 years and I have read many-many tutorials, and this one is among the bests I have ever read. I think you have an intrinsic talent to teach.
Replies have been locked on this page!