Do game engines draw terrain and textures every single frame?

Question

Let's say I have multiple meshes of static terrain, consisting of rocks and dirt that do not move.

Does the game engine still need to draw static objects every single frame?

Therefore, is it necessary for the game engine to draw a terrain consisting of 35k quads with 100+ materials 60 times per second

If not, how can I inform the engine to refrain from updating the dirt, as it serves no functional purpose and remains static?

Would instructing the game engine to update the terrain less frequently conflict noticeably with a distance-based LOD system?

This may sound like a trivial question, but I'm asking because I reduced the refresh rate of some AI regardless of player FPS. I noticed that when the AI's FPS is 50% to 60% slower than the player's, the AI NPCs and enemies leave trails of double images behind.

If I set the terrain to refresh, for example, only once per second or even less frequently, would players see the terrain leaving double images behind? This shouldn't happen, right? Since the terrain doesn't store any movement or position data; it only consists of colors and geometry... or does it?

Answer 1

A typical 3D game draws everything every frame.

That's because in a 3D game, even when content isn't moving/animating, your camera is very frequently moving continuously. So the system has to be able to draw the whole scene from a new perspective every 60th of a second (or whatever the framerate).

That case of a moving camera becomes your bottleneck, and you design around that. Even if the camera isn't always moving, you need to curate and engineer your content to fit in that time budget, so that when the camera does move, your framerate doesn't stutter.

Once your game is consistently able to draw the scene from scratch every frame, there's not a lot of added benefit to stopping it from doing so — the code to detect what can be re-used and render selectively adds complexity and could bog down a game that's already hitting a solid 60 fps. Even something that hasn't moved or changed since last frame might be behind something that did move, so it still needs to be re-drawn to fill the hole where that thing was previously (otherwise you get those trails of ghost images you describe).

It may be helpful for mobile games in terms of reducing heat and battery drain, but only if there are large swaths of time in your game when most of the screen stays frozen, pixel-for-pixel identical to the frame before. That does not describe many mobile games, which are usually animating constantly, and you want to make sure those frames where lots of stuff is happening stay fast too. So it makes more sense to focus on making the re-draw efficient than trying to skip re-draw entirely in the very rare cases when we could.

Some things we do to avoid completely redrawing complex terrain every frame include:

• Culling: detect which parts of the terrain are not going to be visible in this frame and skip rendering them entirely.

• LoD: draw simpler versions of the terrain mesh for distant parts, with simpler materials, or maybe even falling back on imposters over full meshes.

  Updating the correct level of detail to use for each chunk can be a significant amount of work, but it can often be done at a low frequency, spreading the work across multiple frames, at the cost of having some objects drawn a little under-/over-detailed for a frame till the correct LoD is swapped. Avoiding visible pops during the transitions is a whole art of its own too.

• Dynamic resolution with temporal anti-aliasing and upscaling: here we render at a lower resolution from slightly jittered camera positions each frame, and keep a buffer of one or more previous frames. When picking the final colour for a pixel, we reproject its position to find where it was in the previous frames, and blend the colours from multiple frames together. This spreads the work of rendering a smooth, high-res image across multiple frames: we render less detail in any one frame, knowing we can reconstruct a lot of it with the context of previous frames.

  Of course, when the camera is moving dramatically or lots of stuff is changing on screen, this is less effective, but it's mainly when things settle down that players are able to scrutinize the pixels, and that's when temporal techniques shine.

• Virtual texturing: a complex terrain material with tons of layered textures and procedural calculations can be expensive to evaluate for every on-screen pixel as we render each frame. Instead, we can detect which sections of terrain are visible and bake the swatch of material they need to a texture in memory, then render them by just sampling the texture instead of evaluating an expensive shader.

  The virtual texture needs to be updated when new parts of the terrain enter view, or get close enough to need a higher resolution, but this can be done at a lower frequency than every frame, exploiting the persistence of detail we already calculated on previous frames.

These are fairly large tech investments, and not applicable or beneficial to every project, so profile carefully to determine where your major bottlenecks are and what areas will give you the most return on your investment for the least excess complexity.

Answer 2

Usually engines clean the color and depth buffers every frame. And, of course, also render everything every frame.

Some engines allow you to tell them to not clean the buffers, but they would still render everything every frame. Which can yield some trippy results, including trails of images in the void (where there was nothing to render on top to replace them).

Having some things render less frequently than others is usually not a feature.

If we are not talking about disabling clearing the buffers, then the behavior I would expect is not double images, but having the object appear one frame, disappear because the engine cleared the buffers and rendered everything else, and then some frames later appear again for a single frame and so on.

---

You might hack it by rendering to a texture/viewport and overlaying the result※, except, of course, render that less frequently. But it would stay in place in the screen as the camera moves.

I don't know the details of your terrain system, but even if it does not move, the camera does. And assuming the camera has moved but the image of the terrain has not been updated, it would look wrong.

You could try further hackery to move the overlay on the screen according to camera motion. But it won't be perfect, as you are working with a 2D image at this point, so the perspective won't change. And also moving the overlay can't reveal parts of the terrain that were outside of what you rendered.

※This is similar to what some games do for first person weapons so they don't clip into the scenario geometry. It is also similar to some old school crowd solutions that render a cluster of objects once and repeat it on the screen.

---

About level of detail, most of the time the model used the last frame is the same you want to use this frame, since you only swap models when the object passes some distance threshold. If you swap the model a few frames late it is unlikely to be a problem, and if it is, we are talking about popping.

Be aware that often this swap is done in CPU, not GPU. So this process does not need to be tied to the render frequency... While doing it faster than the render frequency is wasting effort, you can do it less frequently with moderate impact... Unless the player is moving way too fast for the frequency you pick.

Updating the level of detail more or less frequently based on the speed at which the camera moves might be a good optimization.

---

I remind you that rendering is not the same as updating. You might have object skip update/process/tick/whatever-your-engine-calls-them calls or update in a separate thread with a different frequency, and still have them render normally.