Board index FlightGear Development Aircraft

New Aircraft: the Extra500

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

Re: New Aircraft: the Extra500

Postby jormapaappa1235 » Thu Feb 20, 2014 4:06 pm

Have you thought about normalmapping the plane? I tried that out and noticed it looks quite good. Check it out ;)

https://www.mediafire.com/?gc9b6xybh9ta5gd

Btw, I've got fps around 30-40, which is acceptable.
jormapaappa1235
 
Posts: 160
Joined: Fri Apr 05, 2013 4:52 pm
OS: Windows 7, Ubuntu

Re: New Aircraft: the Extra500

Postby ludomotico » Thu Feb 20, 2014 4:49 pm

Thorsten wrote in Thu Feb 20, 2014 3:02 pm:what kind of machine is it expected to run reliably with 30 fps?


This is interesting. We are reporting very different performances so there must be something interesting happening with this aircraft from the performance POV.

- Hardware: An old quad core (4 years old), 4GB of RAM and a medium quality nvidia 6-something-0 that cost me 100€ a year ago and I bought specifically for FlightGear. It is not a simple machine, but it is not a high-end neither.
- Software: up to date Debian GNU-Linux (testing), the git version of FlightGear (a week old) slightly personalized. More about this in a moment.
- Configuration: ALS on, landmass and transition shaders all the way up, the rest of the shaders only one step. Random buildings off, trees 1.0. Particles on.
- Airport: LERS. My home airport ("Costa Daurada", Spain). In terrasync you will find some buildings and in my local machine I have included some additional buildings. It is not Paris but the scenery is not empty.

With only 4GB of RAM, I have experimented the "RAM vampire" behavior you were discussing not long ago: fgfs tends to use as much RAM as available, forcing other applications to swap. The simulator doesn't fail but when it closes, the rest of the system is completely KO for several minutes while swapping back to the RAM. Hence, I tested someone's advice: remove the *2 in the tilecache size and reduce the LOD. It worked like a charm: no more of that annoying swapping and only a bit of fog at the horizon. In addition, more or less at the same time I experimented a gain of 10-20FPS: the C172 used to fly @30FPS and now it runs @50-60FPS. This specific aircraft runs @30FPS on my machine. I don't know if it is related to the memory consumption or it is some update in the libraries/flightgear of the last week.

Oh, another thing I changed in my fgfs is I'm using regional textures for my area, but I highly doubt they can improve performance in any way. They are based on your textures for south-africa.
User avatar
ludomotico
 
Posts: 1014
Joined: Tue Apr 24, 2012 1:01 pm
Version: git
OS: Debian GNU/Linux

Re: New Aircraft: the Extra500

Postby Thorsten » Thu Feb 20, 2014 6:04 pm

This is interesting. We are reporting very different performances so there must be something interesting happening with this aircraft from the performance POV.


Must be some driver-dependent quirk in the way the CPU part of the rendering interface somehow works, similar reason why some people can run Rembrandt with acceptable framerates and we're sitting with 15 fps on high end machines. Maybe something ill-defined which triggers a fallback mode on some machines but is accepted on others (?) We've seen similar things with shader code some times when syntax wasn't quite GLSL compatible, but some drivers took it just fine, others did with very poor performance.

You can rule out all scenery effects here - I get back to normal framerates whenever I'm not looking at the panel. That's a tell-tale - it's not scenery, it's not the rendering framework, it's not the Nasal running in the background, it is rendering. But it's not the GLSL part running on the GPU, because I wrote the underlying shaders, I know what they do, where they burn performance and how much of it.
Thorsten
 
Posts: 10693
Joined: Mon Nov 02, 2009 8:33 am

Re: New Aircraft: the Extra500

Postby Hooray » Thu Feb 20, 2014 6:27 pm

disclaimer: I've just been skimming so far, but wanted to comment on performance issues and potential Canvas/Nasal issues mentioned by some posters:

forest-ka wrote in Wed Feb 19, 2014 7:25 am:I'm pretty sure it's because of the canvas -- when I added a canvas to one of my aircraft, framerate went from 30FPS to 20FPS, and that's for a 640x480 HUD canvas.


  • to see if it's canvas related, just exclude the canvas via XML comments: <!-- -->
  • to be 100% sure, make it an empty "dummy" canvas that is not addressed/animated/used by any Nasal code
  • you can also just run a piece of Nasal code that creates a canvas dynamically: viewtopic.php?f=6&t=22143&p=201272#p201272
  • use a different aircraft (ufo,ogel) when trying this and see if it has any impact on fps/latency
  • if it does, check your rendering settings (effects/shaders) and try to adjust them to see if there's some correllation here
  • to see if it's Canvas/Nasal related, just disable all systems updating the texture(s)
  • to see if it's algorithmic due to "rogue" code, use the performance monitor and check 1)events (Nasal timers), 2) props (listeners) and 3) Nasal itself
  • The system monitor is described at: http://wiki.flightgear.org/Howto:Use_the_system_monitor
  • it gives you a rough idea where SUBSYSTEMS use CPU power
  • to see if the whole thing is related to model complexity, try to view the same textured 3D model in fgrun and/or standalone osgviewer/fgviewer, that is also a great opportuntiy to exclude Nasal/Canvas and anything else related to FG
  • you can also try to use osgconv: http://trac.openscenegraph.org/projects ... es/osgconv

Canvas is NOT inherently slow in and of itself - it's just an offscreen rendering context (FBO), and it is used by the GUI, too - e.g. tooltips or the airport-selection dialog, if those work properly (without lag), there's no reason why Canvas should be at fault here


Regardless of the outcome, this looks like a great airplane - and I think the main issue may not be canvas, but rather a highly-detailed 3D model, with lots of textures and effects, and developers not being aware of the complexity they're adding to the scenegraph due to a lack of integrated tools/diagnostics, which really isn't all that uncommon: highly detailed airliners like the 777-200ER are another good example for this: people are creating great aircraft, but they are no longer aware of the impact this has - FG doesn't currently have any built-in LOD management routines, so there's no texture/mesh simplification taking place - it will try to render what you come up with, no matter how complex it is. Which is exactly why osgviewer/fgviewer are such a great diagnostic tools to help troubleshoot what's going on, because they're unrelated to FG, and are not running Nasal, Canvas and/or effects/shaders

Overall, I am convinced that these issues can be solved :D
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: New Aircraft: the Extra500

Postby Hooray » Thu Feb 20, 2014 6:51 pm

Okay, I've just cloned the repository and actually checked out the aircraft, and well - wow: it's kinda impressive ... the whole experience is actually - apart from the amazing quality, level of detail - I am getting ~15-20 fps here, so there are obviously performance issues (some of which can obviously be solved quickly, others may be less obvious).

But the most surprising aspect to me is this: There's exceptionally well-written Nasal code all over the place that's making use of Canvas, and it is much cleaner than the NavDisplay code we have - even though, the latter s certainly more efficient mainly due to MapStructure.

Overall, I am kinda surprised that we have people around here who write such high quality Nasal/Canvas code, without getting involved in the NavDisplay/MapStructure or Canvas efforts themselves - the extra500 Nasal/Canvas code really is exceptionally clean, it is object-oriented and uses interfaces and design patterns - so whoever wrote it, should really get involved immediately in the NavDisplay/MapStructure/Canvas effort to help ensure that things are sufficiently generalized and reusable.

It really is kinda unfortunate that much of this code has apparently been written prior to us starting with the whole ND/MapStructure journey without anybody here speaking up, it could have saved you & us quite some time ... I don't think that our work was "hidden" at all.

Now, fact is: 1) The NavDisplay code is not going to beat the quality of code in the extra500, but likewise: the extra500 Nasal/Canvas code is not going to beat the performance and generic nature of the NavDisplay/MapStructure efforts anytime soon - in other words: please speak up and get involved, so that we coordinate things a little better here and ensure that both frameworks are sufficiently generalized and can benefit from each other.



Image
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: New Aircraft: the Extra500

Postby Kabuki » Thu Feb 20, 2014 7:08 pm

Thorsten wrote in Thu Feb 20, 2014 3:02 pm:
We are aware that the aircraft is a bit heavy on the resource side.


Echoing what others have said here, yes. I'm getting a whopping 12 fps out of it on a high-end gaming laptop - out of curiosity - what kind of machine is it expected to run reliably with 30 fps?

I've done some testing - the framerate is independent of shader quality settings, but depends very much on the view angle, so the culprit is the panel rendering,

[...]

so I would strongly suggest you don't chalk it up as an inevitable consequence of realism, but entertain the possibility that the panel might be designed in a very inefficient way.


I used the property browser to set the current-view to 'external', and my frame rate went from ~1 to ~15. Looking at the debug menu performance information, it seems like it's spending a lot of time on 'events'.

And I agree that simply writing it off as 'the price of realism' is not the way to fly. I could deliver a 'geezer sermon' on how 'back in the olden days, we used to count every byte -- every machine cycle', but I won't. I just notice that with such advances in hardware that we've seen since I started with computers, that programmers have more or less stopped considering how to make code fast and efficient "at the get-go".

What IS a good framerate, btw? IMHO, anything above around 24FPS -- the speed most movies are shown at -- is good enough for me.

There probably should be some kind of benchmark scenario for fair and accurate comparisons of various aircraft. There are all sorts of hardware variations out there, but some kind of test where planes on any system could be compared to a 'standard' plane on the same system, might be worth discussing. E.g. use the "total default setup, immediately after the program starts" as a number to compare to.

Anyway, that plane sure has a beautiful glass cockpit!
This is a family-friendly saloon. No talk stink.
Kabuki
 
Posts: 587
Joined: Fri Oct 23, 2009 11:21 pm
Location: Usually on the ground, always in the sky, except when underwater.
Callsign: Kabuki
Version: 3.0.0
OS: Windows 7

Re: New Aircraft: the Extra500

Postby Hooray » Thu Feb 20, 2014 7:33 pm

Regarding "events (Nasal timers)", there really is a massive amount of code loaded here, but you cannot say for sure if that's a real problem unless you completely disable all code and compare the resulting performance with previous performance - to do that, you'd need to patch NasalSys.cxx FGNasalSys::init() such that it doesn't load aircraft-specific scripts by commenting this line: https://gitorious.org/fg/flightgear/sou ... s.cxx#L799

That would require a rebuild, this is because we do not currently have any way to do this via a --prop: switch unfortunately ...
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: New Aircraft: the Extra500

Postby Philosopher » Thu Feb 20, 2014 7:36 pm

What about commenting out the section in the aircraft? Each script has to be registered in /nasal/<modulename>/<file or script>
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: New Aircraft: the Extra500

Postby Hooray » Thu Feb 20, 2014 7:37 pm

tried that already (and various variations of it), the main problem is that there's dependencies in other places, including property rules (AP system) that simply segfault once certain properties are missing/invalid ...

The next thing I did was overloading globals (maketimer,settimer,setlistener) which also didn't quite work ...

At some point, we really some runtime "task monitor" for Nasal callbacks, and I am about to resurrect some of my old patches for this ... (if I can find them)
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: New Aircraft: the Extra500

Postby Hooray » Thu Feb 20, 2014 7:48 pm

Kabuki wrote: I just notice that with such advances in hardware that we've seen since I started with computers, that programmers have more or less stopped considering how to make code fast and efficient "at the get-go".

What IS a good framerate, btw? IMHO, anything above around 24FPS -- the speed most movies are shown at -- is good enough for me.

There probably should be some kind of benchmark scenario for fair and accurate comparisons of various aircraft. There are all sorts of hardware variations out there, but some kind of test where planes on any system could be compared to a 'standard' plane on the same system, might be worth discussing. E.g. use the "total default setup, immediately after the program starts" as a number to compare to.


This isn't completely false, but the problem is not so much programmers primarily - so far, we cannot say for sure if it's due to Nasal code, 3D modeling/texturing, effects or a combination of everything (model complexity, lack of LOD etc). So the main issue is not necessarily coding, but rather lack of good runtime diagnostics that would provide contributors with tools to determine how much of an impact on resource usage their work has, i.e. in terms of CPU/GPU/RAM/VRAM required. We recently discussed this in a number of threads here (and on the devel list), so there really is a deeper problem here, which cannot be simply attributed to "developers", no matter if they're content developers or core developers - primarily, the issue is one of providing good runtime diagnotics, where things like polygon count, Nasal overhead, RAM requirements would be exposed via the property tree so that people could easily check what's going on under the hood. Even core developers have been running into this in the past 24 months, i.e. we need to start tracking resource usage so that people are aware of what's going on behind the scenes.

coming up with a simple benchmark would not be such a bad idea, and is another long-standing idea, and we do have many building blocks for this in place already: http://wiki.flightgear.org/FlightGear_Benchmark
But the real issue here is 1) making the underlying metrics available, and 2) actually using them - and that should preferably be done in a semi-automated fashion via some kind of scripted/scriptable "validation test suite", i.e. by starting up aircraft with well-defined parameters (location, visibility, weather, shaders/effects) to evaluate the impact on performance when adding certain features (no matter if it's scenery or aircraft). This goes back to another long-standing idea to run FG in a semi-automated mode for regression testing purposes, also discusssed on the devel list a while back: http://wiki.flightgear.org/FlightGear_Headless

Realistically, we cannot expect base package developers to be aware of performance considerations as long as not even core developers are aware of such issues until it is too late - so we really do need better tools here, so that people can use them to tell how much of an impact a feature has on their particular setup/hardware.
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: New Aircraft: the Extra500

Postby D-Leon » Thu Feb 20, 2014 8:48 pm

hard to see the discussion "Performance of Flightgear" on the neck of the extra500.

To get more clarity where the performance goes and specially for pilots who can't fly it now.
I will provide a startup switch to disable the IFD's. Hopefully this weekend.
Therfore is some work needed that the autopilot can be controlled via the keypad without the IFD's.

Dirk
D-Leon
 
Posts: 28
Joined: Wed Oct 03, 2012 8:44 am
Callsign: D-Leon
OS: Linux

Re: New Aircraft: the Extra500

Postby Hooray » Thu Feb 20, 2014 8:52 pm

Some more testing: I can confirm what Thorsten and Kabuki mentioned: The massively detailed cockpit seems to be the main issue, switching views and/or resizing the window will easily give me a fps boost of +30 fps here and ~40-60 ms - so, while making things optional is a good idea for troubleshooting purposes, I am not sure that Nasal-space workarounds will remedy this, even though it does help exclude certain things (Canvas/Nasal) that were raised by others.
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: New Aircraft: the Extra500

Postby hamzaalloush » Thu Feb 20, 2014 10:18 pm

i get 20-25 fps on fully scaled back cockpit view, i'm on a lower resolution though at 1200x800, with all render settings max, urban buildings and als w/advanced weather(250km bare),

i'm using an average computer a gtx 650 ti, 3ghz i7 and 4gb of ram.

i still notice an improvement to 60 fps if i look out the window as noted in this thread.

edit:@Hooray: to your advice, yes with all systems operating. in-flight where there are lots of building 20-22 fps. 24 fps at steady flight above and can reach 30 fps in uneventfull weather. latency is 40-60 ms in both. unmaximise fg and still the same.
Last edited by hamzaalloush on Thu Feb 20, 2014 11:11 pm, edited 5 times in total.
hamzaalloush
 
Posts: 632
Joined: Sat Oct 26, 2013 9:31 am
OS: Windows 10

Re: New Aircraft: the Extra500

Postby Hooray » Thu Feb 20, 2014 10:36 pm

make sure that all systems are running (autostart) to ensure that these tests are conclusive, you can also try to change window dimensions to check if framerate/latency are affected or not.

EDIT: I just used the built-in profiler and can confirm that the Nasal code that is animating the MFD is doing a few things inefficiently, such as updating paths (shivaVG) at frame rate unnecessarily (~30-35% impact here) - but that's not a problem of the Canvas system (or Nasal) - it's a matter of structuring your data accordingly, we made exactly the same mistake when we were working on the airport selection dialog a while ago. Overall, the NavDisplay/MapStructure frameworks will both help and handle at least mapping related things efficiently (I haven't checked if those paths are related to non-mapping elements though).
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: New Aircraft: the Extra500

Postby Hooray » Fri Feb 21, 2014 8:27 pm

Ufo:
Image


Extra500:
Image
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: cobe571, JetFuelSuitcase and 5 guests