Simulation Granularity/Resolution
Posted: Thu Nov 05, 2015 12:29 pm
To make this simple I'll start with asking you consider this question:
Because currently if there is a ship in the same star system as you then I believe that it has the full physics simulation, collision testing, docking procedures and all other real time game simulation code.
I think that this is a little strange when you think about it.
For the games graphics we have the concept of LOD or "Level-of-Detail". In practice this means that we have multiple version of the same model from a high polygon count to a very low polygon count.
When a model is close to the player we show them the high detail model, and when it is far away we show them the lowest detail model.
This is true of the terrain as well with our terrain patch system based on a quad-tree.
Drawing the high detail models when an object is only a couple of pixels across on the screen would be a waste, you cannot see that detail and so it does not need to be drawn, but processing the geometry and scenegraph for a high detail model is still expensive compared to the low detail model.
With the games simulation however we are in effect using the high-LOD-physics everywhere and at all time accelerations. This recently came up whilst discussing #3508 because at the higher time accelerations the time step is so large a ship might travel 100km into the surface of a planet during a single game "tick".
Simulating the game at this level is computationally expensive, doing the physics collision test for dozens/hundreds of ships landing/departing at stations alone must be a significant portion of our CPU time, yet I would argue that it has no benefit to the gameplay or to the player.
Arguably it detracts from the game because not only is CPU time wasted on this but the chances are that the AI makes more mistakes during flight/landing/docking and crashes their ship.
What alternatives do we have?
Andy
Code: Select all
If you cannot see, hear, or otherwise know of an AI piloted ship in the game then is it important to you that it be fully simulated even if the exact same outcome could be achieved using simpler techniques?
I think that this is a little strange when you think about it.
For the games graphics we have the concept of LOD or "Level-of-Detail". In practice this means that we have multiple version of the same model from a high polygon count to a very low polygon count.
When a model is close to the player we show them the high detail model, and when it is far away we show them the lowest detail model.
This is true of the terrain as well with our terrain patch system based on a quad-tree.
Drawing the high detail models when an object is only a couple of pixels across on the screen would be a waste, you cannot see that detail and so it does not need to be drawn, but processing the geometry and scenegraph for a high detail model is still expensive compared to the low detail model.
With the games simulation however we are in effect using the high-LOD-physics everywhere and at all time accelerations. This recently came up whilst discussing #3508 because at the higher time accelerations the time step is so large a ship might travel 100km into the surface of a planet during a single game "tick".
Simulating the game at this level is computationally expensive, doing the physics collision test for dozens/hundreds of ships landing/departing at stations alone must be a significant portion of our CPU time, yet I would argue that it has no benefit to the gameplay or to the player.
Arguably it detracts from the game because not only is CPU time wasted on this but the chances are that the AI makes more mistakes during flight/landing/docking and crashes their ship.
What alternatives do we have?
- Instant-docking: could be used when an AI ship gets close to it's destination station, close being defined based on the level of time acceleration and how far from the player.
- Disable-Collision: simply disable collision testing for ships in certain circumstances, deep space, approaching planet etc, all based on distance from the player like LOD.
- Other ideas: We really need to profile what costs us the most on a per-frame basis and go from there.
Andy