본문으로 바로가기
반응형

`

https://www.ea.com/frostbite/news/terrain-in-battlefield-3-a-modern-complete-and-scalable-system

강연 영상 링크 : https://www.gdcvault.com/play/1015676/Terrain-in-Battlefield-3-A

Other refer : https://www.gamedeveloper.com/programming/real-time-dynamic-level-of-detail-terrain-rendering-with-roam

Overview


• Scalability – hierarchies, payloads and limitations
• Workflows – realtime in-game editing
• CPU and GPU performance
• Procedural virtual texturing – powerful GPU optimization
• Data streaming – minimizing memory footprint
• Robustness(견고성) – global prioritization
• Procedural mesh generation
• Conclusions

• Heightfield-based
• Mesh procedurally generated at runtime
• Surface rendering with procedual shader splatting
  – Arbitrary shaders splatted according to painted masks
• Spline and quad decals
• Terrain decoration
  – Automatic distribution of meshes(trees, rocks, grass) according tomask
  – Billboards supported
• Terrain decoration
  – Important as the terrain surface itself
• Destruction/dynamic terrain
  – Destruction depth map
• Controls crater depth around ie static models
  – Physics material map
• Controls surface effects, audio, crater depth and width
Rivers/lakes
  – Implemented as free-floating decals
  – Water depth in pixel shader

 

Terrain raster resources
• Multiple raster resources used
– Heightfield
– Shader splatting masks
– Colormap, used as an overlay on top of shader splatting
– Physics materials
– Destruction depth mask
– Albedo map for bounce light
– Additional mask channels

 

Scalability(확장성) - hierarchies, payloads and limitations

 

• Our definition of scalability(우리의 확장성의 정의)
  – Arbitrary view distance (0.06m to 30,000m)(임의의 시야거리)0
  – Arbitrary level of detail (0.0001m and lower)(임의의 LOD)
  – 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!(쿼트트리에 대한 지식이 있다고 가정하고 바로 프로스트 바이트의 특징으로)

 

 

Quardtree node payload(전송되는 데이터 그자체를 의미)
The node payload is a central concept
• A quadtree node can be attributed with a ”data blob”; the payload(쿼드트리 노드는 "데이터 얼룩"으로 참조될 수 있음)
• Payload is
– a tile of raster data
– 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

 

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...(페이로드 이동은 우선 순위 메커니즘에 의해 제어)

 

 

LOD payload
• Non-leaf nodes have payload too
• These payloads are used as LODs
• Detail level depends on payload depth
– Nodes closer to root represent lower detail(루트에 가까운 노드는 lower detail을 나타낸다)

 

 

 

View-dependent payload usage
Set of payloads (green dots) used for a certain observer position
– Note area to the left is distantand use lower LOD
Observer Observer Observer moves and another set isused
– Area to the left now use higher LOD

 

 

Motivation for LOD payloads
• With LOD
– cost (payload count) is mostly
independent of terrain size(지형의 크기와 상관없음)
– Scalable!
• Without LOD
– cost depend on terrain size(비용은 터레인 사이즈와 상관있음)
– Not scalable!

 

 


렌더링 알고리즘을 위한 타일 겹침(테두리)
• Source data and workflows on leaf level(소스데이터와 워크플로우는 리프레벨에 따라 이루어진다)
• LODs generated automatically by pipeline(LOD는 자동으로 파이프라인에서 생성)
• Requirements
– Tile overlap (borders) for rendering algorithms(렌더링 알고리즘을 위한 타일 겹침(테두리))
– Continuity(연속성)
• Recursive (reverse) depth first algorithm(재귀(역) 깊이 우선 알고리즘)
– Green LOD tile is generated(녹색의 LOD타일이 생성되고)
– Four children (red) and up to 12 neighbor tiles (blue) are used(4개의 자식(빨간색)과 최대 12개의 인접 타일(파란색) 사용)

 

Terrain decoration payloads(터레인 데코레이션 페이로드)
• Terrain decoration payload
  – Is a list of instance transforms(for grass, trees, rocks)(풀, 나무, 바위등을 위한 인스턴스 변환 목록)
  – Is generated at runtime according to(런타임에서 생성은 다음과 같이 이루어진다)
     • scattering rules(산란규칙)
     • shader splatted masks (position/density)
          – Note that we allow shaders to modify masks!(셰이더가 마스크를 수정할수 있도록 허용)
     • heightfield (ground-clamping and orientation)

 

 

Terrain decoration LOD payloads
• Quite unique (and slightly confusing) concept(상당히 독특하고 약간 혼란스러운 개념)
• LOD payloads used for scalability(확장성을 위해 사용되는 LOD 페이로드)
  – Near-root payloads provide high view distance(루트에 가까운 페이로드는 높은 시야 거리를 제공)
  – Near-leaf payloads provide high density(리프에 가까운 페이로드는 높은 밀도를 제공.)
• Payloads can overlap(페이로드는 겹칠수 있음(
  – Providing high view distance and density

 

 

 

Workflows – realtime in-game editing

 

 

Real time editing in FrostEd(FrostEd is Frostbite editor)
• Game View is game rendering inside editor
• Terrain editing with realtime feedback in game view
  - heightfield sculpting
  - Mask and color painting
  - Decal editing
  - Terrain decoration

 

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(WorldMachine, GeoControl)
• A common workflow

 

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(GeoControl과 월드머신은 8K+래스터를 좋아하지 않음)

 

 

CPU and GPU performance

 

 

Efficient on CPU(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) 많은수의 터레인 데코가 생성시 8ms까지 치솟음. 평균 1~2ms의 SPU
    – <1ms PPU

PowerPC 프로세서 유닛(PPU)에는 많은 장점이 있지만 Cell의 탁월한 컴퓨팅 기능은 SPU(Synergistic Processor Unit)에서 나옵니다. 범용 PPU와 달리 SPU는 고속 벡터 처리라는 단일 목표를 염두에 두고 설계되었습니다. 텍스트 처리, 코드 컴파일 또는 이메일에 SPU를 사용하지 않습니다. 그러나 수십만 픽셀을 새로운 좌표계로 변환해야 하는 경우 SPU가 신속하게 작업을 완료합니다. SPU의 아키텍처는 PPU보다 훨씬 간단합니다. 캐시, 스레드, 페이징 및 메모리 세그먼트가 없습니다. 사용자 레지스터에는 두 가지 유형만 있습니다. SPU를 사용하면 마이크로코딩된 명령어, 캐시에 대해 걱정할 필요가 없습니다.

 

Efficient on GPU
• Pre-baked shader permutations to avoid multi-pass(멀티패스를 피하기 위해 pre-baked된 셰이더 순열)
• Procedual virtual texturing exploit frame-to-frame coherency(절차적 비추얼텍스처링 개발은 프레임간 일관성을 활용)
• Typical figures (PS3) :
  – Full screen GBuffer laydown (w/o detail overlay and terrain decoration) : 2.5-3ms
  – Full screen GBuffer laydown (w/ detail overlay) : 2.5-7ms
  – Terrain decoration : 1-4ms
  – Virtual texture tile compositing : 0.2-0.5ms

 

반응형