Board index FlightGear Development Canvas

Dev and test environment

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.

Dev and test environment

Postby F-JYL » Thu Dec 19, 2013 6:19 pm

Is there any development environment such a "light flightgear" version which can run quickly to be able to test canvas, or do you have any good practice on this respect.
What are the flightgear options to speed up the whole things ?
F-JYL
 
Posts: 54
Joined: Mon Mar 11, 2013 8:34 pm
Callsign: F-JYL
Version: git
OS: Ubuntu 13.10

Re: Dev and test environment

Postby Hooray » Tue May 13, 2014 11:21 pm

F-JYL wrote in Thu Dec 19, 2013 6:19 pm:Is there any development environment such a "light flightgear" version which can run quickly to be able to test canvas, or do you have any good practice on this respect.
What are the flightgear options to speed up the whole things ?


Here's what I am usually using: http://wiki.flightgear.org/Howto:Debugg ... up_Profile
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: Dev and test environment

Postby Bomber » Thu May 15, 2014 8:41 am

3 years and now I find this.... :-\

Has anyone considered having a pulldown menu that allows a newbie to quickly set these values say for..

Debug.
Low end machine
Medium machine
High end machine

I restart FG maybe 30 times a night.

Simon.
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1934
Joined: Fri Dec 14, 2007 7:06 pm
OS: Windows XP and 10

Re: Dev and test environment

Postby Hooray » Thu May 15, 2014 1:33 pm

that would be good to have, agreed - the problem is that it cannot currently be provided by FG itself, because many of these values cannot be affected at run-time.
So for the time being, you could simply use a fgrun startup profile to accomplish the same thing.
For FG to offer this, it would have to be extended (which has been happening over time, but we're still not quite there).
The main thing here is "run-time reinitialization" - i.e. having code that doesn't need to be shut down to change settings, but that simply fetches the new settings and applies them.
Zakalawe has been working towards this as part of the reset/re-init effort - mid-term, the idea is to make GUI launchers obsolete for most people, by providing an in-sim GUI launcher where such settings can be directly changed, including changing aircraft, but also saving/loading flights.
For these reasons, most of us are not too eager to extend external GUI launchers.

Canvas-wise, there isn't much missing to provide an integrated GUI launcher - what would be useful though, is having a new element that renders arbitrary 3D models/camera views to a texture, i.e. for aircraft/scenery previews. But otherwise, this is mostly a matter of having scripting (Nasal) and Canvas available earlier, so that a GUI launcher can created using ~200-300 lines of Nasal. This is also where we could provide a pulldown menu with settings for a handful of startup/run-time profiles.

And of course there are still a handful of subsystems that cannot currently be re-intialized without shutting down the whole thing.
For non programmers, it's helpful to imagine it like exchanging your car radio, seats, brakes or even engine, while going 100 mph - not impossible to pull off, but quite a few - especially because the "car" (FG) was never designed with this requirement in mind.

And changing some settings for different machines, is the equivalent of switching engine + tires, 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: Dev and test environment

Postby Bomber » Thu May 15, 2014 3:42 pm

I'm happy that you can't reinitialise the flight model without shutting down... Please don't write that feature out.

With regards a new canvas front end GUI.
Well this I'd like as I've already designed and drawn mine with 1940's feel to it.

My initial question was actually I think to do with fgrun... This is afterall the default start up for those just downloading FG... Yes ?

Lost a few potential plane developers because they couldn't get their machines to run FG.... Now if I could have said start fgrun, from the pull down menu select 'bare bones basic'... I might have been able to keep em..

It might also help for newbie players as well.... You know the topic that got closed

viewtopic.php?f=42&t=22846
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1934
Joined: Fri Dec 14, 2007 7:06 pm
OS: Windows XP and 10

Re: Dev and test environment

Postby Hooray » Thu May 15, 2014 3:49 pm

fgrun already supports startup profiles, and fgfs itself supports fgfsrc files.
However, I was somewhat wrong - most of the settings shown in the "minimal profile" could be trivially applied at run-time by selecting them from a custom XML dialog and applying the corresponding defaults.

An integrated GUI launcher is something that we'd all like to see, and which we are working towards - it will probably happen within the next 12-18 months (just a guess), not because it's such a high priority, but because, by then, we should have all the pieces for it in place - and the 3-4 main core developers (main, in terms of activity) agree that this is the way forward, so from a middleware (Nasal/XML, Canvas) standpoint, we're going to help with creating a framework to parse our existing GUI dialogs and turn them into canvas-driven GUI widgets, which will need to be developed first of all though - that's the kind of stuff that Philosopher has been doing in his REPL interpreter: custom GUI work.

Well this I'd like as I've already designed and drawn mine with 1940's feel to it.

I think the chances are pretty good that the upcoming GUI will look much less 1940s style than the existing GUI, i.e. fairly modern actually.
But the good news for you is that styling/skinnig is intended to be supported eventually. Tom has in fact added quite a bit of code to make that fast and flexible, not just Nasal, but also C++ - so he seems to consider that a priority, too.

PS: that topic wasn't about newbie players, it was about people thinking that "we" (yeah, YOU too!) are developing FlightGear just for "rich people", and that's been sufficiently discussed and addressed meanwhile. Improving accessability and usability always is a good thing - but like I said, custom startup profiles have been supported by fgfs and fgrun for years, turning the wiki config into a file takes roughly 10 seconds if you know how to copy & paste :D
Turning it into a FG GUI dialog may be 20-30 minutes of work for someone familiar with XML and our GUI dialogs
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: Dev and test environment

Postby Bomber » Thu May 15, 2014 4:56 pm

The point you seem to be missing is that maybe if there was a selectable sliding scale of feature against performance that thread wouldn't have ever happened...

BTW he wasn't talking about me.... That's something else you missed.
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1934
Joined: Fri Dec 14, 2007 7:06 pm
OS: Windows XP and 10

Re: Dev and test environment

Postby Hooray » Thu May 15, 2014 5:08 pm

No need to turn this into our usual banter (or I may get banned by Gijs!) :D

doing this all dynamically at runtime isn't supported currently for other reasons I explained in like a dozen places, including that thread - we all agree that this would be great to have and it is being worked on (but slowly) - the problem is that there are quite a few hard-coded assumptions all over the place - basically, our "car" was never designed to have its "horse power" and feature set changed while driving :D

BTW: We're all contributors here, and the way people like you are doing their work is also complicating such long-term efforts - simply because we currently do not provide any means to tell people how expensive certain features are, not just core features, but also aircraft/scenery features like textures, 3D models, scripts, XML etc - some of our most-complex aircraft render the simulator unusable because people are using huge textures and 3D models for knobs that have 20k polygons, throw in some rogue Nasal code or lots of property rules, and you'll end up with single-digit frame rates :mrgreen:

PS: What you're suggesting is not new at all, it's commonly called "feature scaling", and has been discussed at lengths here. But for the time being, it would be as straightforward to implement as changing your FDM in-flight by adjusting engine/wing foil parameters - I am sure your FDM was never designed with such requirements in mind, and that also applies to most of the legacy FG code that's been around for over 15 years now.

Feature scaling involves not just reading a value/variable once, but either polling it (updating it permanently at frame rate) or acting upon events if some variable has changed, to reset/re-init or adjust the corresponding system - most people didn't/don't write their code that way, because it takes more time - see the XML discussion we had with Stiglr a few days ago: viewtopic.php?f=14&t=23020&start=15#p209490
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: Dev and test environment

Postby Bomber » Thu May 15, 2014 6:03 pm

I agree no need for it get out of hand....

No I'm not after feature scaling.... how about keeping it simple

You say...

fgrun already supports startup profiles, and fgfs itself supports fgfsrc files.
However, I was somewhat wrong - most of the settings shown in the "minimal profile" could be trivially applied at run-time by selecting them from a custom XML dialog and applying the corresponding defaults.


I say...

Why custom... why not have it already there in fgrun... and when people say "I can't get any decent fps" reply "go to first page and select "basic bar bones" and not "All bells and whistles"..

Then all we need is bit in between..
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1934
Joined: Fri Dec 14, 2007 7:06 pm
OS: Windows XP and 10

Re: Dev and test environment

Postby Hooray » Thu May 15, 2014 6:07 pm

I haven't used fgrun in years, I know that given FredB's hiatus from FG, Gijs has meanwhile taken over maintenance - but I don't know if there's any support for pre-configured startup profiles, it would seem to make sense actually - but IIRC, FGx does support exactly those - and it's generally much more "modern" in many aspects (don't use it either tho), I'd suggest to get in touch with gral (FGx lead programmer) to discuss this - it should be as simple as creating a text file once and shipping it as part of th installer

Usability-wise this is a decent suggestion, thank you
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: Dev and test environment

Postby Bomber » Thu May 15, 2014 6:19 pm

Hooray wrote in Thu May 15, 2014 5:08 pm:
BTW: We're all contributors here, and the way people like you are doing their work is also complicating such long-term efforts - simply because we currently do not provide any means to tell people how expensive certain features are, not just core features, but also aircraft/scenery features like textures, 3D models, scripts, XML etc - some of our most-complex aircraft render the simulator unusable because people are using huge textures and 3D models for knobs that have 20k polygons, throw in some rogue Nasal code or lots of property rules, and you'll end up with single-digit frame rates :mrgreen:



Well you made your bed, ya gota lie in it...

If you don't put poly count limits, texture size guides this is what you get...

There's a belief here that open source means you can do what you want.... yes you can, and if H wants a 'museum class' P51D, or me a Lancaster then we can have.. But that said these planes don't meet the requirements for online play, as having 2 of these planes within 20miles of each other reduces the FPS to a slide show.

From my perspective as a Flight Modeller, I'd like to see more accuracy.. not fudged spins, but spins based on differing lift of each wing, cause by the yawing of the plane creating a different AoA. The wing slope creating differing 'actual dynamic pressures'...

Of course there's always fudges, don't get me wrong... compromises have to take place and some effects are so tiny they can be ignored being as at that moment in time they're a fraction of the forces that are being applied.

This doesn't require a super computer.. but I'm watching FPS being gobbled up by other things and wondering who's doing the gobbling here ?
Leave me some computer power for plane systems, please.

Simon

ok I'm gonna post this but I've seen you've posted already
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1934
Joined: Fri Dec 14, 2007 7:06 pm
OS: Windows XP and 10

Re: Dev and test environment

Postby Bomber » Thu May 15, 2014 6:24 pm

Hooray wrote in Thu May 15, 2014 6:07 pm:FGx does support exactly those - and it's generally much more "modern" in many aspects (don't use it either tho), I'd suggest to get in touch with gral (FGx lead programmer) to discuss this - it should be as simple as creating a text file once and shipping it as part of th installer

Usability-wise this is a decent suggestion, thank you


What's FGx ?

I've only been here 3 years...

Seriously FG needs to listen to thick people, with zero patience & zero programming skills...... where's Stiglr when you need him ?
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1934
Joined: Fri Dec 14, 2007 7:06 pm
OS: Windows XP and 10

Re: Dev and test environment

Postby Bomber » Thu May 15, 2014 6:32 pm

Also please understand I'm trying to be 'observational' not critical of anyone, anygroup, anysex.... or for that matter of anything.
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1934
Joined: Fri Dec 14, 2007 7:06 pm
OS: Windows XP and 10

Re: Dev and test environment

Postby Hooray » Thu May 15, 2014 6:35 pm

try the minimal startup profile and you'll see pretty good frame rates/latencies.
Then, don't change a thing and try some aircraft, like the 777 or 787 - those are resource hogs.
So that's just the aircraft side of things.
Next, switch off all scenery rendering (see the "draw mask" section) and make another comparison.
Finally, switch to osgEarth (photo/satellite imagery) and you'll see that it often outperforms FG's native scenery engine, too.

So the equation has multiple variables, and they all affect the final outcome.
Obviously, we have combinations of certain aircraft/scenery/features that end up crippling the simulator massively.

Unfortunately, the main problem here is lack of an integrated "task/process monitor" that would track resource usage per subsystem/feature, or even just per scenery tile or aircraft.
That is something that we've been discussing for years whenever people reported having "resource shortage" issues, despite having hardware worth several $2k-3k US
It's happening, and it is a problem - and we need to address it, but we're all contributing to it, aircraft developers as much as scenery developers, as much as core developers.
Frame rate and frame spacing are much like a pie chart, and we're all eating away from it.

The real issue is accessibility - i.e. having things like XML, property tree, Nasal, effects, FDMs and even Canvas is great - but these are really just technology-enablers.
It's very much like driving a car or flying an airplane: you are given an enabling-technology, i.e. an interface to brake, accelerate, climb/descend etc - without having to understand how an engine works, or why an airplane flies.

To sum it up, FlightGear is not much different from RL here - how many people flying airplanes and driving cars actually understand the underlying systems sufficiently to use them properly, i.e. to make some constraint like fuel efficiency ?

whenever someone uses properties, XML, FDMs, Nasal, effects or Canvas - they only need to "understand" a fraction of the comlexity involved here, and that comes at a cost obviously.
Let's say, most contributors understand ~20% of the performance implications their work has (texturing, 3D modeling, scripting, XML, property rules, effects/shaders, FDM, Canvas) - in total, that means that even just per feature there's a 80% chance that people make fairly inefficient use of the resources available to them through these technology enablers.

There's massive amounts of Nasal code in FG that us dead slow simply because people did not know how to make it faster. But that very knowledge is hard to obtain :-)

So it always is a compromise - accessibility means that we're introducing abstraction layers and giving up control, so that certain stuff can be delegated to user space, which in turn means that we're also accepting the fact that people's work may slow down the whole flying experience until it's no longer flying, but a slide show.

FGx: another GUI launcher, search the wiki/forum or just the web, it has its own forum here
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


Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest