Canvas news: Difference between revisions

Canvas news (view source)

Revision as of 15:26, 4 November 2018

14,599 bytes added , 4 November 2018

→‎Compositor

Hooray

Administrators

20,741

edits

@@ Line 1: / Line 1: @@
 {{Canvas Navigation}}
-This page is primarily intended to keep track of Canvas related core changes and discussions, i.e. mainly of interest to people who are not able to follow the forum/devel list regularly, but who may still want to stay up to date regarding future Canvas developments (i.e. not including fgaddon).
+This page is primarily intended to keep track of Canvas related core/fgdata changes and discussions, i.e. mainly of interest to people who are not able to follow the forum/devel list regularly, but who may still want to stay up to date regarding future Canvas developments (i.e. not including fgaddon).
 Everybody is invited to help contribute to maintain this page and provide up-to-date information. Also, quoting/referincing devel/forum list talks is actively encouraged, too - to help provide the corresponding pointers back to the original discussion threads: [[Instant-Cquotes]].
+== 2019 ==
+placeholder for next year
 == 2018 ==
+=== Compositor ===
+{{Main article|Compositor}}
+[[File:Compositor-08-2018.png|right|thumb|A screenshot showing post-processed gaussian blur and a blue filter:[https://i.imgur.com/Zzxre8a.png]]]
+{{Usr|Icecode}} has been working on and off on multi-pass rendering support for
+FlightGear since late 2017. It went through several iterations and
+design changes, but he think it's finally on the right track. It's
+heavily based on the Ogre3D Compositor and inspired by many
+data-driven rendering pipelines. Its features include:
+* Completely independent of other parts of the simulator, i.e. it's part of SimGear and can be used in a standalone fashion if needed, ala Canvas.
+* Although independent, its aim is to be fully compatible with the current rendering framework in FG. This includes the Effects system, CameraGroup, Rembrandt and ALS (and obviously the Canvas).
+* Its functionality overlaps Rembrandt: what can be done with Rembrandt can be done with the Compositor, but not vice versa.
+* Fully configurable via a XML interface without compromising performance (ala Effects, using PropertyList files).
+* Optional at compile time to aid merge request efforts.
+* Flexible, expandable and compatible with modern graphics.
+* It doesn't increase the hardware requirements, it expands the hardware range FG can run on. People with integrated GPUs (Intel HD etc) can run a Compositor with a single pass that renders directly to the screen like before, while people with more powerful cards can run a Compositor that implements deferred rendering, for example.
+Unlike Rembrandt, the Compositor makes use of scene graph cameras
+instead of viewer level cameras.
+This allows CameraGroup to manage windows, near/far cameras and other
+slaves without interfering with what is being rendered
+(post-processing, shadows...).
+The Compositor is in an usable state right now: it works but there are
+no effects or pipelines developed for it. There are also some bugs and
+features that don't work as expected because of some hardcoded
+assumptions in the FlightGear Viewer code. Still, I think it's time to
+announce it so people much more knowledgeable than me can point me in
+the right direction to get this upstream and warn me about possible
+issues and worries. :)
+=== Aircraft Dialogs ===
+Some of you may already know that the current tool to generate the dialogs ([[PUI]]) is going to disappear in the mid-future. After some (partially controversial) discussion, there seems now to be some support for the idea that canvas is a good tool to generate aircraft-specific dialogs in the future <ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/93862C87-0D3E-47BB-B169-8D3CBBF963B7%40kdab.com/#msg36194973</ref> (as it allows to tailor the dialog closely to the plane and also, canvas being canvas, the UI can smoothly mesh with the 3d models, so you can project a canvas checklist onto a 3d model in sim for instance rather than a popup window).
+Thorsten would very much like to claim to be pioneering this approach, but in fact he believes the [[Extra EA-500|Extra-500 team]] is - look at the [[Extra_EA-500/failure_dialog|failure dialog of that plane]] where you can click the components you want to fail and you see what he means!
+[[File:Extra500-Failuredialog-deice.png|right|thumb|500px|Extra 500 - failure dialog - de-ice]]
+Anyway, Thorsten has started to roll out a few designs of his own and try to keep the tools fairly general so that they can be re-used by others- so here's the revised version of the Shuttle propellant dialog.
+[[File:Propellant dlg02.jpg|thumb|right|an example of the detail dialog which allows to set levels of fuel and oxidizer separately (and the overview dialog shows the usable propellant then, i.e. the minimum of the two) - for aircraft, this would be somewhat simpler.]]
+The general idea is to use semi-transparent 'content gauges' on a background raster image to show where the tank is located and how full it currently is - double-clicking any tank will bring up a detail window which allows to set the content (here propellant and oxidier separately, this is rocket fuel...) and also shows the current tank pressures and temperatures.
+The whole thing can readily be applied on top of a different raster image with a different number of tanks - you just instance and position the labels and 'gauges' you need - in fact placement is probably what's going to take longest (at least for me).
+The whole thing is currently in flux  <ref>{{cite web
+  |url    =  https://forum.flightgear.org/viewtopic.php?p=326789&sid=c15d338facab18fb091aa0530f5dfa0f#p326789
+  |title  =  <nowiki> Aircraft-specific dialogs </nowiki>
+  |author =  <nowiki> Thorsten </nowiki>
+  |date   =  Jan 24th, 2018
+  |added  =  Jan 24th, 2018
+  |script_version = 0.36
+  }}</ref>
+If anyone wants to follow the development or use the code, it's here:
+https://sourceforge.net/p/fgspaceshuttledev/code/ci/development/tree/Nasal/canvas/canvas_dialogs.nas
+=== Plot2D ===
+[[File:Oscilloscope.png|thumb|rleibner's new Oscilloscope addon is working.This screenshot shows the usual c172p "magnetos checking"  Channel 1 (yellow) is '''rpm''' (100 rpm / div).Channel 2 (mauve) is '''magnetos''' (1 / div).Time sweep is 200 ms / div.The idea is to share it as an addon. Mainly to have some feedback about plot2D/graph.<ref>{{cite web  |url    =  https://forum.flightgear.org/viewtopic.php?p=325929#p325929   |title  =  <nowiki> Re: Plot2D and graph helpers </nowiki>   |author =  <nowiki> rleibner </nowiki>   |date   =  Jan 6th, 2018   |added  =  Jan 6th, 2018   |script_version = 0.36   }}</ref>]]
 == 2017 ==
+=== Vertical Situation Display ===
+[[File:Rleibner-canvas-vsd-12-2017.png|thumb|rleibner is developing a graph class that works using local (customized) coordinates and calls the plot2D helpers (see below).For testing (and as exercise) he came up with a VSD (Vertical Situation Display): <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=33457#p324637</ref>]]
+rleibner is developing a graph class that works using local (customized) coordinates and calls the plot2D helpers (see below).
+For testing (and as exercise) he came up with a VSD (Vertical Situation Display): <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=33457#p324637</ref>
+=== Plot2D Helpers ===
+[[File:Plot2D.rectangle and grid.png|thumb]]
+[[File:Plot2D.polyline.png|thumb|plot2D.polyline example]]
+[[File:Graph examples.png|thumb|rleibner's Canvas plotting framework implemented in Nasal <ref>https://forum.flightgear.org/viewtopic.php?f=30&t=32882&start=90</ref>]]
+'''Plot2D''' is nothing more than a collection of helpers that aims to facilitate the task of coding. It makes intensive use of the [[Canvas Nasal API|Canvas API]], a mandatory reference for those who intend to refine the result beyond what is offered by plot2D.<br />
+It is assumed here that you already have a minimal knowledge about [[Canvas]].<br />
+For now '''Plot2D''' resides in the '''SpokenGCA''' addon, but the idea is that in the future it could be included in the $FG-ROOT/Nasal/canvas directory.<br />
+Continue reading at [[How to manipulate Canvas elements]] ...
+=== FG1000 ===
+Here is a little update o the G1000 emulation. Stuart has now got the key [[MapStructure]] layers in place, though they are not styled correctly for the '''G1000''' yet and Stuart would like to replace some of them (airspace in particular) with vector data, and started on the MFD architecture. For prototyping he hacked together a [[PUI]] dialog box, which speeds up development massively as it reloads all the Nasal code each time it's opened.
+There's a screenshot of it here: [[File:Fg1000_mfd.jpg|thumb|right]]
+There's also a wiki page of the current status here: http://wiki.flightgear.org/FG1000 Next steps are to get the MFD architecture in place - this will probably require some changes to Richard's generic [[Canvas MFD Framework|MFD]] to support buttons that don't change the MFD pages better. Stuart has not yet pushed this to fgdata - he'll wait until he's happy with the overall architectures so that there is a solid base for anyone else interested in helping out.<ref>{{cite web
+  |url    =  https://sourceforge.net/p/flightgear/mailman/message/36103513/
+  |title  =  <nowiki> [Flightgear-devel] FG1000 update </nowiki>
+  |author =  <nowiki> Stuart Buchanan </nowiki>
+  |date   =  Nov 4th, 2017
+  |added  =  Nov 4th, 2017
+  |script_version = 0.40
+  }}</ref>
+=== CanvasWidget and PUI ===
+James pushed a change which changes how we integrate [[PUI]] into the renderer and other systems  <ref>https://sourceforge.net/p/flightgear/flightgear/ci/804dc4e74ab921f196ca5e09eb7cd6de74b09c0d/</ref>; this makes our PUI usage more modular, so it can be enabled / disabled in a standard way. It also renders PUI via an FBO so we can use it safely (and scale it) on HiDPI screens, since PUI is too old to support a scaling factor as more modern UI toolkits would do. I’ve done a fair amount of testing, and everything seems to be working, but if you see any changes in how PUI reacts to mouse or key presses, or the appearance of things, please let James know via the issue or devel mailing list. It’s using the same code as it always did but starting from a slightly different place, both in terms of drawing and event handling. One temporary regression: right now CanvasWidget (the mechanism by which we include canvas content into PUI) is messed up because previously PUI had no alpha channel, so the canvas’s alpha was ignored.
+With the new system, the alpha is actually being used, but this is not really desired - it shows up as a semi-transparent map background in the ‘Select airport’ airfield chart, and the Map-Canvas window at least. James thought he had a work-around for this, but the one he came up with is awkward to support on Windows, he still needs to think on a better solution, so in the meantime he pushed a hack so at least Windows still builds and runs <ref>https://sourceforge.net/p/flightgear/flightgear/ci/c1df6e9d1528fc2513c6f455f0c0ccc6ca74e34a/</ref>. (If your canvas content inside PUI has an opaque background, you’ll be fine, so one fix is just to adjust the Canvas code for those dialogs, but James would like to find a backwards compatible fix)<ref>{{cite web
+  |url    =  https://sourceforge.net/p/flightgear/mailman/message/36084254/
+  |title  =  <nowiki> [Flightgear-devel] PUI non-change, CanvasWidget appearance </nowiki>
+  |author =  <nowiki> James Turner </nowiki>
+  |date   =  Oct 20th, 2017
+  |added  =  Oct 20th, 2017
+  |script_version = 0.40
+  }}</ref>
+===MapStructure used by airports.xml ===
+[[File:Airport-selection dialog updated to use MapStructure.png|thumb|Screenshot showing a the [[PUI]] based airports.xml dialog with an embedded [[Canvas]] widget feature a [[MapStructure]] based airport diagram developed by Stuart]]
+Stuart has committed some changes <ref>https://sourceforge.net/p/flightgear/fgdata/ci/d84c527ca747dd6bbd9634507f0664ff3631bdef/</ref> to update the Select Airport dialog to use [[Canvas MapStructure]] Layers to display airport information, rather than the now deprecated map layers. The change should be largely transparent to end users - the only significant change is that your can display navigation symbols. This is all part of a long-term effort to provide the building blocks for a Garmin G1000 - these layers could be used for the airport display on the MFD, and could easily be combined with the APS layer to show a moving aircraft.<ref>{{cite web
+  |url    =  https://sourceforge.net/p/flightgear/mailman/message/36075357/
+  |title  =  <nowiki> [Flightgear-devel] Updated Select Airport dialog </nowiki>
+  |author =  <nowiki> Stuart Buchanan </nowiki>
+  |date   =  Oct 13th, 2017
+  |added  =  Oct 13th, 2017
+  |script_version = 0.40
+  }}</ref>
 === Canvas Slippy Maps ===
 [[File:StuartsSlippyMap1.png|thumb|Stuart pushed some changes to fgdata with OpenStreetMap, OpenAIP and VFRMap layers for the Canvas Map Layer system, which can be seen on the canvas map dialog.  They use a generic Slippy Map OverlayLayer Map Layer. Additional web-based mapping can be trivially added by creating a new lcontroller.  See Nasal/Canvas/map/OpenAIP.lcontroller for an example.I've also added a Web Mercator Projection to the Canvas Map support.The wiki will be updated shortly.<ref>{{cite web  |url    =  https://forum.flightgear.org/viewtopic.php?p=319545#p319545   |title  =  <nowiki> Re: Canvas G1000 </nowiki>   |author =  <nowiki> stuart </nowiki>   |date   =  Sep 28th, 2017   |added  =  Sep 28th, 2017   |script_version = 0.40   }}</ref>]]
 [[File:StuartsSlippyMap2.png|thumb|Stuart pushed some changes to fgdata with OpenStreetMap, OpenAIP and VFRMap layers for the Canvas Map Layer system, which can be seen on the canvas map dialog.  They use a generic Slippy Map OverlayLayer Map Layer. Additional web-based mapping can be trivially added by creating a new lcontroller.  See Nasal/Canvas/map/OpenAIP.lcontroller for an example.I've also added a Web Mercator Projection to the Canvas Map support.The wiki will be updated shortly.<ref>{{cite web  |url    =  https://forum.flightgear.org/viewtopic.php?p=319545#p319545   |title  =  <nowiki> Re: Canvas G1000 </nowiki>   |author =  <nowiki> stuart </nowiki>   |date   =  Sep 28th, 2017   |added  =  Sep 28th, 2017   |script_version = 0.40   }}</ref>]]
+[[File:StuartsSlippyMap3.png|thumb|MapStructure OpenAIP layer created by Stuart for the ongoing G1000 effort]]
+[[File:StuartsSlippyMap4.png|thumb|MapStructure OSM (OpenStreetMap) layer created by Stuart for his ongoing G1000 effort]]
+[[File:Slawek-stamen-maps.png|thumb|Regarding mailling list talk: https://sourceforge.net/p/flightgear/mailman/message/36059733/ and some information in G1000 canvas topic (https://forum.flightgear.org/viewtopic.php?f=71&amp;t=32764There is commented out three different map styles (terrain + overlay, terrain, toner). One can apply this patch to get new tile rendering.<ref>{{cite web  |url    =  https://forum.flightgear.org/viewtopic.php?p=319802#p319802   |title  =  <nowiki> Canvas MapLayer for OSM, OpenAIP, VFR Sectionals and other </nowiki>   |author =  <nowiki> slawekmikula </nowiki>   |date   =  Oct 2nd, 2017   |added  =  Oct 2nd, 2017   |script_version = 0.40   }}</ref>]]
 Stuart wants to build a set of Canvas MapStructure layers for a G1000 implementation - the canvas map UI is really just a way to display it.<ref>{{cite web
@@ Line 231: / Line 355: @@
 === G1000 & MapStructure improvements ===
+{{Main article|FG1000}}
 As of 09/2017, Stuart started making some tentative steps towards a full Garmin [[G1000]] simulation, he started with the excellent xkv1000 as a starting point, particularly for the PFD which very closely mirrors the G1000.
@@ Line 580: / Line 705: @@
 === 2D Panels ===
-James has done most of the work to port the 2D panels to use Canvas, and will do the C++ HUD next, and hence is creating Canvas elements bypassing the Nasal API.<ref>{{cite web
+James is working towards migrating 2D panels to use the Canvas<ref>https://sourceforge.net/p/flightgear/mailman/message/35623408/</ref>.
+This step was inspired by a discussion that originally took place on the devel list, i.e. we should move the 2D panel and HUD rendering over to this approach, since that would get rid of all the legacy OpenGL code besides the GUI. <ref>https://sourceforge.net/p/flightgear/mailman/message/29584988/</ref>
+Moving the HUD to use the Canvas would be a great step from his point of view, since it and 2D panels (which he is happy to write the convert for!) are the last places besides the UI which make raw OpenGL calls, and hence would benefit from moving to the Canvas (and thus, to use OSG internally) <ref>https://sourceforge.net/p/flightgear/mailman/message/30058187/</ref>
+The original goal was to identify common requirements to seee how we manage XML / property-list file processing in a nice way, to support the various formats we want to create canvas elements from - GUI dialogs, 2D panels and HUDs.<ref>https://sourceforge.net/p/flightgear/mailman/message/29588419/</ref>
+James is planning in the next couple of weeks to port the panel code to generate Canvas elements, and then submit my fgcanvas utility to render any Canvas remotely, That code currently users software rendering (too slow for the RaspberryPi he expects), but upgrading the code to use OpenGL ES2 rendering is next on his todo-list so he can fun on Android / iOS devices as well as Raspbery Pi. If you’re interested in working on that please let him know, he would be glad of the help.<ref>https://sourceforge.net/p/flightgear/mailman/message/35552824/</ref>
+James has done most of the work to port the 2D panels to use Canvas in an experimental branch<ref>https://sourceforge.net/p/flightgear/mailman/message/35691472/</ref>, and will do the C++ HUD next, and hence is creating Canvas elements bypassing the Nasal API.<ref>{{cite web
    |url    =  https://sourceforge.net/p/flightgear/mailman/message/35574596/
    |title  =  <nowiki> Re: [Flightgear-devel] Observation about the Canvas Z-ordering </nowiki>

Canvas news: Difference between revisions

Canvas news (view source)

Revision as of 15:26, 4 November 2018

Navigation menu

Search