Board index FlightGear Development Aircraft

757 wx radar

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

Re: 757 wx radar

Postby dom_vc10 » Tue Oct 19, 2021 10:16 am

Hooray wrote in Fri Oct 15, 2021 10:10 pm:there's no good reason for the FPS to drop significantly, it it does, I'd say that's a clear bug in the underlying MapStructure controller files - the point being, what is being rendered are really just simple raster graphics that are placed using lat/lon tuples - thus, the original implementation was fairly simple if I remember correctly. If it's now causing fgfs to stutter, I'd first of all suggest to review the searchCmd() method of the corresponding WXR.lcontroller file.

It will have the equivalent of a foreach loop traversing a bunch of data structures/properties to determine what is to be rendered. If the model lacks a proper equals() helper, it will redraw stuff unnecessarily.

Either way, there is no good technical reason for any of this to be slow or to cause "stuttering" - other than it using a naive algorithm, because the original prototyping code never got updated (?)


It would be awesome to look into this, I guess it will help with any aircraft then using this. It's probably way past my knowledge at this point but heck once I've finished my little updates for the 757F I'm definitely going to challenge myself and take a look... and probably fail :lol: at least I may learn something.
dom_vc10
 
Posts: 339
Joined: Mon Jul 27, 2020 8:33 am
Location: CZ - LKTB
Version: nightly
OS: Linux Mint 20.2

Re: 757 wx radar

Postby Hooray » Tue Oct 19, 2021 2:07 pm

the problem should not be specific to any particular aircraft - so if you can reproduce the issue in a standalone fashion (e.g. using the map-canvas dialog), then you're all set to troubleshoot the issue.

If in doubt, you could also check the "Canvas Test Map" feature (see the devel extensions dialog)

Overall, it should merely be placing/updating a handful of pre-rendered raster images and transform those as needed - so there really isn't anything "slow" per se.
It's almost certainly doing something stupid/naive in the underlying update heuristics - such as running code/updating/redrawing symbols unnecessarily.
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: 757 wx radar

Postby Doorknob747 » Tue Oct 19, 2021 8:34 pm

From what I know, you could keep the weather radar, and just remove the bendex.
Doorknob747
 
Posts: 60
Joined: Thu Sep 02, 2021 5:27 am

Re: 757 wx radar

Postby dom_vc10 » Tue Oct 19, 2021 9:05 pm

Doorknob747 wrote in Tue Oct 19, 2021 8:34 pm:From what I know, you could keep the weather radar, and just remove the bendex.



I did. You can see in my previous post :wink:

dom_vc10 wrote in Fri Oct 15, 2021 3:06 pm:Adjusted (also adjusted the text above the buttons at the bottom the placement was too low now you can see the labels)


Image


What we are discussing now is the effect of the weather radar on the nav display. When there is weather displayed it lowers the FPS which is not ideal. Hooray has made some suggestion and now I need to put some serious education time in to see if I can learn enough about the code to then be able to work on it so we will see if I ever get close on that :D
dom_vc10
 
Posts: 339
Joined: Mon Jul 27, 2020 8:33 am
Location: CZ - LKTB
Version: nightly
OS: Linux Mint 20.2

Re: 757 wx radar

Postby V12 » Tue Oct 19, 2021 9:20 pm

There are some options how to obtain better performance with ND :
- replace all NASAL technology around ND with C++ code and runs it out of the main loop
- rework NASAL to allow run them on the separate CPU core / separated thread and not in the main loop
- develop NASAL compiler and use compiled scripts, not interpreted
- heavy optimize search functions in the all ND layers controllers

IMHO, first option is fastest.
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: 757 wx radar

Postby merspieler » Tue Oct 19, 2021 9:24 pm

Then IMHO YOU, V12, should do it... no matter which one.
Nia (you&, she/her)

Please use gender neutral terms when referring to a group of people!

Be the change you wish to see in the world, be an ally to all!

Join the official matrix space
merspieler
 
Posts: 2241
Joined: Thu Oct 26, 2017 11:43 am
Location: Wish to be in YBCS
Pronouns: you&, she/her
Callsign: you&, she/her
IRC name: merspieler
Version: next
OS: NixOS

Re: 757 wx radar

Postby portreekid » Wed Oct 20, 2021 12:19 pm

merspieler wrote in Tue Oct 19, 2021 9:24 pm:Then IMHO YOU, V12, should do it... no matter which one.


I feel with you, but heed your own advice and ignore. Mostly captain obvious suggestions anyway.
portreekid
 
Posts: 651
Joined: Tue Jan 14, 2014 4:36 pm
Location: Leipzig
Callsign: PORTREE
Version: 2020.2.1
OS: Windows 10

Re: 757 wx radar

Postby Hooray » Wed Oct 20, 2021 6:24 pm

You'd be mistaken by just ignoring such postings - the message itself isn't that wrong, it just suffers from a lack of communications -and soft- skills.
Other than that, those ideas are long-standing ideas brought forward regularly by many long term contributors.

However, the thing is, in this particular case it makes far more sense to review the algorithmic side of things.
Obviously, an implementation of the current algorithm would be faster than the Nasal implementation, but that still doesn't make it "right".

What's almost certainly happening here is a misuse of Nasal, it's rather unlikely that Nasal and the Canvas per se are contributing to the current issue.

For that reason, it's also pointless to move this specific algo to a different thread/CPU (and yes, Nasal does support threading out of the box), despite the overall idea being indeed interesting and relevant overall.

A Nasal compiler also would not help us in this specific case, and a Nasal compiler (via LLVM) has been previously discussed/toyed with - and a number of core devs have contemplated writing a compiler using the existing parser/lexer to retarget Nasal code by using -for instance- a Python backend instead. However, even having a compiler that creates binaries/bytecode will not magically fix a naive/broken algorithm.

the searchCmd() function almost certainly doesn't need heavy optimization, but rather just profiling/debugging - you will almost certainly see it being triggered too often, or it updating stuff unecessarily.

If in doubt, replace/rename the searchCmd function in WXR.lcontroller to return a static list of positions in your vicinity, and then take it from there - e.g. by profiling via systime() or benchmark() - the MapStructure framework comes with built-in profiling support.

Either way, if you care about this particular issue getting fixed, reviewing WXR.* is the best thing you can do. All the other ideas are hardly relevant in the given context.
A single person familiar with Nasal reviewing WXR.lcontroller, can get more done in 1 hour than 5 people working on any of the other ideas for 100 hours :wink:
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: 757 wx radar

Postby V12 » Wed Oct 20, 2021 8:04 pm

4 years ago I had big problem with traffic layer performance, when I worked on Concorde's TCAS. I developed simple and very effective solution, but this solution was not pushed to FGDATA :
viewtopic.php?p=320094#p320094

Probably some similar thing should be developed for WXR with cost of range reduced to 40 or 80 nm. Or something even better.
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: 757 wx radar

Postby Doorknob747 » Thu Oct 21, 2021 5:18 am

Hooray wrote in Wed Oct 20, 2021 6:24 pm:You'd be mistaken by just ignoring such postings - the message itself isn't that wrong, it just suffers from a lack of communications -and soft- skills.
Other than that, those ideas are long-standing ideas brought forward regularly by many long term contributors.

However, the thing is, in this particular case it makes far more sense to review the algorithmic side of things.
Obviously, an implementation of the current algorithm would be faster than the Nasal implementation, but that still doesn't make it "right".

What's almost certainly happening here is a misuse of Nasal, it's rather unlikely that Nasal and the Canvas per se are contributing to the current issue.

For that reason, it's also pointless to move this specific algo to a different thread/CPU (and yes, Nasal does support threading out of the box), despite the overall idea being indeed interesting and relevant overall.

A Nasal compiler also would not help us in this specific case, and a Nasal compiler (via LLVM) has been previously discussed/toyed with - and a number of core devs have contemplated writing a compiler using the existing parser/lexer to retarget Nasal code by using -for instance- a Python backend instead. However, even having a compiler that creates binaries/bytecode will not magically fix a naive/broken algorithm.

the searchCmd() function almost certainly doesn't need heavy optimization, but rather just profiling/debugging - you will almost certainly see it being triggered too often, or it updating stuff unecessarily.

If in doubt, replace/rename the searchCmd function in WXR.lcontroller to return a static list of positions in your vicinity, and then take it from there - e.g. by profiling via systime() or benchmark() - the MapStructure framework comes with built-in profiling support.

Either way, if you care about this particular issue getting fixed, reviewing WXR.* is the best thing you can do. All the other ideas are hardly relevant in the given context.
A single person familiar with Nasal reviewing WXR.lcontroller, can get more done in 1 hour than 5 people working on any of the other ideas for 100 hours :wink:


The 757 and 767 both are a problimatic aircraft when it comes to adding things. The fact is, in FG the 757, 767, 777 have a lot more in common than lets say the latest build of 787. But there is major thing that differentiates the 757 and 767 in performance. The fact that the 757 and 767 are both YaSim, is what prevents it from having performance issues that the 777 gives. Even though the three aircrafts have almost the same or similar number of switches in the cockpit. The 777 in the main hangar never had it's working WXR code available to run, even though there is a interactive switch in the 777 to turn it on. WXR is known issue.

The reason why WXR has been left alone for a long time, was due to the fact that the weather code in the sim is only updated once every hour. That code is in itself old, that it was created in a time when the data was only available once in an hour. Now such data is available almost every minute or second.

Lastly but not least, the tech on a modern aircraft uses a CPU that is almost or as powerful as that of an everyday computer. In fact there were worries in the 737 max that MCAS was even stressing the CPU on the aircraft.

The best solution is for someone to create an MP server that streams a large WebP, FFmpeg, or VP8 like image with 1 pixel representing 1 sqr mile on earth. All the aircraft weather code has to do is show is a cropped area of the entire image, that is located near the aircraft. This would take out a major load that the WXR is causing on the sim.
Doorknob747
 
Posts: 60
Joined: Thu Sep 02, 2021 5:27 am

Re: 757 wx radar

Postby abassign » Thu Oct 21, 2021 7:36 am

V12 wrote in Tue Oct 19, 2021 9:20 pm:There are some options how to obtain better performance with ND :
- replace all NASAL technology around ND with C++ code and runs it out of the main loop
- rework NASAL to allow run them on the separate CPU core / separated thread and not in the main loop
- develop NASAL compiler and use compiled scripts, not interpreted
- heavy optimize search functions in the all ND layers controllers

IMHO, first option is fastest.


Hello,
for some time having created the photoscenary.jl program in Julia (A language for AI and robotics controls created by MIT as an opensource implementation of MathLab.) which is an extremely fast programming language (like C ++), but at the same time of simple and immediate syntax. It has the ability to use the GPU directly and operates in multithreaded and multi-CPU in an absolutely natural way.
After this experience I am thinking of implementing a radar in Julia to be able to create images to be moved on Canvas which, if I am not mistaken, is managed by OSG and therefore does not go through NASAL or FGFS.
The Julia module can work with a C ++ interface and link to the OSG library which is best documented.
NASAL is certainly not the ideal technical solution for doing things that need to be processed on individual pixels and I do not think we will have a NASAL solution (which, moreover, is very expensive in terms of CPU cycles as it is an interpreter like Python) short term multi thread.
Of course, nothing is easy, but I think it's a good way.
Developer of the program https://wiki.flightgear.org/Julia_photoscenery_generator
FDM developer of the G91R1B aircraft https://wiki.flightgear.org/FIAT_G91R1B
JSBSim collaborator
abassign
 
Posts: 947
Joined: Mon Feb 27, 2012 6:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2020.4
OS: Ubuntu 20.10

Re: 757 wx radar

Postby Thorsten » Thu Oct 21, 2021 9:56 am

The best solution is for someone to create an MP server that streams a large WebP, FFmpeg, or VP8 like image with 1 pixel representing 1 sqr mile on earth. All the aircraft weather code has to do is show is a cropped area of the entire image, that is located near the aircraft. This would take out a major load that the WXR is causing on the sim.


Sadly, even if you had a real time server for real weather radar images, that image would have a very tenuous connection with where rain is in-sim, so it would not only be a pretty complicated and expensive but also a pretty useless implementation.

So I fear you'll have to query the weather code and use that to generate rain radar return if you want something useful. This is neither hard not performance intensive on a level that'd be useful.

The whole discussion seems a bit like discussing about renting time on a supercomputer farm to work out the area of a circle - true, the supercomputer would give you Pi to incredible precision, but you don't actually need that for any useful application.

You really don't need Julia or an additional server or C++ modifications for something that's a ten liner in Nasal which has to run every 10 seconds.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: 757 wx radar

Postby abassign » Thu Oct 21, 2021 11:30 am

"You really don't need Julia or an additional server or C++ modifications for something that's a ten liner in Nasal which has to run every 10 seconds."

:shock:

"A toilet remains a toilet even if you paint flowers on it"

However a radar is a rather complicated object, IF YOU WANT TO DO IT WELL, and its weight at the level of a single task that has to do a lot of things besides running NASAL is not negligible.
Personally I prefer to have NASAL do what it does well, that is the scripting language to be included in the XML, but nothing more ...
Developer of the program https://wiki.flightgear.org/Julia_photoscenery_generator
FDM developer of the G91R1B aircraft https://wiki.flightgear.org/FIAT_G91R1B
JSBSim collaborator
abassign
 
Posts: 947
Joined: Mon Feb 27, 2012 6:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2020.4
OS: Ubuntu 20.10

Re: 757 wx radar

Postby Thorsten » Thu Oct 21, 2021 12:40 pm

However a radar is a rather complicated object, IF YOU WANT TO DO IT WELL


Well, a radar is, bit this thread is about a weather radar. Which is, to be useful, limited in potential complexity by what the weather system knows of rain outside the aircraft location. Which is - much more than the radar itself - limited by computational power.

Which in essence means that the path to the simulation of a complex, close to physics weather radar is... closed anyway (unless someone wants to re-write the weather simulation). From which follows that the design of maximally useful weather radar has to work from a rather small list of properties that the weather system provides.

So there's that. You can't do a dependent system more complex than the one it depends on and expect a useful result - USING CAPITALS WON'T CHANGE THAT. :D
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: 757 wx radar

Postby dom_vc10 » Thu Oct 21, 2021 1:28 pm

ok so this went a bit deeper than I expected.

Some interesting and not so bad ideas I would say..
- Using external weather maps - great but it won't match what we see in the sim I presume
- Creating a whole new code - Great but someone needs to write it
- Updating what we have - Best for the short term in my opinion and from what I gleaned in the posts this should just be some tweaking to reduce the FPS hit.

So I will roll my sleeves up and take a look. I have very little coding experience and zero with NASAL so maybe this is an impossible task for me but could be fun ( you can all watch me burn :lol: ). So to move on what is the best advice/resource I can look at to be able to learn about NASAL enough to make some tweaks?
dom_vc10
 
Posts: 339
Joined: Mon Jul 27, 2020 8:33 am
Location: CZ - LKTB
Version: nightly
OS: Linux Mint 20.2

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 17 guests