SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[DaveS]

When are the FPS drops occuring (launch, landing, always)? Do they occur in MOGE? Debug vs Release?

It seems to be limited to on-orbit. And yes, inline client shows the same drop (from 144 Hz, monitor refresh rate) down to below 30 FPS. Sources compiled in Release mode, using VS2017 Community. And they were built fresh, both times.

 

[GLS]

It seems to be limited to on-orbit. And yes, inline client shows the same drop (from 144 Hz, monitor refresh rate) down to below 30 FPS. Sources compiled in Release mode, using VS2017 Community. And they were built fresh, both times.

That excludes the SRBs... I'll look at the changes I made, and report back.

---------- Post added at 10:26 PM ---------- Previous post was at 09:23 PM ----------

I loaded the STS-1 in-orbit scenario and it looks OK with my usual 30-40 FPS. :shrug:
Looking at the changes, the only obvious thing is the Check Bounds code we had and that I removed, but I'm not sure that was even running in the Release config.
Did you try the Debug config?

 

[DaveS]

That excludes the SRBs... I'll look at the changes I made, and report back.

---------- Post added at 10:26 PM ---------- Previous post was at 09:23 PM ----------

I loaded the STS-1 in-orbit scenario and it looks OK with my usual 30-40 FPS. :shrug:
Looking at the changes, the only obvious thing is the Check Bounds code we had and that I removed, but I'm not sure that was even running in the Release config.
Did you try the Debug config?

Yes. It's very intermittent. Sometimes it shows up and sometimes it doesn't.

 

[GLS]

Yes. It's very intermittent. Sometimes it shows up and sometimes it doesn't.

Could it be that the Windows update fragmented your hard drive? If the surface data files are fragmented, it would make some parts of the surface load slower, and in orbit it should be loading new data all the time...

 

[DaveS]

Could it be that the Windows update fragmented your hard drive? If the surface data files are fragmented, it would make some parts of the surface load slower, and in orbit it should be loading new data all the time...

I don't think it's a disk fragmentation issue as I'm using an M.2 NVMe SSD.

 

[GLS]

How about switching to another vessel or deleting the SSU vessel, does that change anything?

 

[DaveS]

How about switching to another vessel or deleting the SSU vessel, does that change anything?

Yes, everything else but SSU is working fine. I think I have fixed it by resetting all the NVIDIA Control Panel settings to default. I guess, something got corrupted during the update process.

 

[GLS]

About (re)installing VS2017 and project targets: to make things simple and avoid changing the projects every time microsoft updates VS, while Windows SDK version 10.0.15063.0 it is available let's stick with it.
My HDD and/or HDD controller when kaput a few days ago (nothing major was lost) and I'm now reinstalling things, and when it came time for VS2017 I started to get errors related to the project target version. If one downloads VS2017 now, it comes with a more recent version of the Windows SDK, and then the "old" projects complain. I had to go back to the installation program and select the 15063 version so everything was aligned. I could have moved the projects to the latest version, but that would cause problems for everybody else, so IMO it's better to stick with what we currently have.
If this is your story, to prevent bogus errors after you downloaded the 15063 version, you'll have to delete the hidden ".vs" folder in the solution directory, and everything should then be working.

 

[Donamy]

...

 

[GLS]

Started playing with 2 vessels at once, and some animations seem to be "over-animating"... most, if not all, animations with parents. Played around and PLB camera animations work fine, and they have parents. Turns out they don't declare MGROUP_XYZ as static, but instead use a pointer and allocate a new instance and use a function called AddManagedAnimationComponent() to deal with the memory at the end. A bit more digging and I found that it was added by SiameseCat back in 2009 with the log "Fixed animation bugs in multi-shuttle scenarios".
So it seems updating our animations to use AddManagedAnimationComponent() is the way to go if we want to have more than one instance of a vessel.
I'd like to use this opportunity to (perhaps) do more animation cleanup, but I got no answers on this question: https://www.orbiter-forum.com/showthread.php?p=567581 :shrug:

 

[DaveS]

Is there any way we could decrease the initialization time of SSU? I'm talking about the time it takes for a scenario to initialize. Even on my high-end 7700K, it takes 20 seconds for SSU to initialize. I'm sure it takes longer on less capable hardware.

 

[GLS]

Is there any way we could decrease the initialization time of SSU? I'm talking about the time it takes for a scenario to initialize. Even on my high-end 7700K, it takes 20 seconds for SSU to initialize. I'm sure it takes longer on less capable hardware.

Yes it does... and it makes debugging so much more fun.:lol:
IMO, most of the time is texture/mesh loading, as there's a noticeable difference between loading a launch scenario and a orbit scenario. Probably 90% of the code is still used (the main vessel), but in orbit it doesn't load SRBs/ET/MLP/Pad, and those represent maybe half or more of the texture/mesh load.

 

[DaveS]

Yes it does... and it makes debugging so much more fun.:lol:
IMO, most of the time is texture/mesh loading, as there's a noticeable difference between loading a launch scenario and a orbit scenario. Probably 90% of the code is still used (the main vessel), but in orbit it doesn't load SRBs/ET/MLP/Pad, and those represent maybe half or more of the texture/mesh load.

They're not even close. I just ran the Atlantis in orbit scenario and the load time decreased by only 3 seconds, so from 20 seconds (launch) to 17 seconds (orbiter alone on orbit). Same settings and everything, only exception being the launch elements.

 

[GLS]

Started playing with 2 vessels at once, and some animations seem to be "over-animating"... most, if not all, animations with parents. Played around and PLB camera animations work fine, and they have parents. Turns out they don't declare MGROUP_XYZ as static, but instead use a pointer and allocate a new instance and use a function called AddManagedAnimationComponent() to deal with the memory at the end. A bit more digging and I found that it was added by SiameseCat back in 2009 with the log "Fixed animation bugs in multi-shuttle scenarios".
So it seems updating our animations to use AddManagedAnimationComponent() is the way to go if we want to have more than one instance of a vessel.
I'd like to use this opportunity to (perhaps) do more animation cleanup, but I got no answers on this question: https://www.orbiter-forum.com/showthread.php?p=567581 :shrug:

Updated all "offending" animations and all seems to work! I haven't committed yet because I have a question: (1) should subsystems use the STS->AddManagedAnimationComponent() call to save their animations in the vector in Atlantis, or (2) should we add a vector to the AtlantisSubsystem (or Subsystem) class so "who needs this service" has it available, or (3) should each subsystem deal with their own animations?
I vote for #2.

 

[GLS]

Flight deck photos of Columbia and Discovery that might be helpful for the vc: https://nasa3d.arc.nasa.gov/detail/ov-102-panels and https://nasa3d.arc.nasa.gov/detail/discovery-flight-deck-panels.

 

[DaveS]

I was just wondering if someone could compute the MECO parameters for 310.5 n.mi apogee? I can't do it myself as we don't have a valid MECO parameter calculator. We really need to get one as our old one (MECOTool.exe) is inaccurate.

 

[GLS]

I was just wondering if someone could compute the MECO parameters for 310.5 n.mi apogee? I can't do it myself as we don't have a valid MECO parameter calculator. We really need to get one as our old one (MECOTool.exe) is inaccurate.

No it isn't.

57NM MECO:

TargetInc=28.500000
TargetLAN=0.000000
MECOAlt=105564.000000
MECOVel=7967.152556
MECOFPA=1.313710

OMS-2:
000:00:42:31
487.520067852889

52NM MECO:

TargetInc=28.500000
TargetLAN=0.000000
MECOAlt=96304.000000
MECOVel=7978.205430
MECOFPA=1.197521

OMS-2:
000:00:43:24
487.520067852889

 

[DaveS]

How does one change the TV ROLL (ITEM 5) in any of the OMS MNVR displays? I've tried the normal way (ITEM 5+xxx where xxx is the desired TIG roll angle) but always get an illegal entry error. This is a bit bothersome as it is always initialized as 180 (great for non-RTHU) but should be 0 for RTHU missions.

 

[GLS]

How does one change the TV ROLL (ITEM 5) in any of the OMS MNVR displays? I've tried the normal way (ITEM 5+xxx where xxx is the desired TIG roll angle) but always get an illegal entry error. This is a bit bothersome as it is always initialized as 180 (great for non-RTHU) but should be 0 for RTHU missions.

This is what the literature says:

Item 5 (TV ROLL) is the roll attitude for OMS
burns. Normally, it is 180°, which corresponds
to a heads-down attitude. A different number
can be entered in MM 202 only, but it is seldom
changed.

Item 5, TV ROLL, the desired local roll angle at ignition, comes from a compool (I-load, uplink, or
crew input) and this item is used to update the displayed value (in OPS 2 only). Upon reinitialization
of the display, the latest value will be displayed in OPS 1, 2, and 3. This item is not
supported by BFS, but the I-loaded or uplinked value is displayed in OPS 1 and 3.

 

[DaveS]

So I have hit a bit of a stumbling block on a planned project. The problem is that I need two DPS SM displays, namely SM 211 and SM 212. The titles are SSE OVERVIEW and SSE MECHANISMS.

The project deals with the HST service equipment, mainly the FSS and some of the equipment carriers. For the best simulation, I think it would be best to integrate at least the FSS like we have done for the IUS and Centaur. The FSS is controlled through SSPs and both these SM displays.