Compositor: Difference between revisions

Jump to navigation Jump to search

Compositor (view source)

Revision as of 12:17, 30 November 2019

9,143 bytes removed ,  30 November 2019
no edit summary
No edit summary
Line 63: Line 63:


The new '''Compositor''' is an improved re-implementation of Zan's original work using not just XML, but also [[Property Tree|properties]] and a handful of [[Canvas]] concepts.
The new '''Compositor''' is an improved re-implementation of Zan's original work using not just XML, but also [[Property Tree|properties]] and a handful of [[Canvas]] concepts.
== News / Changelog ==
== Developer Discussion ==
{{Note|This is a rough summary of the main topics discussed among core developers on the FlightGear Devel mailing list.}}
=== Integration ===
The Compositor is disabled by default at compilation time in
FlightGear (not SimGear). Both Rembrandt and the forward pipeline are
still available if this flag is disabled.<ref>https://sourceforge.net/p/flightgear/mailman/message/36578956/</ref>
The Compositor is a standalone part of SimGear, the problem is the
interfacing with FlightGear (CameraGroup and the FGRenderer). It's
hard to have two simultaneous renderers when many other parts of the
sim rely on it. You always end up with a lot of 'if' branching, as it
happended with Rembrandt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36657975/</ref>
=== Compatibility ===
it is worth remembering that at the moment compositor is
identical to the default pipeline and thus there will be no advantage
for flying - it is currently there so we can develop it further<ref>https://sourceforge.net/p/flightgear/mailman/message/36605836/</ref>
The Compositor is designed to be compatible with everything in
FlightGear, except of course Rembrandt and the classic forward
pipeline. It makes use of Effects for everything shader related and
works seamlessly with multiple monitors/windows defined in the
CameraGroup. There are also plans to support Canvas.
=== FGData structure ===
The current approach seems fine - i.e. having a Compositor
folder within fgdata to provide some isolation of the new components. 
My approach would likely be to create a Compositor/Shaders folder for
shaders rather than using the existing fgdata/Shaders folder.  Once
things mature, I'd revisit this to determine a long-term folder structure.<ref>https://sourceforge.net/p/flightgear/mailman/message/36657761/</ref>
Richard has proposed a similar file structure and Fernando agreed, it is
definitely a good idea to separate new Effects from the old ones for
now.<ref>https://sourceforge.net/p/flightgear/mailman/message/36657975/</ref>
There is a new scheme that Fernando is currently working on whereby we
have a definition of the effects/shaders within the pipeline keep them
within the pipeline folder structure; together with defining what the
shader does (if applicable) so it can be controlled by a future UI.
There is a very rough draft design doc for this available here
http://www.zaretto.com/sites/zaretto.com/files/compositor-effects-registry.pdf <ref>https://sourceforge.net/p/flightgear/mailman/message/36606242/</ref>
=== Canvas support ===
So far, we were focused on implementing camera views in Canvas. We also keep in mind that this might be an important groundwork for what might be RTT support for effects/shaders. For that we obviously need a link between Canvas and Effects. It's kind of a good thing that both systems are completely separated and don't know of each other, we are given more freedom when it comes to joining them. This link is kind of delicate and has to be well planned out. For example Hooray (and also Thorsten, but I'm not too sure) suggested per-element effects. It'd be kind of useful to have that, but would that give us the flexibility we need? Shaders can receive many input textures and modern shaders support MRT (Multiple Render Targets) too. It makes sense to come up with some kind of well defined link between Canvas and Effects that allows for inputting/outputting canvases via effects. This would allow the same things that per-element effects would allow but with more flexibility and less overlapping functionality. <ref>https://forum.flightgear.org/viewtopic.php?f=47&t=32846&#p318059</ref>
What we have now, works similarly to how Rembrandt does its buffers. There is a new texture type called "canvas" that allows shaders to access any canvas texture via a texture unit, just like you'd access a normal texture from the hard drive. This removes (most) limitations of addPlacement, which can only substitute the "base" texture (unit 0). The posibilities are endless, it just needs some care and work. At the moment we could have shadow mapping outside Rembrandt just by creating a new view placed at the Sun and make it render the depth buffer to a canvas. Then every ALS shader could access this canvas and do the shadow comparison thingy. Planar reflections in the water should be kind of trivial as well, it'd just require the model-view matrix to be multiplied by a reflection matrix and the water shader could just paste the result over the water surface (with some more fancy calculations to make it pretty of course).<ref>https://forum.flightgear.org/viewtopic.php?f=47&t=32846&hilit=canvas+view+element+offscreen#p318662</ref>
Actually, every ALS shader could choose to access this canvas - so one can run the more detailed opacity map technique in cockpit and shadow mapping outside for instance.<ref>https://forum.flightgear.org/viewtopic.php?f=47&t=32846&hilit=canvas+view+element+offscreen#p318693</ref>
=== Availability ===
Would it be practical to get to a point where both the legacy and
compositor CameraGroup classes can co-exist at runtime? I recently made a
fix (pull request coming shortly) that involved a lot of duplicate code in
the legacy and compositor code, and then I had to change compile options,
recompile, etc. to test it; yuck. I'm very enthusiastic about the
compositor, but it will get much more of a workout if it  is compiled and
available to everyone.<ref>https://sourceforge.net/p/flightgear/mailman/message/36605878/</ref>
=== Runtime Toggling ===
Ideally, we would want a toggle between Default and
Compositor pipelines while Compositor is being developed.  I would keep
the toggle point very simple for now - perhaps a commandline switch to
activate compositor and disable default.  The harder part is the
refactoring necessary to allow the two approaches to coexist - one being
active and the other being inactive (e.g. feature toggle -
https://www.martinfowler.com/articles/feature-toggles.html) <ref>https://sourceforge.net/p/flightgear/mailman/message/36657761/</ref>
Runtime toggling for the Compositor has been discussed before.
Implementing such thing is not trivial though. The legacy
CameraGroup/renderer is already quite messy due to Rembrandt. Around a
year ago, when I started planning the Compositor, I made the decision
to keep things simple and keep the CameraGroup implementation for the
compositor as a separate file, just so I wouldn't have to deal with
that mess. The advantages you mention for runtime toggling are indeed
very interesting, but I'm personally not interested in having to deal
with the headache caused by implementing it. I seem to recall that
James proposed adding a compositor build to Jenkins, that would be a
nice middle ground so people can test/develop for the Compositor while
keeping the legacy renderer intact.<ref>https://sourceforge.net/p/flightgear/mailman/message/36657975/</ref>
=== Replacing the legacy renderer ===
The vision is we would replace the legacy rendering with
compositor; this will then allow us to clean up a lot of the hardcoded
stuff that sets up the pipeline, remove the Rembrandt code and generally
have a good tidy up.
Tim Moore suggested to dump the legacy renderer and going with
the compositor. He did some work to eliminate the
need for the far camera, and decided to gamble on doing the work with the
compositor renderer instead of the legacy renderer. He had to add render
buffers to the compositor pass syntax, but otherwise it went well. Going
forward, other work he is doing will use the compositor.
This work uses a floating point depth buffer, the OpenGL clip control
extension to restrict Z values from 0 to 1, and the scheme of reversing the
Z values so that 0 is at the far plane. Tim will submit a merge request for
it once he determines if something similar will work for systems that don't
support clip control.<ref>https://sourceforge.net/p/flightgear/mailman/message/36659646/</ref>
drop support for legacy renderer: agree - not wise.  It is too early to
consider doing so.
== Gallery ==
<gallery mode=packed widths=230px heights=230px>
Aircrane-compositor-11-2019.jpeg|Aircrane helicopter in [[Compositor]] mode, screen shot by wlbragg <ref>https://forum.flightgear.org/viewtopic.php?f=47&t=36269&start=45#p357570</ref>
</gallery>
{{#ev:youtube|5KYZylR3Wao}}


== Features ==
== Features ==
Line 190: Line 77:


Currently the Compositor can only be enabled at compile time via the <code>-DENABLE_COMPOSITOR=ON</code> CMake flag in FlightGear. SimGear doesn't require any extra parameters. Once you have a binary with the Compositor enabled and you run it, you will be presented with the default rendering pipeline. At the time of writing, this is the low spec rendering pipeline. If you want to try the ALS pipeline, start FlightGear with the command line argument: <code>--compositor=Compositor/ALS/als</code>
Currently the Compositor can only be enabled at compile time via the <code>-DENABLE_COMPOSITOR=ON</code> CMake flag in FlightGear. SimGear doesn't require any extra parameters. Once you have a binary with the Compositor enabled and you run it, you will be presented with the default rendering pipeline. At the time of writing, this is the low spec rendering pipeline. If you want to try the ALS pipeline, start FlightGear with the command line argument: <code>--compositor=Compositor/ALS/als</code>
== Good to know ==
* still untested, but it's supposed to work with multiple monitors <ref>https://forum.flightgear.org/viewtopic.php?f=47&t=36269#p354669</ref>
* Spot lights aren't supported yet for clustered shading, i.e. they are registered and parsed but aren't processed as lights. Point lights are, but I don't remember what's their current status regarding shaders. <ref>https://forum.flightgear.org/viewtopic.php?f=47&t=36269#p353179</ref>
* shadows are only supported on the ALS pipeline <ref>https://forum.flightgear.org/viewtopic.php?f=47&t=36269&start=60#p357586</ref>
* Transparency on trees require MSAA (anti-aliasing) <ref>https://forum.flightgear.org/viewtopic.php?f=47&t=36269&start=45#p357580</ref>
*  Vegetation shadows will be done by the "legacy" method currently in use. Shadow mapping on vegetation is much more expensive in terms of performance and the current algorithm does the job well enough. <ref>https://forum.flightgear.org/viewtopic.php?f=47&p=357606</ref>


== Notes for aircraft developers ==
== Notes for aircraft developers ==
Line 320: Line 199:
* Should the terrain cast shadows? The terrain is rarely steep enough to cast shadows. Apart from that, the terrain in FlightGear messes with automatic near/far computations for the shadow passes since the geometry is not tessellated enough. Also, the terrain LOD is not good enough to have decent cull times at far cascades.
* Should the terrain cast shadows? The terrain is rarely steep enough to cast shadows. Apart from that, the terrain in FlightGear messes with automatic near/far computations for the shadow passes since the geometry is not tessellated enough. Also, the terrain LOD is not good enough to have decent cull times at far cascades.
* Adding a "internal only" shadow flag for aircraft developers. This allows farther shadow cascades to cull complex objects that are only visible in the nearest cascades. (Very important optimization for aircrafts with complex cockpit geometry).
* Adding a "internal only" shadow flag for aircraft developers. This allows farther shadow cascades to cull complex objects that are only visible in the nearest cascades. (Very important optimization for aircrafts with complex cockpit geometry).
* Vegetation shadows will be done by the "legacy" method currently in use. Shadow mapping on vegetation is much more expensive in terms of performance and the current algorithm does the job well enough. <ref>https://forum.flightgear.org/viewtopic.php?f=47&p=357606</ref>


==== Post-processing ====
==== Post-processing ====
Icecode
343

edits

Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/121182"

Navigation menu