Compositor: Difference between revisions

Jump to navigation Jump to search
882 bytes added ,  30 November 2019
m
→‎Availability: https://sourceforge.net/p/flightgear/mailman/message/36657975/
m (→‎Developer Discussion: structure topics)
m (→‎Availability: https://sourceforge.net/p/flightgear/mailman/message/36657975/)
Line 98: Line 98:
compositor, but it will get much more of a workout if it  is compiled and
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>
available to everyone.<ref>https://sourceforge.net/p/flightgear/mailman/message/36605878/</ref>
=== Runtime Toggling ===
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 ===
=== Replacing the legacy renderer ===

Navigation menu