Board index FlightGear Development Spaceflight

Space Shuttle - Development

Discussion about development and usage of spacecraft

Re: Space Shuttle - Development

Postby Thorsten » Thu Dec 06, 2018 3:02 pm

Are the red and yellow engine lights supposed to be in this configuration, both red and yellow lit up, at startup on the launchpad?


I honestly have no idea. But the lights do illuminate after MECO, so the lights can be on even if all is okay with the engines if they don't actually run.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby GinGin » Thu Dec 06, 2018 7:36 pm

@Thorsten:

Class 1 Siren For fire alert


The emergency (class 1) aural alarms consist of a siren (activated by the smoke detection system) and a klaxon (activated by the delta pressure/delta time sensor that recognizes a rapid loss of cabin pressure), and they are annunciated by hardware. The siren's frequency varies from 666 to 1,470 hertz and returns at a five-second-per-cycle rate


Returns at five second per cycle : for me it means that in five second, the siren goes from 666Hz to 1470Hz and back to 666 Hz in 5 seconds, is it correct?


https://drive.google.com/open?id=1wSU2mnpf4gOtlhNc3hOhNmCbILdxS4BQ




Class 3 single tone for the Blue Sm alert

The SM alert tone is a steady tone of 512 hertz of predefined duration generated in the C/W electronics when activated by inputs from the onboard computers.



I took an arbitrary two seconds for the length, long enough :)



https://drive.google.com/open?id=1PKAdBFdyHtnwACnvr2V7hmgcEOGWY1X9


@WlBragg : SM blue alert seems correct, same than for the abort button

For the MPS lights, not sure at all either.
I would say at least yellow light extinguishe with APU on and Hydraulics. I will dig further
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Development

Postby wlbragg » Thu Dec 06, 2018 7:51 pm

@Thorsten

In case you notice the inefficiency of the Master Alarm animation logic I put in place before I finish changing it to something more efficient, I am changing it from the three object select animations per button to the much more efficient texttranslate and only one object per button. I don't have a good answer why I didn't do this in the first place other than I guess I just didn't think about it.
I realized how dumb it was after looking at what I did with an almost identical problem in the c172p. I noticed it while refreshing my memory about the procedural light.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7588
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Space Shuttle - Development

Postby wlbragg » Fri Dec 07, 2018 5:48 am

Not sure what this is. The call to SpaceShuttle.master_alarm_mngr.unset_alarm(); is triggering the error.

Code: Select all
Nasal runtime error: No such member: kit_oms_flag
  at /mnt/GDrive/Aircraft/Development Aircraft/SpaceShuttle/Nasal/cws.nas, line 1830
  called from: , line 4
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7588
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Space Shuttle - Development

Postby Thorsten » Fri Dec 07, 2018 8:14 am

Simple typo...
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby wlbragg » Fri Dec 07, 2018 8:35 am

I saw the commit, thanks.

I pushed the Master Alarm Button changes including some procedural lighting for them.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7588
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Space Shuttle - Development

Postby wlbragg » Fri Dec 07, 2018 6:23 pm

Much better, now if we can spice up the CW lamps.

Image

EDIT:

The procedural lighting is more subtle in the final commit.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7588
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Space Shuttle - Development

Postby wlbragg » Sat Dec 08, 2018 6:08 pm

@Thorsten
How much performance would you guess we would gain if you could change double sided mesh to single sided mesh for say a 1/2 to 3/4 or even more of all the cockpit and detailed-cockpit mesh?

I don't know why I am just now noticing this, experience I guess. Starting on the latest switch requests I noticed all the breakers and really everything associated with the particular panel I was working on was all double sided.

I know early on I was trying to catch this type of mesh and change it, where possible, when I noticed it. I think that was mostly when laying out the cockpit mesh over all. I don't recall ever looking at the switch, breaker, guards, fasteners, etc. Although I also noticed on this particular panel even the base of the panel was double sided.

If there is a good bit of gain to be had in this, I will make it a mission to go through panel by panel and make sure it is as streamlined as possible. With the understanding there could be a few things we need to leave double sided .
Last edited by wlbragg on Sat Dec 08, 2018 6:59 pm, edited 1 time in total.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7588
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Space Shuttle - Development

Postby Thorsten » Sat Dec 08, 2018 6:49 pm

I strongly suspect systems and instruments are currently the performance limitation, not rendering, so the Shuttle is one of the few areas in FG that are actually CPU limited.

(Otherwise I fail to see why a high-end GPU doesn't get the job done faster, the cockpit is complex but not that complex).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby wlbragg » Sat Dec 08, 2018 7:08 pm

OK, I am most of the way through the detailed mesh anyway, and it is virtually all double sided. It is maybe more detailed than it needs to be. For example I was thinking the switch covers need to be double sided. But on closer examination they are actually 3dimentation and have separate mesh on all sides, so even they don't need to be double sided.
It wasn't that much work and it's going to bug me until it is optimized and I basically already committed, at least to the detailed mesh.
This would be a good test for @eatdirt or @GinGIn to take note of performance stats before and after they pull the next development branch commits.
I'm going to see if I can notice a difference if I don't forget to run the sim before I export the .ac.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7588
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Space Shuttle - Development

Postby wlbragg » Sat Dec 08, 2018 7:51 pm

Wow, I finished the detailed cockpit and with a very basic analysis I noticed approximately 3+ fps increase overall. I was getting 7-20 fps looking around the cockpit before. After I was getting no less than 10 and as high as 25.
Interesting, this was starting in orbit.

It's push to development if anyone wants to test it.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7588
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Space Shuttle - Development

Postby Thorsten » Sat Dec 08, 2018 8:24 pm

If you have it done anyway, let's just use it - technically it is the correct approach, I was just wondering whether it's worth much effort from your side.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby Hooray » Sat Dec 08, 2018 8:40 pm

I strongly suspect systems and instruments are currently the performance limitation, not rendering, so the Shuttle is one of the few areas in FG that are actually CPU limited.

(Otherwise I fail to see why a high-end GPU doesn't get the job done faster, the cockpit is complex but not that complex).


assuming that all of this is using Richard's MFD framework, it should be pretty easy to call .hide() and .show() respectively on each MFD's top-level root group to determine the impact of rendering/not rendering the instruments, while still updating them - as a matter of fact, using a Canvas event listener, it would even be fairly easy to come up with a custom event handler to easily disable MFD rendering by clicking an instrument twice.

You would not even have to touch any of the shuttle's code, but only add the corresponding event handler to the MFD class to have a nice and simple way to easily toggle rendering on/off for certain displays, so that you can see if any of this has an effect on performance or not - I believe, this shouldn't take more than 20 lines of Nasal code added to the MFD helper class, and you could even make it a development option to keep this disabled by default, it might still be helpful though - especially for non-coders not familiar with Nasal/Canvas internals.
With a bit of C++ glue code, the Canvas system and its elements could also be hooked up to the OSG/FG stats handler.
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: Space Shuttle - Development

Postby Thorsten » Sun Dec 09, 2018 7:33 am

assuming that all of this is using Richard's MFD framework, it should be pretty easy to call .hide() and .show() respectively on each MFD's top-level root group to determine the impact of rendering/not rendering the instruments, while still updating them


I know the relative performance impact on my machines pretty well - I'm just not sure the bottlenecks are the same for everyone.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby Hooray » Sun Dec 09, 2018 10:31 am

Right, I believe Richard's MFD framework is also using a propertyManager abstraction to memoize get/set operations, so that would be another option to see how the equation is influenced by disabling/enabling property I/O.

Providing people with tools to report back the corresponding numbers/findings, might provide some additional insight here ?

Thinking about it, we could register an event handler and show a Canvas GUI dialog with checkboxes to let people tinker with various settings (enable/disable rendering, property updates etc), and make this part of Richard's MFD class.
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

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 3 guests