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

[GLS]

I still have to figure out a way to handle the first step, but here's a better view of the LOX part:

(don't mind the mess around)

 

[GLS]

DaveS, can you tell me which bellows (G or G') are the latest version? One version, i.e. same number and order of vertexes, is much easier to handle (and maybe faster). The G' bellows are all "good" and I have it all working very well. They look chaper than the G bellows (78 vs 152) but still look good.
BTW: IMO we don't need the circular ends (it should all connect now), so we could decrease the bellows/pipes vertex/triangle count quit a bit.

Also, when updating the mesh, the coordinates in the CISS.h file should be updated as well... they were several cms off... (I've updated them now and will commit the changes with the new animations)

 

[DaveS]

DaveS, can you tell me which bellows (G or G') are the latest version? One version, i.e. same number and order of vertexes, is much easier to handle (and maybe faster). The G' bellows are all "good" and I have it all working very well. They look chaper than the G bellows (78 vs 152) but still look good.
BTW: IMO we don't need the circular ends (it should all connect now), so we could decrease the bellows/pipes vertex/triangle count quit a bit.

I checked in updated versions of the CISS meshes where they have the same meshes for the bellows as well as the ducts themselves. I also deleted the circular end pieces as per your request.

 

[GLS]

Pardon my (potential) ignorance on the subject but why is there a need to have the vertexes duplicated? Is it normals, mapping, something else?

 

[DaveS]

Pardon my (potential) ignorance on the subject but why is there a need to have the vertexes duplicated? Is it normals, mapping, something else?

Vertices duplicated? Where?

 

[GLS]

Problem detected: some bellows are 152v while most are 144v...

---------- Post added at 10:41 PM ---------- Previous post was at 10:40 PM ----------

Vertices duplicated? Where?

Pretty much every one on the bellows (at least).

 

[DaveS]

Problem detected: some bellows are 152v while most are 144v...

---------- Post added at 10:41 PM ---------- Previous post was at 10:40 PM ----------


Pretty much every one on the bellows (at least).

I just checked, the bellows are fine, they're identical across the board. The only differences I noted was on the vent ducts vs the F/D/D ducts.

 

[GLS]

I just checked, the bellows are fine, they're identical across the board. The only differences I noted was on the vent ducts vs the F/D/D ducts.

GEOM 152 144 ; LOX_DUCT_BELLOW3
GEOM 144 144 ; LH2_DUCT_BELLOW3

A visual count gives 72v, so they are all duplicated (and no, I didn't forget to count the other side)... I just don't know if there is a need for that.

 

[DaveS]

Everything should be good now in the new version I have checked in. The reason for the vertex duplication is something that is done by the msh export script. Everything is good natively but for some reason the vertices needs to be essentially "unwelded", doubling the vertex count.

 

[GLS]

Almost there: I need all 4 "XYZ_BELLOW1" bellows to be rotated 180, so the bottom face is up, and the vertexes of the face I want to move have the same indexes as the rest.

Then the 2 liquid "XYZ_BELLOW2" bellows (LH2 and LOX) don't have the vertexes in the same order. Most are but not all. This is really important as it simplifies the code and only requires 1 list of vertexes.

 

[DaveS]

Almost there: I need all 4 "XYZ_BELLOW1" bellows to be rotated 180, so the bottom face is up, and the vertexes of the face I want to move have the same indexes as the rest.

Then the 2 liquid "XYZ_BELLOW2" bellows (LH2 and LOX) don't have the vertexes in the same order. Most are but not all. This is really important as it simplifies the code and only requires 1 list of vertexes.

This should now be correct.

 

[GLS]

This should now be correct.

All gaseous bellows are good, but the liquid ones... the #3 ones are correct, but the others are 114v instead of 108v like the #3 ones. IMO cloning the #3 bellow and using that for the #2 and #1 bellows would work, as long as the orientation is such that the aft face of #2 and #3 are using the same vertex indexes and that aft face is the top face of #1.

 

[DaveS]

All gaseous bellows are good, but the liquid ones... the #3 ones are correct, but the others are 114v instead of 108v like the #3 ones. IMO cloning the #3 bellow and using that for the #2 and #1 bellows would work, as long as the orientation is such that the aft face of #2 and #3 are using the same vertex indexes and that aft face is the top face of #1.

Try things now.

 

[GLS]

Try things now.

It looks OK now!
I'll commit in a bit.

Switching gears (let's see if we can sneak this one in 2017), is there any info on the orientation of the PTUs? As they have a 340º range in both axis, the motion needs to measured from the correct direction. Currently the tilt has the 20º "blind spot" behind the "normal" orientation, and IMO it makes more sense for that to be straight down.

---------- Post added at 03:21 PM ---------- Previous post was at 01:59 PM ----------

New CISS bellows animation is up!

---------- Post added at 03:27 PM ---------- Previous post was at 03:21 PM ----------

Is there anything remaining to do in these tickets?
95 Accuracy of OMS burn targeting system
103 Reentry plasma sheet mesh appears late and disappears too late (was: #62)
111 SPEC/DISP states are not saved for IDP/GPC pairs
147 Centaur piping bellows
164 RSLS unable to shut engines during an abort

 

[DaveS]

It looks OK now!
I'll commit in a bit.

Switching gears (let's see if we can sneak this one in 2017), is there any info on the orientation of the PTUs? As they have a 340º range in both axis, the motion needs to measured from the correct direction. Currently the tilt has the 20º "blind spot" behind the "normal" orientation, and IMO it makes more sense for that to be straight down.

---------- Post added at 03:21 PM ---------- Previous post was at 01:59 PM ----------

New CISS bellows animation is up!

---------- Post added at 03:27 PM ---------- Previous post was at 03:21 PM ----------

Is there anything remaining to do in these tickets?
95 Accuracy of OMS burn targeting system
103 Reentry plasma sheet mesh appears late and disappears too late (was: #62)
111 SPEC/DISP states are not saved for IDP/GPC pairs
147 Centaur piping bellows
164 RSLS unable to shut engines during an abort

Ticket#95: Not that I can think of now that we do have a proper OMS TVC system in place along with a correct c.g location. The only issue is with single engine burns as you previously noted, those leave a trimmable dVY component but not of any significant amount (approx. 1.5-2 fps).
Ticket#103: Not really. Could be tweaked some if desired but it can be closed.
Ticket#111: It can be closed if the states are indeed saved/loaded correctly.
Ticket#147: Can be closed now.
Ticket#164: Can be closed with the explanation in the ticket.

 

[GLS]

It seems I was a bit too eager in separating the VC mesh panels... I just finished separating the forward panels and now working the code I notice that because of the "basic" click area implementation in the trunk (as opposed to panels with more than 1 click area in the VC branch), the HUD switches are controlled from the wrong panel. No (further) problems with one VC mesh, but now with each panel only "playing" with its own mesh, they can't play with the neighbor's toys... :facepalm:
So to "fix" this and allow things to move forward, I'll "steer into the slide" and merge the VC branch to the trunk. In practical terms this will bring to the trunk the click area upgrade, which works as planned (nobody complained :shrug.
After this the VC branch will still exist, waiting for its main purpose: VC mesh upgrade, which now will have the majority of the code side of it done.

---------- Post added at 10:24 PM ---------- Previous post was at 04:58 PM ----------

It seems I was a bit too eager in separating the VC mesh panels... I just finished separating the forward panels and now working the code I notice that because of the "basic" click area implementation in the trunk (as opposed to panels with more than 1 click area in the VC branch), the HUD switches are controlled from the wrong panel. No (further) problems with one VC mesh, but now with each panel only "playing" with its own mesh, they can't play with the neighbor's toys... :facepalm:
So to "fix" this and allow things to move forward, I'll "steer into the slide" and merge the VC branch to the trunk. In practical terms this will bring to the trunk the click area upgrade, which works as planned (nobody complained :shrug.
After this the VC branch will still exist, waiting for its main purpose: VC mesh upgrade, which now will have the majority of the code side of it done.

... and done!
Now in the trunk it is much easier to operate the pilot's MDUs from the CDR side thanks to the panels now having multiple click areas.
Also, the Drag Chute buttons now only appear when the Drag Chute is used.

This concludes the vc panel mesh separation. The code still needs some clean up, as now every panel specifies its mesh instead of using the default vc mesh, and... something else that I just forgot... :facepalm:
Anyway, I tried to get all the switch IDs as correct as possible, but in some cases there is no info... at least there should be no mistakes. :shrug:

 

[Wolf]

Hi SSU team,
First of all happy new year everyone!

I was wondering if you are working on the following issues brought up by DaveS a while ago:
1) Ticket 163 (aerojet DAP and HUD diamond symbol problems)

2) Orbiter being too lazy/slow on roll commands in atmospheric flight

Thanks

 

[GLS]

Hi SSU team,
First of all happy new year everyone!

I was wondering if you are working on the following issues brought up by DaveS a while ago:
1) Ticket 163 (aerojet DAP and HUD diamond symbol problems)

2) Orbiter being too lazy/slow on roll commands in atmospheric flight

Thanks

On the guidance diamond (and entry guidance in general) I know little about it so I can't really comment on what is done, what is missing and what needs corrections. One thing I know is that we don't do the separation between GNC and FCS... that's something we should try to get better in the new GPCs. Another thing missing for Orbiter 2016 is altitude data to find the runway.
In general, atmospheric flight stability dropped in Orbiter 2016 due to the wind effects. Our yaw control problems (ticket 85) don't help, although manual rudder is now available.
On the manual control side, things changed with the controller updates I did awhile back. We can now get our hands and feet to control what the astronauts did, but getting a good "translation" between pressing a key and pressing a pedal or moving a joystick is not easy. Currently when the user is pressing a key, the controller will move at a constant rate, and when the key is released the controller will return to 0 at the same constant rate*. There is a DPS display (SPEC 43 on OPS 8?) that shows the controller input signals.
This setup doesn't allow for "sharp" inputs, but I don't see other ways to do this. :shrug: Plus, there are also gains in the FCS to play with. Another thing to consider is that our opinion on the handling of the vehicle is very subjective, as we didn't fly it... :uhh:


*) The RHC "translation" will need some changes for orbit operations, as firing the RCS is not as it should be.

---------- Post added at 07:14 PM ---------- Previous post was at 05:35 PM ----------

Question: in the BasicPanel template, there's no problem in assuming the type is (derived from) a Vessel class, right? I need to call AddMesh() and others to "centralize" the panel loading, instead of having the same code repeated in each panel class.
This has to go there or in the derived AtlantisPanel class, which has a type Atlantis, which is a Vessel so there is absolutely no "conflict" in there.

 

[Urwumpe]

Question: in the BasicPanel template, there's no problem in assuming the type is (derived from) a Vessel class, right? I need to call AddMesh() and others to "centralize" the panel loading, instead of having the same code repeated in each panel class.
This has to go there or in the derived AtlantisPanel class, which has a type Atlantis, which is a Vessel so there is absolutely no "conflict" in there.

Sadly we can't use the new C++ Concepts yet that will come in the new standard and are already implemented in the gcc. :lol:

I personally would recommend adding a simple "AddMesh" to BasicPanel already and restrict the template parameter to a subclass of VESSEL.

Should already be good enough. The silver bullet solution would be creating a subsystem in SSU for handling meshes regardless how Orbiter evolves or which special tricks we need.

 

[GLS]

Sadly we can't use the new C++ Concepts yet that will come in the new standard and are already implemented in the gcc. :lol:

I personally would recommend adding a simple "AddMesh" to BasicPanel already and restrict the template parameter to a subclass of VESSEL.

Should already be good enough. The silver bullet solution would be creating a subsystem in SSU for handling meshes regardless how Orbiter evolves or which special tricks we need.

Would that be done like this

template <>
class BasicPanel <Vessel>

instead of what we have?

template <class TVessel>
class BasicPanel