SSU Development Thread (3.0 to 4.0)

[DaveS]

Looks fine to me. :thumbup:
BTW, could you check if the PLB handrails are in the correct position? I've been looking from the aft windows and it doesn't really match the in-flight photos.

Could you check the handrails now? I think they're good enough now.

 

[Urwumpe]

It seems a little to wrinkly especially the EE. Maybe some remapping would work better. IMO

A bit of remapping, sure, but practically, too wrinkly does not describe it well:

The original is pretty wrinkly there.

But then, the blankets are also more visible from up close then they currently are - and they are not everywhere, especially at the EE, you have gaps that we currently lack.

 

[DaveS]

A bit of remapping, sure, but practically, too wrinkly does not describe it well:

The original is pretty wrinkly there.

But then, the blankets are also more visible from up close then they currently are - and they are not everywhere, especially at the EE, you have gaps that we currently lack.

You can't really use pre-launch photos of stuff like blankets due to the effect of escaping air from the PLB through the vents during ascent. The escaping air causes a bit of blanket wrinkling.

 

[GLS]

Could you check the handrails now? I think they're good enough now.

Looks like it, thanks! It's hard to get a good picture of them all to compare, but from the aft window it seems better.

---------- Post added at 02:48 AM ---------- Previous post was at 12:21 AM ----------

After fixing a ticket could it be left open, so the person who opened it can check if the issue is really fixed? (see https://sourceforge.net/p/shuttleultra/tickets/141/) This would prevent "premature-ticket-closing sindrome". :rofl:

 

[DaveS]

Is any one but me suffering a 40-50% reduction in FPS when using the KSC15 final approach scenario in the beta version? I have done some digging and it seems connected to the MFDs. Once I have turned off all the MDUs, my normal smooth FPS returns. And I only experience this with SSU, all the other vessels are smooth. And it only occurs during landing when the terrain rendering is at maximum. This drop in FPS makes landing very difficult as there's a noticeable lag between control inputs.

Edit:
I just wanted to add that MFD texture resolution doesn't contribute to the low FPS. I have tried with both 512x512 and 256x256 with no change in FPS. The only Orbiter visual setting that had any effect was changing surface elevation rendering from cubic interpolation to linear interpolation. This bought back 20 FPS. A bit smoother, but still laggy in control inputs.

 

[Urwumpe]

Is any one but me suffering a 40-50% reduction in FPS when using the KSC15 final approach scenario in the beta version? I have done some digging and it seems connected to the MFDs. Once I have turned off all the MDUs, my normal smooth FPS returns. And I only experience this with SSU, all the other vessels are smooth. And it only occurs during landing when the terrain rendering is at maximum. This drop in FPS makes landing very difficult as there's a noticeable lag between control inputs.

Makes sense, since MFD rendering is VERY slow, depending on refresh rates. It had been worse initially.

 

[DaveS]

Makes sense, since MFD rendering is VERY slow, depending on refresh rates. It had been worse initially.

The issue is that I'm not experiencing the FPS drop with the same scenario with the stable 2010 P1 version with the same visual settings (save for the ones introduced in the beta).

 

[Urwumpe]

The issue is that I'm not experiencing the FPS drop with the same scenario with the stable 2010 P1 version with the same visual settings (save for the ones introduced in the beta).

I would not exclude that it could be related. Remember that the beta has a much stronger demand on the GPU.

 

[DaveS]

I would not exclude that it could be related. Remember that the beta has a much stronger demand on the GPU.

Why would would the FPS go up only when the MFDs are turned off? Turn on the MFDs and the FPS drop. This is during the same run, so the terrain and everything is still the same. This tells me that there's something going with the MFDs, not the beta itself.

 

[GLS]

Nothing has been changed other than removing the 9 (sometimes) 10 MDU limit. As the aft MDUs are off in that scenario I don't think that is the source of any major drop in fps. Maybe it's something internal to Orbiter?
The A/E PFD is (by far) the slowest one to draw... it just has too many things, and it isn't finished yet! It might be possible to gain some performance by drawing the tapes on the fly... but getting all the details right might be an issue, and I'm not sure it would be faster anyway. The MCDS cockpit would be so much easier to do.
I'm not sure the other MEDS displays are capable of being draw faster. Even the "static" parts (the boxes around the numbers and so) are not that static, as if the data is not available in the ADC, it is draw in red so it pretty much has to be drawn in realtime.

 

[DaveS]

Nothing has been changed other than removing the 9 (sometimes) 10 MDU limit. As the aft MDUs are off in that scenario I don't think that is the source of any major drop in fps. Maybe it's something internal to Orbiter?
The A/E PFD is (by far) the slowest one to draw... it just has too many things, and it isn't finished yet! It might be possible to gain some performance by drawing the tapes on the fly... but getting all the details right might be an issue, and I'm not sure it would be faster anyway. The MCDS cockpit would be so much easier to do.
I'm not sure the other MEDS displays are capable of being draw faster. Even the "static" parts (the boxes around the numbers and so) are not that static, as if the data is not available in the ADC, it is draw in red so it pretty much has to be drawn in realtime.

What is the refresh rate of the MDUs anyway?

 

[Urwumpe]

What is the refresh rate of the MDUs anyway?

What you say in the Orbiter settings for all MFDs. We can only specify a factor for reducing the refresh rates of distant MFDs.

 

[DaveS]

What you say in the Orbiter settings for all MFDs. We can only specify a factor for reducing the refresh rates of distant MFDs.

I was referring to the real MDUs, so a proper refresh rate could be set.

 

[GLS]

What you say in the Orbiter settings for all MFDs. We can only specify a factor for reducing the refresh rates of distant MFDs.

Yeah, we could draw them only in 1/4 or whatever of the frames, but we still need to show something each frame, so we would have to save the current display and copy it to the screen in those "no-update" frames... not sure how much faster that would end up being.

---------- Post added at 04:42 PM ---------- Previous post was at 04:40 PM ----------

I was referring to the real MDUs, so a proper refresh rate could be set.

I'd say it fast enough that we can't get there. :facepalm:

 

[DaveS]

Yeah, we could draw them only in 1/4 or whatever of the frames, but we still need to show something each frame, so we would have to save the current display and copy it to the screen in those "no-update" frames... not sure how much faster that would end up being.

Another reason why we should go to our own MFD render system?

 

[GLS]

Another reason why we should go to our own MFD render system?

Hmm, that might save us that "back buffer"...

 

[Urwumpe]

I was referring to the real MDUs, so a proper refresh rate could be set.

The MDUs are hard to tell, but I would assume much higher than we can do easily.

The DPS updates its screens only twice per second, a limitation of the AP-101B.

 

[DaveS]

This is from a PM between Poscik and me regarding a custom MFD rendering system for SSU:

Hey.

Long time no speak. The reason why I'm contacting you now is that I seem to remember that you were working a replacement for the MFD rendering for SSU. This is something that the rest of us (Urwumpe, GLS, me and SiameseCat) have been talking about for a while now.

It has now taken on quite a bit of seriousness due to a severe reduction in frame rates (40-50%) in the beta version of the next edition of Orbiter. And it seems related to how Orbiter renders MFDs.

We have come up against several limitations of Orbiter MFD rendering which is hampering us. If you could detail your rendering system, I think something could be implemented.

Hi! Yeah, I remember I had something in mind What I wanted to do is to use pure Direct3D to render MFD to texture and then paint it on VC Panel. Here some pros and cons:

Disadvantages:

• Dependence on DirectX SDK/OpenGL or other rendering sdk(maybe SDL?)
• Device acquiration - basically, graphics client is owner of the graphics device. So when we instantiate our own device, GPU drivers have to switch between instances when rendering particular stuff. And this costs time and potential bugs/memory leaks, as device will lost it's state.
• Sharing texture between devices - one device have to write to texture, second one have to read this and paint. This have to be synchronized. As far as I know, graphics client have to create texture resource for every MFD in order to render it later.

Advantages:

• pure access to Direct2D/Direct3D
• Matrix transformations of objects - f.e. ADI ball can be described as simple textured 3D Mesh, then rotated properly with Matrix and then projected on 2D Plane. I think this is much simpler and faster than manually drawing and transforming 2D shapes in GDI.

This of course is just random idea, but IMO direct access to rendering device and it's resources is key here. Access either via OrbiterAPI (and AFAIK there is no such functionality yet) or via separate instance of device.



I'll try to appear on IRC this evening, se we could discuss it further. Also feel free to paste my message in SSU thread.



I rencently gained some DirectX rendering skills, so I will do some research what can be done here.

 

[GLS]

I like the ADI part... we could then do the yaw without breaking a sweat, and that would allow the ATT REF PB to be used (after some kind of IMU is implemented). The HSI would also be easier. I know nothing about the D2D and/or D3D, except they are faster than GDI, but how hard can it be to draw lines and numbers after the initial setup is done? :shrug:

 

[Urwumpe]

I like the ADI part... we could then do the yaw without breaking a sweat, and that would allow the ATT REF PB to be used (after some kind of IMU is implemented). The HSI would also be easier. I know nothing about the D2D and/or D3D, except they are faster than GDI, but how hard can it be to draw lines and numbers after the initial setup is done? :shrug:

Not too hard, but still, you should remember that we also produce a dependency that way directly to DirectX. Not good for portability and compatibility with rendering clients.