Rendering system improvements

This page is intended to be a talk about possible technical changes to the flightgear rendering engine to allow better appearance and performance. Please keed feature requests etc on some other page.

Current state

This section describes how the scenery is currently rendered.

Rendering system

Flightgear has mostly one pass rendering system, where the whole scenery is rendered in one pass. Lighting is applied directly when rendering, and currently there is support for only one light (the sun).

Cameras

By default flightgear has at least three cameras: Near camera, far camera and gui camera. The first two are used to render the scenery and the last one is used to render all(?) 2D stuff, like menus.

Scenery cameras render so that the far camera is rendered first and then the near camera. The transition is at 100 meters by default (iirc). Near camera has znear at around 1cm and far camera has zfar at ~12km.

The near/far camera system is in place because of zbuffer precision issues, which appear if one wants to render things very near and very far. See [1].

Rendering order

Scenery is rendered in following order (this is from my memory, there might be some errors....)

1. Skydome
   1. Sky itself
   2. Stars
   3. Moon and sun halos
   4. Moon and sun
2. Terrain and opaque objects
3. Clouds (3D) (Back-to-front) (*)
4. Translucent objects (Back-to-front) (**)
5. Lights
6. Cockpit (***)

(*) 2D clouds are rendered differently, the rendering order is from bottom to top and top to bottom, the render bins do not very well match 3D cloud bin leading to artifacts. (**) Translucent objects should be renderd in the same bin as 3D clouds, but currently they are rendered after clouds, so they can be seen through the clouds which looks wrong. (***) The cockpit mostly fits the near camera and that's why it's rendered last.

This order leads to significant amount of overdraw, terrain is drawn over the sky and cockpit is then drawn over the terrain. With heavy shaders this overdraw is slow.

Other rendering systems

One pass multi lights

In this method, the scene is rendered in one pass and shaders/lighting models takes all lights into account.

• No overdraw
• Limited amount of lights -> Suits for outdoor scenes with only sun/moon
  • OpenGL fixed pipeline supports 10 lights
  • With shaders it depends on the available uniforms/varyings. Depending on the shader complexity, maybe 4 lights would be possible
• Lighting model depends on the object, can have various different models
• Lighting is calculated for all pixels for all lights, even if they are unlit
• Must do sorting by light volume to select best lights
• Works with translucent objects

Multi pass one light

Render only one light at the time, rendering the whole scene with additive blending for all lights.

• Infinite amount of lights
• Huge amount of overdraw
• Needs heavy sorting and culling to improve speed
• Works with complex shaders
• Lighting model depends on the object, can have various different models
• Depending on the culling, lighting is only calculated for objects that are in the light
• Has issues with translucent objects

Deferred shading

In deferred shading, the whole scene is first rendered with a simple shader that writes diffuse color, normal, depth, and other parameters to multiple textures (G-buffer). Then, lighting is calculated with those parameters. See for example [2].

• Infinite amount of lights
• One big light is about as heavy as many small ones
• Suits for indoor scenes with multiple small lights
• Rendering target precision is an issue (especially normal buffer)
• Large memory footprint
• Geometry pass shader is/should be simple and fast
• One lighting shader for all geometry -> limited lighting models (maybe 4 different lighting types)
• No overdraw in lighting pass
• Does not work with translucent objects

Mixed

A mixed system combines some of the above to give good performance and visual appearance. I think something like this could suit our needs:

• Render scene with one pass, use two lights: sun and moon
• Render diffuse color and depth (and normal?) to texture targets -> allows post processing effects
• Render all other small lights using those textures -> the light cone approach
  • Texture targets allow recovering the original color during night
  • Storing normal and depth allows rendering smooth light in the light cone
  • Light cones can be easily culled by visiblity
• Allows various lighting models in the sun/moon pass, light cones have all only basic lighting model
• Light cones need stencil operations and changing the front/backface culling -> might be slow?
• Fog rendered as a post process quad (after opaque geometry) -> same fog for every object
• Translucent objects?

Rendering systems in other projects

Currently just a placeholder to write some notes about other projects and what we might learn from them.

Outerra

[3]

• Continuous noise coordinates -> continuous noise function
• Slope, curvature etc as vertex attributes
• Terrain refinement on load time and on shader
• Trees -> Billboards -> Baked texture
• Limited amount of materials (4?) -> Easy to mix on shader level

I don't really understand how are roads implemented in Outerra, some kind of shader level spline interpolator, but how can the amount of splines be large enough?

Links:

• About procedural terrain refinement: [4]
• Horizontal displacement: [5], [6]
• Logarithmic z-buffer: [7]

X-Plane

[8]

Links:

• Auto-variation in terrain textures: [9], [10]
• Visiblity (how far is far enough?): [11]
• Global illumination: [12], videos [13]
• Object performance: [14], [15]

Other things

New rendering order

To limit the overdraw, I suggest following rendering order:

1. Opaque parts of cockpit
2. Terrain
3. Skydome
4. Clouds (3D)/translucent objects
5. Translucent parts of cockpit

With near/far camers there might be need to use stencil operations or similar to limit rendering only to parts visible from the cockpit.

Get rid of near/far camera

Ways to get rid of near and far cameras.

Custom z function

Use custom z function in the shader, for example log(z).

• Better precision -> no z fighting
• Cannot use early z kill in the shader -> All pixels are evaluated -> Slow
• Shaders can easily modify z value -> relief mappign etc

Floating point z buffer

Need more info about this...

Cockpit only near camera

Render only the inside view using near camera, everything else with far camera. Put the transition to somewhere around 0.5-1.0m.

• Is the precision then sufficient?
• No z fighting in the instruments
• Can render everything else in single pass
• Might need to use stencil operations with cockpit if cockpit is rendered first

Related wiki pages

Proposals:Scenery_related Proposals:Eye_Candy_related Howto:_Improve_Framerates