VRL Anti-Aliasing

There have been tons of articles and research papers about anti-aliasing. Only a few solutions have proven to be robust and performant in this area. HOOPS Luminate delivers several methods to add anti-aliasing to rendered images, both for software and for hardware rendering needs.

We have a number of hardware rendering anti-aliasing methods available in HOOPS Luminate:

Using HOOPS Luminate’s ‘engine anti-aliasing’. HOOPS Luminate’s engine anti-aliasing is a hardware method based on brute force supersampling. See below under Engine Anti-Aliasing. The engine anti-aliasing method may be the best compromise and the most efficient anti-aliasing technique available for hardware rendering needs.

Using the RED::RenderShaderAAFilter shader. This shader implements an anti-aliasing technique based on the NVIDIA FXAA method by Timothy Lottes. See below under FXAA.

Leveraging GPU’s hardware anti-aliasing capabilities: Pure hardware anti-aliasing can be enabled at the window construction time, using the RED::WindowRenderInfo class. See below under Hardware Anti-Aliasing.

Finally, HOOPS Luminate delivers a unique software rendering anti-aliasing method:

Based on supersampling. See below under Software Anti-Aliasing

Engine Anti-Aliasing

HOOPS Luminate’s engine anti-aliasing is a technique based on brute force supersampling. The quality of this method is near perfect for the number of samples, as it’s brute force. It’s enabled using RED::IViewpointRenderList::SetEngineAntiAlias. specifying the number of samples will increase the resolution of the rendered image which is processed internally by tiles before being stretched back to the original size:

../../../../_images/engine_aa_no_superscale.png — **Engine AA workflow, without using the superscaling option**

This anti-aliasing technique is quite slow for a hardware based rendering technique. However, it has the advantage that it does not consume a single byte of extra memory during the rendering. It works for all buffer formats, including LDR buffer formats and HDR float or half float buffer formats.

The engine anti-aliasing technique can also activate the ‘superscale’ option of the method. In this case, the rendering occurs in one single pass:

../../../../_images/engine_aa_superscale.png — **Engine AA workflow, using the superscaling option**

This method is almost as fast as any hardware native anti-aliasing method. It does consume a lot of extra memory (needed to render into an extra large buffer). It works for all buffer formats, which is a must have with modern graphics. Of course, as this is still brute force supersampling, the quality remains at a top level.

FXAA

FXAA is the fastest anti-aliasing technique available. However, it’s not a true anti-aliasing method. FXAA is a post-processing filter applied to the scene. This means that using FXAA, details that were missed in the original will not be revealed. However, FXAA is good at smoothing long edges and frontiers between geometries. For this purpose it’s a very good, fast and convenient tool.

Using the FXAA anti-aliasing is performed by rendering the scene to a render image and then having this image processed by a RED::RenderShaderAAFilter.

Hardware Anti-Aliasing

The effect of hardware anti-aliasing is widely dependent on the underlying GPU capability. That’s why it’s difficult to do comparisons on this without explicitely choosing several GPUs to work with. Most hardware anti-aliasing technique are generally fast, but produce average quality results. The methods used in GPU based hardware anti-aliasing techniques generally differ a lot from pure brute force super-sampling, which is our preferred solution for the generation of high quality images.

Hardware anti-aliasing must be set up at the window creation time using the optional RED::WindowRenderInfo parameter, using RED::WindowRenderInfo::SetHardwareAntiAlias. The anti-aliasing setting used can’t be changed after the window construction.

Hardware anti-aliasing is only available for the default VRL of a window. It’ll be ignored for auxiliary VRLs, due to the usage of OpenGL Framebuffer Objects for the rendering into VRLs.

Hardware anti-aliasing is generally not available for HDR formats of the rendering buffer. This makes it very limited in uses for the production of real-time high quality images that deserve a full HDR rendering pipeline.

Software Anti-Aliasing

Software anti-aliasing is turned on using RED::IViewpointRenderList::SetSoftAntiAlias. Of course, the window must be rendered using one of the RED::IWindow::FrameTracing (or derived) methods. Activating software anti-aliasing produces brute force high quality results in software.

Comparison of Anti-Aliasing Methods

Zooming the images in your browser should reveal all the details. The FXAA method can’t catch up all the details, while the two other methods are pure brute force techniques, so they do reveal a lot more of all the originally missed details.

../../../../_images/vrl_noaa.png — **No anti-aliasing**

../../../../_images/vrl_fxaa.png — **FXAA anti-aliasing**

../../../../_images/vrl_engineaa.png — **Engine anti-aliasing**

../../../../_images/vrl_softaa.png — **Software anti-aliasing**