SSU Development Thread (2.0 to 3.0)

[DaveS]

A good example of the disagreement in the coordinates are the PLB lights. In Orbiter, the correct coordinates for the forward starboard light are as follows: 1.4, -1.04, 9.2. GMAX and AC3D gives it as 1.4, -3.06, 5.51. So only the X axis is in agreement, Y/Z do not agree at all.

 

[SiameseCat]

I think that's the CG offset. The differences between the coordinates is equal to shift in the meshes resulting from the CG calculation. This didn't affect the previous meshes because the CG offset was only used during launch, and the CG was at the mesh center on orbit. Animations shouldn't be affected by this.

 

[DaveS]

I think that's the CG offset. The differences between the coordinates is equal to shift in the meshes resulting from the CG calculation. This didn't affect the previous meshes because the CG offset was only used during launch, and the CG was at the mesh center on orbit. Animations shouldn't be affected by this.

ÖK, but that doesn't explain why the FWD radiator panels won't agree with the ref points.

---------- Post added at 05:49 AM ---------- Previous post was at 05:42 AM ----------

This is in Orbiter with the ref point given by OMW:

And this is in OMW:

 

[Urwumpe]

I think that's the CG offset. The differences between the coordinates is equal to shift in the meshes resulting from the CG calculation. This didn't affect the previous meshes because the CG offset was only used during launch, and the CG was at the mesh center on orbit. Animations shouldn't be affected by this.

Important is the visual and the coordinates relative to the CG, when the animations are defined - the animations are updated by Orbiter during CG shifts.

 

[SiameseCat]

For the forward radiators, the reference points I'm getting from OMW are 2.538, -0.747, 0.0

 

[DaveS]

That explains things, I was always measuring with the doors open, not closed. I haven't done animations in a long time so I'm a bit rusty.

---------- Post added at 05:21 PM ---------- Previous post was at 04:23 PM ----------

That explains things, I was always measuring with the doors open, not closed. I haven't done animations in a long time so I'm a bit rusty.

The radiators have now been sorted out and are animating properly. Now on to another question: How can I account for the cg shift when calculating the new positions for stuff like lights and camera positions? What is the deltas to the positions in the model?

For example: The static position for the RMS EE light when deployed is -2.69, 0.23, 7.45.

 

[Urwumpe]

The radiators have now been sorted out and are animating properly. Now on to another question: How can I account for the cg shift when calculating the new positions for stuff like lights and camera positions? What is the deltas to the positions in the model?

We have a variable to account for a reference position to CoG shifts. But don't ask me its name, I am not at SSU in the moment.

 

[SiameseCat]

That explains things, I was always measuring with the doors open, not closed. I haven't done animations in a long time so I'm a bit rusty.

---------- Post added at 05:21 PM ---------- Previous post was at 04:23 PM ----------


The radiators have now been sorted out and are animating properly. Now on to another question: How can I account for the cg shift when calculating the new positions for stuff like lights and camera positions? What is the deltas to the positions in the model?

For example: The static position for the RMS EE light when deployed is -2.69, 0.23, 7.45.

I don't move any of the groups when measuring animation locations, and just look at the unchanged mesh.

For the CG shift, the simplest thing to do might be to focus on the animations (which are unaffected by the CG shift) for the moment and I'll figure out how to handle the other stuff. The lights are a bit complex because the light sources move automatically after a CG shift, but beacons don't. Fixed camera positions are fine, and I think moving cameras (like the PLBD or EE cameras) should work without any changes. The offset isn't constant (eventually, I want to move the CG as fuel is used up, payloads deployed, etc.), so it's more complex than just adding a fixed constant.

 

[DaveS]

I'm almost done fixing up the stuff that I can. However, can someone wire up the star tracker door switches (O6) so that I can properly correct their animations?

---------- Post added at 06:43 PM ---------- Previous post was at 01:27 PM ----------

Checked in what I have fixed so far, along with a fix for the wing painting issue.

 

[DaveS]

How is the fixing up of the rest of the orbiter animations that I was unable to correct coming along?

 

[SiameseCat]

I'm working on the animations at the moment. I've been busy with non-Orbiter stuff lately, so progress is fairly slow.

 

[Urwumpe]

After some experimenting with JavaFX yesterday evening, I am sure that it is really the way to go for the "SSU Toolbox". Really simple to learn, you can really get a good separation between Java code and FXML UI description, translations are even simpler than before with Java.

Just installing Visual Studio 2013 here, will take a look at connecting the Star Tracker animation to the switches via a stub class.

 

[DaveS]

I'm still trying fix some of the animations and this is the latest problem:

I have gone through several rotation points as well as vectors but nothing seems to fix it. I don't know if it is the cg shift function that's messing up the rotation points or what. One thing that could help troubleshoot the problem would be that MM801 FCS C/O actually saved/loaded the aerosurface drive selection (ITEM 10/11). Currently you have to restart it every time you reload the scenario.

 

[SiameseCat]

Can you post the elevon animation definitions? It might be something to do with parent/child animations, but I'm not sure. The CG shift is performed after the animations are defined, so it shouldn't cause any issues.

BTW, I've already fixed the ET umbilical doors and I'm working on the PLBD animations.

 

[DaveS]

Can you post the elevon animation definitions? It might be something to do with parent/child animations, but I'm not sure. The CG shift is performed after the animations are defined, so it shouldn't cause any issues.

This is the very latest iteration:

// ***** Elevon upward animation *****
  static UINT LAileronGrp_up[2] = {GRP_LEFT_INBOARD_ELEVON,GRP_LEFT_OUTBOARD_ELEVON};
  static MGROUP_ROTATE LAileron_up (midx, LAileronGrp_up, 2,
    _V(0,-4.61,-10.51), _V(0.995261553294495, 0.097218629773975, 0.001725850138444), (float)(34.0*RAD));
  static UINT LAileronDoorGrp_up[2] = {GRP_LEFT_INBOARD_ELEVON_SEAL_PANEL,GRP_LEFT_OUTBOARD_ELEVON_SEAL_PANEL};
  static MGROUP_ROTATE LAileronDoor_up (midx, LAileronDoorGrp_up, 2,
    _V(0,-4,-10), _V(-0.998913, 0.0465805, 0.00183875), (float)(22.0*RAD));

  static UINT RAileronGrp_up[2] = {GRP_RIGHT_INBOARD_ELEVON,GRP_RIGHT_OUTBOARD_ELEVON};
  static MGROUP_ROTATE RAileron_up (midx, RAileronGrp_up, 2,
    _V(0,-3.9,-10.54), _V(-0.995259638999982, 0.001726197889982, -0.097238218918646), (float)(34.0*RAD));
  static UINT RAileronDoorGrp_up[2] = {GRP_RIGHT_INBOARD_ELEVON_SEAL_PANEL,GRP_RIGHT_OUTBOARD_ELEVON_SEAL_PANEL};
  static MGROUP_ROTATE RAileronDoor_up (midx, RAileronDoorGrp_up, 2,
    _V(0,-4,-10), _V(0.998913, 0.0465805, 0.00183875), (float)(22.0*RAD));
  
  // ***** Elevon downward animation *****
  static UINT LAileronGrp_down[2] = {GRP_LEFT_INBOARD_ELEVON,GRP_LEFT_OUTBOARD_ELEVON};
  static MGROUP_ROTATE LAileron_down (midx, LAileronGrp_down, 2,
    _V(0,-3.9,-10.54), _V(-0.995259638999982, 0.001726197889982, -0.097238218918646), (float)(18.0*RAD));
  static UINT LAileronDoorGrp_down[2] = {GRP_LEFT_INBOARD_ELEVON_SEAL_PANEL,GRP_LEFT_OUTBOARD_ELEVON_SEAL_PANEL};
  static MGROUP_ROTATE LAileronDoor_down (midx, LAileronDoorGrp_down, 2,
    _V(0,-3.4,-10), _V(-0.998913, 0.0465805, 0.00183875), (float)(5*RAD));

  static UINT RAileronGrp_down[2] = {GRP_RIGHT_INBOARD_ELEVON,GRP_RIGHT_OUTBOARD_ELEVON};
  static MGROUP_ROTATE RAileron_down (midx, RAileronGrp_down, 2,
    _V(0,-3.9,-10.54), _V(-0.995259638999982, 0.001726197889982, -0.097238218918646), (float)(18.0*RAD));
  static UINT RAileronDoorGrp_down[2] = {GRP_RIGHT_INBOARD_ELEVON_SEAL_PANEL,GRP_RIGHT_OUTBOARD_ELEVON_SEAL_PANEL};
  static MGROUP_ROTATE RAileronDoor_down (midx, RAileronDoorGrp_down, 2,
    _V(0,-3.4,-10), _V(0.998913, 0.0465805, 0.00183875), (float)(5*RAD));

 

[DaveS]

Checked in updated code to position the External Airlock and ODS correctly in the PLB of the new orbiter.

---------- Post added at 01:55 AM ---------- Previous post was at 12:53 AM ----------

And now the starboard MPMS and the OBSS have been properly realigned as well.

 

[SiameseCat]

The SSU repository (and the SSU V2.0 zip) includes a number of files included with Orbitersim (see the list below). Earth.cfg needs to be included to add the SSU bases, but I think the other files should be deleted from the SSU repository (I don't think they're even used in SSU anymore).

Config/Vessels/ProjectAlpha_ISS.cfg
Textures2/Atlantis/c2.dds
Textures2/Atlantis/c3.dds
Textures2/Atlantis/MGAtlantis.dds
Textures2/Atlantis/R1L1.dds
Textures2/Atlantis/R2.dds
Textures2/Atlantis/STSVC01.dds
Textures2/Atlantis/STSVC02.dds
Textures2/Atlantis/STSVC03.dds
Textures/Exhaust_atsme.dds

 

[DaveS]

The SSU repository (and the SSU V2.0 zip) includes a number of files included with Orbitersim (see the list below). Earth.cfg needs to be included to add the SSU bases, but I think the other files should be deleted from the SSU repository (I don't think they're even used in SSU anymore).

Config/Vessels/ProjectAlpha_ISS.cfg
Textures2/Atlantis/c2.dds
Textures2/Atlantis/c3.dds
Textures2/Atlantis/MGAtlantis.dds
Textures2/Atlantis/R1L1.dds
Textures2/Atlantis/R2.dds
Textures2/Atlantis/STSVC01.dds
Textures2/Atlantis/STSVC02.dds
Textures2/Atlantis/STSVC03.dds
Textures/Exhaust_atsme.dds

Yes. The textures are remnants from the time we used the default Atlantis rather than our own custom mesh.

The ISS config file however was modified to work with the SSU ODS. Checking the code, it does a search for an attachment point with the ID of "APAS" to see if there's any compatible docking ports in the vicinity. This is what lead to the creation of the STS-126 docking scenario, to test out the ODS code.

 

[Urwumpe]

The ISS config file however was modified to work with the SSU ODS. Checking the code, it does a search for an attachment point with the ID of "APAS" to see if there's any compatible docking ports in the vicinity. This is what lead to the creation of the STS-126 docking scenario, to test out the ODS code.

We need to redo this for the next version of Orbiter anyway. Hopefully the ODS will then work better with the new attachment system.

 

[SiameseCat]

Yes. The textures are remnants from the time we used the default Atlantis rather than our own custom mesh.

The ISS config file however was modified to work with the SSU ODS. Checking the code, it does a search for an attachment point with the ID of "APAS" to see if there's any compatible docking ports in the vicinity. This is what lead to the creation of the STS-126 docking scenario, to test out the ODS code.

The ISS config file in the SSU repository seems identical to the one included with Orbitersim; there are no attachments defined.