1
$\begingroup$

I am looking at many games like Dead Island 2, Red Dead Redemption 2, and Minecraft and I see that while the render distance grows, the CPU load grows with it. Why could this be happening? Lack of optimization or fundamental limitations?

How is higher render distance so CPU-intensive? Is it because of a higher number of draw calls? If so, can’t they just minimize draw calls by batching objects or other techniques?

Does a high draw distance always imply high CPU usage, or is something that could be optimized, but sometimes isn't?

Improve this question
$\endgroup$

3 Answers 3

Reset to default
1
$\begingroup$

This depends on the application.

If the rendering distance is larger, more objects have to be managed by the CPU. For example Minecraft, there you have "chunks" that store the block information of an area of 16x16x256 blocks. When you move, new "chunks" come into the view area, so the CPU has to load or generate them.

In other games, new objects (geometry) must be loaded from disk and sent to the GPU. Modern games have so many textures and models that the GPU is not able to store them all. So the CPU has to decide which textures and models are needed.

Other aspects can also play a role. For example, animals walking around. As long as you are too far away to see them, they don't need to be updated. But if the rendering distance is greater, they should move.

More rendering calls also play a role. However, not as strongly as the aspects mentioned above. Because in general, the number of different geometries that need to be rendered should not be too large. And with instance rendering, objects with the same geometry can be rendered multiple times with just one drawing call.

Does a high draw distance always imply high CPU usage, or is something that could be optimized, but sometimes isn't?

No. The render distance is part of the projection matrix. When comparing two render calls:

  1. Entire scenario is in range:
  2. Entire scenario is in range, but render distance is doubled:

The rendering time will be the same.

Even with drawing calls for each geometry in the world, both renderings will take the same amount of time (on CPU). On GPU, of course, things look different...

Improve this answer
$\endgroup$
1
  • $\begingroup$ The render distance isn't necessarily part of the projection matrix, the infinite projection matrix is very popular. Among other things an infinite projection solves the issue of the sides of a projection being much longer then the center. (especially for large viewing distances) Another issue it resolves is showing extreme detail reduction for very large viewing distances such as showing a billboard for an entire mountain range that is many kilometers (such as 50km away) in the distance. While still maintaining a spherical viewing distance of 1km. $\endgroup$
    – pmw1234
    Aug 12 at 22:44
1
$\begingroup$

There are a number of reasons CPU usage goes up with viewing distance but the fundamental reason is the number of objects that need to be processed goes up.

Increasing viewing distance linearly increases the viewing area quadratically. Which means the number of items that must be considered for drawing increases quadratically.

There are many techniques to mitigate this, some of which you suggested but at the end of the day the shear number of items that needs processing is going to drive CPU usage up.

There are GPU based algorithms that can process millions of items but incorporating those into a game engine is non-trivial especially for a game that has already been published. There are also hardware limitations that must be considered when implementing GPU based algorithms.

Also, there are many games that have very large viewing distances. World of Warcraft comes to mind as an older game that allowed scenery to be viewed for many kilometers, and it did so on "ancient" hardware. So it is possible to overcome this problem.

At the end of the day it is going to depend on the goals of the project. The skills of the development team and the capabilities of the underlying hardware.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Exponentially is not the right term, IMO. The area grows as the square of the distance, so quadratically. $\endgroup$
    – user1703
    Aug 10 at 11:54
  • $\begingroup$ I new writing exponential would get someone's hackles up. I changed it, but the only goal was to capture that high rate of growth in a term that a wide audience would easily understand. $\endgroup$
    – pmw1234
    Aug 10 at 11:59
  • 1
    $\begingroup$ Mh, dilemma between technique and journalism... $\endgroup$
    – user1703
    Aug 10 at 12:03
0
$\begingroup$

As said in other comments, the increased workload can be due to more objects visible, needing rendering (though this is a partial explanation because in a first approximation the rendering effort depends on the surface area to be painted).

A possible cure is to handle several object geometries with simplified details and select the one to be rendered depending on the viewing distance. This principle is similar what is done in mipmapping for textures (texture images stored with different resolutions), though harder to implement with discrete surfaces.

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ A possible cure is to handle several object geometries with simplified details and select the one to be rendered depending on the viewing distance. How does the CPU benefit from geometry with simplified details? My understanding is that after the geometry is loaded, the draw call cost is essentially the same regardless if it is simplified or not. correct? Or do you mean that simpler geometries are just faster to load when needed and might need fewer draw calls because they are simpler (fewer child objects, materials, etc)? $\endgroup$
    – Vasilescu Andrei
    Aug 11 at 1:56
  • $\begingroup$ @VasilescuAndrei you are right... On CPU it don't matter if your geometry is detailed or not. This is a performance boot for the GPU. But you are also right, that loading a simplified mesh is faster than loading a detailed mesh. Only to point it out: there are algorithms to convert low detail meshes to high detail meshes e.g. displacement mapping and or curved PN triangles. So the CPU doesn't need to choose which level of detail should be rendered, because only one level of detail exist. The GPU decides how mush tessellation is needed. $\endgroup$
    – Thomas
    Aug 11 at 15:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.