20,741
edits
CompositeViewer support: Difference between revisions
Jump to navigation
Jump to search
m
→Open Questions: https://sourceforge.net/p/flightgear/mailman/message/37075174/
m (→Open Questions: https://sourceforge.net/p/flightgear/mailman/message/37075174/) |
|||
| Line 90: | Line 90: | ||
=== Open Questions === | === Open Questions === | ||
'''Status 08/2020''' | |||
We are dropping compositor on next but we didn’t pull the switch yet, focusing on getting 2020.2 as stable as possible. | |||
It would be very nice if CompositeViewer just works. However, James emphasized that we have a very complex display stack, with lots of permutations, and frankly we’re trying to /simplify/ the display layer, in anticipation of VSG in the future, not add more special cases to it. Since we don’t really have a large pool of 3D renderer developers, we need to be able to use a standard one without too much additional work or customisation. | It would be very nice if CompositeViewer just works. However, James emphasized that we have a very complex display stack, with lots of permutations, and frankly we’re trying to /simplify/ the display layer, in anticipation of VSG in the future, not add more special cases to it. Since we don’t really have a large pool of 3D renderer developers, we need to be able to use a standard one without too much additional work or customisation. | ||
Getting rid of Rembrandt, and making Compositor the only rendering pipeline, will drastically help with reducing the number of code paths we need to maintain. So we should not in a hurry to add a new optional code path we have to test for, and which might interact weirdly with multi-camera / fgviewer / stereoscopic / etc. <ref>https://sourceforge.net/p/flightgear/mailman/message/37075182/</ref> | Getting rid of Rembrandt, and making Compositor the only rendering pipeline, will drastically help with reducing the number of code paths we need to maintain. So we should not in a hurry to add a new optional code path we have to test for, and which might interact weirdly with multi-camera / fgviewer / stereoscopic / etc. <ref>https://sourceforge.net/p/flightgear/mailman/message/37075182/</ref> | ||
What we need is a bit more analysis of what it might impact, in terms of multi-camera support, performance across different platforms and so on. Especially, knowing how it will impact switching to VSG in the future, if VSG isn’t going to have an equivalent, then we should be be quite reluctant to start using it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37075174/</ref> | |||
=== Potential Issues === | === Potential Issues === | ||
So far, it seemed we 'Cant Use' CompositeViewer because of $reasons in the Effects code<ref>https://sourceforge.net/p/flightgear/mailman/message/26189393/</ref>. Maybe the reason is simply that it needs some work to move away from the single CameraGroup, however.<ref>https://sourceforge.net/p/flightgear/mailman/message/37059939/</ref> | So far, it seemed we 'Cant Use' CompositeViewer because of $reasons in the Effects code<ref>https://sourceforge.net/p/flightgear/mailman/message/26189393/</ref>. Maybe the reason is simply that it needs some work to move away from the single CameraGroup, however.<ref>https://sourceforge.net/p/flightgear/mailman/message/37059939/</ref> | ||