Board index FlightGear Development Spaceflight

Space Shuttle - Development

Discussion about development and usage of spacecraft

Re: Space Shuttle - Development

Postby Richard » Sun Dec 09, 2018 11:48 am

I'd expect some improvement by using single sided surfaces as it easily and quickly culls surfaces that can't be viewed because their normal is away from the view.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Space Shuttle - Development

Postby Thorsten » Sun Dec 09, 2018 12:18 pm

As usual, I'd expect performance improvements by rendering related stuff if rendering is the bottleneck, but not if something else is. For me at least the Shuttle is limited by running displays and systems, so graphics performance sadly is not that relevant.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby GinGin » Sun Dec 09, 2018 12:45 pm

@WlBragg: Yep, I will test the changes in FPS.


Edit

Well, I can't say if I see or not improvements.

Around 60 fps alsmot all the time and bottleneck for me is for Ram when I use more than 500 km visibility

Image


The major improvement I had FPS wise ( almost doubled them from 30 to a solid 60 + constant with Max settings) was to move the game on a very fast NVME SSD ( 3000 mo/s of read/write instead of 400Mo/s ish for a " normal " one) and put the swap virtual memory file on it


New colors of Master Alarm looks really nice. Red Freon loop, niceeee :)
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Development

Postby wlbragg » Sun Dec 09, 2018 1:53 pm

Richard wrote in Sun Dec 09, 2018 11:48 am:I'd expect some improvement by using single sided surfaces as it easily and quickly culls surfaces that can't be viewed because their normal is away from the view.

My testing was anything but definitive, but it appeared to help with the rendering in interior view as you scrolled around. As you know that interior mesh has to be one of the heaviest in FG and that entire interior detailed mesh was double sided.
I didn't test the loading time and would be surprised if it helped that at all. The vast amount of that time is surely all the systems loading.
Beings I noticed a slight difference, if anyone else verifies my observation I will go through the cockpit mesh (as opposed to the detailed cockpit) and make sure that is also all single sided. Most of it is simple enough, except the individual switch and breaker mesh, there is a ton of that.
I am amazed at how many switches and breakers we have isolated and activated to date. :D
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 GinGin » Sun Dec 09, 2018 1:58 pm

I am amazed at how many switches and breakers we have isolated and activated to date


Quite impressive indeed.
When we press shift + C, almost all the cockpit is in yellow :)


What is the meaning of double sided code wise?
Do we loose texture definition when it is single sided?
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Development

Postby Hooray » Sun Dec 09, 2018 2:37 pm

Back when were troubleshooting/optimizing the ND/MapStructure stuff (around 2012 IIRC), we would simply instantiate the corresponding displays inside a GUI dialog without loading any particular aircraft/cockpit to be able tell the impact of just doing the displays, at some point we squeezed out so much performance, that we were able to run 12+ displays without much impact at all.

Another thing that we were regularly doing is loading just the 3D model of the cockpit in osgviewer/fgviewer to determine the load caused by the cockpit mesh.

I am fully aware that these things are self-explanatory to shuttle coders like Thorsten and Richard, but it may still be useful for people less familiar with fg internals, who may be running into performance issues. As a matter of fact, I don't have access to a system with a 16gb GPU, and I never have been able to load the shuttle, let alone fly it. So I am following this out of personal interest (which is also why I previously suggested to share more videos and/or create pre-recorded flights, to be able to do some troubleshooting (read: profiling/benchmarking) without actually having to learn how to launch/fly the thing).

Like Thorsten said, bottlenecks are different for everybody, depending on the hardware, OS/drivers and settings in use.

But it would definitely be interesting to have more data, especially to be able to compare it with other setups and other aircraft known to require certain resources (e.g. extra500)

As a matter of fact, it might not even be such a bad idea to generally hook up the Canvas system (i.e. its elements) to the built-in osg stats handler, so that we can enable stats for different FBO contexts.

http://wiki.flightgear.org/Howto:Protot ... le#Gallery
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Space Shuttle - Development

Postby Richard » Sun Dec 09, 2018 3:17 pm

wlbragg wrote in Sun Dec 09, 2018 1:53 pm:
Richard wrote in Sun Dec 09, 2018 11:48 am:I'd expect some improvement by using single sided surfaces as it easily and quickly culls surfaces that can't be viewed because their normal is away from the view.

My testing was anything but definitive, but it appeared to help with the rendering in interior view as you scrolled around. As you know that interior mesh has to be one of the heaviest in FG and that entire interior detailed mesh was double sided.


Changing to single sided is tedious but definitely worth doing, I spent many hours doing this on the F-15 although mainly that was fixing the surface normals as AC3D can change to one sided for an entire mesh with a couple of clicks; whereas in blender it is a lot more difficult as ISTR that you have to do each object individually.

I've been doing a lot of work recently on figuring out model load; generally having a lot of individual .xml files is bad, as is loading .xml or geometry (.ac) files that aren't in use. The actual load time of the .ac is fairly quick, I was previously wrong about this[1].

For example the C-172 is particularly slow to load because it includes a lot of models which in turn pulls in a lot of textures.

Pre-loading models is a bad idea, not sure if the shuttle does this, but it is a work around to a core problem that we should fix in the core. With the recent improvements in the LOD and the upcoming texture cache we will start to see model load improvements that previously could be worked around by pre-loading.

So I'd expect no real improvement in load performance from changing to single sided; the model file will be the same length, and the geometry identical apart from the single-sided flag.

However run time performance should improve; you may also find that certain 'facing the other way' surfaces that use a different texture can reduce state changes.

Overall it's still state changes (and therefore number of distinct textures) that hurt performance the most. Geometry count doesn't really make a proportionate difference.

My recommendation remains that a single texture and .ac for the interior and a single texture and .ac for the outside is the best performance wise for both load and render; although I do appreciate the difficulties in doing this.

--------------------------
[1] load improvements that I'd attribute to .ive format appear to be actually more related to the embedded DDS textures and osgviewer loads .ive a lot faster than FG does; to prove this I had to change FG to support .ive,.osgt,.osgb better. Also note that using .ac or .obj is really still the only supported option as there are certain things (e.g. effects) that only apply to ,ac and ,obj.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Space Shuttle - Development

Postby Thorsten » Sun Dec 09, 2018 6:28 pm

Back when were troubleshooting/optimizing the ND/MapStructure stuff (around 2012 IIRC), we would simply instantiate the corresponding displays inside a GUI dialog without loading any particular aircraft/cockpit to be able tell the impact of just doing the displays


That's all very nice to hear, but many Shuttle displays reference the Nasal part of systems simulation directly to avoid property I/O, so you can spend a few weeks rigging that complete setup outside the Shuttle - which clearly is not worth my time.

Another thing that we were regularly doing is loading just the 3D model of the cockpit in osgviewer/fgviewer to determine the load caused by the cockpit mesh.


A large mesh in itself is not an issue for a modern graphics card, what is an issue is breaking that mesh into 400+ parts - but there's no choice here if we want 400+ moving switches in the cockpit.

I don't have access to a system with a 16gb GPU, and I never have been able to load the shuttle


It loads quite fine into 8 GB, supposedly someone has also managed to load it into 4 GB (in orbit at least with no terrain underneath).

But it would definitely be interesting to have more data


If you want to submit a patch and gather that data, you're very welcome. If you want me to gather that data, I have to decline - I feel I largely have the data I need to make decisions how do design things and my time is better spent improving the Shuttle or FG in general.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby legoboyvdlp » Sun Dec 09, 2018 6:36 pm

Hooray wrote in Sun Dec 09, 2018 2:37 pm:. As a matter of fact, I don't have access to a system with a 16gb GPU, and I never have been able to load the shuttle, let alone fly it.

I run it just fine on a 2GB card at full settings - and in fact on an Intel card (with the detailed mesh and ALS (no shaders) as well - I don't think it's lack of VRAM at fault there.
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Space Shuttle - Development

Postby Hooray » Sun Dec 09, 2018 9:33 pm

Thorsten wrote in Sun Dec 09, 2018 6:28 pm:If you want to submit a patch and gather that data, you're very welcome. If you want me to gather that data, I have to decline - I feel I largely have the data I need to make decisions how do design things and my time is better spent improving the Shuttle or FG in general.


Well, I don't think there is any need to "restructure" things or submit any patches - as a matter of fact, in response to the original Canvas performance issues, I did submit a C++ patch integrating an optional profiler which can provide actionable data very easily - and it's even documented in the wiki, TheTom used this mechanism back in 2012 to heavily optimize the Canvas system at the C++ level, but it is not at all specific to C++ code: http://wiki.flightgear.org/Built-in_Profiler

As you can see, it's using two fgcommands, you don't need to touch any Nasal or C++ code, you can just execute those fgcommands via the Nasal console (provided the profiler is integrated in your binary) and you can dump said data to a file that you can share with people able to interpret such data, and what can I say, all of us may be in for a surprise ;-)
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 GinGin » Tue Dec 11, 2018 3:11 pm

Good job on the C/W implementation, sound and colors really increase the immersion level

Image
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Development

Postby eatdirt » Sun Dec 16, 2018 11:57 pm

Hi there,
just tested the OMS ignition during ascent... superb! Got direct insertion into an elliptical orbit having 2200 miles of HA.

Be careful though, the OMS timing should be properly timed. In one of the tests, I got a premature MPS extinction due to fuel starving, but the OMS were still burning. OMS firing alone with ET attached is not nice, the Shuttle went on high spin in less than a few seconds and got destroyed!

I am now running to break my last elevation at 3000nm :)

Cheers,
Chris.
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

Re: Space Shuttle - Development

Postby Thorsten » Mon Dec 17, 2018 6:49 am

Be careful though, the OMS timing should be properly timed.


This is not called OMS assist for nothing - I don't think anyone ever envisioned the burn to last for more than two minutes...

But yeah, the assumption is that the ascent DAP does the necessary vectoring using the MPS gimbals, the OMS engines aren't gimbaled at all during the assist burn. Quickly changing to the OMS TVC DAP might resolve that (though I'm not sure whether vectoring works with the ET attached) - so... just make sure the OMS is off by the time you have MECO :mrgreen:
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby Thorsten » Mon Dec 17, 2018 2:23 pm

Fire in space - and the smoke detection numbers are now also driven 8)

Image

I trust the usual suspects see where the fire is with a single glance :mrgreen:

(Need to wait a bit for the 3d works still...)
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby legoboyvdlp » Mon Dec 17, 2018 2:38 pm

Avionics bay 2?
What sort of extinguishers does the Shuttle have? Is damage to the avionics simulated? :)
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 5 guests