20,741
edits
(10 intermediate revisions by the same user not shown) | |||
Line 5: | Line 5: | ||
|name = Canvas Camera Views | |name = Canvas Camera Views | ||
|started = 08/2016 (prototyped by F-JJTH) | |started = 08/2016 (prototyped by F-JJTH) | ||
|description = adds support for rendering slave scenery views to a FBO/RTT (texture) | |description = adds support for rendering slave scenery views to a FBO/RTT (offscreen-texture) | ||
|status = experimental/known issues | |status = experimental/known issues (being prepared for review/integration) | ||
|maintainers = none | |maintainers = none | ||
|developers = F-JJTH, Icecode GL, Hooray | |developers = F-JJTH, Icecode GL, Hooray, cyrfer <ref>{{cite web |url = https://forum.flightgear.org/viewtopic.php?p=320012#p320012 |title = <nowiki> Re: getting started with RTT </nowiki> |author = <nowiki> cyrfer </nowiki> |date = Oct 5th, 2017 |added = Oct 5th, 2017 |script_version = 0.36 }}</ref><ref>{{cite web |url = https://forum.flightgear.org/viewtopic.php?p=324494#p324494 |title = <nowiki> Re: Canvas:View development </nowiki> |author = <nowiki> cyrfer </nowiki> |date = Dec 14th, 2017 |added = Dec 14th, 2017 |script_version = 0.36 }}</ref>, Stuart (review <ref>{{cite web | ||
|url = https://forum.flightgear.org/viewtopic.php?p=317967#p317967 | |||
|title = <nowiki> Re: Gear view in cockpit computer </nowiki> | |||
|author = <nowiki> stuart </nowiki> | |||
|date = Sep 1st, 2017 | |||
|added = Sep 1st, 2017 | |||
|script_version = 0.40 | |||
}}</ref>) | |||
<!-- | |||
|topic-sg = https://sourceforge.net/u/fgarlin/simgear/ | |||
--> | |||
}} | }} | ||
Line 15: | Line 25: | ||
== Summary == | == Summary == | ||
{{Main article|Compositor}} | |||
Several aircraft developers have manifested their interest in being able to render to a texture (RTT) {{Wikipedia|Render target}} and use it inside cockpits as mirrors, external cameras (so called tail cams) and other uses. Effects and shaders developers have also reached a point where ignoring RTT is a waste of resources and a limitating factor when creating new effects. Although this Canvas element is directed mainly towards the first need, it is a first step forward in terms of finally exposing Render To Texture capabilities to non-C++ space too. | Several aircraft developers have manifested their interest in being able to render to a texture (RTT) {{Wikipedia|Render target}} and use it inside cockpits as mirrors, external cameras (so called tail cams) and other uses. Effects and shaders developers have also reached a point where ignoring RTT is a waste of resources and a limitating factor when creating new effects. Although this Canvas element is directed mainly towards the first need, it is a first step forward in terms of finally exposing Render To Texture capabilities to non-C++ space too. | ||
Line 22: | Line 33: | ||
* Mirrors | * Mirrors | ||
* In-sim view configuration | * In-sim view configuration | ||
* On demand creation of views and windows | * On demand creation of views and windows (e.g. [[FGCamera]] previews) | ||
* Prototyping/testing HUDs or PFDs requiring synthetic terrain to work properly | * Prototyping/testing HUDs or PFDs requiring synthetic terrain to work properly | ||
Line 129: | Line 140: | ||
| [[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)]] | | [[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 = https://forum.flightgear.org/viewtopic.php?p=320025#p320025 |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 = https://forum.flightgear.org/viewtopic.php?p=320105#p320105 |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 == | == Implementation details / for the reviewer == | ||
Line 134: | Line 153: | ||
{{Note|This section provides a rough overview for the potentiaal reviewer, which is also intended to be used as the commit message when/if this should get committed}} | {{Note|This section provides a rough overview for the potentiaal reviewer, which is also intended to be used as the commit message when/if this should get committed}} | ||
This set of patches (touching SimGear and fgdata) implements a new <code>Canvas::Element</code> by creating a sub-class named <code>Canvas::View</code>. The meat of it is in the constructor, i.e. <code>Canvas::View::View()</code>, where an off-screen camera (RTT/FBO) is set up, the FGCanvasSystemAdapter file has been extended to provide access to the FlightGear view manager to compute/obtain the view-specific view matrix, which is then used by | This set of patches (touching SimGear and fgdata) implements a new <code>Canvas::Element</code> by creating a sub-class named <code>Canvas::View</code>. The meat of it is in the constructor, i.e. <code>Canvas::View::View()</code>, where an off-screen camera (RTT/FBO) is set up, the FGCanvasSystemAdapter file has been extended to provide access to the FlightGear view manager to compute/obtain the view-specific view matrix, which is then used by this new canvas view element to update the offscreen camera in Canvas::View::update() accordingly. | ||
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 = https://forum.flightgear.org/viewtopic.php?p=320105#p320105 |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]] | To actually test the new element using the [[Nasal Console]], paste the following snippet of code into it: | ||
<syntaxhighlight lang="nasal"> | <syntaxhighlight lang="nasal"> | ||
Line 198: | Line 220: | ||
== Ideas == | == Ideas == | ||
{{See also|Canvas_Troubleshooting#Adding_draw_masks_for_Canvas}} | {{See also|Canvas_Troubleshooting#Adding_draw_masks_for_Canvas}} | ||
* do we need support for looking up view numbers by name ? | |||
* support draw-masks for scene graph features (terrain, skydome, models etc): " it'd be benefitial in the long run to let the user choose what part of the scene graph they want to show. This would be useful for deferred rendering schemes, where sometimes you don't need to display the whole scenery to save some precious frames. Canvas makes that easy with all of its property handling" | * support draw-masks for scene graph features (terrain, skydome, models etc): " it'd be benefitial in the long run to let the user choose what part of the scene graph they want to show. This would be useful for deferred rendering schemes, where sometimes you don't need to display the whole scenery to save some precious frames. Canvas makes that easy with all of its property handling" | ||
* work out what is needed for [https://forum.flightgear.org/viewtopic.php?f=71&t=27985&p=264718&hilit=synthetic+terrain#p264718v synthetic terrain views] [http://www.aircraftspruce.eu/catalog/graphics/10-03932s.jpg] | * work out what is needed for [https://forum.flightgear.org/viewtopic.php?f=71&t=27985&p=264718&hilit=synthetic+terrain#p264718v synthetic terrain views] [http://www.aircraftspruce.eu/catalog/graphics/10-03932s.jpg] | ||
Line 232: | Line 255: | ||
|script_version = 0.40 | |script_version = 0.40 | ||
}}</ref> | }}</ref> | ||
* check if '''CullThreadPerCameraDrawThreadPerContext''' works, see [[Howto:Activate multi core and multi GPU support]] | |||
== Base Package == | == Base Package == |