SSU Development Thread (3.0 to 4.0)

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,797
Reaction score
2,782
Points
188
Website
github.com
For me the FPS doesn't return until all the MFDs have been turned off, not just the ADI/HSI. So it isn't the heaviness of the ADI and HSI that is the true culprit of the FPS reduction.

I don't see much reduction changing from 0 to 1 MDU on.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,423
Reaction score
677
Points
203
I don't see much reduction changing from 0 to 1 MDU on.
I did some further tests and one A/E PFD costs me about 10 FPS. All DPS displays are pretty a much a wash, no real impact. So I was premature in my conclusion that the A/E PFD had no role in the reduction.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,592
Reaction score
736
Points
128
For me the FPS doesn't return until all the MFDs have been turned off, not just the ADI/HSI. So it isn't the heaviness of the ADI and HSI that is the true culprit of the FPS reduction.

Does the same occur with Orbiter's stock MFDs ?
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,592
Reaction score
736
Points
128
After changing the MFD refresh rate to 0.1s I get 10-20 FPS hit from each open PFD. Smaller hit from all other modes but still bigger than from stock MFDs. To me it looks like it's somehow related to GDI based drawing.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,797
Reaction score
2,782
Points
188
Website
github.com
After changing the MFD refresh rate to 0.1s I get 10-20 FPS hit from each open PFD. Smaller hit from all other modes but still bigger than from stock MFDs. To me it looks like it's somehow related to GDI based drawing.

Yes, our MFD code is still all GDI...
I could change it to run on Sketchpad, but unless the mesh projection thing becomes a reality, I think a HDC is still going to be needed for SetWorldTransform() to work in the ADI and HSI.
 

Poscik

Addon Developer
Addon Developer
Joined
Mar 28, 2008
Messages
512
Reaction score
3
Points
18
Location
Sulejówek
If this code is disabled then does the performance problem go away ? Drawing rectangles can't be a problem.

Rendering a user supplied mesh to a MFD screen can be easily arranged in the sketchpad, technically almost everything is already there.

So indeed there is no sense to draw MFD somewhere behind the scenes.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,423
Reaction score
677
Points
203
Yes, our MFD code is still all GDI...
I could change it to run on Sketchpad, but unless the mesh projection thing becomes a reality, I think a HDC is still going to be needed for SetWorldTransform() to work in the ADI and HSI.
Can't we use the ADI from the Shuttle-A? In the beta the Shuttle-A has been equipped with a fully functional ADI that's very easy on the FPS.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,797
Reaction score
2,782
Points
188
Website
github.com
Can't we use the ADI from the Shuttle-A? In the beta the Shuttle-A has been equipped with a fully functional ADI that's very easy on the FPS.

I just took a quick look at it and it is very interesting.... but if I'm understanding well the concept used there, that shows the mesh in the 2D panel. We need to project the mesh to a surface.

EDIT: but for the MCDS cockpit, that is exactly what we need.
 
Last edited:

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,527
Reaction score
2,261
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
A Sketchpad solution sounds like the best approach to me.... what would be needed for that?

Would something help reducing the "Waiting present" times?
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,797
Reaction score
2,782
Points
188
Website
github.com
A Sketchpad solution sounds like the best approach to me.... what would be needed for that?

Redo all displays (maybe except the DPS ones). I could do all that, and at the same time "fix" the CRTMFD by merging it into the main vessel*. I'd like to do some testing first to be sure we can at least keep the current ADI and HSI working with Sketchpad (without the mesh projection). All if this is 2 or 3 weeks in the future... :facepalm: ... but I get there.
We should probably get the last SSU for Orbiter 2010 out the door first, and then focus on Orbiter 2016. Even if it is delayed several months, there are tons of stuff we can improve meanwhile (this MFD situation, the talkbacks, lights, etc). Anyway, there are problems to fix for several weeks/months.


*) I just had this idea: custom MFDs for the upper stages to display the timers and prop, instead of having that in the HUD... :hmm:
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,527
Reaction score
2,261
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
I just had this idea: custom MFDs for the upper stages to display the timers and prop, instead of having that in the HUD... :hmm:

What about doing a "upper stage mission control center" building, that can be used for all our upper stages? This way we don't repeat ourselves. (DRY)

I would not be surprised if DaveS now corrects me, but I am almost sure that the upper stages had been controlled in the same building as the Shuttle, likely just a different room, so maybe we could combine both tasks.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,797
Reaction score
2,782
Points
188
Website
github.com
What about doing a "upper stage mission control center" building, that can be used for all our upper stages? This way we don't repeat ourselves. (DRY)

I would not be surprised if DaveS now corrects me, but I am almost sure that the upper stages had been controlled in the same building as the Shuttle, likely just a different room, so maybe we could combine both tasks.

Unless we also do the mission planning and guidance so the stage works by itself (tons of stuff), there will not be much to do/look at in that mission control.
My idea was more oriented to "package" the information we output to the HUD in a better way. It could also be a good training/learning case for merging the CRTMFD.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,423
Reaction score
677
Points
203
Redo all displays (maybe except the DPS ones). I could do all that, and at the same time "fix" the CRTMFD by merging it into the main vessel*. I'd like to do some testing first to be sure we can at least keep the current ADI and HSI working with Sketchpad (without the mesh projection). All if this is 2 or 3 weeks in the future... :facepalm: ... but I get there.
We should probably get the last SSU for Orbiter 2010 out the door first, and then focus on Orbiter 2016. Even if it is delayed several months, there are tons of stuff we can improve meanwhile (this MFD situation, the talkbacks, lights, etc). Anyway, there are problems to fix for several weeks/months.


*) I just had this idea: custom MFDs for the upper stages to display the timers and prop, instead of having that in the HUD... :hmm:
Well, the DPS displays do have to redone in order to work with the new MFD texture resolution setting[Extra|Instruments and panels|MFD parameter configruation]. Currently we end up with this:

SSU_hires_MFD.jpg
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,797
Reaction score
2,782
Points
188
Website
github.com
Well, the DPS displays do have to redone in order to work with the new MFD texture resolution setting[Extra|Instruments and panels|MFD parameter configruation]. Currently we end up with this:

SSU_hires_MFD.jpg

Yeah, I knew that was going to happen if the resolution was increased (I still haven't changed it), as all the displays are "locked" for 256x256.
A fix (maybe not for every item on display) would be to get the chosen resolution and from it get a scale factor to which all current coordinates would be multiplied (1 for 256, 2 for 512 and 4 for 1024), but that is not going to make things faster as all coordinates must be calculated on the fly. Yes, we could use a left-shift instead of a multiplication, but it would still be an extra hit in performance (probably not a lot though). As an alternative, we could have separate versions of each display with "hardcoded" coordinates for each resolution... that would increase the amount of code but it would allow more control of what shows at each resolution, allowing tweaks to get the best results. I think the expression "pick your poison" applies...
For now I'd keep the 256x256 and give priority to the Sketchpad move (2-3 weeks and I'm 1000% on it).

Any thoughts on the last SSU for Orbiter 2010? The only things I think are missing are the IUS umbilical boom hinge mesh that has the wrong angle, the bellows animation in the CISS, and the manual probably needs more text in the upper stage chapter.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,527
Reaction score
2,261
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Any thoughts on the last SSU for Orbiter 2010? The only things I think are missing are the IUS umbilical boom hinge mesh that has the wrong angle, the bellows animation in the CISS, and the manual probably needs more text in the upper stage chapter.

Not sure, I don't see any more missing features to be completed right now. changing the DPS makes no sense now, because if we change rendering of the MFDs anyway, we better do the final steps there afterwards.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,423
Reaction score
677
Points
203
Any thoughts on the last SSU for Orbiter 2010? The only things I think are missing are the IUS umbilical boom hinge mesh that has the wrong angle,
Could you show what you mean by "wrong angle"? In all the photos I have, it (the overall boom structure) is following the curvature of the AFTA.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,797
Reaction score
2,782
Points
188
Website
github.com
Could you show what you mean by "wrong angle"? In all the photos I have, it (the overall boom structure) is following the curvature of the AFTA.

The boom rotation axis is such that it rotates paralel to the PLB (like the animation), and not radially away from the IUS (like the current hinge is). This is visible in the images when the ASE is raised and I've seen a picture that shows that hinge a bit better and confirms this. Let me see if I can find it....

---------- Post added at 11:20 AM ---------- Previous post was at 11:11 AM ----------

The boom rotation axis is such that it rotates paralel to the PLB (like the animation), and not radially away from the IUS (like the current hinge is). This is visible in the images when the ASE is raised and I've seen a picture that shows that hinge a bit better and confirms this. Let me see if I can find it....

Found more than one:
magellan_vpf.jpg

Preparation_of_an_Inertial_Upper_Stage.jpg

KSC-95EC-0575.jpg
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,423
Reaction score
677
Points
203
To me it looks like the rotation axis is what I have now. This is a really good close up from STS-26:

STS-26_S26-31-065.jpg


And this one from STS-41:
STS41-83-012.jpg
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,797
Reaction score
2,782
Points
188
Website
github.com
The first photo shows very well that the direction of the rotation is not 100% radially away from the IUS. If it was, the boom would be a bit sideways on that photo instead of head-on. On the photos I posted, the angle of the hinge is clearly visible.
 
Top