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

[Wolf]

I used GIMP (with a dds plugin from somewhere).

I have edited my post above. I think I found the reason. I never used D3D/DDS after sometimes I had PS CTD by selecting it. DDS always works.

 

[GLS]

I am afraid the yellow labels on the SSME are not usable. I thought they needed resizing only but then realized the label is inverted on engine n.2 (is there a way to fix this?)

They should all be copies of ME-1, except for a rotation... I don't know what DaveS did.

 

[DaveS]

Latest mesh results:


mid fuselage issue

View attachment 15932


Is this sharp seam correct?

View attachment 15933

I am afraid the yellow labels on the SSME are not usable. I thought they needed resizing only but then realized the label is inverted on engine n.2 (is there a way to fix this?)

All these issues should now have been corrected in the latest revision. Not sure what happened to the midbody sidewalls. Everything looked good in AC3D but once the mesh was exported to msh it all got mucked up. I had to remap the midbody sidewalls for the issue to go away.

 

[Wolf]

About the OMS pods, the HRSI "ring" does not align with the rest of the tiles


SSU




Real orbiter



Also the line between the HRSI and the rest of the pod in the real shuttle is curved, in SSU is straight

I guess this comes from the stock Atlantis and the Fleet mesh/textures since they have the same issue. Is that fixable?

 

[DaveS]

About the OMS pods, the HRSI "ring" does not align with the rest of the tiles


SSU

View attachment 15934


Real orbiter

View attachment 15935

Also the line between the HRSI and the rest of the pod in the real shuttle is curved, in SSU is straight

I guess this comes from the stock Atlantis and the Fleet mesh/textures since they have the same issue. Is that fixable?

Are you sure that your tile pattern is correct? Things look good with the modern set up.

---------- Post added at 03:22 PM ---------- Previous post was at 03:18 PM ----------

Here's a link to a folder with a number of images and photos of the OMS pod: https://www.dropbox.com/sh/6msaqok62zvet5m/AADd6xt6I0qdYbxqf3eHtap9a?dl=0

 

[Wolf]

Are you sure that your tile pattern is correct? Things look good with the modern set up.

---------- Post added at 03:22 PM ---------- Previous post was at 03:18 PM ----------

Here's a link to a folder with a number of images and photos of the OMS pod: https://www.dropbox.com/sh/6msaqok62zvet5m/AADd6xt6I0qdYbxqf3eHtap9a?dl=0

I ve corrected the tiles pattern since it was wrong (wrong number of black HRSI tiles) but the boundries are exactly the same. If you check the stock SSU textures you ll see the same thing: the outer ring does not align with the other tiles hence there is a dent in the pattern as my screenshot show. Also the edge between the tiles and the AFRSI should follow a curved line, in SSU it is a straight line.

Ok I had not loaded today's update... now the HRSI look much better and the ring is aligned. As a side effect I have now some extra issues with the seams of the Columbia/Challenger PODs but I'll wait until you are done with the orbiter mesh and see what is the final outcome
One thing that popped up in the mid body sidewall area is:

1) US flag and labels are now vertically stretched (check the US flag now patially covered by the PB vebt door and the U.S. and NAsa meatball look stretched)

2) the mid mody sidewall where the mesh issue was has now a sort of shadow/lighted separation (you can see them both when the area is lighted or in the dark)

 

[DaveS]

I ve corrected the tiles pattern since it was wrong (wrong number of black HRSI tiles) but the boundries are exactly the same. If you check the stock SSU textures you ll see the same thing: the outer ring does not align with the other tiles hence there is a dent in the pattern as my screenshot show. Also the edge between the tiles and the AFRSI should follow a curved line, in SSU it is a straight line.

Ok I had not loaded today's update... now the HRSI look much better and the ring is aligned. As a side effect I have now some extra issues with the seams of the Columbia/Challenger PODs but I'll wait until you are done with the orbiter mesh and see what is the final outcome
One thing that popped up in the mid body sidewall area is:

1) US flag and labels are now vertically stretched (check the US flag now patially covered by the PB vebt door and the U.S. and NAsa meatball look stretched)

2) the mid mody sidewall where the mesh issue was has now a sort of shadow/lighted separation (you can see them both when the area is lighted or in the dark)


View attachment 15936

View attachment 15937

The midbody issues should be fixed now. I checked the meatballs and they're a perfect circle.

 

[Wolf]

The midbody issues should be fixed now. I checked the meatballs and they're a perfect circle.

If you look at the US flag on the port side you ll notice the top left corner is overlaped by the PB vent door. The flag used to sit right below the door so either the logos are now stretched vertically or the door has shifted downward.
I have also the impression the UNITED STATES label is now stretched vertically..
Does it look ok to you?

 

[DaveS]

If you look at the US flag on the port side you ll notice the top left corner is overlaped by the PB vent door. The flag used to sit right below the door so either the logos are now stretched vertically or the door has shifted downward.
I have also the impression the UNITED STATES label is now stretched vertically..
Does it look ok to you?

Have you updated to revision 2873? The vent doors have been moved to their real locations thanks to a document I found on NTRS.


This is the graphic from that document: https://www.dropbox.com/s/f7yc8k2r3umkr18/IOA_Mech_Assessment_vent_doors.jpg?dl=0

 

[Wolf]

Have you updated to revision 2873? The vent doors have been moved to their real locations thanks to a document I found on NTRS.


This is the graphic from that document: https://www.dropbox.com/s/f7yc8k2r3umkr18/IOA_Mech_Assessment_vent_doors.jpg?dl=0

Yes, 2873. I did not know you moved the vent doors

 

[GLS]

I'm (hopefully) finishing the HUD runway outline: I re-did the math, put it in a nice runway-to-HUD conversion function, and it looks good... until the points are behind the vehicle... :facepalm:
The trouble is when a point is vertically behind the vehicle, the math should (and does) place it vertically in line with the boresight, but in reality that is not correct. When the runway threshold points are in that situation (a little after the vehicle crosses them, and because of the nose-up attitude, eventually they will be directly behind the vehicle), they are placed next to the boresight instead of being placed somewhere below... I can't figure out where that "somewhere below" is... :uhh:

 

[Donamy]

Yes, 2873. I did not know you moved the vent doors

Could you move the flag and squash it on the texture, so it looks correct. I know it a hack way to do it, but it's been known to work.

 

[DaveS]

Could you move the flag and squash it on the texture, so it looks correct. I know it a hack way to do it, but it's been known to work.

No need as the problem was that the vent doors were positioned too low to match the positions listed in chart linked above. With the vent doors repositioned, things look better: https://www.dropbox.com/s/6hge9ks0lh5mikl/SSU_midbody_vent_doors.jpg?dl=0

 

[Donamy]

Those OMS pods look good. But the tail needs a lot of work.

 

[GLS]

I'm (hopefully) finishing the HUD runway outline: I re-did the math, put it in a nice runway-to-HUD conversion function, and it looks good... until the points are behind the vehicle... :facepalm:
The trouble is when a point is vertically behind the vehicle, the math should (and does) place it vertically in line with the boresight, but in reality that is not correct. When the runway threshold points are in that situation (a little after the vehicle crosses them, and because of the nose-up attitude, eventually they will be directly behind the vehicle), they are placed next to the boresight instead of being placed somewhere below... I can't figure out where that "somewhere below" is... :uhh:

Well, basically gave up on this for now. I think my math is missing something, for points far away the error is negligible, but grows as the point gets closer to the HUD. Some sort of plane clipping is needed and/or a change to my "pretty" runway2HUD conversion function. :shrug:
On the positive side, I made the body flap functional. Not sure the aero part is doing much, but it now moves and the manual control switches work. (BTW: the mesh for panel C3 is SCARY... :uhh The position isn't saved and it currently defaults to a full-up position, so maybe further work is needed in the short term.

Anyway, I'll now hop over to the trunk to see how things are going.

---------- Post added at 11:05 PM ---------- Previous post was at 07:37 PM ----------

Opened a few more tickets regarding the OV mesh... this one is really bad. :thumbsdown:
I can't open the mesh in blender, and in Orbiter deploying the gear shows that one of the main gear wheels animates with the opposite door, and the nose gear isn't there at all. :facepalm:

---------- Post added 06-26-18 at 04:21 PM ---------- Previous post was 06-25-18 at 11:05 PM ----------

Cleaned up the scary panel mesh group of panel C3 (85% reduction in vertex count and 57% in triangles in that group).

---------- Post added at 08:18 PM ---------- Previous post was at 04:21 PM ----------

Added a few tickets to track all the recent mesh issues.

---------- Post added 06-27-18 at 12:05 AM ---------- Previous post was 06-26-18 at 08:18 PM ----------

Any good literature about the internals of the MDMs? I'll need to add them to get the Radar Altimeter connected and feeding the HUD, as the lack of granularity on the "normal" altitude is very noticeable at low altitudes. :shrug:

---------- Post added at 11:16 PM ---------- Previous post was at 12:05 AM ----------

While coding the power switches for the MDMs I noticed that for pretty much every switch we call SetInitialAnimState( 0.5f ), to define the switch mesh group position for the animation. Given that we have TONS of switches and they all (or 99.9%) are in that position, I think we could remove all those calls and by setting the variable to 0.5 by default (it's 0.0 now). It would save a few milliseconds during loading, and it would be less code, etc... :shrug:

---------- Post added 06-28-18 at 07:40 PM ---------- Previous post was 06-27-18 at 11:16 PM ----------

Is there a list of which signals go into which IOMs?

 

[Urwumpe]

Is there a list of which signals go into which IOMs?

What kind of signal do you need?

 

[GLS]

What kind of signal do you need?

The signals that connect to the IOMs (switches, sensors, etc), so the GPCs can go "IOM 6, ch 0, bit 5" is the CDR RDR ALTM switch. It's not really urgent, as for now I'll probably only use those RDR ALTM switches and the RA (which uses its own card), but it would be a nice list to have instead of connecting things at random.

 

[Urwumpe]

The signals that connect to the IOMs (switches, sensors, etc), so the GPCs can go "IOM 6, ch 0, bit 5" is the CDR RDR ALTM switch. It's not really urgent, as for now I'll probably only use those RDR ALTM switches and the RA (which uses its own card), but it would be a nice list to have instead of connecting things at random.

There are different kinds of IO modules - the Radar Altimeter uses a serial I/O kind of IO Module AFAIR.


Such a switch would likely be a discrete input kind of IO Module, which has three 16 bit output registers, each bit in the register representing the state of one input line.



TACAN and MLS use one special IO module.

 

[GLS]

There are different kinds of IO modules - the Radar Altimeter uses a serial I/O kind of IO Module AFAIR.


Such a switch would likely be a discrete input kind of IO Module, which has three 16 bit output registers, each bit in the register representing the state of one input line.



TACAN and MLS use one special IO module.

Yes, I've refreshed my knowledge on the MDMs. :thumbup:
What I don't know is to which bit of which channel is whatever switch connected on. It's not super-critical as we know there are 48 such signals in a DIL/DIH/DOL/DOH, and we know how many of those cards are there in each MDM, so we won't "over-connect" things. :shrug:

 

[Urwumpe]

Yes, I've refreshed my knowledge on the MDMs. :thumbup:
What I don't know is to which bit of which channel is whatever switch connected on. It's not super-critical as we know there are 48 such signals in a DIL/DIH/DOL/DOH, and we know how many of those cards are there in each MDM, so we won't "over-connect" things. :shrug:

And every switch actually has three electrical switches inside, providing three signals to their MDM.