SSU Development Thread (2.0 to 3.0)

[DaveS]

The dimension issue, is over an overall length number. My source as posted above is 1458.24, DaveS's mesh has it as 1428.95. By scaling the original mesh down, all measurements were affected. Just moving the star trackers to different positions would cause distortions.

I'm not sure why the length isn't adding up. When I made the new orbiter, I used the real coordinates for everything.
When Donamy told me about the length discrepancy I immediately checked the mesh to make sure I hadn't screwed it up somewhere along the way but everything checked out again and again.

Just for the sake of discussion here's what I'm using:
The forward-most point of the orbiter nosecap: Xo236
The aft-most point of the orbiter vertical stabilizer: Xo1694

Using those two numbers in a simple subtraction (1694-236) gives 1458. Convert that to metric, 36.45. And checking again now, it is 36.49.

 

[Donamy]

My metric converter says 36.49= 1436.6

37.04= 1458.246

It's not the size of the GB, but how you use it.

 

[GLS]

Sorry to butt in, but if those conversions are from inches to meters, then I have to agree with Donamy (1in = 2.54cm). DaveS seems to be using 1in = 2.5cm.
Anyway just to say that I added funcionality to the SYS SUMM key, to bring SPEC 18/19 up without keying "SPEC 18 PRO".
I think I can squeeze another week of "moderate pace work" in SSU, so I was thinking of starting the MEDS ADI/8-ball/whatever it's called (forgot the name now). Even if I just manged to do the tapes, it would be helpfull because it would allow the used to have access to the altitude and speed in the "shuttle units", along with G-force and stuff. But the CRTMFD is kinda messy (specially the menu part), so I need some pointers as to where/how I'm going to do it.

 

[SiameseCat]

I'm not sure if this is the right time, but at some point I'd like to move all the painting code from CRT MFD to the MDU class. CRT MFD would essentially be a wrapper which passes button presses and redraw requests from Orbitersim to the MDU.

 

[Urwumpe]

I'm not sure if this is the right time, but at some point I'd like to move all the painting code from CRT MFD to the MDU class. CRT MFD would essentially be a wrapper which passes button presses and redraw requests from Orbitersim to the MDU.

I agree to this. I would maybe limit CRT MFD to only paint graphical primitives... Or even completely dispose CRT MFD and orbiters MFD framework and implementing the displays like in the real Shuttle without compromises to Orbiters MFD standards.

There are quite many possibilities to optimize things, if we could decide for one way: Do the low-level painting completely on the MFD or dispose the MFD.

 

[DaveS]

I agree to this. I would maybe limit CRT MFD to only paint graphical primitives... Or even completely dispose CRT MFD and orbiters MFD framework and implementing the displays like in the real Shuttle without compromises to Orbiters MFD standards.

There are quite many possibilities to optimize things, if we could decide for one way: Do the low-level painting completely on the MFD or dispose the MFD.

I vote for ditching the Orbiter MFDs entirely just so we can get some decent resolution on the MDUs. What are using now? 256x256?

 

[Urwumpe]

I vote for ditching the Orbiter MFDs entirely just so we can get some decent resolution on the MDUs. What are using now? 256x256?

Exactly. But I think we already cheated to increase this to 512x 512. The real displays are 1024 x 1024, if we do the rendering inside SSU, we could easily paint all displays on a single large texture and stay in GPU memory, without having to take the PCI-X bottleneck.

 

[GLS]

I vote for ditching the Orbiter MFDs entirely just so we can get some decent resolution on the MDUs. What are using now? 256x256?

That would be good as it's kinda hard to read the displays without zooming big time. And it would allow the use of the right-most button for the MEDS menu.

 

[DaveS]

Exactly. But I think we already cheated to increase this to 512x 512. The real displays are 1024 x 1024, if we do the rendering inside SSU, we could easily paint all displays on a single large texture and stay in GPU memory, without having to take the PCI-X bottleneck.

Thanks. Yes, I seem to remember something about this. And that 1024x1024 resolution should be something any decent hardware can accomplish today as the shuttle MDUs are mid-1990's tech.

---------- Post added at 12:12 AM ---------- Previous post was at 12:10 AM ----------

That would be good as it's kinda hard to read the displays without zooming big time. And it would allow the use of the right-most button for the MEDS menu.

Yes, I find myself using 20° FoV when entering data just to be able to read the text.

 

[Urwumpe]

Decent hardware, yes. But no reason to be wasteful there. We have GPU, which could do the low-level painting for all 10 MDUs in the idle time of the other SSU computations. We should use it.

As soon as we do the painting on CPU memory and have to transfer it back through the PCI Express interface, we loose a lot of performance, that is what already harms us for the R2 panel, since we paint the talkbacks in CPU memory on a very large texture.

 

[SiameseCat]

I also vote for ditching the Orbitersim MFDs, as long as we have a full implementation of the ADI displays (including the 8-ball). I think we need either Surface MFD or the MEDS equivalent.

 

[Urwumpe]

I also vote for ditching the Orbitersim MFDs, as long as we have a full implementation of the ADI displays (including the 8-ball). I think we need either Surface MFD or the MEDS equivalent.

Well, if we render on the GPUs, we might be capable of doing them really easily... If not everybody wants to install the Direct X SDK for the rendering, we could make the important rendering functions in a separate DLL and distribute a stable binary for compiling the Orbiter.

 

[DaveS]

I also vote for ditching the Orbitersim MFDs, as long as we have a full implementation of the ADI displays (including the 8-ball). I think we need either Surface MFD or the MEDS equivalent.

Surface MFD doesn't include the rate or target attitude needles that the ADI has.

 

[GLS]

So, with this I think we have a long term goal for SSU v5!!! (with v3 being this version released +/-ASAP, and v4 the mission config stuff)
I'm trying to change the current menu to find a place for the Primary Flight Displays. I'll try to get it started, but probably won't finish it in a week. So IMO the plan should be as follows: if me, or somebody, get the PFD (at least one) in a reasonable state it should go in the next release, if not just comment it out and it goes in the next release.
Parallel to this, we would start the migration to the current displays to the MDUs and then part way with the orbiter MFDs. Good plan?

 

[GLS]

So I did a cleanup and updated the menu in CRTMFD... was kinda messy in there, still works now so it looks like I didn't break anything.
Started doing the Ascent/Entry PFD in the MDU because I'm not seing a way of putting that in the IDP, were it belongs right? Just wanted to check exactly were it should go, because this is going to take alot of "GDI work" and it would be a shame to have to redo it.

 

[SiameseCat]

So I did a cleanup and updated the menu in CRTMFD... was kinda messy in there, still works now so it looks like I didn't break anything.
Started doing the Ascent/Entry PFD in the MDU because I'm not seing a way of putting that in the IDP, were it belongs right? Just wanted to check exactly were it should go, because this is going to take alot of "GDI work" and it would be a shame to have to redo it.

I think that's correct. The MEDS displays are drawn by the MDU, not the IDP. The IDP draws the GPC displays. (Hopefully someone will correct me if I'm wrong)

 

[Urwumpe]

I think that's correct. The MEDS displays are drawn by the MDU, not the IDP. The IDP draws the GPC displays. (Hopefully someone will correct me if I'm wrong)

Thats correct. the IDP is pretty much just a 386SX computer which translates the old DEU drawing instructions for a CRT into drawing instructions for a MDU.

OK, some more functions it also has. But not much more. :lol:

 

[GLS]

So with that cleared, there's another "problem": how to access the data in the GPC software from the MDUs? It's possible of course, but it will mean start including the headers of the software classes to have access to them... is there any ETA on the busses implementation? With that sharing data would probably be cleaner, and when we move the OMS/MPS, APU/HYD and SPI displays to the MDUs can get rid of some functions in Atlantis.

 

[DaveS]

Orbiter mesh update: It is nearing completion. Both the X and Z axes are done leaving only the Y axis to be worked on. Once that is done, final texture re-alignments will be done and then the code updates will begin.

 

[GLS]

Current state of A/E PFD:

View image in gallery​

It's far from being done but it's a start. I have a few more days so I'm sure I can finish the tapes and hopefully some more things. For the tapes I was going to use a system of having in memory only a part of the tape, and redraw it only when we needed a new part. It worked but it just got too complex, so now I just draw the whole thing at the start. It uses more memory, but it's nowhere near as much as I was fearing (125x2500 dc).
So, as you can see the display suffers from aliasing... and a good way to "lower the frequencies" and getting it all smooth is to draw big and then resize (carefully). And so I had this idea to draw it at 512x512 or 1024x1024, then resize to 256x256 to get it smooth, and when we go our own "MFDs" we already have a big display ready to use. For that we have to make some decisions like (1) what is going to be the size of the displays and (2) will we use this anti-aliasing method there? (In my experience x2 the size already works well, with x4 it gets a little better and after that it's just too big... I vote for x2)

---------- Post added at 01:51 PM ---------- Previous post was at 03:05 AM ----------

So I just tried 512x512 and it doesn't look good after the resize... the text is too thin (even bold text) and when the resize average is done it just "dissolves" in the black background becoming gray...
I will have to stick with the regular size for now.