Board index FlightGear Development Spaceflight

Space Shuttle - Development

Discussion about development and usage of spacecraft

Re: Space Shuttle - Development

Postby wlbragg » Sat Dec 03, 2022 7:20 pm

I also was considering tying in into the "detailed" switch, either using livery or some other method. Is it feasible to just replace the existing texture with the higher res version and keep it simple. How much heavier is this texture going to be? I think it is load time mostly, right? We would need to do some testing along the way, I suppose.
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 » Sun Dec 04, 2022 11:02 am

Is it feasible to just replace the existing texture with the higher res version and keep it simple.


Actually I just had an idea that might even work: What about texturing the Shuttle with a canvas? Inside the canvas controlling, we should be easily able to change a background texture and even load decals and similar fun stuff upon request.

(Sadly, this still doesn't give us a switch that affects normal maps etc...)

Simply using a hires texture might cost A LOT of GPU memory - think Earthview, the 24k sized sheets aren't exactly cheap to handle.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby Hooray » Sun Dec 04, 2022 7:17 pm

like you said, canvas liveries are a thing, and have been for many years meanwhile - however, there's the issue of VRAM/RAM occupancy, which got discussed frequently over the years, I believe that James and Stuart talked about an optional way to discard unused RAM once the canvas livery is applied, not sure if this got ever implemented or not 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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Space Shuttle - Development

Postby GinGin » Sun Dec 04, 2022 7:36 pm

The texture is around 80 mb.
We have the approval of the author (Wolf who made very nice HD texture for SSU Orbiter add on https://www.orbiter-forum.com/threads/ssu-hi-res-textures.35761/)
Snax used those textures for FG and he is looking to work on the normal one also later on.
I am waiting for its final version of the spstob_1 file and I will push it in the dev branch next week.

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

Re: Space Shuttle - Development

Postby eatdirt » Wed Dec 07, 2022 8:46 pm

We have the approval of the author (Wolf who made very nice HD texture for SSU Orbiter add on

Nice! I hope "approval" means that it can be licensed GPL right?

NB: I have to say that the thread goes out of hand in a quite funny way! Gingin, you should not fly with these people :P
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

Re: Space Shuttle - Development

Postby eatdirt » Sat Dec 10, 2022 12:31 pm

I am definitely testing too much and not sleeping much...

Another merge request landing:

https://sourceforge.net/p/fgspaceshuttledev/code/merge-requests/47/

This one is a bastard. First, let me stress it was there before my recent changes (tested by reverting my last commits), and historically, possibly, introduced by Eileen (I've found it by cycling targets).
While in the process of fixing this issue, I've discovered another one, possibly much older, probably dating from the very first implementation of the proximity manager. This one is a race condition, two ways of providing the proximity coordinates are fighting, and, without entering details, this was the cause of the jumps seen sometimes on the rdv dialog.

This merge request is definitely for Thorsten. I've put a lot of details in the merge request summary, but I can answer more questions if needed.

Other can test by stressing Eileen, asking her to cycle over targets, even if there is only one target, and looking carefully at the rdv dialog window to check if positions and velocities abruptly change (they should not). Also, you should not see the Shuttle symbol jittering. We though it was due to numerical accuracy issues, but it is not, that was the race condition (Proximity calculations are damned robust within the proximity zone).

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

Re: Space Shuttle - Development

Postby Thorsten » Tue Dec 13, 2022 11:31 am

This one is a race condition, two ways of providing the proximity coordinates are fighting, and, without entering details, this was the cause of the jumps seen sometimes on the rdv dialog.


At least this explains why I've never been able to nail it down... I've assumed I'm looking for an ordering issue of two independent Nasal loops, i.e. does the proximity object manager update position in the frame before or after the display queries?

The analysis reads plausible and the fixes don't look like they could cause any side effects, so I've pushed the button.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby eatdirt » Wed Dec 14, 2022 10:06 am

does the proximity object manager update position in the frame before or after the display queries?


I was thinking an ordering problem at first, and swapped the ordering of the two proximity calculations, but that was not fixing the issue (visible in a merge I rejected myself https://sourceforge.net/p/fgspaceshuttledev/code/merge-requests/46/).

I don't really know how "canvas" are implemented at a lower lever, but, for triggering that issue, it really looks they're running in a thread? So, my best understanding is that cdlg_rdv calls, at its pace, SpaceShuttle.proximity_manager_target_xyz to read it. In the meanwhile, this guy is written in a fast loop by payload_manager.compute_proximity(), and within a slow loop by rel_orbital.compute_proximity() (called from stage.nas at 0.8s intervals). Therefore, most of the time, everything goes fine, but, from time to time, SpaceShuttle.proximity_manager_target_xyz is read just after it has been updated by the rel_orbital module and before it was overwritten by the payload_manager, hence the transient jumps. Obviously, changing the order or the two compute_proximity() will not fix the issue since there always exists a time at which one has written over the other. (If the issue is not due to some threading of canvas, that could also be induced by some memory buffering in nasal I guess?).

I have been playing a lot prox operations (not with ISS yet though), there is still only one remaining very minor issue, which is "a miss". If we enter too fast the proximity zone, you see the target passing nearby and exiting as it should. But, depending on how fast and how different are the two proximity calculations, it may happen that after exiting, the rel_orbital position finds the inertial position again in the proximity zone and you get another chance for free, the target enters again :) A possible fix would be to update the true anomaly of the target at exit time by the proximity coordinates computed by the payload_manager when it unloads. Holidays project :)
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

Re: Space Shuttle - Development

Postby Thorsten » Wed Dec 14, 2022 11:43 am

A possible fix would be to update the true anomaly of the target at exit time by the proximity coordinates computed by the payload_manager when it unloads.


Don't do that... we might lift ISS onto a highly elliptic orbit just by accident :mrgreen: (Well, okay, if you just update true anomaly then all is fine, but... is that going to really fix the issue?)

Unfortunately we don't really have a good orbital engine for anything apart from the Shuttle - the proximity calculations are too coarse in time to be long-term stable and the analytic solution in the far region is long-term stable but doesn't contain all of the tidal terms. No easy fix unfortunately...
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby eatdirt » Wed Dec 14, 2022 1:51 pm

Well, okay, if you just update true anomaly then all is fine, but... is that going to really fix the issue?


Don't worry, I am not going to try such a stunt now, especially after having chased mini bugs :) That was just an idea, and you may be right, it may not solve the issue!
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

Re: Space Shuttle - Development

Postby GinGin » Fri Dec 16, 2022 10:25 am

Excellent Chris, I will test a ride to ISS or HST. Long time!
On my side, I am waiting for the last adjustements on the HD texture to push it.

I pushed a commit with up to date mission files. Informations might be found at the top of each mission files.

Main things:
*ISS and HST have a 2 mn countdown before launch (RINC of 0.05° at the end)
Auto OMS load for OMS 2 (initial phasing)
*STS1 mission file has advanced meco parameters based on real mission. Standard Insertion. Auto OMS1 and 2.

@EatDirt: Tell me what you think about the last changes in the TAEM transition at HAC init. Smoother roll AP normally
I have also fine tuned the time to hac computation; more consistent.
You can see it on pfd in medium rate error and on spec 50 page.

Image


Almost finish with entry spec 54.
One more thing to implement to display an instantaneous impact point if the 3 engine fails and that should be ok.
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Development

Postby eatdirt » Sat Dec 17, 2022 8:40 pm

@EatDirt: Tell me what you think about the last changes in the TAEM transition at HAC init. Smoother roll AP normally
I have also fine tuned the time to hac computation; more consistent.


Hi Gingin, I gave it a try at KTTS, it runs very smoothly now, the transition at HAC init is easy to follow, well done!

There is still this little spike in guidance towards the end of the HAC, but it is not really a problem, ignoring it and we arrive straight in front of the runway!
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

Re: Space Shuttle - Development

Postby GinGin » Sun Dec 18, 2022 9:02 pm

There is still this little spike in guidance towards the end of the HAC


It is the transition between HAC logic and Pre final logic, just before the Auto Land logic kicks in.
I worked on that, it should be ok in the next commit.
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Development

Postby GinGin » Thu Dec 22, 2022 2:05 pm

@EatDirt: I pushed a commit with better transition from HAC to Prefinal state (no more initial Spike). Tell me how you find it.

I have also pushed the HD external texture that you can find in models/spstob_1_hd
Just removed the _hd and save the previous one to test it.
I updated the authors file with references for the hd texture.
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Development

Postby GinGin » Sun Jan 08, 2023 11:47 am

@wlbragg: Hello Wayne, I was wondering what would be the easiest way to switch in game between the two set of external textures ?
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 3 guests