Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Addons > Addon Support & Bugs > Addon Developer Forums > Space Shuttle Ultra
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Space Shuttle Ultra Support & development threads for Space Shuttle Ultra addon.

Reply
 
Thread Tools
Old 11-27-2019, 09:07 PM   #2791
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 Sorry, but if you want the keys for our projects Palazzo in the Tuscany (Crowdfunding is great! Please also support my Patreon so I can buy another solid-gold Tesla X.), you'll have to defeat me in a fair duel. Tomorrow on sunrise, in the castle garden. Bring your own sword.
Deal! Let's just hope my buttler wakes me up on time...



Quote:
Originally Posted by Urwumpe View Post
 Or you at least demote me to "Developer" as your first task as "Admin", so we are not having an overly large admin team. You and DaveS should be enough to do the job.
I don't really see the need for that...
GLS is online now   Reply With Quote
Old 11-27-2019, 09:45 PM   #2792
Urwumpe
Not funny anymore
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by GLS View Post
 I don't really see the need for that...

Well, I do, that should be enough in that special case.

Should something happen to me eventually, you might have my admin account being abused, if I have more rights than really necessary.
Urwumpe is offline   Reply With Quote
Old 11-27-2019, 10:40 PM   #2793
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 Well, I do, that should be enough in that special case.

Should something happen to me eventually, you might have my admin account being abused, if I have more rights than really necessary.
Your wish is my command.
GLS is online now   Reply With Quote
Thanked by:
Old 11-29-2019, 05:51 PM   #2794
GLS
Addon Developer
 
GLS's Avatar
Default

I think I finally finished the SRB meshes!
I'll dump the remaining issues/improvements in the SRB ticket for future work. Still to do now is the correction of the SRB vessel c.g. and thruster plumes, but I'll probably jump to the IUS ASE first as I'm a little tired of looking at SRBs, and that should be quick anyway.


Quote:
Originally Posted by GLS View Post
 I haven't looked at the Orbiter recently, but (some of) the handrails were colliding with other parts, so they are not in the correct place. I think some of the sill structures are also not in the correct place. With the ExtAL pins now in the correct place, the PLBD drive collides with them, so they are also not in the right place.
If there is no position data for these items, then IMO we need to look at photos and use both the known positions of the pins of payloads and the PLB ring frames, to bound the positions of those items. That way, any future problems will be of a smaller magnitude.

One other thing I noticed while I was looking at the SRB corrections in the stack is gaps between the wing chines (the top of them) and the bottom part of the vehicle.
Quote:
Originally Posted by DaveS View Post
 Dealt with these in the latest commit. Everything looks alright now.
Quote:
Originally Posted by GLS View Post
 That was fast....
...way too fast... the gaps in the chines still exist, and the "middeck wall" is sticking out of the bottom (more on this below). There is also a hole in the SILTS pod. The PLB handrails still have the same issues as before (and they now collide with the slidewire mechanism), and the Ku-Band antenna collides with the forward-most RH PLBD drive mechanism. BTW, checking the coordinates of the antenna drives might be a good idea as the dish isn't pointing up in the way it should.
Radiators and PLBD door sections don't line up (they probably should), and radiator chevrons are out of place.


On a "middeck" to show behind the side hatch window (which btw is still oval), IMO this is all we need:
Code:
GEOM 8 10
1.95 -2.21245 13.2803 -0.577349 0.577349 -0.577349 0 0
1.95 -0.212448 13.2803 -0.577349 -0.577349 -0.577349 0 0
1.95 -2.21245 9.90941 -0.577349 0.577349 0.577349 0 0
1.95 -0.212448 9.90941 -0.577349 -0.577349 0.577349 0 0
-1.95 -2.21245 13.2803 -0 0.707083 -0.707083 0 0
-1.95 -0.212448 13.2803 -0 -0.707083 -0.707083 0 0
-1.95 -2.21245 9.90941 -0 0.707083 0.707083 0 0
-1.95 -0.212448 9.90941 -0 -0.707083 0.707083 0 0
1 2 0
3 6 2
5 0 4
6 0 2
3 5 7
1 3 2
3 7 6
5 1 0
6 4 0
3 1 5
A simple and un-textured 5-sided box.
GLS is online now   Reply With Quote
Old 12-01-2019, 03:19 AM   #2795
GLS
Addon Developer
 
GLS's Avatar
Default

Finished the work on the IUS ASE (and IUS)!!!

Didn't find any data on the tilt table dimensions, so I kept that we had and just removed the extra vertices in it. Trunnion pins, tilt table rotation axis and IUS/PL interface* should be at their correct positions. Also corrected the materials and re-ordered the mesh groups to reduce texture and material switching.
Then I did a "quick tour" of the IUS itself, and corrected the materials as well and added the missing EEC part. Had to correct the dimensions of all 3 parts, with not enough data, so common sense was used to fill the gaps. Here is an image of the finished product:

Also added a second set of struts to deploy the second cone, but I found a photo that shows only one set... given that I have no idea how it actually deployed, I think we should stick with a second set of struts.


Now, the last item on my list of graphics work: back to the SRBs to finish the vessel coordinates.

*) later while working on the IUS 2 stage I noticed that the IUS/PL interface apparently isn't the top-most part of the IUS, but the bottom of the top ring...
Attached Thumbnails
Click image for larger version

Name:	eec.PNG
Views:	178
Size:	156.9 KB
ID:	16881  
GLS is online now   Reply With Quote
Old 12-01-2019, 12:12 PM   #2796
GLS
Addon Developer
 
GLS's Avatar
Default

DaveS, I just saw your question on NSF regarding the CISS plumbing. Please, look at diagram 19.1-1 (on the "diagram book") that has an overview of the aft bulkhead. At the bottom there are 6 (but only 4 are labeled) "blank panels" that were know as "Payload Oxidizer Panel" (starboard side) and "Payload Fuel Panel" (port side).
A quick search on google shows that the inboard pair was for electrical connectors, and the 4 outboard panels were for fluids:


Page 138 here shows precise locations for the panels (disregard the relocation suggestions).
So the CISS should have used the 2 starboard outboard panels.
GLS is online now   Reply With Quote
Old 12-01-2019, 04:56 PM   #2797
Urwumpe
Not funny anymore
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by GLS View Post
  Also added a second set of struts to deploy the second cone, but I found a photo that shows only one set... given that I have no idea how it actually deployed, I think we should stick with a second set of struts.

I think one set is correct, the RL-10 also needs only one set of struts, the second nozzle segment is kept in place by tension. Also see this photograph:


Urwumpe is offline   Reply With Quote
Old 12-01-2019, 05:20 PM   #2798
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 I think one set is correct, the RL-10 also needs only one set of struts, the second nozzle segment is kept in place by tension. Also see this photograph:


Yes, but how is the middle cone held before deployment and how does it deploy?
GLS is online now   Reply With Quote
Old 12-01-2019, 06:33 PM   #2799
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quote:
Originally Posted by GLS View Post
 Yes, but how is the middle cone held before deployment and how does it deploy?
I'm thinking that there's a lip or capture ring on the base nozzle that engages the first extendable nozzle while the the second extendable nozzle keeps on going until it reaches the end of travel where it locks into place. So the larger second nozzle extension has some sort of capture feature that holds the smaller first nozzle extension until it engages the capture feature on the base of the base nozzle. This way you would only need one set of extension struts.
DaveS is online now   Reply With Quote
Old 12-03-2019, 02:14 PM   #2800
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by DaveS View Post
 I'm thinking that there's a lip or capture ring on the base nozzle that engages the first extendable nozzle while the the second extendable nozzle keeps on going until it reaches the end of travel where it locks into place. So the larger second nozzle extension has some sort of capture feature that holds the smaller first nozzle extension until it engages the capture feature on the base of the base nozzle. This way you would only need one set of extension struts.
Yeah, there might be a "capture feature" where the 2 EECs meet, and the inner EEC (middle cone overall) is just tied at the top to the base of the mechanism. As the outer EEC deploys it eventually "collects" the inner EEC and whatever is holding it up is released/breaks and it then goes down with the outer EEC.
Starting to look plausible to me.

---------- Post added at 07:18 PM ---------- Previous post was at 06:46 PM ----------

Currently tracking a wierd issue: the RH SRB shifts a bit away from the OV when at separation. The LH stays rock solid where it should, i.e., the only motion is the normal separation, but the RH has an immediate shift, and then does the normal motions.
Everything looked good now, so decided to get in the DeLorean and go back to see when this first issue appeared. From r3144 onwards it has this issue, so it isn't related to my recent work in the SRB area, as I was hoping it would.
Can anyone check if this also happens, before I go further back?

---------- Post added 12-02-19 at 12:44 AM ---------- Previous post was 12-01-19 at 07:18 PM ----------

Went back to before the latest big change in the SRB vessels (before the big merge with the aero stuff) and nothing changed. Played around with the code and it seems that it the first attachment to be released gets shifted: I swaped the order of the detachments and the LH SRB did the shift while the RH was correct.
I'm begining to thing this is related to the (latest) Orbiter beta version, as I recently updated to r90. Tomorrow I'll go back in those revs to see if anything changes.

---------- Post added at 03:25 PM ---------- Previous post was at 12:44 AM ----------

Went back to the Orbiter 2016 revision and still have the bug.
It probably wouldn't help, but did a CRT memory leak check, and it looks clean on SSU's side of the wall (just had the new DPS bus manager not being released), but... that only checks malloc calls, so I had to replace the new calls with a macro to get the offending file and line info, and I only did that in Atlantis.cpp, so it's totally possible that some of the other 20000 indications I got were from our side.

I'm currently out of ideas to track down this SRB shift... if push comes to shove, we could probably "force" the position of the SRB vessels after separation, but even if that works, it's just sweeping a bug under the rug...

---------- Post added 12-03-19 at 02:14 PM ---------- Previous post was 12-02-19 at 03:25 PM ----------

It appears I'm finally done with the SRBs! Corrected the locations of plumes and thrusters so it all worked again, as some meshes and the SRB vessel center shifted a bit.
But more than that, the BSMs had some directions that I don't really know where they came from. I recalculated them, using the data from the NASA TM X-64967 (which Urwumpe "introduced" here some years ago) and, surprise surprise, it now looks much more realistic: they fall away while mostly pitching, instead of pitching almost in place before falling back. The only flaw in the new numbers is that they are averages of the 4 BSMs in each end, so it doesn't have the small roll induced by the more isolated aft BSM. I think there is enough data to calculate individual positions, but there are other things to do and this thing is far from bad as it is now, so these "small" details will have to wait.

Didn't spend much time working the smoke "explosion" at launch, so no solution on that yet.

Also, fixed a "logic hole" in the SSME and SRB lights: their positions were not being updated during launch, so the c.g. shifted and the lights got out of place.

I'll now (re)work the EEC deployment on the IUS, and that should close out the graphics branch for now. I'll wait maybe until the weekend before merging it back to the trunk, so "independent" checks of the changes to the SRBs and to the IUS (and its ASE) can be done.
GLS is online now   Reply With Quote
Thanked by:
Old 12-03-2019, 09:26 PM   #2801
GLS
Addon Developer
 
GLS's Avatar
Default

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.
Attached Thumbnails
Click image for larger version

Name:	eec2.PNG
Views:	111
Size:	163.5 KB
ID:	16885  
GLS is online now   Reply With Quote
Old 12-05-2019, 01:58 AM   #2802
GLS
Addon Developer
 
GLS's Avatar
Default

Here's something I did with 5 minutes on google and maybe 1h converting coordinates and placing vertices: the correct outline of the windows.
Code:
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...



Overhead windows are also out of place (as is the side hatch window).
Attached Thumbnails
Click image for larger version

Name:	windowA.PNG
Views:	90
Size:	13.6 KB
ID:	16889   Click image for larger version

Name:	windowB.PNG
Views:	92
Size:	14.4 KB
ID:	16890   Click image for larger version

Name:	windowC.PNG
Views:	92
Size:	13.6 KB
ID:	16891  
GLS is online now   Reply With Quote
Thanked by:
Old 12-05-2019, 09:20 PM   #2803
GLS
Addon Developer
 
GLS's Avatar
Default

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!!!
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.

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 is online now   Reply With Quote
Thanked by:
Old 12-08-2019, 11:56 AM   #2804
GLS
Addon Developer
 
GLS's Avatar
Default

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.
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...

---------- 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 is online now   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Addons > Addon Support & Bugs > Addon Developer Forums > Space Shuttle Ultra


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 12:28 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.