Optimize game engine

[Ghent96]

below, please find suggestions from the community on how to optimize your game engine, increasing client-side FPS rates and reducing server-side CPU lag (heavy load). Everyone feel free to contribute:

1) collisions - game is doing way too many calculations still, and rail entities made this much worse. Consider turning off collision checks for turret-docked entities, or at least allowing servers to choose their own yes/no value in the config.

2) bounding boxes - similar intent to optimize collisions. Ships need proper collision detection and bounding boxes. After a ships is built, and a blueprint saved, allow players to "weld" the ship. This is a 1-time operation by the server that calculates a collision mesh /bounding box for the ship, and removes the ability to add new bloxks onto the ship. It can be repaired from the original blueprint to restore lost blocks in combat, or unwelded, in a shipyard only. Calculating such a mesh will also allow better & lower LODs of ships/stations when far away, and offer extreme improvements in framerate.

3) easier config options to turn off animated textures

4) easier / clearer config options to turn off sector/planet rotations.

5)

6)

7)

8)

9)

10)

(some above left blank to edit later when other suggestions come in)

 

[Megacrafter127]

below, please find suggestions from the community on how to optimize your game engine, increasing client-side FPS rates and reducing server-side CPU lag (heavy load). Everyone feel free to contribute:

1) collisions - game is doing way too many calculations still, and rail entities made this much worse. Consider turning off collision checks for turret-docked entities, or at least allowing servers to choose their own yes/no value in the config.

2) bounding boxes - similar intent to optimize collisions. Ships need proper collision detection and bounding boxes. After a ships is built, and a blueprint saved, allow players to "weld" the ship. This is a 1-time operation by the server that calculates a collision mesh /bounding box for the ship, and removes the ability to add new bloxks onto the ship. It can be repaired from the original blueprint to restore lost blocks in combat, or unwelded, in a shipyard only. Calculating such a mesh will also allow better & lower LODs of ships/stations when far away, and offer extreme improvements in framerate.

3) easier config options to turn off animated textures

4) easier / clearer config options to turn off sector/planet rotations.

1) what happens to turrets, that moved into their mothership, and then turret collision is turned on again? Are they supposed to be reset, or do they remain stuck, causing permanent collisions? If the former, how to efficiently check that? What if the reset position is blocked by blocks that were built after the turret was rotated a bit?

2) Unless the shape of your ship is very simple, I don't see how creating a collision mesh would help, especially if it would have to be updated with every lost block.

3) The animated textures, at least from what I know and hear, do not impact performance at all. All 4 of the cycled textures are in the same sheets, meaning all are loaded anyways, and the cycle itself is too slow to cause any impact, especially since only UV coordinates have to be switched. There is no reason against such an option, but there are much better ways to increase performance.

4) Already the case, unless you know a more easy way than to set a single setting to -1 [and the behaviour of that setting is also described in the comment of that setting in the config file]

 

[kookster]

1. I feel this needs to be improved too, but I don't think removing it all together is the best solution, what that solution might be I wish I could give more input.

2. I don't think this would actually help. Even if you have a very simple ship design say a giant hole gets blown in it, do you really want to have a invisible wall because that is where the ship once was? otherwise you have to take the damage into account.

3. I feel this would only effect really low end computers, I have never had a issue. Could it be done? Yes, but I think other things could be done.

 

[jayman38]

1. I had an idea here on how to reduce collision checks, starting with simple rail-docked entities. (Summary: Essentially turning off collision checks between the root entity and the docked entity after verifying zero collisions along the entire movement path.) Collisions would either have to be re-instated when the docked entity becomes undocked, or else there needs to be a special event to handle undocked entities.

2. I think I read somewhere that ships already have a bounding box. Now, whether it is being used in every place it should, such as fleet operations, is another matter. On the other hand, a simplified LOD-enabled mesh that reflects the ship's undamaged surfaces would have a great many uses, including holographs, and would only be used for LOD when the ship is either undamaged (I imagine the ship would be in an undamaged state for at least 90% of it's operational lifetime) or very far away from the observer, where non-catastrophic battle damage is not normally noticeable anyway.

3. Everybody keeps saying that animated textures do not affect performance, but I have had personal experience with a moderately powerful computer, inside the shell of a medium-sized ship (about 200m long and about 81m in diameter), when I have put down thousands of system blocks and hundreds of them are blinking at me, while I think about how to fill the shell efficiently, my game measurably slows down and becomes "choppy". When I'm looking at an equal number of static-frame blocks (for example, large greebled walls of armor blocks with static textures), I do not experience that chop. It may be dependent on GPU chipsets, but it would be better to have a game setting to stay on the first frame, rather than demand that everyone with a slow-down problem update their GPU (not a cheap prospect).

 

[Ghent96]

Yes, to those that have actually tested it, there is (depending on your computer stats ofc) a small to HUGE difference in performance by turning off animated textures. So, that said, having proof, I can not personally waiver on #3.
[DOUBLEPOST=1466824994,1466824754][/DOUBLEPOST]

...2) Unless the shape of your ship is very simple, I don't see how creating a collision mesh would help, especially if it would have to be updated with every lost block...

Aye, but this is why I suggest a "weld" operation. That finalizes the collision mesh until the ship is either destroyed or unwelded in a shipyard. The point is to avoid updates with every lost block (like current) and enhance performance.

 

[Megacrafter127]

The point is to avoid updates with every lost block (like current) and enhance performance.

So when a ship is welded no individual blocks can be destroyed at all? And if they can be destroyed, the mesh WILL have to be updated, otherwise incoming projectiles may hit the mesh where the block is already destroyed, meaning the damage goes nowhere[apart from shields], Or which block should be hit in that case? The next in line, that would require raytracing, which[unless the weapon is a beam-weapon, because it already is a raytrace] is likely more expensive and would require creating a new mesh anyways. This new mesh also cannot be localized, as there is no guarantee how small the hole actually is.
From what I can gather and make educated guesses about, while making such meshes may increase performance greatly for large simple shapes, once the ship takes blockdamage, the benefits are mostly lost, if you want the game to be consistent.
And if collision damage is enabled, the benefits will cease very quickly, as the use for collision meshes[detecting collisions] will in many cases destroy some blocks, and thus force a regeneration of the mesh anyways, which is relatively expensive.

 

[Madman198237]

We literally can't avoid updates with every lost block. That'd just be a mess, as Megacrafter is explaining. What we could potentially do is remove child/parent entity collision checks. There was a suggestion thread a couple of days ago that explained a series of ever-more-complex yet more useful steps in reducing parent/child collision checks.