Base Pass

3 minute read

← Back to all passes

Responsible for:

  • Rendering final attributes of Opaque or Masked materials to the G-Buffer
  • Reading static lighting and saving it to the G-Buffer
  • Applying DBuffer decals
  • Applying fog
  • Calculating final velocity (from packed 3D velocity)
  • In forward renderer: dynamic lighting

Cost affected by:

  • Rendering resolution
  • Shader complexity
  • Number of objects
  • Number of decals
  • Triangle count
Figure: Top left: Final look of the scene, after lighting and post processes. Top right: World-space normals in G-Buffer. Bottom left: Base color (aka albedo) in G-Buffer. Bottom right: Roughness in G-Buffer.

The base pass renders materials. Shaders serve many purposes, but by materials I specifically mean the part that’s created in the material editor. In foward rendering mode the base pass also calculates and applies lighting. On the contrary, deferred rendering (the default mode in UE4) saves only the resulting material properties: final roughness, base color, metalness and so on into the G-Buffer (“geometry buffer”). Then it leaves the lighting calculation for another pass (that’s why it’s called deferred). This material data is also used later by various other passes, most notably by screen-space techniques: dynamic reflections and ambient occlusion.

But that’s just a part of this pass’ responsibilities. It reads static lighting – from lightmaps, indirect lighting caches – and applies it, by blending it immediately with material’s color.

The base pass also applies DBuffer decals. The decals in view are projected onto objects, their shaders are run and the results blended with the contents of the G-Buffer. Fog is also mixed in during this pass.

Optimization

Shader complexity is obviously the most important factor here. You can check it roughly using the Shader Complexity view mode. It’s also useful to look at the number displayed in the Stats window in Material Editor – just be sure to check this number after you press Apply. The “good” value of shader instructions depends on the rendering resolution of your game and the area covered by the material on screen. To test how much the performance is affected by a shader, replace it temporarily with a basic material and compare miliseconds spent in the base pass.

Watch out for memory bandwith. Textures used by materials, as well as lightmaps, need to be read every frame. Even if you re-use textures a lot (which is a good thing), it only helps to save on the GPU memory and on reading from the CPU RAM. The data still needs to be transferred to the local cache and then to shader cores. A dedicated chapter explains the memory-related costs.

Increasing rendering resolution directly affects the weight of the G-Buffer and other full-screen textures. The memory size of the G-Buffer can be read with the command stat RHI. You can temporarily scale the rendering resolution with r.ScreenPercentage XX, e.g. 20 or 150. This will allow you to see how much additional VRAM is needed for a given resolution.

Decals are an oft-overlooked source of trouble. This pass can take a serious hit when there are too many decals in view. Keep their material complexity low as well, though this is rarely an issue with decals.

The costs (and optimization advice) which you’ll normally see in Lights passes apply here instead when using forward rendering. In addition to the general rules, keep light overlap (aka overdraw) in check. Forward renderers are genetically allergic to multiple lights hitting the same object.