fix(terrain): Cover the visible ground at high camera zoom

[sailro]

Problem

With the default settings (DrawEntireTerrain=No) the terrain is only drawn within a window of tiles around the view center. At high camera zoom this window no longer covers the visible ground, so any map water renders behind it. Many maps that have no real water still keep a map-sized "Default Water" polygon, which then makes the whole map look flooded when the camera is zoomed out.

The legacy workaround was DrawEntireTerrain=Yes, but that always draws the entire map and is very slow even at normal zoom (#2743).

Fix

Size the normal draw window to the actual visible footprint instead of a fixed tile count:

• Project the four view corners onto the ground plane (the same method updateCenter() already uses to position the window).
• Grow the draw size just enough to span them, bounded by the map extent and snapped to whole vertex-buffer tiles, so the terrain only reallocates when a zoom threshold is crossed.
• Use a single square size so the window stays stable as the camera rotates (no reallocation on yaw).
• Near-horizontal / parallel corner rays (which meet the ground far away, behind the camera, or not at all) are clamped to the map extent, so they cannot produce a degenerate or NaN draw size.

At normal zoom the footprint is smaller than the normal window, so this is a no-op and behavior is unchanged; the window only grows as the camera zooms out. It works for all maps.

This change lives in the default DrawEntireTerrain=No path. It does not modify the DrawEntireTerrain path, so it does not by itself resolve #2743 — it removes the need for that slow workaround in the common case.

Before / After

Before — zoomed out on a no-water map, the terrain window ends and the map's default water polygon fills the rest of the view:

After — the draw window covers the visible ground, so the sand renders all the way out (same scene type, patched build):

After on a stock map (Whiteout) — the real lake still renders correctly and the terrain fills the view (the black wedge top-left is genuinely off-map, past the terrain border at extreme zoom):

Testing

• Built Release / Win32 and tested in skirmish (Zero Hour).
• At maximum camera zoom-out: no water bleed-through on no-water maps, and the real water on stock maps still renders correctly.
• Performance stays smooth at all zoom levels across multiple maps (no DrawEntireTerrain=Yes-style degradation).

AI disclosure

Per the contribution guidelines: the code in this PR was written with the help of an LLM (GitHub Copilot CLI) and then reviewed, iterated on, and verified by a human. The approach — projecting the view footprint the same way updateCenter() does, tile snapping, and map-extent / NaN bounding — was chosen deliberately, and the change was validated in-game across several maps and zoom levels. The diff is intentionally small and self-contained: one file, only the draw-size calculation in updateTerrain().

cc @xezon

[greptile-apps]

Greptile Summary

This PR fixes a terrain draw window that could fall short of the visible ground at high camera zoom, causing the map's default water polygon to bleed through on maps with no real water. The fix projects the four viewport corners onto the ground plane — using the same ray-casting math as updateCenter() — and grows the draw window to cover the resulting footprint, snapped to VERTEX_BUFFER_TILE_LENGTH blocks and capped at the map extent.

• The base NORMAL/LOW_ANGLE sizing is preserved; the new footprint code only increases dimensions.x/y when the projected footprint is larger, making this a no-op at normal zoom.
• NaN and near-horizontal ray degenerate cases are correctly rejected with the !(>=) idiom before they can inflate the draw size.
• The draw window is kept square (using the larger footprint dimension) to prevent reallocations when the camera yaws.

Confidence Score: 5/5

Safe to merge — the change is self-contained, the footprint expansion only ever enlarges the draw window (never shrinks it below the existing NORMAL/LOW_ANGLE baseline), and the worst-case degenerate inputs are guarded against.

The ray projection math is a faithful copy of the logic already in use inside updateCenter(), the NaN guard and map-extent clamp are both correct, and the tile-snap formula produces the expected block counts. The only issue is an unused variable (viewportMax) that may generate a compiler warning but has no runtime effect.

No files require special attention.

Important Files Changed

Filename	Overview
Core/GameEngineDevice/Source/W3DDevice/GameClient/W3DView.cpp	Terrain draw window is now dynamically sized by projecting the four viewport corners onto the ground plane, clamped to the map extent and snapped to VERTEX_BUFFER_TILE blocks. Logic closely mirrors the existing updateCenter() ray projection; NaN/parallel-ray handling via the !(>=) idiom is correct. One unused variable (viewportMax) may produce a compiler warning.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[getDesiredTerrainDrawSize] --> B{DrawEntireTerrain?}
    B -- Yes --> C[Set dimensions = full map extent\nreturn true]
    B -- No --> D{cameraPitch > threshold\nor scripted camera?}
    D -- Yes --> E[dimensions = NORMAL_DRAW_WIDTH/HEIGHT]
    D -- No --> F[dimensions = LOW_ANGLE_DRAW_WIDTH/HEIGHT]
    E --> G[Project 4 viewport corners\nonto ground plane via ray cast]
    F --> G
    G --> H[Clamp corners to ±mapExtent\nto handle NaN / parallel rays]
    H --> I[Compute footprintSpan\n= max of X and Y span]
    I --> J[Snap up to nearest\n1 + N×VERTEX_BUFFER_TILE_LENGTH block]
    J --> K{zoomDrawSize > current dimensions?}
    K -- Yes --> L[Grow dimensions.x and dimensions.y\nto zoomDrawSize]
    K -- No --> M[No-op at normal zoom]
    L --> N[return true]
    M --> N

Loading

_{Reviews (6): Last reviewed commit: "perf(terrain): Grow the draw window only..." | Re-trigger Greptile}

[Skyaero42]

@Mauller is this something you were addressing in #1711 as well, or is it a separate issue?

[sailro]

Tidied the comments in updateTerrain() to match the style we landed on in #2786:

• Dropped references to other functions (updateCenter()) so the comments can't go stale if that code is renamed or moved.
• Removed the issue id from the comments.
• Condensed the header block from ~13 lines down to 5, keeping just the what/why/how. The finer implementation details (map-extent bounding, NaN clamping, tile snapping, rotation stability) are already documented by the inline comments right next to the relevant lines, so nothing was lost.

No functional change — comments only.

[sailro]

@Mauller is this something you were addressing in #1711 as well, or is it a separate issue?

Hi @Skyaero42, From the #2785 side, I think these are separate, complementary fixes rather than the same one:

• fix(view): Adjust default camera height to compensate for screen aspect ratio #1711 is about camera height vs. aspect ratio (Camera height does not scale properly along with aspect ratio of game resolution #78): it scales m_maxHeightAboveGround/m_minHeightAboveGround by an aspect-ratio factor in setDefaultView() (and re-applies it on resolution change / new game) so the camera isn't too low on wide screens. It doesn't change terrain rendering.
• fix(terrain): Cover the visible ground at high camera zoom #2785 is about terrain coverage: in updateTerrain() it sizes the terrain draw window to the visible footprint so the ground — and not the map's water plane — is drawn when the view is zoomed out. It doesn't change the camera.

Same file, but different functions (setDefaultView/setZoomToDefault vs updateTerrain), so no logical overlap or expected conflict.

They're actually complementary: #1711 raises the effective camera height on wide aspect ratios, which is exactly the zoomed-out condition where an un-sized terrain window stops covering the view and the water bleeds through. #2785 derives the window from the projected view corners, so it adapts automatically to whatever camera height #1711 produces. So #1711 can make the symptom more visible on wide screens, and #2785 fixes the rendering side of it.

@Mauller can confirm the #1711 specifics/intent — I'm only speaking to how #2785 relates.

Thanks!

[sailro]

Hello @xezon @Skyaero42

I'd be happy to discuss or modify anything in this PR that you think is worth changing.

I'm just trying to fix a display issue that I think is crucial given today's high resolutions.

Thanks!

[sailro]

I was able to test the fix during a 4h session (Generals Online fork with this fix backported), on various maps. All good !

[Skyaero42]

There is a major deficit in reviewing capacity. You just gonna have to be patient.

[sailro]

@Skyaero42 @xezon Update now that #2846 has landed.

I rebased this PR on top of it, and the fix now lives inside the new W3DView::getDesiredTerrainDrawSize(): the footprint-based growth is applied to the "desired" draw size there, so it composes with your model instead of fighting it.

Why it's still worth having alongside #2846:

• bugfix(heightmap): Fix full terrain rebuild on every frame when DrawEntireTerrain is enabled #2846 targets the m_drawEntireTerrain / showAllTerrain path. It makes DrawEntireTerrain=Yes cheap by no longer rebuilding the whole terrain every frame.
• This PR targets the default path (DrawEntireTerrain=No). When you zoom far out on a normal map, terrain is only drawn in the fixed NORMAL/LOW_ANGLE window around the view center. Past that window the map's default water plane shows through, so maps with no real water look flooded. The only prior workaround was DrawEntireTerrain=Yes, i.e. exactly the slow path bugfix(heightmap): Fix full terrain rebuild on every frame when DrawEntireTerrain is enabled #2846 had to rescue.

So the two are complementary: #2846 makes the "draw everything" workaround fast; this PR removes the need for that workaround in the common case by sizing the draw window to the actual visible footprint. It's a no-op at normal zoom and grows only as you zoom out, bounded by the map extent and snapped to tile blocks so it doesn't reallocate every frame.

The latest commit also extends the coverage to the scripted camera (for example the main-menu shell map), which can likewise see past the regular window.

Happy to tweak anything.

[Caball009]

I did some quick performance comparisons:

1. Comparing with DrawEntireTerrain=No, there's still a noticeable drop in performance, even at camera heights where all visible terrain is rendered.
2. Comparing with DrawEntireTerrain=Yes, there's a very noticeable improvement in performance.

@sailro Can you verify these findings?

I'd be hesitant to add this code for DrawEntireTerrain=No, but perhaps it's worth having for DrawEntireTerrain=Yes.

[sailro]

@Caball009 Thanks a lot for profiling this - your finding was real and pointed at an actual inefficiency in my code, which I've now fixed (latest commit).

Root cause of the drop you saw with DrawEntireTerrain=No:
The normal draw window is 129 vertices = 128 tiles wide. My snapping was adding a full spare 32-tile block before rounding up, so the window grew to 161 as soon as the visible footprint passed ~95 tiles - roughly a whole block earlier than geometrically necessary. So for footprints of 96-128 tiles, which the normal 129 window still fully covers, I was drawing a 161 window = 25 blocks instead of 16 (+56%). Depending on the viewport aspect ratio, the footprint can already sit in that band at fairly normal camera heights - which is exactly the "drop even at camera heights where all visible terrain is rendered" you observed. Good catch.

The fix:
Compute the required block count with a ceiling division to the smallest size that actually covers the footprint, plus a small centering margin (sized to updateCenter()'s CENTER_LIMIT re-centering tolerance) instead of a whole spare block. Result:

visible footprint	before	after
up to ~124 tiles	161 (25 blocks)	129 (16 blocks) - no-op
~125-128 tiles	193	161
larger	grows	grows one block later

So at any camera height where the visible terrain fits the normal window, this is now a genuine no-op - only the four corner-ray projections run, and setTerrainDrawSize()'s guard early-returns with no rebuild.

On the two cost sources when actually zoomed out:

• (a) unavoidable: once the visible ground genuinely exceeds the normal window, more terrain has to be drawn to cover it - any fix that covers the ground pays this. But it scales with what's on screen, unlike DrawEntireTerrain=Yes which draws the whole map regardless of zoom.
• (b) avoidable: the extra ring of blocks from the early growth. That was the bug; it's gone now.

Comparing against the DrawEntireTerrain=No baseline is only apples-to-apples in the range where 129 still covers everything (now a no-op). Past that, the baseline is necessarily cheaper because it draws less - and shows the water bug this PR fixes.

On your suggestion to apply it for DrawEntireTerrain=Yes instead:
I looked into it and it isn't a clean swap. DrawEntireTerrain=Yes also (1) forces the camera far-clip plane to 100000 in updateCameraClipPlanes() and (2) takes a whole-map early-return in updateCenter() (no streaming). Repurposing the flag to mean "footprint-sized" would change its documented semantics and remove the conservative "just draw the whole map" escape hatch. Footprint sizing for the =Yes path could be a separate follow-up, but I think this PR is best kept on the default path, which is where the flooding bug actually bites players.

Happy to share raw numbers or a capture if useful.