Jump to: navigation, search

Canvas View Camera Element

4,280 bytes added, 13:22, 2 January 2018
Implementation details / for the reviewer
| [[File:Canvas-view-element-prototype-by-icecode gl.png|thumb|upright|[[Canvas]] gui dialog with a custom canvas element to display view manager views (based on code prototyped by F-JJTH)]]
== Getting involved ==
Icecode GL has been quite interested in this subject lately. [...] For shader support it'd use the current effects framework, and to display stuff on the screen it'd either use Canvas or a OSG window directly.If you are interested feel free to contact him so he can share with you some code and pointers/ideas that he's been collecting along the way. I guess that'd be better than starting from zero.<ref>{{cite web |url = |title = <nowiki> Re: getting started with RTT </nowiki> |author = <nowiki> Icecode GL </nowiki> |date = Oct 5th, 2017 |added = Oct 5th, 2017 |script_version = 0.36 }}</ref>
The Canvas system is currently constrained to being 2D specific, i.e. to be useful for any of the "3d scene" stuff you're interested in, you'd need to read up on adding new/custom elements - e.g. those useful for 3d stuff, and effects/shaders specifically.As Icecode GL mentioned, this is something that he's been tinkering with lately. Like he also mentioned, based on Zan's groundwork (newcameras), we are looking at exposing a similar degree of flexibility via the Canvas system by introducing new elements and/or additional "modes".For starters, this will probably only involve a new view-manager based Canvas view to render a slave scenery view to a Canvas texture. The next incarnation may include effects/shader support to customie such a slave view.Besides, it would also be possible to render a totally independent scene/osg::Node - which is something that we once prototyped to load 3D models from disk and rotate/transform those using an osg::PositionAttitudeTransformMatrix
[[Howto:Extending Canvas to support rendering 3D models]]
[[File:Canvas-model-element-rotated.png|right|250px]] <ref>{{cite web |url = |title = <nowiki> Re: getting started with RTT </nowiki> |author = <nowiki> Hooray </nowiki> |date = Oct 7th, 2017 |added = Oct 7th, 2017 |script_version = 0.36 }}</ref>
== Implementation details / for the reviewer ==
BTW: This is also a good way to stress-test the renderer, as new cameras can be easily added to the scene at runtime, so that the impact of doing so can be easily measured.
the patch is experimental, it will basically look up a view and dynamically add a slave camera to the renderer that renders the whole thing to a Canvas, a Canvas is a fancy word for a RTT/FBO context in FlightGear that can be updated by using a property-based API built on top of the property tree in the form of events/signals that are represented via listeners.Which is to say each Canvas has a handful of well-defined property names (and types) that it is watching to handle "events" - think stuff like changing the sie/view port etc. And then there is a single top-level root group, which serves as the top-level element to keep other Canvas elements.A Canvas element is nothing more than a rendering primitive that the Canvas system can handle - e.g. stuff like a raster image can be added to a Canvas group, a text string/font, and 2D drawing primitives in the form of OpenVG instrutions mapped to ShivaVG. And that's basically about it (with a few exceptions that handle use-case specific stuff like 2D mapping/charts).Apart from that, the main thing to keep in mind is that a Canvas is really just a FBO - i.e. an invisible RTT context - to become actually visible, you need to add a so called "placement" - this tells the rendering engine to look up a certain canvas and add it to the scene/cockpit or the GUI (dialogs/windows).So far, all of this is handled using native code that watches the global /canvas tree in the property tree - there is a canvas manager that handles events and passes them onto the corresponding canvas instance and its child elements.Realistically, all Canvas textures are however instantiated/updated using scripting space hooks that end up writing to the corresponding properties in the global property tree, this makes it much easier to manipulate a canvas/element, because you don't need to do any low-level getprop/setprop stuff, but can directly use an element specific API.<ref>{{cite web |url = |title = <nowiki> Re: getting started with RTT </nowiki> |author = <nowiki> Hooray </nowiki> |date = Oct 7th, 2017 |added = Oct 7th, 2017 |script_version = 0.36 }}</ref>
To actually test the new element using the [[Nasal Console]], paste the following snippet of code into it:

Navigation menu