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

[GLS]

New IUS EEC deploy mechanism is up!

Not the most detailed thing, but it serves the purpose. Yes, the strips are rotated: I found that they detached and rotated away from the nozzle so it could gimbal. Not sure about the timing of it all, so put a 2s pause between deployment and the rotation, which I set at 3s.
I also deleted the hidden triangles in the RCS, and that alone reduced the size of the mesh by over 10%.

So now I'm pretty much waiting for the Orbiter.msh to get squared away so we can finally release.

 

[GLS]

Here's something I did with 5 minutes on google and maybe 1h converting coordinates and placing vertices: the correct outline of the windows.

GEOM 44 22
-0.158242 2.11646 10.4186 -0.121281 0.992584 -0.00503555 0 1
-0.6477 2.05905 10.4186 -0.121281 0.992584 -0.00503555 0 1
-0.158242 2.11646 9.94439 -0.121281 0.992584 -0.00503555 0 1
-0.6477 2.05423 9.94439 -0.121281 0.992584 -0.00503555 0 1
0.158242 2.11646 10.4186 0.121281 0.992584 -0.00503555 0 1
0.6477 2.05905 10.4186 0.121281 0.992584 -0.00503555 0 1
0.158242 2.11646 9.94439 0.121281 0.992584 -0.00503555 0 1
0.6477 2.05423 9.94439 0.121281 0.992584 -0.00503555 0 1
-0.128778 0.826644 13.2012 -0.255348 0.665792 0.701071 0 1
-0.913892 0.95593 12.7922 -0.255348 0.665792 0.701071 0 1
-0.336804 1.55867 12.43 -0.255348 0.665792 0.701071 0 1
-0.826262 1.52921 12.2799 -0.255348 0.665792 0.701071 0 1
-0.984504 0.95212 12.7597 -0.592425 0.594806 0.54329 0 1
-1.83845 0.534544 12.286 -0.592425 0.594806 0.54329 0 1
-0.895604 1.49009 12.268 -0.592425 0.594806 0.54329 0 1
-1.23876 1.47815 11.9065 -0.592425 0.594806 0.54329 0 1
-1.87477 0.53556 12.2322 -0.756737 0.596728 0.266854 0 1
-1.91211 0.929514 11.2472 -0.756737 0.596728 0.266854 0 1
-1.27051 1.4746 11.8476 -0.756737 0.596728 0.266854 0 1
-1.43612 1.47384 11.378 -0.756737 0.596728 0.266854 0 1
-2.39979 -1.39205 11.3973 -0.986084 0 0.166143 0 1
-2.45034 -1.39205 11.0973 -0.986084 0 0.166143 0 1
-2.39979 -1.08775 11.3973 -0.986084 0 0.166143 0 1
-2.45034 -1.08775 11.0973 -0.986084 0 0.166143 0 1
0.128778 0.826644 13.2012 0.255348 0.665792 0.701071 0 1
0.913892 0.95593 12.7922 0.255348 0.665792 0.701071 0 1
0.336804 1.55867 12.43 0.255348 0.665792 0.701071 0 1
0.826262 1.52921 12.2799 0.255348 0.665792 0.701071 0 1
0.984504 0.95212 12.7597 0.592425 0.594806 0.54329 0 1
1.83845 0.534544 12.286 0.592425 0.594806 0.54329 0 1
0.895604 1.49009 12.268 0.592425 0.594806 0.54329 0 1
1.23876 1.47815 11.9065 0.592425 0.594806 0.54329 0 1
1.87477 0.53556 12.2322 0.756737 0.596728 0.266854 0 1
1.91211 0.929514 11.2472 0.756737 0.596728 0.266854 0 1
1.27051 1.4746 11.8476 0.756737 0.596728 0.266854 0 1
1.43612 1.47384 11.378 0.756737 0.596728 0.266854 0 1
-0.208788 1.85103 9.60606 -0 0 -1 0 1
-0.584708 1.78651 9.60606 -0 0 -1 0 1
-0.208788 1.55131 9.60606 -0 0 -1 0 1
-0.584708 1.55131 9.60606 -0 0 -1 0 1
0.584708 1.55131 9.60606 -0 0 -1 0 1
0.208788 1.55131 9.60606 -0 0 -1 0 1
0.584708 1.78651 9.60606 -0 0 -1 0 1
0.208788 1.85103 9.60606 -0 0 -1 0 1
0 3 1
3 0 2
4 7 6
7 4 5
8 11 9
11 8 10
12 15 13
15 12 14
16 19 17
19 16 18
20 23 21
23 20 22
24 27 26
27 24 25
28 31 30
31 28 29
32 35 34
35 32 33
36 39 37
39 36 38
43 40 41
40 43 42

Forward windows are too aft and too low.

Like I suspected, the current forward bulkhead, which should be the blankets, is so much forward that is is actually forward of the actual bulkhead... :facepalm:

Overhead windows are also out of place (as is the side hatch window).

 

[GLS]

I was thinking of adding compression to the aero data to improve loading times, but before I went ahead I decided to check how long it took, and clocked it at ~1.6s. From what I remember, it took 4s with the old aero data, which had to be rotated (e.g. vertical-body force to lift, etc) so tons of trigonometry. While working the aero, I deleted all of that and made the tables already in the axis that Orbiter wants == gain. So I think I'll leave it as is, as it's about 0.1s per file, and each is on average about 30kB in size, so I don't think compression would gain much in here.

As I had "the clock on my hand", I decided to time the Atlantis class constructor (~3.2s) and the scenario loading (~3.7s), places were most loading happens.
I was somewhat surprised by the numbers, so I decided to dig a bit more and the loading of meshes is by far the driver here: 98% of the time in the constructor! The Orbiter.msh alone takes almost 80% of it!!! :uhh:
Although I didn't dig much in the scenario loading, I'd guess most time also goes to mesh loading (RMS/ODS/VC panels), although I'm sure parsing the scenario file takes some of it.

All of that in MOGE. In D3D9, mesh loading times increase almost 10x, with 12.6s needed to load the Orbiter.msh file, probably a result of the more data structures that have to be created for the extra visuals, and the extra textures that also have to be loaded.

I'm wondering if the order of the mesh groups affects the loading and, or only, the rendering? (material and texture switching)
In any case, I'll write a script to re-order the mesh groups, so that doesn't have to be done by hand, but manual intervention will still be needed for transparency details. :shrug:

Another +/- performance related thing is all the unused DPS files and logic. I don't think that is costing many milliseconds, but in the end it's not being used, so I think I'll delete all that, first in the SimpleGPC_IO branch to test and make sure there are no issues, but it isn't my intention to rush this to make the SSU 5.0 train.

 

[GLS]

I think I found a way around our problem of the shifting payloads during the first frame: our c.g. calculation logic goes after all child attachments, and their child attachments (and on, and on...) to calculate the mass and position of each "leaf" attachment, the root of which is the main SSU vessel. It uses the relative position of the vessels to figure out the positions, but in the first time step the rotation matrix returned for a vessel at a child attachment is not correct, so basically the payload is thought to be somewhere else in the Solar System. :uhh:
A (possible) way around this is using the known positions and orientations of the attachments, to obtain, in parent vessel coordinates, the c.g. of a vessel attached to a child attachment.
The problem is that I don't quite have the brain power to make it happen... I think the child-to-parent attachment position must be rotated by some amount related to its orientation, and then the parent-to-child position must be added, but I'm getting dizzy just thinking about it... icard-facepalm:

---------- Post added 12-08-19 at 11:56 AM ---------- Previous post was 12-07-19 at 11:15 PM ----------

Just merged the graphics branch to the trunk, so the new SRBs and other changes are now "mainstream".

 

[GLS]

Committed a Python script to re-order mesh groups for best performance!
It does not fully support comments in the meshes: some will not be on the output file, others will, and others should crash it, but I've ran dozens of meshes by it and there shouldn't be an issue. :shrug:
Other than that, it should keep all the flags (even the undocumented ones), and detect some basic errors (wrong number of groups, vertices, etc, or missing things).

Still some work needed on passing the names of the mesh files, but for now it is usable. BTW, usage is "SSU_MGRO.py inputmesh.msh outputmesh.msh".

On what this does exactly: it changes the order of the mesh groups to have groups that use the same texture together, and then inside those "sub-groups" put all groups that use the same material next to each other. In both cases, the index order is used. There are currently 2 issues with the current logic:
1) the material isn't "saved" across texture changes, so on some meshes the result isn't the absolute best possible, and maybe 1, 2 or 3 extra material switches will exist, but this is not a commom situation nor a big performance loss;
2) there is no way to know what mesh groups are transparent (at least not texture wise), so those groups will probably end up in the middle instead of the end of the mesh. To try to minimize this I already place the groups without texture at the end, but still no attention is payed to the material. This is only an issue for a small number of meshes, so doing a bit of manual editing shouldn't be an issue in those rare cases.

I have no intentions of putting the meshes thru the script for SSU 5.0, but it seems like another good and fast thing for the 5.1 release.

 

[DaveS]

I'm nearing completion of work on the orbiter mesh. The position of the windows have been updated.

In the process of fixing the Xo576 bulkhead, we now have the problem that the texture for it doesn't fit anymore. The bulkhead is now more true to the real one in that the section with the MLI blankets is now entirely flat at Xo576.1 while the upper frame section now fits with the coordinates layed out in the PLBD Familiarization Manual. The step between the blanket section and the upper frame is hidden by "V" shaped blankets, I've attached a photo of the starboard half on OV-105 that shows these blankets. Anyone feel up to updating our Xo576 bulkhead texture?

 

[Donamy]

Looks like tin foil

 

[DaveS]

Looks like tin foil

The MLI blankets? They're made up of several layers of PFTE and silver impregnated Kapton.

---------- Post added 12-20-19 at 01:28 AM ---------- Previous post was 12-19-19 at 08:27 PM ----------

Checked in the updated orbiter mesh. It requires a rebuild of the sources as I fixed a typo in a mesh group label and I also checked in three forgotten updated files (all of them related to the Centaur stuff).

 

[GLS]

First impressions on the recent Orbiter.msh changes: white PLB (again) and editing error in the starboard side fwd bulkhead frame.
A closer look reveals a mess of things at the fwd end of the PLBDs: seal in mid-air, the monkey fur instead of being squeezed between the door and the bulkhead like it was, now goes thru the door on some areas, faces of the top of the frame are visible below the frame (next to the bulkhead blankets), PLBDs not vertically flush with the fwd fuselage and actually collide with it... I thought I had that nailed, and the only issue was the bulkhead blankets, but I guess I got the math wrong... :shrug:
The PLBD new centerline stuff, pretty much add nothing new: the "basic" door shape still isn't respected, with an edge at the center of the mesh (the high point of the doors), so the "fit" the fwd and aft fuselages, doors collide instead of having the small gap between them, with the seals and stuff, centerline faces not aligned and some missing, centerline latch mechanisms collide with centerline seals.
There are also gaps just below the OV name zone in the fwd fuselage, and near that there parts of the sills that stick out of the fuselage. The star trackers have groups that are misaligned, faces missing, and some parts stick out above the fuselage.
On the fwd bulkhead blankets: they probably are where the bulkhead is and not a bit aft of it, so that's probably why the PLB fwd cameras are almost falling off their bases: the bases, and handrails, have long attachments to the bulkhead. Plus, maybe the blankets highlighted in red in a previous post should be added to avoid the current step transition.

Loaded the "window outlines" mesh group I posted a few days ago, and the windows are still not in the right place, or with the right size (at least aft windows).

---------- Post added at 02:10 PM ---------- Previous post was at 01:59 PM ----------

Centaur and CISS: nice addition of the hole in the CISS adapter ring to allow for the feedline, but the disconnect panels are not aligned.
There is also a difference in vertex count around the Centaur fwd frame and the LH2 tank, result: large gaps where they meet.
RCS thrusters meshes and thruster locations don't match.
The vent/dump pipes go out of the PLB in one place, then turn into a PLB cavity, then turn out towards the fuselage... shouldn't they go to the cavity directly?
There is also a panel on the starboard side of the Orbiter, where nothing connects... was that really there?

 

[DaveS]

GLS: Could you take a shot at correcting the forward windows, I just can't get them right. I've attached a zip file containing a msh file with the canopy separated for easier work. Once you're done, you just attach a zip file with the updated msh file and I'll re-integrate it.

As far as the forward cameras almost falling off the platforms, well that's how the real ones were mounted. They weren't centered on the platforms. As evidence I have attached a CAD image of the Ku band bolt R&R work done on Atlantis at the pad prior to STS-115 in 2006. I've rotated the image so the orbiter is horizontal for easier viewing. As you can see PLB cam A is mounted near the aft edge of the PTU-to-platform bolts.

I've fixed the issues with PLBDs, at least I hope. I've also started on the texture mapping with the fuselage, PLBDs, wings and vertical stabilizers done. What else needs work in this department?

 

[GLS]

GLS: Could you take a shot at correcting the forward windows, I just can't get them right. I've attached a zip file containing a msh file with the canopy separated for easier work. Once you're done, you just attach a zip file with the updated msh file and I'll re-integrate it.

As far as the forward cameras almost falling off the platforms, well that's how the real ones were mounted. They weren't centered on the platforms. As evidence I have attached a CAD image of the Ku band bolt R&R work done on Atlantis at the pad prior to STS-115 in 2006. I've rotated the image so the orbiter is horizontal for easier viewing. As you can see PLB cam A is mounted near the aft edge of the PTU-to-platform bolts.

I've fixed the issues with PLBDs, at least I hope. I've also started on the texture mapping with the fuselage, PLBDs, wings and vertical stabilizers done. What else needs work in this department?

On the windows, the mesh I posted are the outlines, so basically the windows with "sharp" corners instead of round. I'm seen some diagrams with some info on the corners, IMO that's not as critical as the position of the windows. The should be correct, both to avoid changing the textures in the future, as well as having the area surrounding the vc correct.

IMO, they don't need to be millimetrically perfect, but the last time I looked at them they were some cms away from where they should be.
I don't know what "tools" your editing software has, but in blender it's not easy to rotate things about other places other than XYZ, or translate in other directions without math. So, my strategy would be first get the orientation correct with XYZ with individual rotations, then when it has (some) z-fighting, i.e. it is co-planar, it's time to get the position correct. It's not a 5-minute job, but it should only need doing for the windows windows on one side, then the other is just a mirror image. :shrug:

As far as mapping, that should be the last item on the list, or it risks being for naught. :shrug:

 

[DaveS]

The main question for me is what the coordinates is for? Is for the outer most window pane, the cut-out outside or the cut-out inside? It is a good difference between each possibility.

 

[GLS]

The main question for me is what the coordinates is for? Is for the outer most window pane, the cut-out outside or the cut-out inside? It is a good difference between each possibility.

It doesn't say in the document (Shuttle Orbiter /Cargo Standard Interfaces (CORE) - ICD-2-19001, Revision L), but it makes sense that they are refering to the outer pane as there is no other info on the inside of the crew compartment. Also, the PLB windows are at Xo576.1, so that would be on the bulkhead, so outer-most pane. :shrug:

---------- Post added 12-26-19 at 11:18 AM ---------- Previous post was 12-25-19 at 12:09 PM ----------

I get CTDs after updating to r3193... the texture and material list in the mesh have numbers in the names....

 

[DaveS]

New DFI pallet in the works. Overall structure is complete but is still missing some wiring.

 

[DaveS]

I get CTDs after updating to r3193... the texture and material list in the mesh have numbers in the names....

Could you please try r3199? The numbers were some left over debug stuff I needed to use but completely forgot to remove as I'm strictly a D3D9Client user and it didn't have any issues.

 

[GLS]

New DFI pallet in the works. Overall structure is complete but is still missing some wiring.

I'm not saying it shouldn't be done (although I haven't really seen anything on what we have to warrant a new mesh :shrug, but shouldn't work on the big rock (Orbiter mesh) between us and much-delayed SSU 5.0 release take priority? And then we still have the textures: I recently ran a scenario with Challenger and it still has the black chines like Columbia, something I mentioned way back when SSU 4.x came out. :facepalm:
Not that I don't like the "development part", but that has be towards a release or it's not really fun. And then the basics need to have priority: it's all very pretty to have a shining new DFI pallet, and then the SSME eyelids still have issues... :uhh:

Could you please try r3199? The numbers were some left over debug stuff I needed to use but completely forgot to remove as I'm strictly a D3D9Client user and it didn't have any issues.

No CTDs now.

Noticed that the SSUbay_norm.dds is now 65MB, which to put in perspective is near half of the SSU package on a single texture...

 

[DaveS]

I'm not saying it shouldn't be done (although I haven't really seen anything on what we have to warrant a new mesh :shrug, but shouldn't work on the big rock (Orbiter mesh) between us and much-delayed SSU 5.0 release take priority? And then we still have the textures: I recently ran a scenario with Challenger and it still has the black chines like Columbia, something I mentioned way back when SSU 4.x came out. :facepalm:

I'm not reworking the textures yet again. So we have bigger problems than Columbia's wing chines on Challenger as the textures doesn't fit the mesh anymore.

Not that I don't like the "development part", but that has be towards a release or it's not really fun. And then the basics need to have priority: it's all very pretty to have a shining new DFI pallet, and then the SSME eyelids still have issues... :uhh:

What issues? They look fine to me.

Noticed that the SSUbay_norm.dds is now 65MB, which to put in perspective is near half of the SSU package on a single texture...

This should be fixed in r3200. The problem is that Paint.NET keeps moving forward while Orbiter's DX7 graphics engine is stuck in the early 2000's. So this have created a disconnect between new standards in the DDS texture format and the now almost 20 year old DX7 DDS format.

 

[GLS]

What issues? They look fine to me.

Well, they should all be in the same relative position to the nozzles, and their surfaces should all be in the same relative position to the "rings" on the aft face of the aft compartment, so when the engines gimbal they just "slide" like an eye in the eye socket.

 

[GLS]

I've been working on the new RCS for SSU 98.0 shifty, and I'm not sure the positions of the FRCS nozzles are correct (the shapes aren't). I found very useful info on the nozzle positions and orientations on the SODB, page 4.3.2-71. For the graphics department, only the "Thruster mount attach" columns and the data at the bottom of the table are needed (that's position and orientation), and the rest of the table is for me... :dry:
I'm somewhat surprised that most of the nozzle orientations are so "well behaved", i.e., aligned with a plane.
So, as the basic RCS nozzle shape is the same for all of them, it's a question of creating a cone (the nozzle) with the correct aperture, put a disk on the small end (the injector), and then replicating that, rotating to the correct orientation and placing the center of the disk at the coordinates. Finally the hard part: figuring out where is the vehicle OML to then cut the nozzle so it doesn't stick out of the OML. The table has some info of where the nozzle ends, but that seems more oriented towards the physical effects than to the actual shape, as it simplifies the radial component. Still those are probably good ball park numbers as to where the cut is.

I'm mentioning this now, because it would be a shame to have to re-work, again, the OV mesh in the future to fix the nozzle positions and orientations, and then have to fix the textures, again.

 

[GLS]

Just noticed that the rad hose rollers have been reverted from my "post-diet version" in r3102 (last time I worked the Orbiter.msh) which, if I remember well, represented a good % decrease in the size of the PLB sill structures.... :shrug: