Board index FlightGear Development Canvas

Canvas VSD

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.

Canvas VSD

Postby rleibner » Sat Dec 16, 2017 10:02 pm

Hi,
I'm developing a graph class who works using local (customized) coordinates and calls the plot2D helpers.
For testing (and as exercise) I wanted to code a VSL (Vertical Situation Display).
ImageI know thaht it's a bit naif and there's a lot of work to do (autozoom, linking to AP, etc), but ... it has only some 65 lines of code !!

I'm very interested to hear your comments. To try it, you'll need 3 files:
    * plot2D.nas (download from here)
    * graph.nas (download from here)
    * vsd.nas (download from here)
For testing, put all the 3 under your $FG-HOME/Nasal folder.
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 269
Joined: Fri May 19, 2017 8:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: next
OS: Ubuntu 18.04.4

Re: Canvas VSD

Postby wkitty42 » Sat Dec 16, 2017 10:08 pm

hummm... so if we put them in that directory, they automatically start running?

/me thinks an important step has been left out...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9123
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: Canvas VSD

Postby rleibner » Sat Dec 16, 2017 10:32 pm

wkitty42 wrote in Sat Dec 16, 2017 10:08 pm:/me thinks an important step has been left out...

You are right, I am too eager to share my evidence :oops:
Will work on that and fix it . I promise.
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 269
Joined: Fri May 19, 2017 8:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: next
OS: Ubuntu 18.04.4

Re: Canvas VSD

Postby Hooray » Sat Dec 16, 2017 10:49 pm

wow, that's looking really good - not just referring to the screenshot, but also to the code you've written, really clean and compact !

for the vsd part, you can probably simplify the code by introducing a PropertyPlotter helper that maps the property/value vector to the polyline vector, and a terrain/altitude plotter - the common requirement for the Graph class would be to have setter/update methods that accept a func which returns the values to be updated/added.

Besides, since terrain sampling in Nasal is generally known to be a potential performance bottleneck, I would also suggest to make the property sampler routine itself configurable by passing a func that does the sampling - e.g. something like .setTerrainSampler() - that way, different methods can be used/tested more easily.

One thing that you might want to consider is reusing the same graph to show different plots (same axis alignment) - i.e. you would set up one group per polyline (plot), and then render those to the same x/y graph - basically, your graph class would use a vector (or maybe a hash) to store a list a of values that are to be rendered.

Regarding your io.load_nasal() approach, I mentioned a possible workaround to deal with both scenarios in a portable fashion here: http://wiki.flightgear.org/Talk:How_to_ ... s_elements

Again, this is really looking good - and I am sure that you can see the benefits of using such a decoupled design, because troubleshooting/benchmarking and optimizations can now be done easily at the graph.nas level, while benefiting all applications using your new API.

PS: To see if the current class/object setup works properly, you could try to instantiate multiple different graphs and add them to the same dialog, e.g. showing different properties (altitude over terrain, vs, groundspeed over time) - that should be easy to do using your existing code, i.e. a PropertySampler routine could show different property trends.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Canvas VSD

Postby rleibner » Sat Dec 16, 2017 11:20 pm

wkitty42 wrote in Sat Dec 16, 2017 10:08 pm:hummm... so if we put them in that directory, they automatically start running?

Fixed. Now at the Nasal Console you must enter :
vsd.show();

Hooray wrote in Sat Dec 16, 2017 10:49 pm:to have setter/update methods that accept a func which returns the values to be updated/added.
In fact, the graph.graphic function works in such way. I will generalize that approach.
Hooray wrote in Sat Dec 16, 2017 10:49 pm:since terrain sampling in Nasal is generally known to be a potential performance bottleneck, I would also suggest to make the property sampler routine itself configurable
There are 3 configurable parameters into vsd.nas:
    * Timer interruptions: (line 23) I wrote 0.5 sec
    * Sampling resolution: (line 40) tried 0.5 nm but finally choosed 0.25 nm
    * Sampling distance: (line 41) 7 nm
Hooray wrote in Sat Dec 16, 2017 10:49 pm:I mentioned a possible workaround to deal with both scenarios in a portable fashion

I did not notice that you had wrote on the discussion tab. I will read your comments carefully.
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 269
Joined: Fri May 19, 2017 8:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: next
OS: Ubuntu 18.04.4

Re: Canvas VSD

Postby Hooray » Sun Dec 17, 2017 2:39 pm

depending on what you have in mind for the Graph/VSD code, you could also restructure the vsd.nas code to inherit a new VSDClass from your Graph class, so that it would become easier to create independent graph instances - e.g. imagine rendering multiple VSDs to a single Canvas GUI dialog. This may seem redundant/unnecessary at this point, but hat way, the code would become even more generic, too - and you could test the whole thing by creating separate VSD instances for different AI/MP nodes (e.g. referring to your existing SpokenGCA work)

You have already created a layered design meanwhile, so that you have different classes (and files) where certain functionality can live, without affecting the other components.

Regarding terrain sampling: I meant to say, that there are different methods available to do the terrain sampling, including a hard-coded terrain presampler using properties instead of the geodinfo() call. Thus, if the method is made configurable (accepting a callback), different back-ends could be used.

Anyway, please just consider this "feedback" - what you have is certainly much more than anybody was expecting (again!) :-)
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU


Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest

cron