SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]
- Thread starter DaveS
- Start date
- Status
GLS
Well-known member
So how is this CISS situation going to be resolved? I'm about 3 or 4 groups from finishing the cleanup on the CISS_CentaurG_Prime mesh.
GLS
Well-known member
I said I'd work the CISS at 1:36 PM...
About you not being need, of course you are and there are still tons of work to do: pads, ETs, MLPs all have tons of hidden triangles to delete, and there are still tons of things to model (the VC comes to mind).
About me temporarily "taking over" the Orbiter.msh, for months I listed issues that for some reason you didn't fix, and given that this is the "main" mesh, I'd like a crack at it to put these issues to bed. :shrug:
---------- Post added at 05:32 PM ---------- Previous post was at 03:36 PM ----------
Committed a cleaner CISS Prime. I'm still cleaning the DEPLOYMENT_ADAPTER group, but the rest should be done (got about a 7% reduction), and if it applies, it can be copied to the (non-prime) CISS, and/or worked in whatever manner it may be need.
Of note are the following issues:
- CSS_BULKHEADS has vertices in the middle of surfuces, are they really needed?
- CSS_BULKHEADS has missing faces in bottom ends and they don't connect to yokes
- inner-most hole in PROPELLANT_DISCONNECT_PANELS has faces across it
- DA_ROTATION_ARM has flaw in aft end
I'll finish cleaning the remaining group later today, but right now I need to get some fresh air.
---------- Post added at 09:20 PM ---------- Previous post was at 05:32 PM ----------
Finished the DA group clean up: almost 25% reduction. There are still a few dozen triangles on the inside and aft faces of the ring that I'm not sure if they needed.
I'm now finished with CISS_CentaurG_Prime.msh, shall I clean the CISS_CentaurG.msh, and/or the Centaurs, or just go back to the Orbiter.msh?
---------- Post added at 11:25 PM ---------- Previous post was at 09:20 PM ----------
Just created the "omsrcs" branch for future work in those systems, and dumped some work I've been doing "on the side" for the last months. Don't bother switching to there as it probably doesn't compile, and even if it does, it won't work as there is tons of stuff missing.
GLS
Well-known member
As promissed, more on the Ku-band antenna.
First let's start at the base and then work our way to the dish.
Your diagrams show the DA axis at Xo589 and Yo99.6, and the diagram 15.7-2 of JSC-11174 has Xo589 and Yo100, and the mesh, and code, don't seem to match these values (the 2 rings inside don't match those values, and I'm guessing that is part of the axis) (I'd go with Yo99.6 as it seems more "detailed").
The base structure of the DA gimbal (in the Orbiter.msh) has an oval shape, which I'm guessing is not correct, and should be centered at the axis.
On the DA deploy angle, the diagram 15.7-2 has 143º, but calculating the angle based on the detailed positions of the "Gimbaling Intersection" coordinates yields 143.747339º. We currently have 136.5º.
Then there is the radiator inner surface, which apparently should be at Yo99.6, but that is where the outer surface currently is. The diagram 15.7-2 isn't super clear, but my interpretation is that the indicated position is for the inner surface, so the rad would be off position by its own width.
I'm currently checking 14.1, and it shows the radiator panel outer surface at Yo99.6. Here's the rub through: The forward and aft radiator panels do not share the same thickness. The forward panels have a thickness of 0.9" while the aft panels have a thickness of 0.5". The difference in thickness comes from the extra Freon-21 tubes for the forward panels. The forward panels have 68 tubes while the aft panels have 26 tubes. The inter-tube distance is also different, 1.9" for the forward panels and 5.0" for the aft panels.
GLS
Well-known member
In my interpretation of the diagram (the lower left corner one), the solid line is the inner side of the rad, and the dashed line is probably the dynamic envelope of the radiator. Again, the diagram isn't clear, but it seems weird to indicate the position of the outer side of the rad, which doesn't really matter to the antenna, while not indicating the position of the inner surface, and do this in different line styles. :shrug:
Sadly there seems to be no more info on the rads in any other diagram.
Anyway, we can leave this rad business for after the antenna. You can go ahead on the antenna work if you want, as I'm correcting the side hatch window.
GLS
Well-known member
Well, r3103 reverted my work in correcting the position of the PLBDs hinges... it's so nice to work day and night for nothing... :facepalm:
I think I'll just quit the graphics work as a whole and just do code. We don't have the position of everything, but there is info for lots of parts, so the animations will have the correct coordinates. If the meshes aren't correct, that isn't going to be my problem anymore. :shrug:
I kept a TODO list that I'll post in the ticket in a few minutes.
Please advise when the meshes/textures are ready to release SSU 5.0.
One note for future work: I can't really do much work in the ascent side of things with the current "slideshow" launch performance, so cleaning the pads/MLP isn't a bad idea.
I think I'll just quit the graphics work as a whole and just do code. We don't have the position of everything, but there is info for lots of parts, so the animations will have the correct coordinates. If the meshes aren't correct, that isn't going to be my problem anymore. :shrug:
I kept a TODO list that I'll post in the ticket in a few minutes.
Please advise when the meshes/textures are ready to release SSU 5.0.
One note for future work: I can't really do much work in the ascent side of things with the current "slideshow" launch performance, so cleaning the pads/MLP isn't a bad idea.
Is it really that heavy? There's hardly any detail to either the hardstand, the FSS or RSS. The FSS/RSS meshes were made in 2011, when I definitely didn't have a very capable PC (as compared to today). I don't think I even had a discrete GPU back then, I was reliant on an IGPU and not very much RAM.
I think I actually considered 30/40 FPS acceptable back then. It wasn't until I got my current PC(that's now 3 years old, going by the oldest component) that I really got to experience fluid gaming (60+ FPS).
GLS
Well-known member
Well, the pad has tons of hidden crap (e.g., the tanks at SE and SW of the pad are duplicated...), but the big one is MLP... the crap in the umbilicals alone.... :facepalm::facepalm:
This downtime has allowed me to think about things and come to some conclusions. And I see your point about detailed and high resolutions and lower end machines. I now agree that by default, things should be easy on the hardware, that means lower resolutions and detail levels. So with that, I'd like you to resume your work on "de-detailing" the meshes. I on the other hand, will continue my work on hi-detail meshes/textures but as potential separate and independent add-ons that I'm the only one responsible for to the main SSU package. This will mean no more "trunk-breaks" from me. It also removes me from the critical path, as creating these hi-detail meshes/textures takes a long time as a lot of research is involved.
I think this solution could make everyone happy. I'll still be active in performing general research as before but anything else from me will be considered as "side-projects" and not official work.
I think this solution could make everyone happy. I'll still be active in performing general research as before but anything else from me will be considered as "side-projects" and not official work.
GLS
Well-known member
In just removing the hidden triangles, most meshes will decrease their size by 20/30%, and that is a HUGE gain in performance, both loading them and also during simulation, regardless of the level of detail.
IMO, there is no need for "de-detailing", at least not on a visible scale. The only time I did that was the PLB hose rollers, that are black, small and 16 in total, and using less vertices around them was easy gains. My policy is "we only need the vertices that are needed". But more important is having the detail correct, so it's not a waste of vertices.
Right now what the meshes need is consolidation: (1) deleting the hidden triangles (and later some optimizations) and (2) fixing what exists now. Then, new stuff can be added with confidence. If instead of fixing these issues NOW, we keep adding more things, tomorrow we will have the same issues, plus issues in the new stuff, as it was build on not-so-solid foundations. Ignoring the problems doesn't make them go away, it will only serve for them to multiply.
The "trunk-breaks" are resolved by having major work being done in a branch, like a new VC, or the entry stuff. There is no problem in doing "small work" in the trunk.
GLS
Well-known member
Just so we are clear, I'm now alone working in SSU?
If so, well... SSU 5.0 will take many months to come out (not that it was around the corner). :facepalm:
If so, well... SSU 5.0 will take many months to come out (not that it was around the corner). :facepalm:
I feel sorry I cannot be of any help. Said that I am afraid you're pretty much alone (with Dave) on this project. If I remeber well this addon was started more than 12 years ago (!) with several guys on it, now we are down to 1/2 people. This is not a full time job, you're doing this in your spare time (and man I appreciate your efforts and results) but without more manpower in the project I seriously doubt we will ever see an SSU version that goes beyond beta, or maybe your grandchildren will.
It 's really a shame for Shuttle enthusiasts like me.
GLS
Well-known member
I think I can keep pushing SSU forward (if I didn't think so, I'd quit), but it's just going to take more time. This next release is going to hurt, as there are many meshes to clean and fix, but afterwards it should get better.
GLS
Well-known member
That's the reason I started to look at the meshes, because its starting to look like a broken record. I think the visuals (and the code as well) will never be *perfect* for a number of reasons, with the most obvious reasons being (1) that we don't know the details of every part and, (2) time. The best we can do is to take the info that we have and make those parts correctly, and what we don't know we obviously make up.
Then there is the more recent issue of "modeling quality", which is visibly costing performance.
IMO, both of these issues are worked only once, and then it's done and dusted. :shrug:
The trick here is actually working them.
If you want to complain about something that is 12 years old, then just take a look at our "temporary" DPS. That one alone has been on the docket for that long. Right now, it is THE road block to implementing more systems. Even the Ku band system and PLBD system is only half-implemented because we're still waiting for that "all-powerful brand new" DPS that's "just around the corner".
I'm thinking that it should be the focus of the next release, not the VC. Just exactly will a new VC give us that we already don't have? It will still run into the DPS Roadblock no matter how good looking and accurate it is. I know I'd feel 10x as motivated to get back into the grind if we weren't essentially dancing around an issue that should have been resolved years ago.
Sorry if this seems like a rant, but I just had to get this out there.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
I still can't code for a while, so consider this as an outsiders comment, please. I am no longer an active contributor.
- I think, what mostly disturbs people about the progress (or the perceived lack of it), is that there is no true Roadmap. Not, that you are too few hands for too much work. Who doesn't respect the work done in the past 12 years doesn't deserve to be heard.
- Especially the mesh work simply just happened, usually without anybody complaining that unknown work is done or complaints about unknown requirements on the meshes. Except those times when release urges again and people test the current state of the project.
- I would recommend some better transparency there, tell what needs to be done and what you are fixing next. Maybe make a shortlist of five "most annoying flaws" you are intending to fix in the next iteration of each mesh. Just the big list of issues on SF isn't a good indicator of direction.
- The DPS is a very complicated topic and requires time to focus and plan things. Its better to "drill thinner boards" there, if there are too few development resources. Its current architecture gets the job done, but its sure not in a state that makes it easy to develop further.
- Also, there seems to be a lack of agreement, what the next major project milestone should be. Again, I can't contribute code, so I won't tell you what this milestone should be, but you should find an agreement there.
- Status
Similar threads
