Repository navigation
Massive performance degradation with DrawEntireTerrain=Yes #2743
Description
Reported by 2 users. Probably comes from the recent heightmap changes. Needs fixing.
Reacted by Hossam Abubakr
Reacted by Sebastien Lebreton
{{ message }}
Activity
sailro commentedon Jun 12, 2026
I looked into this together with the related water-at-zoom problem, and it turned out to be two distinct issues that people had been conflating through the
DrawEntireTerrain=Yesworkaround. I opened two complementary PRs.Background: why people often set
DrawEntireTerrain=Yes(I was doing this)In the default path (
DrawEntireTerrain=No) the terrain is only drawn within a window of tiles around the view center. At high camera zoom that window stops covering the visible ground, and on the many maps that keep a map-sized "Default Water" polygon, that water then renders behind the terrain window and the map looks flooded. The long-standing community workaround was to setDrawEntireTerrain=Yesso the whole map is always drawn — which hid the water bug but is what makes this issue (#2743) so slow.So there are really two problems:
PR #2785 — fixes the rendering bug (default
DrawEntireTerrain=Nopath)[#2785] sizes the normal draw window to the actual visible footprint instead of a fixed tile count: it projects the four view corners onto the ground (the same way
updateCenter()already positions the window), grows the draw size just enough to span them, bounded by the map extent and snapped to whole vertex-buffer tiles. At normal zoom it is a no-op; the window only grows as you zoom out, on all maps.Effect on this issue: it removes the need for
DrawEntireTerrain=Yesin the common case (no more water bleed-through at zoom without it). It deliberately does not touch theDrawEntireTerrainpath, so on its own it does not fix #2743 — it just makes the slow workaround unnecessary for most users.PR #2786 — fixes this issue directly (
DrawEntireTerrain=Yespath)[#2786] fixes the actual performance degradation. Root cause is two competing sources of truth for the terrain draw size:
WorldHeightMap::createDrawArea()force-overrides the stored draw size to the full map whenDrawEntireTerrain=Yes(or the stretch size whenStretchTerrain=Yes).W3DView::updateTerrain()requests the normal draw size throughHeightMapRenderObjClass::setTerrainDrawSize()every frame.setTerrainDrawSize()early-returns when the requested size equals the stored size, but the requested normal size can never match the stored full-map size. So every frame it re-raninitHeightData()+ a full-mapupdateBlock(), and setm_needFullUpdate, makingupdateCenter()do a second full-map update — roughly two full terrain rebuilds (vertices + lighting) per frame. This regressed in #2677, which added the per-framesetTerrainDrawSize()call (W3DView.cpp, commit ccd8766) alongside the full-map override increateDrawArea()(commit c47b01a).The fix is two parts:
StretchTerrain/DrawEntireTerrainoverrides insidesetTerrainDrawSize()(same precedence ascreateDrawArea()), so the unchanged-check matches and the terrain is no longer rebuilt every frame.updateCenter()early-returns in that case (small maps,StretchTerrain, orDrawEntireTerrain) and never reached itsm_needFullUpdatehandling. SoupdateCenter()now honors a pendingm_needFullUpdatein that early-return path with a single fullupdateBlock, ensuring lighting / device-reset / late-texture repaints still happen — but only when actually requested instead of every frame. (Without this second part, the first part alone left undrawn/untextured tiles on the shell map.)Steady-state cost returns to a one-time full update plus the normal full-map draw (i.e. the pre-#2677 cost), and terrain still updates correctly on lighting, device-reset and texture changes.
TL;DR
DrawEntireTerrain=Yesunnecessary in the common case (fixes the water-at-zoom bug in the default path).DrawEntireTerrain=Yesfast (fixes the per-frame full rebuild regressed by fix(heightmap): Fix up view and heightmap to work better with low camera pitch #2677) — i.e. this issue.Tested in Zero Hour with
DrawEntireTerrain=Yes: smooth in-game where the unpatched build was heavily laggy, and the shell map / in-game terrain renders correctly.sailro commentedon Jun 21, 2026
I really think #2786 is solving this performance issue (while #2785 extend support for larger resolutions). Happy to make changes or discuss anything.
Thanks!
xezon commentedon Jun 21, 2026
I will get to it when when I get the time. Luckily this is not an issue for retail players (because DrawEntireTerrain=No), but mod players.
sailro commentedon Jun 27, 2026
I'm giving the root cause of the why I'm presenting those 2 PRs: I'm plying casually with my friends every weekend, we have all at least QHD monitors, and we were using only
DrawEntireTerrain=Yesin ourinifiles for a very long time because we always had issues with water & limited terrain rendering. Note that we are using the GeneralsOnline fork.For like a month or two now, given the performance degradation, the GeneralsOnline fork even removed the reading of this
DrawEntireTerrainparameter so we are stuck with this kind of unplayable rendering:DrawEntireTerrainis quite self-contained to start : fix(heightmap): Prevent per-frame full terrain rebuild with DrawEntireTerrain #2786Thank you !
stephanmeesters commentedon Jun 27, 2026
As far as I know it should be possible to run a custom build of GO for matches between friends, but you need to pick "Generals Online Anti Cheat (GOAC)" not the EasyAntiCheat option
sailro commentedon Jun 27, 2026
Indeed I was able to build and connect online, the only subtlety I found was to set the
USE_DEBUG_ON_LIVE_SERVERdefine to bypass the auto-update CRC gate. This one is specific to the GeneralsOnline fork.Thanks for the tip !
fix(terrain): Cover the visible ground at high camera zoom
fix(terrain): Cover the visible ground at high camera zoom