OpenGL Support

Gazebo uses OpenGL to render images for both user feedback (ObserverCam model) and simulated cameras (e.g., MonoCam, StereoHead, SonyVID30 models). This document describes OpenGL concepts with which users should be familiar, and lists some limitations of particular OpenGL driver implementations.

Offscreen rendering and the renderMethod attribute

With version 0.5, Gazebo has moved to an off-screen rendering model; i.e., camera images are rendered to memory rather than the screen. This approach has a number of significant advantages:

Support for console mode operation (no GUI; good for batch jobs).

Support for stereo cameras (with simulated disparity maps).

No weird X window manager artifacts in simulated camera images (as was the case with Gazebo 0.4).

Unfortunately, hardware/driver support for (accelerated) offscreen rendering currently seems to be very patchy, with at least four different methods available:

XLIB : Render to an unmapped X window. This is just a sneaky way of using the standard on-screen rendering pipeline (to a hidden window).
- Pros: hardware accelerated
- Cons: only works on some X11 implementations (e.g. works on OS X, but not on Linux/Xorg).
SGIX : Use the SGIX pbuffer extension (which was designed specifically for this purpose).
- Pros: hardware accelerated
- Cons: only available on some chipsets (works on NVidia; not sure about ATI).
GLX : Use the GLX pixmap extension (write to offscreen pixmap).
- Pros: standard API.
- Cons: no hardware acceleration.
GLXP : Use the GLX pbuffer API in GLX 1.3.
- Pros: standard API
- Cons: not supported on some drivers?

Since different platforms support different solutions, Gazebo implements methods 1, 2 and 3, selectable via the renderMethod attribute in the camera models. Users can also select the AUTO method, which automatically cycles though the methods to find one that works.

Hardware compatability list

Due to the off-screen rendering issues described above, Gazebo is not compatable with certain hardware/software combinations. Known working (and not working) combinations are listed below.

Linux/nVidia
- Gentoo Linux, XOrg X11
- nVidia GeForce (various) with nVidia binary driver
- Supports: GLXP (accelerated), SGIX (accelerated), GLX (non-accelerated)
- Notes: XLIB produces corrupted images

Linux/ATI
- Gentoo Linux, XOrg X11
- ATI ? with ATI flgrx driver
- Supports: GLXP (accelerated), GLX (non-accelerated)
- Notes: XLIB produces corrupt images; SGIX crashes Gazebo.

OSX/nVidia
- Apple OS X 10.3, Apple X11 1.0
- nVidia with Apple drivers
- Supports: XLIB (accelerated), GLX (non-accelerated)

Please let us know of any non-working combinations.

Performance tips

Gazebo can be very CPU intensive, with almost all of the cycles going into rendering or collision detection. Here are some tips for making rendering faster:

To good approximation, rendering time is proportional to the the number cameras (since each camera must render the scene), the size of the camera image(s), and the camera update rate(s). Reducing any or all of these will increase rendering speed significantly.

Rendering time scales with scene complexity (number of vertices). Some models are particularly vertex rich, and must be used sparingly. A good way to check the scene complexity is to force wire frame rendering using the polygonFill attribute; this will show all of the triangles in the scene.

Re-generate terrains with a sparser grid and/or larger error bound; this can dramatically reduce the number of vertices in a terrain.

Turn off skins or re-create the skin model with a reduced set of vertices.

Camera frustrums and clip planes

Gazebo uses the standard OpenGL perspective projection (pin-hole camera). The field-of-view for such cameras is defined by four attributes:

The horizontal field of view.
The aspect ratio (image width/height).
Near and far clip planes.

The easiest way to understand these attributes is through the notion of a frustrum (depicted below).

Camera frustrum

The frustrum defines the viewable volume in three dimensions, with the near and far clip attributes bounding the depth of the volume (i.e., the camera will only see points whose depth lies between the near and far clip values).

Clip values also have a second function: the ratio nearClip/farClip controls the effective resolution of the Z-buffer used by OpenGL for hidden surface removal. See the OpenGL documentation for details, but suffice to say setting the near clip to zero and the far clip to infinity is a bad idea. Lowering this ratio will lead to better quality rendering.

Last updated 12 September 2005 21:38:45