NavDisplay & MapStructure discussion (previously via PM)

[Philosopher]

EDIT: Okay, here's a patch:

Did this make it into your team clone? I'm working on it currently, and need to know if I should apply it. Working on making Map-Controllers.

[Hooray]

No, I didn't have gitorious access when I posted this - and Gijs then mentioned that I had introduced an issue (range being restricted to 10nm) - so I didn't bother, it was only later that I figured out that the primary controllers (query range etc) are overwritten by the navdisplay entries - see: viewtopic.php?f=71&t=21509&start=15#p200244

Of course, you can use the code - the APT layer should be straightforward, it's just copy&paste and some editing after all.

[5H1N0B1]

Hi everyone,
Hope I'm not off topic but, I tried to put your huge work on the mirage 2000, and I have this :



This is the code I put :

Code: Select all

##
# storage container for all ND instances
var nd_display = {};

###
# entry point, this will set up all ND instances

setlistener("sim/signals/fdm-initialized", func() {

##
# configure aircraft specific cockpit/ND switches here
# these are to be found in the property branch you specify
# via the NavDisplay.new() call
# the backend code in navdisplay.mfd should NEVER contain any aircraft-specific
# properties, or it will break other aircraft using different properties
# instead, make up an identifier (hash key) and map it to the property used
# in your aircraft, relative to your ND root in the backend code, only ever
# refer to the handle/key instead via the me.get_switch('toggle_range') method
# which would internally look up the matching aircraft property, e.g. '/instrumentation/efis'/inputs/range-nm'
#
# note: it is NOT sufficient to just add new switches here, the backend code in navdisplay.mfd also
# needs to know what to do with them !
# refer to incomplete symbol implementations to learn how they work (e.g. WXR, STA)

      var myCockpit_switches = {
   # symbolic alias : relative property (as used in bindings), initial value, type
   'toggle_range':    {path: '/inputs/range-nm', value:40, type:'INT'},
   'toggle_weather':    {path: '/inputs/wxr', value:0, type:'BOOL'},
   'toggle_airports':    {path: '/inputs/arpt', value:0, type:'BOOL'},
   'toggle_stations':    {path: '/inputs/sta', value:0, type:'BOOL'},
   'toggle_waypoints':    {path: '/inputs/wpt', value:0, type:'BOOL'},
   'toggle_position':    {path: '/inputs/pos', value:0, type:'BOOL'},
   'toggle_data':       {path: '/inputs/data',value:0, type:'BOOL'},
   'toggle_terrain':    {path: '/inputs/terr',value:0, type:'BOOL'},
   'toggle_traffic':       {path: '/inputs/tfc',value:0, type:'BOOL'},
   'toggle_centered':       {path: '/inputs/nd-centered',value:0, type:'BOOL'},
   'toggle_lh_vor_adf':   {path: '/inputs/lh-vor-adf',value:0, type:'INT'},
   'toggle_rh_vor_adf':   {path: '/inputs/rh-vor-adf',value:0, type:'INT'},
   'toggle_display_mode':    {path: '/mfd/display-mode', value:'MAP', type:'STRING'},
   'toggle_display_type':    {path: '/mfd/display-type', value:'LCD', type:'STRING'},
   'toggle_true_north':    {path: '/mfd/true-north', value:0, type:'BOOL'},
   # add new switches here
      };


   # get a handle to the NavDisplay in canvas namespace (for now), see $FG_ROOT/Nasal/canvas/map/navdisplay.mfd
   var ND = canvas.NavDisplay;

   ## TODO: We want to support multiple independent ND instances here!
   # foreach(var pilot; var pilots = [ {name:'cpt', path:'instrumentation/efis',
   #                 name:'fo',  path:'instrumentation[1]/efis']) {


   ##
   # set up a  new ND instance, under 'instrumentation/efis' and use the
   # myCockpit_switches hash to map control properties
   var NDCpt = ND.new("instrumentation/efis", myCockpit_switches);
   
   nd_display.cpt = canvas.new({
      "name": "ND",
      "size": [2048, 2048],
      "view": [1024, 1024],
      "mipmapping": 1
   });

   nd_display.cpt.addPlacement({"node": "blackbkd"});
   var group = nd_display.cpt.createGroup();
   NDCpt.newMFD(group);
   NDCpt.update();

      
}); # fdm-initialized listener callback


var showNd = func(pilot='cpt') {
   # The optional second arguments enables creating a window decoration
   var dlg = canvas.Window.new([400, 400], "dialog");
   dlg.setCanvas( nd_display[pilot] );
}



Where "blackbkd" is the 3D object screen.

What is wrong here ? How can I resize it ? does the "blackbkd" have a wrong size ? (I do not think but I could check)
Any idea ?
Thanks in advance to you guys

5H1N0B1

[Gijs]

Make sure the display in your 3D model is uvmapped to a complete texture (so from edge to edge).

[5H1N0B1]

Hi dudes, size not fixed yet.
I have question : With same condition (same place, Nellis (KLSV), same weather -no cloud), I have a little lost in term of performances :
around 80 ms frametime without NavDisplay, and a little more than 120 ms with it.
How does the NavDisplay is updated ? If it's a loop, could it be possible to have a variable to set the frequencies ?
Just asking, cause the job here is incredible

[Hooray]

we're aware of where these problems are coming from, and we know how to fix them - in summary:

• there are still a few layers using the old removeAllChildren() logic which is known to be NOT canvas-friendly, i.e. inefficient
• there's quite a bit of code runninng inside the update() method that needs to be factored out into hash functions - this is also required to better support non-Boeing NDs (Airbus etc)
• functions specified inside the "NDStyles" hash support a predicate to reduce framerate impact
• in the future, we should also support listeners here, and timers for certain symbols
• the "global" timer is currently pretty aggressive, i.e. running almost at framerate

How does the NavDisplay is updated ? If it's a loop, could it be possible to have a variable to set the frequencies ?

see: https://gitorious.org/fg/fgdata/commit/ ... ent_104427
And specifically: https://gitorious.org/fg/fgdata/source/ ... y.mfd#L824

[5H1N0B1]

Almost done...



I just have to configure the buttons....seems great

[5H1N0B1]

Anyways what is the little green arc on this picture ?
(it seems to react in a certain way with terrain...)

[Gijs]

It's a prediction of when you will reach the altitude set in in your autopilot, based on your current ground speed and vertical speed.

[Hooray]

Did this make it into your team clone? I'm working on it currently, and need to know if I should apply it. Working on making Map-Controllers.

I have now pushed the APT stuff to the gitorious team clone, onto the canvas-radar branch where you pushed your TFC work, I also added two buttons to the test dialog for zooming (not yet linked to the me.map.controller range property though).

https://gitorious.org/fg/canvas-hackers ... 63cbcf617b

[Johan G]

I noticed that you intend to replace the canvas maps with the more flexible MapStructure also in dialogues (see this wiki diff).

Some things to keep in mind when working on Map Controllers:

• we may also want to support optional mouse-panning (see airport-select dialog)
  
• we may also want to support optional tooltips for layer elements

I would like to also see mouse zooming (with the scroll wheel), if that would be possible (though only in mouse pointer mode).

[Hooray]

it's possible using 3 lines of Nasal code and addEvenListener() - it's exactly the same code as zooming, just with even type set to "wheel": http://wiki.flightgear.org/Canvas_-_Eve ... vent_types

[5H1N0B1]

Just before changing the whole canvas things...
Couldn't it be easier to use this kind of xml code :

Code: Select all

 <animation>
    <type>pick</type>
    <object-name>screen</object-name>
    <action>
      <button>4</button>
      <!--  scroll up -->
      <repeatable>false</repeatable>   
      <binding>
                <command>property-cycle</command>
                <property>/instrumentation/efis/inputs/range-nm</property>
                <value>10</value>
                <value>20</value>
                <value>40</value>
                <value>80</value>
                <value>160</value>
                <value>320</value>
      </binding>   
    </action>
  </animation>

  <animation>
    <type>pick</type>
    <object-name>screen</object-name>
    <action>
      <button>3</button>
      <!--  scroll up -->
      <repeatable>false</repeatable>
 
      <binding>
                <command>property-cycle</command>
                <property>/instrumentation/efis/inputs/range-nm</property>
                <value>320</value>
                <value>160</value>
                <value>80</value>
                <value>40</value>
                <value>20</value>
                <value>10</value>             
      </binding>   
    </action>
  </animation>

It look like more simpler, and easy to manage scroll zoom...
Just my 2 cents opinion...

[Hooray]

Update: Philosopher has fixed the TFC layer, and we've started working on scaling and styling support, so that draw() routines provided in .symbol files can be easily customized by aircraft/dialog developers:


To support sytling in your own .symbol files, there are some things to be kept in mind, see: http://wiki.flightgear.org/MapStructure#Symbols

[5H1N0B1]

For the symbols, that's a great things !! (Already thinking about the radar ...)

Anyways, the nav mfd is done on the mirage 2000. Gjis wanted some screen capture.
All bug I have are known (airport display etc...) but these screen shot should probably help.