Canvas news: Difference between revisions

Canvas news (view source)

Revision as of 17:34, 10 February 2020

6,995 bytes added , 10 February 2020

m

→‎2020

Hooray

Administrators

20,741

edits

@@ Line 4: / Line 4: @@
 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]].
+== 2020 ==
+=== Canvas EFIS Framework ===
+The '''canvas EFIS framework''' (created by jsb) is by-product of the EFIS development
+done for the CRJ700 family, which uses Rockwell Collins Proline.
+It is published as a separate framework in the hope that it is useful for other aircraft as well,
+however some features may be rather specific.
+The biggest motivation and primary design goal was to support "near optimal"
+performance but that does not come automatically of course.
+{{Main article|Canvas EFIS Framework}}
+== 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 />

Canvas news: Difference between revisions

Canvas news (view source)

Revision as of 17:34, 10 February 2020

Navigation menu

Search