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

[Urwumpe]

Two words: branch, please.

Of course. :lol:

 

[Urwumpe]

Created a Branch "MultiprocessDPS" based on the current "OrbiterBeta" branch for further development. I'll keep it synchronized with any development branch we'll use later until merging it.

 

[GLS]

Finally switched to the trunk to see the changes to the OV model and there is a big hole in the PLB... :uhh:

In a quick look I saw that the bottom of the aft compartment isn't flat (I think it should be, but I could be wrong), and there are several places with "holes", i.e., things don't fit tight like gear doors, RCC panels.
I still have to open it in blender to see how it looks there, but the SB animation issue appears to be gone.

 

[DaveS]

Finally switched to the trunk to see the changes to the OV model and there is a big hole in the PLB... :uhh:

In a quick look I saw that the bottom of the aft compartment isn't flat (I think it should be, but I could be wrong), and there are several places with "holes", i.e., things don't fit tight like gear doors, RCC panels.
I still have to open it in blender to see how it looks there, but the SB animation issue appears to be gone.

Everything looks good here, except for the wing box hole. Did you rebuild the sources after switching?

 

[Urwumpe]

I decided to do some cleanup first in the new DPS branch before getting to real implementation work:

• Included CMake, because I started work cursing about the project files again
• Finished a findpackage script for CMake to select OrbiterAPI and configure paths. Can also be used for other add-ons
• Added a findpackage script for LibUltra, automatically configuring projects that want to use it.
• Removed duplicate files from LibUltra and ShuttleUltra
• Started removing the bloat from Atlantis.h. Its really a bad idea to reference EVERYTHING in Atlantis.h and reference Atlantis.h everywhere
• Working towards splitting compilation up into modules, so we don't need to compile all files when something changes in a single header.
• Moved shuttle orbiter specific code from LibUltra to SpaceShuttleUltra
• Including general purpose code in that place
• Included a "DPS Monitor" MFD to assist in development of the new DPS and later for debugging software.
• Plan to include support to create both ZIP and MSI style release packages

Something different: Any recommendations against including support for NASAs Procedure Representation Language in LibUltra? Its a XML format that replaces the old printed checklists in Orion. Could maybe also be useful for describing checklists in SSU or other add-ons, like the Project Apollo Checklist MFD does.

 

[DaveS]

This is what I have as far as the orbiter is concerned: https://www.dropbox.com/s/gobn82i4jzlvkdk/SSU_no_issues.jpg?dl=0

 

[GLS]

Everything looks good here, except for the wing box hole. Did you rebuild the sources after switching?

Yep.

---------- Post added at 07:25 PM ---------- Previous post was at 07:21 PM ----------

This is what I have as far as the orbiter is concerned: https://www.dropbox.com/s/gobn82i4jzlvkdk/SSU_no_issues.jpg?dl=0

Well, I can see a hole at the bottom of the tail in that image... :facepalm:
The anti-aliasing in D3D9 hides lots of seams that don't meet. Try MOGE and you'll see.

---------- Post added at 07:54 PM ---------- Previous post was at 07:25 PM ----------

Included CMake, because I started work cursing about the project files again

I've had no issues here since I cleaned up the projects back in VS2013. All temp files go in a folder and only the dlls (and a few files that can't be controlled) go into the Modules folder. Pretty much all the projects use the same settings, and libUltra is only included where needed, and in such a way that no conflicts arise in a multi-thread, multi-project compilation.

Removed duplicate files from LibUltra and ShuttleUltra

I remember doing something similar awhile ago... not sure if I removed them all.... :uhh:

Started removing the bloat from Atlantis.h. Its really a bad idea to reference EVERYTHING in Atlantis.h and reference Atlantis.h everywhere

Working towards splitting compilation up into modules, so we don't need to compile all files when something changes in a single header.

Yes, Atlantis.h is in many, many, many, ........, many, many places, and I've spent sometime in the past trying to reduce the need for it, mostly in the VC panels. About the modules thing, I think VS is smart enough (most of the times :shifty to only compile what is needed. If one change causes the whole project to be rebuilt, then IMO we need to do a better job with the includes. :shrug:

Included a "DPS Monitor" MFD to assist in development of the new DPS and later for debugging software.

I'd prefer something "external" to the vessel, or something that we can easily "hide" before a release.

Plan to include support to create both ZIP and MSI style release packages

What is the need for the MSI? What install options do we need?

Something different: Any recommendations against including support for NASAs Procedure Representation Language in LibUltra? Its a XML format that replaces the old printed checklists in Orion. Could maybe also be useful for describing checklists in SSU or other add-ons, like the Project Apollo Checklist MFD does.

How would things be displayed to the user?

 

[Urwumpe]

I'd prefer something "external" to the vessel, or something that we can easily "hide" before a release.

No problem to make it a separate MFD, all needed communication between DPS and MFD would be via a single DPSArchitectureModel interface anyway.

What is the need for the MSI? What install options do we need?

Well, it would make it easier to remove old files from the system before installing a new version of it, compared to ZIP. Also the tools for it are already on any development system of us, it is just a configuration, CMake handles that pretty well.

How would things be displayed to the user?

No concrete idea yet. A MFD like Project Apollo uses in the same style would be a good reference, but should I get some better information about the eProc display for Orion rendering such XML files, I would go that path.

 

[GLS]

Well, it would make it easier to remove old files from the system before installing a new version of it, compared to ZIP. Also the tools for it are already on any development system of us, it is just a configuration, CMake handles that pretty well.

Wouldn't that be something for an "addon manager" to do?

No concrete idea yet. A MFD like Project Apollo uses in the same style would be a good reference, but should I get some better information about the eProc display for Orion rendering such XML files, I would go that path.

IMO there are 2 ways:
1) we show stuff in a dialog, which is very flexible on what is shown and it would work on any vessel;
2) we put checklist 3D models in the VC and somehow write things into there, which would be a total PITA to manage, and performance wise not a good thing.

 

[Urwumpe]

1) we show stuff in a dialog, which is very flexible on what is shown and it would work on any vessel;
2) we put checklist 3D models in the VC and somehow write things into there, which would be a total PITA to manage, and performance wise not a good thing.

Or put it into a MFD and display it via ExtMFD.


Not sure how terrible 2) really would be, if we are not painting the textures in every timestep. Maybe it could be even better than a MFD. But I suspect, it requires some framework to be useful.



1) Would likely be the best approach in performance, but 2) way more immersive. Since both would require the same renderer, why not go both ways?



Starting with 1) and later adding the option of 2).

But first of all, I rather want to have other things implemented there before doing this. For example, I would rather want the PRL for adding AI crew and MCC to SSU.

 

[GLS]

Updated ticket #177 with the most recent list of Orbiter.msh issues.

 

[GLS]

As I got a 2-3fps launch, I decided to check the graphics stuff and found that we went from a 128KB texture for the SRBs (RSRM_Casing.dds) to a 2MB texture, which is pretty much all white! There is another very similar file for the other SRB, so that makes it twice the pain (if different files are needed for left/right, then the file names should be consistent, otherwise nobody knows what is going on). Add the fwd and aft skirt textures, which also grew a lot = slide show launch, in which things are stuttering even at x0.1. Are files this large really necessary????

 

[Donamy]

We definitely need a lite version.

 

[GLS]

We definitely need a lite version.

It would only be a graphics version, as I doubt NASA had code/subsystems that it didn't need... :shrug:
But even that would not be easy or quick to do, as man power is short... animations would probably be a PITA if groups change place or disappear...
IMO, if things are kept "sane" and we delete the +/-30% hidden stuff currently in the meshes, we should keep an acceptable performance.

 

[Urwumpe]

It would only be a graphics version, as I doubt NASA had code/subsystems that it didn't need... :shrug:
But even that would not be easy or quick to do, as man power is short... animations would probably be a PITA if groups change place or disappear...
IMO, if things are kept "sane" and we delete the +/-30% hidden stuff currently in the meshes, we should keep an acceptable performance.

We already optimized rendering well for performance lately, so there isn't really a big potential left. All I could imagine is adding low res versions of the launch pads for rendering at bigger distances before orbiter completely removes them from rendering.

The particle streams are a bit excessive IMHO, they cost a lot of performance during launch when appearing in the view.

 

[GLS]

We already optimized rendering well for performance lately, so there isn't really a big potential left. All I could imagine is adding low res versions of the launch pads for rendering at bigger distances before orbiter completely removes them from rendering.

The particle streams are a bit excessive IMHO, they cost a lot of performance during launch when appearing in the view.

The current Orbiter.msh is about 11MB down from 14MB, and it still contains many triangles that are doing nothing, so there is still performance left there. The MLP also has tons of stuff that can go (the pipes in the T0 umbilicals are are filled with triangles that are doing nothing), the pad base also has tons of triangles that can go, the same for the water tower. We could probably add FLAG 1 (I think) to some groups that we don't need have shadows (I already did that for all the times we hide a group, so it's shadow is also "hidden"). Textures are a bit tricky, but we could probably save one or 2 is we organize things.
I think that there are many "small bits" we can do, that by themselves aren't much, but when combined would help a lot.

About the particle streams, it seems they cost performance even when not in view, which is something we can't control... but we can control their generation rate and lifetime.

 

[Urwumpe]

But well, its a lot of effort for a tiny gain now. But year, we need a better quality assurance there, hidden faces should be prevented before they get discovered in the meshes.

 

[GLS]

But well, its a lot of effort for a tiny gain now. But year, we need a better quality assurance there, hidden faces should be prevented before they get discovered in the meshes.

I think that when pipes are created, by making several cylinders, the cylinder "caps" aren't removed... which causes a big waste. Same for cubes and rectangular structures.
After I finish with the entry stuff, I can help with the cleaning, but some things have to be done by "experts" as I don't know the details of the model.

 

[GLS]

DaveS, I'm trying to check the gear touchdown points (I'm fine tuning the damping and stiffness parameters) and I see that the NLG animation axis is defined a bit forward than what I think is correct. There are coordinates for the gear deploy axis in diagram 13.1 of JSC-11174.

 

[DaveS]

I'm currently working on addressing the mesh issues in ticket#177. I'm having some issues understanding the following:

* face missing inboard of salad bowls?
* some kinks and holes around the nose cap, at the 5 and 7 o'clock positions when viewed from the front

I haven't found anything that matches that above descriptions in the mesh, so screenshots would be helpful. They always with mesh issues, so please always try to include them.