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

[GLS]

Part of the new displays were just committed!
The ENTRY TRAJs, VET SITs and both PFD are still to be worked on, but the rest of the displays now has (almost) sub-atomic accuracy :rofl:.
The "SSU A" font must be installed (don't bother using it for other texts as I only did the letters that were needed, so it's missing some).
MFDs at 512x512 is now mandatory. I'm still up against 60fps in D3D9, and in MOGE I get over 20 fps with 4 MDUs on... everything on and it becomes a slideshow... lowering the refresh rate is always an option :shrug:.
A "SSU B" will soon arrive to be used in the PFDs and the titles of the OMS/MPS and APU/HYD displays, and the entry displays updated.

 

[DaveS]

The new displays looks great! The DPS text is no longer a blurry awful mess. Everything is nice and readable.

 

[GLS]

I need a bit of "beta testing".
A new version of the shuttle icons for the entry displays has just been committed, but they seem a bit thin to me. I'd like to know if that is really the case, so I can make them "fatter".
Also, I made some changes to the scratch line to make it look and work more like the real thing. Please play with it to be sure it works. There's still error checking, so hitting the keyboard like a monkey will cause problems :lol:.

 

[DaveS]

I need a bit of "beta testing".
A new version of the shuttle icons for the entry displays has just been committed, but they seem a bit thin to me. I'd like to know if that is really the case, so I can make them "fatter".
Also, I made some changes to the scratch line to make it look and work more like the real thing. Please play with it to be sure it works. There's still error checking, so hitting the keyboard like a monkey will cause problems :lol:.

It's really needs to be fatter and bigger. I could barely see it.

 

[GLS]

It's really needs to be fatter and bigger. I could barely see it.

Fatter I agree, but I'm not so sure about bigger... I'll have to make some measurements.

---------- Post added at 05:50 PM ---------- Previous post was at 03:53 PM ----------

Ok, I changed the way the icon points are stored, so it should be easier to change them. They are thicker now, and the size was already pretty much correct. They look better, except for when a rotation is applied in the VERT SITs :facepalm:. The solution for this might be having non-integral coordinates for the (non-rotated) points, such that they are a bit "closer" to each other, and when a rotation is applied they don't diverge as much.

 

[GLS]

Just committed the updated Orbit PFD. There are now 2 SSU fonts that need to be installed for things to look as intended.
As of now, all 3 subsystem displays are done, of the DPS displays only the ENTRY TRAJs and HORIZ SIT still need work, the GDI Orbit PFD is done (still no yaw... not sure it will ever be done), the Sketchpad version is missing 3 arcs (there's not arc function) and a final version of the ADI, and the big one (A/E PFD) is still at 0%.

About the ADI, I did a new texture and "squeezed" a scaled-down version of it into the current texture, so it looks a bit better and complete but still far from ideal. The mesh has not enough points for a smooth look and the texture mapping has some issues.
I'm wondering if creating the mesh "manually" (in matlab or something) isn't a better way to deal with the mapping. Another problem is how to deal with the pole areas that squeeze the texture, changing the shape of things in those areas. I think we'll have to distort the texture somehow... anyone with experience in this?

 

[GLS]

Any news on the new DPS model? We'll need some changes to what we currently have to deal with the 3D terrain on landing, and it doesn't make sense to use more "duct-tape" on the DPS. We should "centralize" the access to altitude, speed, attitude, etc data by having sw in the GPCs that collects this data from subsystems (IMU, ADP, AA, RA, etc, which collected it from Orbiter), processes it, and then makes it available to who wants it (except somethings that need real data for physics purposes, and thus should go directly to Orbiter). Right now, the immediate need is correct altitude data source (Nav, then ADP, then RA) to allow landing way above sea level.

 

[Urwumpe]

Any news on the new DPS model?

Will take some time, I was completely written off ill last week after finally passing my exams. And yes, having a "GNC compool"-like memory structure is exactly why I want a new DPS model.

But I need some more time to get up speed again. I have some Corn Ranch developments first in the FIFO, sometime this summer, I wanted to try something nerdy and implement a JIT compiler embedded in an Orbiter add-on - but since the target add-on is currently broken in Orbiter 2016, its likely I will switch to SSU earlier.

 

[GLS]

Is there any way to decrease the light level in the vc in D3D9? It gets so bright that I reach for my sunglasses...

 

[DaveS]

Is there any way to decrease the light level in the vc in D3D9? It gets so bright that I reach for my sunglasses...

Are you talking about the HDR effects by Solarliner? If so, I don't think you can as it is alpha-level stuff. Regular D3D9Client for me looks OK, not much different than 2010.

 

[GLS]

Are you talking about the HDR effects by Solarliner? If so, I don't think you can as it is alpha-level stuff. Regular D3D9Client for me looks OK, not much different than 2010.

I don't think so... I just installed D3D9 and I think I decreased the AA level to ease the load, nothing more. It's been like this since I can remember, way way brighter than in Orbiter 2010.

EDIT: here's a wide view at the start of the EDW TAEM scenario. The sun is +/- behind the camera, but still I think it's just too bright.

 

[DaveS]

I don't think so... I just installed D3D9 and I think I decreased the AA level to ease the load, nothing more. It's been like this since I can remember, way way brighter than in Orbiter 2010.

EDIT: here's a wide view at the start of the EDW TAEM scenario. The sun is +/- behind the camera, but still I think it's just too bright.

That's the HDR effects currently being worked on by Solarliner. For now, avoid any builds by Solarliner as his modifications are not part of the official D3D9Client yet. Try this one by jarmonik: http://www.orbiter-forum.com/showthread.php?p=537952&postcount=3992

 

[GLS]

That's the HDR effects currently being worked on by Solarliner. For now, avoid any builds by Solarliner as his modifications are not part of the official D3D9Client yet. Try this one by jarmonik: http://www.orbiter-forum.com/showthread.php?p=537952&postcount=3992

Like I said, I don't think it's the HDR stuff as it has been like this for 2 or 3 months, and that is the D3D9 build I'm using (it shows version "n/a" during loading).

 

[DaveS]

I checked out the EDW 22 TAEM scenario and now I see it too. I think it's related to lighting model changes that was done a while back. Until the jarmonik updates the D3D9Client documentation, I have no idea on how to fix it.

 

[jarmonik]

I don't think so... I just installed D3D9 and I think I decreased the AA level to ease the load, nothing more. It's been like this since I can remember, way way brighter than in Orbiter 2010.

EDIT: here's a wide view at the start of the EDW TAEM scenario. The sun is +/- behind the camera, but still I think it's just too bright.

Thanks, I have totally forgotten that one. I guess we need to tune down the sunlight intensity while rendering the VC. It went broken during the PBR implementation.

 

[DaveS]

Thanks, I have totally forgotten that one. I guess we need to tune down the sunlight intensity while rendering the VC. It went broken during the PBR implementation.

Well, technically we should get rid of the emissive material settings and implement the actual cockpit lighting. It is really dark in the orbiter if the lights are off. SOP is to darken the lights after the de-orbit burn if it is a night-landing. Also, this is why each crew member wears glow-sticks on their ACES.

---------- Post added at 07:34 PM ---------- Previous post was at 07:30 PM ----------

This is from entry of STS-115/12A, only a slight glow from the overhead incandescent lights:

 

[Urwumpe]

Also, this is why each crew member wears glow-sticks on their ACES

We have no crew members :dry:

 

[GLS]

Finished the A/E PFD conversion (finally)! Here's a VC panorama from MOGE:

I did some small corrections to the tapes, of which the velocity tape deserves some words. Above 4Kfps its all the same (inertial or relative velocity (now corrected for airspeed)), but below 4Kfps (or Mach 4) the tape shows Kfps even though it says M next to the numbers. AFAIK it only showed real Mach numbers when data from the ADTAs was available, and on all other situations it showed Kfps. For now the KEAS display shows airspeed (with wind) at all times. So with all this the velocity tape will not read 2.5M at TAEM I/F for example. I could "duct-tape" a solution, but like I said before it's better to get the GPCs squared away and have the proper data flow from the right places.

I did some resource management and made all the pens and brushes static inside the MDU class, so it's now all shared between the 11 instances. Did the same with the bitmaps for the tapes (which are big), and it seems to be loading a tiny bit faster now. I also added code to deallocate all that stuff... but it seems there are some "leaks" somewhere, as on a subsequent run the GDI usage is higher.
Also, the OV texture is now deleted on exit, so D3D9 won't complain in its log anymore.

 

[Hlynkacg]

Is that FDAI MFD Functional and if so would you consider releasing a generic version that works with ordinary orbiter vessels?

 

[GLS]

Is that FDAI MFD Functional and if so would you consider releasing a generic version that works with ordinary orbiter vessels?

It's all drawn with GDI (Sketchpad doesn't have Arcs, so it would be a bit harder to do there), and it only does pitch (-90º to +90º) and roll (full 360º). Right now yaw would be hard to do... but with some (fundamental) changes I think it's possible to draw a full ball in any orientation. It's somewhat expensive in fps at the moment due to the nature of GDI. I don't think it does more than the SurfaceMFD, so no point in making this separate.

In D3D9, there are some extra goodies, and instead of drawing we can render a mesh. So we render a ball and control its orientation, and this allows us much "easier access" to the full range of orientations. Now we just need an IMU to drive the ball in all its glory. :lol: This would actually be something worth releasing, once it matures a bit... but it would only work in D3D9.