Canvas view camera element: Difference between revisions

Jump to navigation Jump to search
m
Line 66: Line 66:
   |date  =  Sep 2nd, 2017  
   |date  =  Sep 2nd, 2017  
   |added  =  Sep 2nd, 2017  
   |added  =  Sep 2nd, 2017  
  |script_version = 0.40
  }}</ref>
it would be possible to also come up with an XML-configurable rendering pipeline - in fact, Zan once came up with a modified CameraGroup design that would move the whole hard-coded pipeline to XML space: [[Canvas Development#Supporting Cameras]]<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=275228#p275228
  |title  =  <nowiki> Re: Review of FG on reddit: xpost </nowiki>
  |author =  <nowiki> Hooray </nowiki>
  |date  =  Feb 6th, 2016
  |added  =  Feb 6th, 2016
  |script_version = 0.40
  }}</ref>
Ideally, something like this would be integrated with the existing view manager, i.e. using the same property names (via property objects), and then hooked up to CanvasImage, e.g. as a custom '''camera://''' protocol (we already support canvas:// and http(s)://)
So some kind of dedicated CanvasCamera element would make sense, possibly inheriting from CanvasImage.
And it would also make sense to look at Zan's new-cameras patches, because those add tons of features to CameraGroup.cxx
This would already allow arbitrary views slaved to the main view (camera)
<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=261665#p261665
  |title  =  <nowiki> Re: WINDOW IN WINDOW </nowiki>
  |author =  <nowiki> Hooray </nowiki>
  |date  =  Oct 25th, 2015
  |added  =  Oct 25th, 2015
  |script_version = 0.40
  }}</ref>
As has been said previously, the proper way to support "cameras" via Canvas is using CompositeViewer, which does require a re-architecting of several parts of FG: [[CompositeViewer Support]]
Given the current state of things, that seems at least another 3-4 release cycles away.
So, short of that, the only thing that we can currently support with reasonable effort is "slaved views" (as per $FG_ROOT/Docs/README.multiscreen).
That would not require too much in terms of coding, because the code is already there - in fact, CameraGroup.cxx already contains a RTT/FBO (render-to-texture) implementation that renders slaved views to an offscreen context. This is also how Rembrandt buffers are set up behind the scenes.
So basically, the code is there, it would need to be extracted/genralied and turned into a CanvasElement, and possibly integrated with the existing view manager code.
And then, there also is Zan's newcameras branch, which exposes rendering stages (passes) to XML/property tree space, so that individual stages are made accessible to shaders/effects.
Thus, most of the code is there, it is mainly a matter of integrating things, i.e. that would require someone able to build SG/FG from source, familiar with C++ and willing/able to work through some OSG tutorials/docs to make this work<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=260810#p260810
  |title  =  <nowiki> Re: WINDOW IN WINDOW </nowiki>
  |author =  <nowiki> Hooray </nowiki>
  |date  =  Oct 17th, 2015
  |added  =  Oct 17th, 2015
  |script_version = 0.40
  }}</ref>
Canvas is/was primarily about exposing 2D rendering to fgdata space, so that fgdata developers could incorporatedevelop and maintain 2D rendering related features without having to be core developers (core development being an obvious bottleneck, as well as having  significant barrier to entry).
In other words, people would need to be convinced that they want to let Canvas evolve beyond the 2D use-case, i.e. by allowing effects/shaders per element, but also to let Cameras be created/controlled easily.
Personally, I do believe that this is a worthwhile thing to aim for, as it would help unify (and simplify) most RTT/FBO handling in SG/FG, and make this available to people like Thorsten who have a track record of doing really fancy, unprecedented stuff, with this flexibility.
Equally, there are tons of use-cases where aircraft/scenery developers may want to set up custom cameras (A380 tail cam, space shuttle) and render those to an offscreen texture (e.g. GUI dialog and/or MFD screen).
It is true that "slaved views" are kinda limited at the moment, but they are also comparatively easy to set up, so I think that supporting slaved camera views via Canvas could be a good way to bootstrap/boost this development and pave the way for CompositeViewer adoption/integration in the future. <ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=260810#p260810
  |title  =  <nowiki> Re: WINDOW IN WINDOW </nowiki>
  |author =  <nowiki> Hooray </nowiki>
  |date  =  Oct 17th, 2015
  |added  =  Oct 17th, 2015
   |script_version = 0.40  
   |script_version = 0.40  
   }}</ref>
   }}</ref>

Navigation menu