To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

A Compositor is a rendering pipeline configured by the Property Tree. Every configurable element of the pipeline wraps an OpenGL/OSG object and exposes its parameters to the property tree. This way, the rendering pipeline becomes dynamically-reconfigurable at runtime.

Contents

Background

First discussed in 03/2012 during the early Rembrandt days, Zan came up with patches demonstrating how to create an XML-configurable rendering pipeline.

Back then, this work was considered to look pretty promising [1] and at the time plans were discussed to unify this with the ongoing Rembrandt implementation (no longer maintained).

Adopting Zan's approach would have meant that efforts like Rembrandt could have been implemented without requiring C++ space modifications.

Rembrandt's developer (FredB) suggested to extend the format to avoid duplicating the stages when you have more than one viewport, i.e. specifying a pipeline as a template, with conditions like in effects, and have the current camera layout refer the pipeline that would be duplicated, resized and positioned for each declared viewport [2]

Zan's original patches can still be found in his newcameras branches which allow the user to define the rendering pipeline in preferences.xml:

At that point, it didn't have everything Rembrandt's pipeline needs, but most likely could be easily enhanced to support those things.

Basically the original version added support for multiple camera passes, texture targets, texture formats, passing textures from one pass to another etc, while preserving the standard rendering line if user wants that. [3]

In 02/2018, Icecode GL re-implemented a more generic version of Zan's idea using Canvas concepts, which means the rendering pipeline is not just xml-configurable, but using listeners to be dynamically-reconfigurable at runtime via properties.

Status

08/2018

Fernando has been working on and off on multi-pass rendering support for
FlightGear since late 2017. It went through several iterations and
design changes, but he think it's finally on the right track. It's
heavily based on the Ogre3D Compositor and inspired by many
data-driven rendering pipelines. Its features include:

Completely independent of other parts of the simulator, i.e. it's part of SimGear and can be used in a standalone fashion if needed, ala Canvas.

Although independent, its aim is to be fully compatible with the current rendering framework in FG. This includes the Effects system, CameraGroup, Rembrandt and ALS (and obviously the Canvas).

Its functionality overlaps Rembrandt: what can be done with Rembrandt can be done with the Compositor, but not vice versa.

It doesn't increase the hardware requirements, it expands the hardware range FG can run on. People with integrated GPUs (Intel HD etc) can run a Compositor with a single pass that renders directly to the screen like before, while people with more powerful cards can run a Compositor that implements deferred rendering, for example.

This allows CameraGroup to manage windows, near/far cameras and other
slaves without interfering with what is being rendered
(post-processing, shadows...).

The Compositor is in an usable state right now: it works but there are
no effects or pipelines developed for it. There are also some bugs and
features that don't work as expected because of some hardcoded
assumptions in the FlightGear Viewer code. Still, I think it's time to
announce it so people much more knowledgeable than me can point me in
the right direction to get this upstream and warn me about possible
issues and worries. :)

The next major (and hopefully final) iteration of the Compositor is
mostly done now, just some more cleanup is needed. I've tried to keep
the changes contained in CameraGroup.cxx/hxx and in new files in
SimGear to ease the merging process.

Use Cases

FAQs

I started the Compositor to hopefully unify rendering in FG in the most
non-radical way. Instead of changing a large part of the codebase like
Rembrandt, the Compositor aims to bring the same funcionality and slowly
deprecate parts of the FG Viewer code.

Indeed, this should help bring more interesting effects to the table.
I'm specially looking forward to porting ALS to a multi-pass
environment through PBR.

Shadows

It includes shadows indeed. The Compositor stacks several passes of
different types on top of each other, and exchanges buffers between
them. Nothing prevents someone from creating a new pass type that
implements a shadow map pre-pass. I've already tried myself
successfully, but the problem is telling the pass which light should be
used, which brings me to spotlights.

Light Sources

Allowing aircraft/scenery developers to include "real" lights is a whole
different aspect of the scene graph that shouldn't be managed by the
Compositor. Some kind of system that exposes OpenGL lights should be
implemented and linked to the Compositor. Some decisions have to be made
though. In a forward renderer lights aren't as cheap as in a deferred
renderer, so if the aircraft developer says there has to be a light
there, someone using a forward renderer might see a performance drop or
not see them at all.

I haven't had the time to update the repos to the latest changes in the official repos, but it shouldn't matter for now.

Merging

I'd love to have this merged as soon as possible, but maybe next month is a
bit too rushed. I don't even know if the approach I'm using will be the
definitive one or the small implications the Compositor might have on the
rest of the viewer related code. I'm not in a rush though, I can wait for
the next release if I can't make a decent enough merge request in June/July.

Elements

Buffers

A buffer represents a texture or, more generically, a region of GPU memory. Textures can be of any type allowed by OpenGL: 1D, 2D, rectangle, 2Darray, 3D or cubemap.

Passes can render to a buffer (Render to Texture), to several buffers (Multiple Render Targets) or directly to the OSG context. This allows chaining of multiple passes, sharing buffers between them. They can also receive other buffers as input, so effects can access them as normal textures.

Canvas integration

Apart from serving as a debugging tool for visualizing the contents of a buffer, integrating the Compositor with Canvas allows aircraft developers to access RTT capabilities. Compositor buffers can be accessed within Canvas via a new custom Canvas Image protocol buffer://. For example, the path buffer://test-compositor/test-buffer displays the buffer test-buffer declared in test-compositor.