Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Terrain in Battlefield 3: A Modern, Complete and Scalable System

In the session from Game Developers Conference 2011, we'll take a complete look at the terrain system in Frostbite 2 as it was applied in Battlefield 3. The session is partitioned into three parts. We begin with the scalability aspects and discuss how consistent use of hierarchies allowed us to combine high resolutions with high view distances. We then turn towards workflow aspects and describe how we achieved full in-game realtime editing. A fair amount of time is spent describing how issues were addressed.

Finally, we look at the runtime side. We describe usage of CPU, GPU and memory resources and how it was kept to a minimum. We discuss how the GPU is offloaded by caching intermediate results in a procedural virtual texture and how prioritization was done to allow for work throttling without sacrificing quality. We also go into depth about the flexible streaming system that work with both FPS and driving games.

13.
Scalability• Our definition of scalability – Arbitrary view distance (0.06m to 30 000m) – Arbitrary level of detail (0.0001m and lower) – Arbitrary velocity (supercars and jets)• Main observation – It is all about hierarchies! – Consistent use of hierarchies gives scalability ”for free”• Hierarchies not new to terrain rendering – Frostbite approach similar to flight simulators• Quadtree hierarchies used for all spatial representations• Assuming knowledge of quadtrees, we jump right into Frostbite specifics!

14.
Quadtree node payload• The node payload is a central concept• A quadtree node can be attributed with a ”data blob”; the payload• Payload is Nodes (white circle) – a tile of raster data Payload (red dot) – a cell of terrain decoration • A list of instances (rock, grass, trees) – a piece of decal mesh• All nodes have payload... – ... but only a few have it loaded

15.
Nodes with and without payload• Payloads are constantly in motion – They are loaded (streamed), generated or freed evey frame – Only a fraction of the nodes have payload resident• Payload movement is governed by prioritization mechanisms... – ... but more of that later

17.
View-dependent payload usageSet of payloads (green dots) used Observer moves and another set isfor a certain observer position used – Note area to the left is distant – Area to the left now use higher and use lower LOD LOD Observer Observer

25.
External tools• When tools are not enough terrain can be exported and imported – Select all or part of terrain – Metadata + raw file – Edit raw file and reimport • Metadata will import to right area – Puts WorldMachine, GeoControl in the loop • A common workflow

26.
Workflow issues• Conflict between data compression and realtime editing• Realtime editing bypass pipeline• Clever update scheme for procedural content needed – We already had one (destruction)• Frostbite terrains too large for some popular tools – GeoControl and WorldMachine do not like 8k+ rasters

28.
Efficient on CPU• All work done in jobs, most on SPU and many wide – Early unoptimized versions consumed 10ms+ PPU time • BF3 final measurements (PS3) – 1-2ms SPU (peaks at ~8ms when lots of terrain decoration is happening) – <1ms PPU

35.
Clipmap indirection• Clipmap level is resolved on CPU for each draw call – Avoids additional pixel shader logic – Requires each 64x64 map to have its own mip chain• Texture space has to be roughly organized with world space – Not an issue for terrain – More generic use cases are probably better off with multiple classic virtual textures

45.
Resident set size: Powerful blurriness• Streaming does not remove memory footprint – A resident set is still needed• Resident set can be huge – Theoretical value for BF3 level on PS3: 70+Mb!• Blurriness feature shrinks resident set significantly – Increase blurriness by one and save around 70% – Very important memory saver for BF3 – Shipped with 32Mb terrain resident set

50.
Reducing disc seeks• Often main reason for latency – Can seek maybe four files per second – A terrain can have hundreds of files (tiles/payloads)• Methods to reduce the number of seeks – Use terrain resolution layouts at spawn • Otherwise minutes can pass before stabilization (waiting for file seeks)! – Co-locate overlapping tiles of different types • Store heightfield tile together with color and mask tiles