SSU Development Thread (3.0 to 4.0)

[GLS]

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]

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]

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 ?

 

[DaveS]

Does the same occur with Orbiter's stock MFDs ?

No, not even Surface MFD or Map MFD.

 

[jarmonik]

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]

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]

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]

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]

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.

 

[Urwumpe]

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]

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]

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]

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]

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:

 

[GLS]

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:

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]

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]

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]

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:

 

[DaveS]

To me it looks like the rotation axis is what I have now. This is a really good close up from STS-26:

And this one from STS-41:

 

[GLS]

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.