Board index FlightGear Development Canvas

On board radar Canvas integration

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Re: On board radar Canvas integration

Postby Hooray » Tue Feb 04, 2014 11:14 pm

Reading is one thing, but playing around is another important thing - read something, and then try to apply it - if something doesn't quite work, read some more and then play with it again.
the TFC layer is complex and it's normal that it's confusing - but some other layers are fairly simple. You can also just look at the "symbol" files - to see how drawing is accomplished.
The lcontroller and scontroller files are a bit more involved - but we can help with things.

Regarding multiple inheritance, see the Nasal OO docs in the wiki for some tutorials and more details.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: On board radar Canvas integration

Postby Philosopher » Tue Feb 04, 2014 11:58 pm

Sorry, I just got back, need to catch up, but two comments:

a) MapStructure already deals with geo.Coord
b) inherit from geo.Coord not geo.Coord.new() (make sure to provide a latlon() method as well, which TFc does)
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: On board radar Canvas integration

Postby 5H1N0B1 » Sat Feb 08, 2014 12:18 pm

Hi guys,
I spent a little time understanding the code and I found the link that was missing to me :

Code: Select all
var searchCmd = func {
   # TODO: this would be a good candidate for splitting across frames
   print("Doing query: "~name);
 
   var result = [];
   # FIXME: need a Map Controller for this, and all query_range's/get_position's
   var myPositionVec = me.get_position();
   var max_dist_m = me.query_range()*NM2M;
 
   # AI and Multiplayer traffic
   foreach (var traffic; [model_root.getChildren("aircraft"), model_root.getChildren("multiplayer")]) {
      foreach(var t; traffic) {
         if (me.in_range(t.getValue("position/latitude-deg"),
                        t.getValue("position/longitude-deg"),
                        myPositionVec,
                        max_dist_m))
            append(result, TrafficModel.new(t, nil, me.layer));
      }
   }
 
   #debug.dump(result);
   #return [];
   print("TARGETS:", size(result) );
   return result;
};


So this function return an array[] of geo.Coord and take its source in ai/model.

The RADAR object will integrate much more controls tha only range. (Btw I saw that there also an 'in_range' method in this controllers and I have on on the RADAR)
The targets[TARGET] that will provide the radar will be only those to display. That means the 'TARGET's controller' here could be highly simplified.
Anyways, "listen to ai model" events will higly decrease the caculation time -> This is a great idea, and I will add it in the RADAR code.

Now it's a little more enocchian for me (or perhaps I learnt Angle language ... 8) )
I'll code it without rush.

We willhave fun :mrgreen:
5H1N0B1
"Each day, with every person you meet, there is something to learn"
5H1N0B1
 
Posts: 212
Joined: Thu Aug 30, 2012 9:36 am
Location: France
Callsign: 5H1N0B1
IRC name: _5H1N0B1
Version: GIT
OS: Ubuntu

Re: On board radar Canvas integration

Postby Hooray » Sat Feb 08, 2014 12:45 pm

I just hope that it didn't take you long to figure this out, because that's also written in the wiki article - where I added it after it explaining it here to you a few times :D
Make sure to really read what we wrote here - it could save you a ton of time, even if it should take you 20 minutes to re-read everything...
I have really tried to answer all your questions here, and moved things over to the wiki subsequently. So there should be little left that needs explaining.
If there's still something missing, I would advise to re-check all resources - even if that means reading things twice.
Overall, nothing beats making some own experiments to familiarize yourself with the system though.
Regarding the listener-based approach, you will also find previous postings discouraging that method - it's currently one of the reasons rendering the TFC layer unusuable unfortunately.
While this is due to the way the C++/AI code is set up, it still is an issue that would need fixing to work reliably.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: On board radar Canvas integration

Postby 5H1N0B1 » Sat Feb 08, 2014 12:51 pm

Of course wiki helped a lot !!
Thanks to you :) and to your help :)
I just didn't have lot of time to read/code or try...but in the weekend, a rapid look on the wiki, on the code and that's it :)

Thanks to all :)
(Now Ihave work to do ^^)
5H1N0B1
"Each day, with every person you meet, there is something to learn"
5H1N0B1
 
Posts: 212
Joined: Thu Aug 30, 2012 9:36 am
Location: France
Callsign: 5H1N0B1
IRC name: _5H1N0B1
Version: GIT
OS: Ubuntu

Re: On board radar Canvas integration

Postby Hooray » Sat Feb 08, 2014 12:55 pm

For your first experiments, I would suggest to play with some of the simpler layers, e.g. NDB or DME - you can copy the files, and then follow the guidelines to customize the layer - i.e. name it "TEST". That will give you a new layer to play with, that renders DMEs - you could then easily change searchCmd or change the symbol's draw routine. Once you know how everything works there, it will be MUCH easier to play with the TFC layer, because all the concepts will be familiar already
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: On board radar Canvas integration

Postby 5H1N0B1 » Tue Feb 25, 2014 3:31 pm

About radar thing, if I understand well, the TFC object is the closest to what we want.
So when I look the TFC controller, there is a loop, which go threw th AI/MP tree, and take each model in range.

This is typically the code of the radar, with few more things : all the radar stuff will execpt models like the inRange do. (So terrain will except etc...)

My greatest concern here is that the radar code/loop/update HAVE to work without the canvas. I means it has to work in total independance, that you can have the radar updating without having a canvas or MapStructure. And this for obvious reasons like using the radar in other application (like missiles...<taking a witch voice>my dear little missile </taking a witch voice>)

So to me we have to solution to update TFC( or TARGET) positions :
- Have in the TFC controller something like myRADAR.getTargetArray() -> and this will return an TARGET array each time it's necessary.
- Radar code fill a property tree in /instrumentation/RADAR[0]/targets, and the TFC get it with the actual loop instead of look into AI/models

I have a great preference for the first one. (the second is just transform an array into a property tree and transfrm the property tree into an array ->aberration)
But to do the first on I could have problem : I don't really know actually how can I call an object myRADAR, that doesn't exist in the TFC controller function.
Perhaps Global variable ? I don't really know. (I'll have to check the doc about variable visibilty...)
Any idea from nasal non humain coder ? :mrgreen:

Have fun

5H1N0B1
5H1N0B1
"Each day, with every person you meet, there is something to learn"
5H1N0B1
 
Posts: 212
Joined: Thu Aug 30, 2012 9:36 am
Location: France
Callsign: 5H1N0B1
IRC name: _5H1N0B1
Version: GIT
OS: Ubuntu

Re: On board radar Canvas integration

Postby Hooray » Tue Feb 25, 2014 3:42 pm

About radar thing, if I understand well, the TFC object is the closest to what we want.
So when I look the TFC controller, there is a loop, which go threw th AI/MP tree, and take each model in range.

This is typically the code of the radar, with few more things : all the radar stuff will execpt models like the inRange do. (So terrain will except etc...)

This is all correct.

5H1N0B1 wrote in Tue Feb 25, 2014 3:31 pm:My greatest concern here is that the radar code/loop/update HAVE to work without the canvas. I means it has to work in total independance, that you can have the radar updating without having a canvas or MapStructure. And this for obvious reasons like using the radar in other application (like missiles...<taking a witch voice>my dear little missile </taking a witch voice>)


right, the correct way is to come up with your own Radar/Target classes and only use them inside the lcontroller file's searchCmd() method - that way, you have no tight coupling, and can easily reuse your radar/target for other purposes, such as AI traffic or AI-guided missiles.


So to me we have to solution to update TFC( or TARGET) positions :
- Have in the TFC controller something like myRADAR.getTargetArray() -> and this will return an TARGET array each time it's necessary.
- Radar code fill a property tree in /instrumentation/RADAR[0]/targets, and the TFC get it with the actual loop instead of look into AI/models

I have a great preference for the first one. (the second is just transform an array into a property tree and transfrm the property tree into an array ->aberration)

right, what you'll want to do - referring to TFC.lcontroller- is replacing the "TrafficModel" (currently representing a single aircraft with TCAS) with your own "Target" class.
SearchCmd() would then be modified to query a RadarClass object that returns a list of "TargetClass" objects.
That way, your own code will never have any dependencies regarding MapStructure or Canvas.

We tried to explain the concept previously: viewtopic.php?f=71&t=21993#p199912

But to do the first on I could have problem : I don't really know actually how can I call an object myRADAR, that doesn't exist in the TFC controller function.
Perhaps Global variable ? I don't really know. (I'll have to check the doc about variable visibilty...)
Any idea from nasal non humain coder ? :mrgreen:


I think Philosopher was going to come up with a tutorial on doing exactly that - but these are basically the steps:
- you create your Radar class, i.e. in your aircraft (or the radar-mapstructure dialog for testing purposes, i.e. inside the Nasal/open block)
Basically, depending on how/where you create an object, it will "live" in a certain namespace - which you need to prefix.
Then, you come up with the correct namespace where your object lives, see: http://wiki.flightgear.org/Howto:Unders ... nd_Methods
You can use print(closuer()[0]) to print the active namespace to the console: http://plausible.org/nasal/lib.html

For testing purpsoes, none of this is important however - you can simply instantiate (=create an object) your class at the top of the "radar-mapstructure" dialog.
The only thing you'll have to change later on is a single line to point to your aircraft's namespace, e.g. "m20005.radar".
That's exactly the way, the ND is internally structured and set up to work with different aircraft, too.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: On board radar Canvas integration

Postby 5H1N0B1 » Sat Mar 01, 2014 11:17 am

Just to push further the reflexion/thinking about radar, something close to the radar code already exist on the FG projet in c++. It's in the HUD code.
HUD_ladder.cxx, line 271 :
Code: Select all
    // draw hud markers on top of each AI/MP target
    if (_target_markers) {
        SGPropertyNode *models = globals->get_props()->getNode("/ai/models", true);
        for (int i = 0; i < models->nChildren(); i++) {
            SGPropertyNode *chld = models->getChild(i);
            string name;
            name = chld->getName();
            if (name == "tanker" || name == "aircraft" || name == "multiplayer") {
                bool valid = chld->getBoolValue("valid");
                bool in_range = chld->getBoolValue("radar/in-range", true);
                if (valid && in_range) {
                    float h_deg = chld->getFloatValue("radar/h-offset");
                    float v_deg = chld->getFloatValue("radar/v-offset");
                    float pos_x = (h_deg * cos(roll_value) -
                                   v_deg * sin(roll_value)) * _compression;
                    float pos_y = (v_deg * cos(roll_value) +
                                   h_deg * sin(roll_value)) * _compression;
                    draw_circle(pos_x, pos_y, 8);
                }
            }
        }
    }


That the little circle drawn on the HUD. This is really interresting for 2 reasons :
1) In c++, navigate through AI/MP models cause no fps decrease
2) Perhaps we can start in nasal but to the end, put the all the radar object code in C++
3) We could merge the 2 C++ loops in one
4) The radar would become very "cool"

What do you think guys ? (And it would take a little more time because my c++ is a little rusty -5 years without C++ coding...-)
5H1N0B1
"Each day, with every person you meet, there is something to learn"
5H1N0B1
 
Posts: 212
Joined: Thu Aug 30, 2012 9:36 am
Location: France
Callsign: 5H1N0B1
IRC name: _5H1N0B1
Version: GIT
OS: Ubuntu

Re: On board radar Canvas integration

Postby Hooray » Sat Mar 01, 2014 4:53 pm

- have you determine that traversing AI/MP properties really is a worthwhile target (i.e. a bottleneck) ?
- what exactly are you doing when traversing those properties ?
- the same thing is done in various other places, such as e.g. the Map code
- making this code available as a nasal extension function or even an object would at most take 5-10 minutes
- it really is trivial, see the Nasal/CppBind tutorial
- I can help with that, and even implement this completely if you think it's needed
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: On board radar Canvas integration

Postby Philosopher » Sun Mar 02, 2014 12:20 am

I don't think we need it (until it is really a problem - but I don't think it will be). Our implementation was only taking ~40 ms for 40 models (IIRC), and there might be a chance to optimize it a tiny bit more.

But yes, what other "excepting" jobs will you do?
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: On board radar Canvas integration

Postby Hooray » Sun Mar 02, 2014 1:24 am

I am also not convinced that we really need to move this stuff to C++ - it will be automatically faster once we re-implement props.nas on top of cppbind.
Also, we could just as well extend the props.nas wrappers to support running a callback foreach vector element, to help reduce Nasal space overhead (namely setupFunCall).
For the time being, I think it'd be premature optimization - for now, you should really just come up with a working prototype, so that we can help optimize things in scripting space, and once all possibilities are explored/exhausted there, we can do some profiling to determine if there's any low-hanging fruits to optimize this further.
Personally, I don't see there being 100 different targets typically - but we could certainly optimize it for that.
Then again, if this is about non-traffic aspects of the radar, such as radio propagation and doing terrain queries, that would be better done separately - ideally, via C++ helpers at some point.
But that doesn't mean that you cannot come up with a prototype until then - the LW/AW system does a lot of terrain queries using a hardcoded C++ system, the so called "terrain presampler" which is property configurable, so that could be used once geodinfo() stops providing sufficient performance - and we could still provide dedicated functions, too - or even use parts of Adrian's radio propagation code.

Overall, I'd suggest to focus on the more important aspects of this, rather than irrelevant optimization ideas that just have theoretical benefits for now, because there isn't even working prototype available yet.

None of this is impossible or even difficult - but typically, people need to have a working prototype to optimize that, rather than optimize things for some theoretical use-case that will not even matter in the end...
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: On board radar Canvas integration

Postby 5H1N0B1 » Sun Mar 02, 2014 10:15 am

Roger that :)
I 'll build the nasal radar and use TFC code to make it working.
5H1N0B1
"Each day, with every person you meet, there is something to learn"
5H1N0B1
 
Posts: 212
Joined: Thu Aug 30, 2012 9:36 am
Location: France
Callsign: 5H1N0B1
IRC name: _5H1N0B1
Version: GIT
OS: Ubuntu

Previous

Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest