Board index FlightGear Development Spaceflight

Space Shuttle

Discussion about development and usage of spacecraft

Re: Space Shuttle

Postby Thorsten » Fri Dec 18, 2015 2:55 pm

@Hooray:

Overall, using the corresponding Canvas/OSG level helpers for this should be more Canvas friendly.


Let me try to get everyone on the same page...

The status is that I have little idea of canvas internals. The current setup and workflow is designed by Richard, and he's developed and tested it for the F-15. I am fairly sure he also has done some optimization on it.

I don't think we've every had the situation in FG that we had to support 11 screens in a cockpit, each of which can show potentially close to a hundred different pages, each page potentially displaying a hundred properties. So whatever we do, we're testing out limits.

I have some 15 display pages done so far, so there's 80% or so still left to be done. It takes me about 2-4 days to do one, so the current avionics represents a signifciant amount of work - two months of my FG time probably. I have an established workflow which lets me work at this speed. Given that, there's very few conditions under which I'd throw that work away and start from scratch with a different approach.

What's certainly not going to happen is that I start toying with canvas, make use of code snippets, create test cases to see whether there's actually a performance gain. What conceivably might happen is that I change the workflow if the current design turns out to be unscalable and there's a clearly established workflow which brings demonstrably superior performance - but I don't see any of this so far.

I appreciate that you're trying to help out with your experience, but... it actually needs to be helpful to have an effect. I have a ton of avionics modeling still to do, I don't really have the time to go and experiment, I'm going to follow the procedure which is tested (and which you approved of to the degree that you suggested to Richard to make it generally available). Getting the design right to match the real system is a fairly complicated problem, because the real Shuttle avionics isn't in any way simple or intuitive - it's a mess, and I had to read through the manual three times to understand how it ties together. I don't get the impression from several of your suggestion that you understand quite what we're trying to simulate (or I plainly don't understand some of your suggestion) - so maybe it'd help if you read 2.6 of the crew manual so that we all know we're talking about the same thing?

I hope that helps avoiding potential frustration in the future :-)
Thorsten
 
Posts: 10982
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Thorsten » Fri Dec 18, 2015 4:02 pm

@wlbragg:

After some trial and error, I'm almost sure I'm seeing some z-clipping effect for the pilot-side displays when under a shallow angle - could you check whether the offset of the surface onto which we write the text to do background surface behind is the same left and right?
Thorsten
 
Posts: 10982
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby wlbragg » Fri Dec 18, 2015 6:27 pm

Thanks Richard!
would you rename the MDU buttons

Yes.

@Thorsten
- could you check

Yes

By the way, I read a bit of the display section because I am obviously going to have to get intimate with it to do some of the animations. It is incredibly complex and I am shocked and amazed at the speed that you plow through this stuff.

Really cool though, it's looking great.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4888
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: Space Shuttle

Postby wlbragg » Fri Dec 18, 2015 7:49 pm

I'm not really sure what the issue is with what looks like z-fighting. I know how to fix it by what must have been either you or Richard's example of the rightmost display but I don't necessarily understand exactly what it is that causes the behavior.
The fix is a black background object that covers the grey panel background. The black bg obj also has to be large enough to cover the gray sides as you look at an angle.

Anyway, I'm going through it one by one and adding the bg obj and adjusting. I should have it commited later this afternoon or tonight.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4888
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: Space Shuttle

Postby Thorsten » Sat Dec 19, 2015 7:49 am

Some panorama shots of the Shuttle cockpit on my page.

A portrait of the Shuttle on the FG page.

Enjoy :-)
Thorsten
 
Posts: 10982
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Hooray » Sat Dec 19, 2015 1:16 pm

I suggested to introduce/expose the MFD framework, but that doesn't mean that some of the underlying mechanisms are necessarily all that suitable (or even just scale) once the use-case changes - like you said, the degree of avionics modeling you are currently doing is unprecedented, and most airliners even just struggled with supporting two instances of separate displays. However, the suggestions I made in that context, and the code snippets I posted, would still be applicable.

Like I said, it would make sense to move away from all the explicit sprintf logic you are using all over the place, and introduce a helper function for that purpose, so that things are encapsulated - this will greatly simplify/facilitate any efforts to optimize the code once/if Canvas itself contains sprintf-functionality for creating property-based labels/text nodes (see the Canvas forum).

The point is not that the code sucks, but that it will be difficult to scale/update in the time to come - the whole SVG handling logic looks pretty much like Gijs' original PFD/ND code, and this can also be greatly simplified by treating SVG elements as keys in a corresponding hash/dictionary - so that those would be directly Canvas objects.

PS: I do understand what you are trying to do, but like you say, I am not interested in reading the manual - but I can see the Canvas-level requirements to support the use-cases you mentioned (shared state shown on different instances of the same instrument, including different screens for each, and having screen selectors). You may rightly say that I need to read the manual to "be on the same page" - and I may respond "and you should read all the Canvas docs/snippets on the wiki" - but I think we should be able to arrive at a compromise, i.e. where you state your requirements (abstrat/high-level view), and I respond with concrete Canvas related advice & code snippets.

For the time being, I don't consider your approach scalable, i.e. 1) it is unlikely to perform too well for people with much less powerful hardware, and 2) it is unlikely to be very flexible - that has nothing to do with the MFD framework as such, but with the way some lower level helpers/methods are using Canvas.

So I am far from being frustrated, and I also hope that you are not getting frustrated due to my advice - but just like you saw some inefficient techniques being used in vitos' Su15, I am currently seeing problematic techniques being used in some of the space shuttle code.

But like you said, your success is proving you right - so you could just as well disregard any advice I am giving (and I will just keep my mouth shut), I am just concerned that you are approaching a situation where things will no longer be easy to just "update", but where a major rewrite may be needed to work around certain issues.

And in fact, we have seen exactly that in other incidents (think PFD, ND, but also the EFB work) - arguably, that is why the whole CDU work never made it to the forum, before being completed behind the scenes, which is also understandable.

So it is up to you obviously, I am not going to read the manual, or even fly the shuttle - but I am willing to help with the Nasal/Canvas side of this, to ensure that people can use it without having to own a $3k notebook with 2048 MB of VRAM, 8 cores and 16gb of RAM ;-)

I do appreciate that the design may seem "complicated", but that is like someone telling you that "integral calculus is difficult" - it solely depends on your background, and it seems that Richard is already using much more object-oriented programming that you are normally willing to put up with ;-)
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Thorsten » Sat Dec 19, 2015 2:09 pm

As for OOP, I use it when I see the point, I don't when I don't - the whole code for the IDP/MDU/Keyboard/GPC is largely an OOP structure, so is the antenna management - whereas the command parser is not.

As for the rest - the idea of designing the display in SVG seems good to me, because it allows to combine text and graphics elements in one go, makes it editable via both a graphical system and a text editor,... the one striking advantage is that it makes doing 100 pages of displays seem in reach - which I don't really see messing with other structures. And an existing design always beats the non-existing ideal design.

The performance impact needs to be tested - I'm frankly most worried about getprop() rather than anything else.

Like I said, it would make sense to move away from all the explicit sprintf logic you are using all over the place


Should that really eat performance, we can use another formating function (I never got it to do leading whitespaces anyway). This should be a simple change. As far as I understood Richard, the only reason we need it is to get double values suitably formated.
Thorsten
 
Posts: 10982
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Hooray » Sat Dec 19, 2015 2:44 pm

Sorry, you missed the point: sprintf/getprop: that's really the same thing we are talking about, i.e. the property tree overhead.

So the point is not that sprintf() is slow, but that the whole mechanism of using getprop() calls wrapped in a sprintf() call for formatting purposes is not encapsulated at all.

In other words, you are using this "idiom" all over the place, without having introduced a helper function.
This is one of the really low-hanging fruits to change - provide a single function that encapsulates the current mechanism, and then call that instead of having all those nested sprintf/getprop calls over the place.

The very instant, there is only a single function dealing with this, that is all that needs to be updated if/once Canvas provides a more native, zero-Nasal, alternative. And in the meantime, that's also a good way to determine the overhead caused by this.

Thuss I was never talking about a hypothetical design - I fully understand how the SVG mechanism works, it is using the exact same approach that the PFD, ND code is using - and it is in line with the corresponding tutorials and code snippets on the wiki, which I helped write/maintain.

So I didn't suggest to move away from the SVG structure, but to treat SVG element IDs as hash fields, to simplify the code.

From a complexity standpoint, my suggestion would be to partition page elements into display-specific and shared state, the latter could be also a simple lookup hash, that all displays can use to obtain the corresponding state - so that only a single update() method would need to update those fields.

I am pretty sure we can deal with the complexity, it just seems that some of the constructs that are currently used, do not scale particularly well when it comes to supporting an array of independent instances of the same instrument/display. Like you said, the property I/O is pretty much unprecedented currently, and it would make sense to encapsulate any related functionality, so that we can provide more native Canvas-level additions to work around such issues (we did that for the navaid stuff, too - when that turned out to be the bottleneck).

But currently, the code is increasingly structured in a fashion that would make it difficult to update such constructs even if more efficient Canvas-level mechanisms become available, so that this would cause more work than necessary - which is touching on the whole setprop(lw~"") philosophy and having a "compat_layer.nas" module to encapsulate things that may benefit from being changed/updated at some point (think the terrain presampling).
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Richard » Sat Dec 19, 2015 3:12 pm

Hooray wrote in Sat Dec 19, 2015 2:44 pm:So the point is not that sprintf() is slow, but that the whole mechanism of using getprop() calls wrapped in a sprintf() call for formatting purposes is not encapsulated at all.


All of the displays currently follow a very similar coding structure so it would be reasonably simple to write a script to fix all of these. I may further refactor all of these objects when we've got more information about the performance implications. I'd probably do this by having a data provider object that is referenced by all of the displays.

I'm currently not sure if we can share the canvas elements across displays, so I've made copies of everything for each display. The implementation as it stands is still a work in progress and I'm sure there will be more changes later. The important thing is to get the avionics built and once we reach a point where most of the displays are done then we can optimise it.

I just tried the shuttle on my i7 laptop; and the main performance is going into the JSBSim; 100 times more than anything else. This is with all the draw-masks set to false and I get 10 fps. 1 fps with graphics turned on. Nasal and canvas are trivial amounts by comparison.
Richard
 
Posts: 707
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: Space Shuttle

Postby Hooray » Sat Dec 19, 2015 3:31 pm

Richard wrote in Sat Dec 19, 2015 3:12 pm:I'm currently not sure if we can share the canvas elements across displays, so I've made copies of everything for each display.

You are right, that would help reduce the OSG-level workload, i.e. scene graph-level instancing.
But for the time being, Canvas does not support anything like that.
The only thing that works reasonably well is to treat a Canvas as a texture map and reference parts of it, to reuse those elsewhere, i.e. as raster images.
That would work for shared/common state, assuming the layout/arrangement is identical.
We are using this for creating NDs with dozens of symbols, which can also be styled/animated (see the SymbolCache implementation)

The data provider abstraction is what the Avidyne code is using, too.
In the case of propery-driven labels that are formatted using sprintf(), it would probably be easier to just introduce a helper function, and delegate that to C++ code - as per the comments at: viewtopic.php?f=71&t=28160


I have tried to run the space shuttle on the Intel GMA netbook I am using currently, and I don't get any usable performance out of it, even with EarthView disabled.
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Thorsten » Sat Dec 19, 2015 4:31 pm

I have tried to run the space shuttle on the Intel GMA netbook I am using currently, and I don't get any usable performance out of it, even with EarthView disabled.


EarthView doesn't have much performance impact, it's just a textured sphere. The cockpit however has, because it's a 25 MB heavy mesh even with nothing running.

So you might try 1) in HUD view (just the impact of systems) and 2) with all displays off (guess you need to comment them out) to see just how much rendering the bare cockpit costs and how much the avionics takes.
Thorsten
 
Posts: 10982
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Thorsten » Sat Dec 19, 2015 6:03 pm

I'm not sure whether I get the data provider idea.

I sort of see how if you have more than one getprop() in a frame fetching the same property, you want to do it once and then hand the value over from the stored copy the second time.

However, in a real use case, we'd never actually have that situation.

(PLT and CDR would run partially identical layout - but even now we're never updating them in the same frame).

If I want to display 500 properties in real time, I have to get them from the property tree. So then are we talking about not displaying them in real time, having internal update cycles, marking each property for importance? That's going to be a bitch.

(I do suspect low performance systems are killed by the cockpit mesh long before the avionics strikes... if JSBSim actually is a bottleneck, we can probably mitigate that somewhat by selectively running channels - I've been doing that for a few cases for fun and it's reasonably easy to do)
Thorsten
 
Posts: 10982
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Hooray » Sat Dec 19, 2015 7:23 pm

The Avidyne code is using such an abstraction - personally, I am more inclined to think in terms of building blocks, which does not mean that any of your existing code needs to be rewritten from scratch, but should be encapsulated in a fashion so that common coding constructs (such as sprintf/getprop idiom) are put into a helper function, which can later on be re-implemented/optimized, without having to touch tons of files/functions.

Like Richard said, much of the code is fairly similar in structure, so a regex/sed expression may be able to capture most/many occurrences - but otherwise, I think that it would be a good idea for you to look at recurring coding patterns and see if those could/should be unified using a helper function/template - note that this does not even have to involve any object-oriented programming, you could just as well use tiny procedures and/or function generators (functions returning functions)

For instance:
Code: Select all
p_dps_apu_hyd.oil_outt_1.setText(sprintf("%4.0f", K_to_F(getprop("/fdm/jsbsim/systems/thermal-distribution/apu1-temperature-K"))));


Lines like these can be wrapped using a helper function that:
  • take a CanvasText element
  • accept a sprintf format string
  • a list of properties
  • a list of conversion functions for each property

Later on, it would be much easier to update such code to use 2-3 Canvas APIs to accomplish the same thing without having to go through Nasal space at all.

If I want to display 500 properties in real time, I have to get them from the property tree.

that is actually interesting, because a few years ago, 500 property accesses was the average (per frame) that would be observed for the whole simulator:
http://www.mail-archive.com/flightgear- ... 03176.html
David Megginson (designer of the property tree) wrote:I hacked my copy of FlightGear to loop through
property accesses multiple times and watched the framerate. Here's
what I got, using the lower value whenever the framerate fluctuated:

1. No extra accesses: 44fps
2. 500 SGPropertyNode pointer accesses per frame: 43fps (2.3% slowdown)
3. 500 fg(Get|Set)* accesses per frame: 42fps (4.5% slowdown)
4. 1,000 SGPropertyNode pointer accesses per frame: 42fps (4.5% slowdown)
5. 1,000 fg(Get|Set)* accesses per frame: 40fps (9% slowdown)
6. 10,000 SGPropertyNode pointer accesses per frame: 27fps (39% slowdown)
7. 10,000 fg(Get|Set)* accesses per frame: 22fps (50% slowdown)

The surprise here is that most of the loss comes not from the map
lookup (which is skipped by the SGPropertyNode pointer access) but
from the SGPropertyNode::getValue itself: at 10,000 accesses, the
first 39% of the overhead comes from getValue, and only the remaining
11% from the map lookup. That's just wrong, but it's also good news,
because the map lookup should be easy to fix -- I'm doing a profiling
build now to help me hunt down the problem. So far, we're making far
fewer than 500 property lookups per frame, so there is no noticable
drop, and you may be just as well off using fg(Get|Set)* directly for
now.


Note that, these days, we do have the option to have "private" property trees - using the props.nas module, which can create/provide a private property tree, which can also be accessed from a Nasal worker thread - while this will not be useful for properties residing in other subsystems (think FDM), custom state could be kept in such a private property tree to reduce the overall load of the main loop, i.e. reduce the number of properties accessed in the main loop/thread.

It would be interesting to check how many property accesses there are currently using different aircraft/systems, and how much the shuttle is adding in comparison.
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Hooray » Sat Dec 19, 2015 8:04 pm

Here's a code snippet demonstrating how a private property tree /could/ be accessed in a background thread.
I haven't tested this extensively - realistically, you should be able to get update rates >= 50 khz using this approach.
However, it is not truly asyncornous, because the GC will still affect the main loop (rate/spacing).
Which is to say that it would probably be better not to "busy-wait", but to use a timer instead, i.e. to limit the max rate to a sane value - s far as I know, all timers are however using the events subsystem, which is running in the main loop.
So haven't tested that ...

To be put into the Nasal ocnsole:
Code: Select all

var duration=5.0;
var thread_enabled = 1;
var counter = 0;

##
# will be executed by the worker thread
var test = func() {
var val="bar";
while(thread_enabled) {
 counter += 1;
 var myTree = props.Node.new();
 var foo=myTree.getNode("foo",1);
 foo.setValue(val);
 var value=foo.getValue();
 if (value !=val) die("Error ...");
}
};


##
# will be called to stop the thread
var stopThread = func() {
thread_enabled = 0;
print("Iterations: ", counter, " duration:", duration);
print("Rate: ", counter/duration/1000, " khz");
timer.stop();
}

###
# start worker thread
var t=thread.newthread(test);
print("Worker thread started");

## start a timer to kill the thread
var timer = maketimer(duration, stopThread);
timer.singleShot=1;
timer.start();


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

Re: Space Shuttle

Postby sanhozay » Sat Dec 19, 2015 8:59 pm

What are the rules for thread safety when reading/writing the property tree from multiple threads in Nasal?
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 11:57 am
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 3 guests