Page 1 of 1

Simulation Granularity/Resolution

Posted: Thu Nov 05, 2015 12:29 pm
by FluffyFreak
To make this simple I'll start with asking you consider this question:

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?
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?
  • 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.
Discuss! :)

Andy

Re: Simulation Granularity/Resolution

Posted: Thu Nov 05, 2015 4:17 pm
by impaktor
is it important to you that it be fully simulated

Sometimes I see the question "is it possible to fly from one system to the next using only thrusters?". There is a value in just knowing it is possible to do and that things are "correctly simulated", but as you said this comes at a cost. It is not worth it if it results in so few ships you never see them. Far better then to "cheat" (when the player isn't looking), and allow for more ships, more fun, and actually have traffic at the space ports.
doing the physics collision test for dozens/hundreds of ships landing/departing at stations alone must be a significant portion of our CPU time
I guess simulating the ships as point particles wouldn't help any, since you still have to do the collision check, (just with a simpler object)?
Drawing the high detail models when an object is only a couple of pixels across on the screen would be a waste
I was actually thinking about this when I read the GTA V rendering article about how they only render every other background pixel.

I think all your three points sound good.