SSU Development Thread (2.0 to 3.0)

[SiameseCat]

There seem to be some issues with the new mesh.

 

[DaveS]

There seem to be some issues with the new mesh.

I forgot to check in the updated Atlantis.cpp, this is now done.

 

[SiameseCat]

There seem to be some issues with the new mesh using the default Orbiter graphics client (everything looks fine using the DX9 client):

 

[DaveS]

There seem to be some issues with the new mesh using the default Orbiter graphics client (everything looks fine using the DX9 client):

I'm not sure where the problem is. Is this a high priority or can we just live with it for now?

 

[SiameseCat]

I'm not sure where the problem is. Is this a high priority or can we just live with it for now?

It needs to be fixed before release, so I would consider this fairly high priority. I don't want to force people to use the DX9 client to run SSU.

 

[DaveS]

It needs to be fixed before release, so I would consider this fairly high priority. I don't want to force people to use the DX9 client to run SSU.

I'll see if I can't track the the problems.

---------- Post added at 07:43 PM ---------- Previous post was at 06:28 PM ----------

I have checked in an update that should hopefully fix the problems. It isn't present on my install anymore so let me know if you still have it.

 

[SiameseCat]

The mesh issues have now been fixed.

 

[DaveS]

The mesh issues have now been fixed.

No other issues? It can't now be merged with the trunk?

 

[SiameseCat]

I'm working on fixing the ODS C/L camera and related issues (the docking port/attachment positions also need to be corrected). Once that's done, I'll merge the newmesh branch with the trunk.

 

[STS]

Just wondering, why you need it to work with the old inline client?

 

[SiameseCat]

Just wondering, why you need it to work with the old inline client?

The inline client is the default client used by Orbiter, and I don't want to force people to use an external graphics client so SSU works. Also, if the mesh doesn't work in the inline client, that indicates that there might be a problem somewhere with the mesh, so there might also be problems with future versions of the DX9 client or other graphics clients. I don't see any disadvantages in ensuring SSU works with the old graphics client, and it probably avoids a lot of bug reports from people who still use the Orbiter inline client.

---------- Post added at 06:36 PM ---------- Previous post was at 06:05 PM ----------

The 2.1-newmesh branch has been merged into the trunk.

 

[GLS]

Back in the SSU office for some days now, pretty much finished the helium system, just some tweeks remaining here and there and then I'll get back to you in a few days.
In the mean time there's a few issues I'd like to go over. Due to the change of mesh I need somebody to give me the positions of the LH2 backup dump vent, LH2 fill/drain, and the position of the center of the SSME nozzles at the exit of the nozzle (for the LOX dump vents).
Another thing: is anybody here using the default graphics client? I recently changed laptops and the default client now shows all kinds of "artifacts", black surfaces swirling all around the vehicle, sometimes there's missing parts on the orbiter and the swirling surfaces appear to be the orbiter textures. The more effects I turn on, the more likely this is to occur. And this only happens on SSU, DG & co. work fine. Using the D3D9 client everything is fine.
Probably not related to this, in both clients, in the STS-1 scenario the texture on the right side of the FRCS doesn't look right, and the textures of the ET umbilical and it's doors look like they have some offset. (Just looked at the SLC-6 launch scenario and there it shows a dark texture that looks like it belongs somewhere else)
Still on the textures, the ET burned texture that shows during second stage looks like it has some problems in the LOX feedline (it has some gray and red bands).
Back to STS-1, Columbia has the drag chute "place" in the tail, which did not happen until STS-50... (wrong mesh being used or there's only one mesh?)
Sorry about all the "complaining"... every thing else looks super!

 

[DaveS]

Back in the SSU office for some days now, pretty much finished the helium system, just some tweeks remaining here and there and then I'll get back to you in a few days.
In the mean time there's a few issues I'd like to go over. Due to the change of mesh I need somebody to give me the positions of the LH2 backup dump vent, LH2 fill/drain, and the position of the center of the SSME nozzles at the exit of the nozzle (for the LOX dump vents).

Check in what you got and I'll correct the positions.

Another thing: is anybody here using the default graphics client? I recently changed laptops and the default client now shows all kinds of "artifacts", black surfaces swirling all around the vehicle, sometimes there's missing parts on the orbiter and the swirling surfaces appear to be the orbiter textures. The more effects I turn on, the more likely this is to occur. And this only happens on SSU, DG & co. work fine. Using the D3D9 client everything is fine.

Could you post a screenshot? I corrected something like this in revision 1599 of the 2.1-newmesh branch.

Probably not related to this, in both clients, in the STS-1 scenario the texture on the right side of the FRCS doesn't look right, and the textures of the ET umbilical and it's doors look like they have some offset. (Just looked at the SLC-6 launch scenario and there it shows a dark texture that looks like it belongs somewhere else)
Still on the textures, the ET burned texture that shows during second stage looks like it has some problems in the LOX feedline (it has some gray and red bands).

This is a known problem due to the age of the Columbia/Challenger textures. Only the Discovery, Atlantis and Endeavour textures have been updated.

Back to STS-1, Columbia has the drag chute "place" in the tail, which did not happen until STS-50... (wrong mesh being used or there's only one mesh?)

There's only one orbiter mesh, so the early missions look out of place with the drag-chute equipped vertical tail. Besides there's no code to deactivate the deployment of the drag-chute any way.

 

[GLS]

Check in what you got and I'll correct the positions.

hhmmm, that's the part that I was refering to in the begining of my previous post... there needs to be a discussion on whether I upload to the trunk of create a branch (need to read about that). Anyway I'd like to have everything done before upload. In the meantime I could post that portion of the code here...

Could you post a screenshot? I corrected something like this in revision 1599 of the 2.1-newmesh branch.

I'm using the last revision, and this happened before the merge.
Montage of the artifacts below. This shows the "bad" bug, the black planes that tend to desappear after it gets above the clouds. There's a "very bad" bug where the wings and nose are missing and there are orbiter textures "swirling" all around, so much that you almost can't see the vehicle.

 

[DaveS]

I'm using the last revision, and this happened before the merge.
Montage of the artifacts below. This shows the "bad" bug, the black planes that tend to desappear after it gets above the clouds. There's a "very bad" bug where the wings and nose are missing and there are orbiter textures "swirling" all around, so much that you almost can't see the vehicle.

I checked and it is present here as well. So far I have exonerated the orbiter, the pad, and MLP. I'm testing the ET and SRBs now.

 

[1hippienaut]

just finished downloading the 2 photos from dropbox DaveS
will get that area sured up and and theyre ready for Go
minus the FES area i have them ready at dropbox

 

[DaveS]

One on one testing reveals nothing wrong. All meshes are good. More troubleshooting reveals that that problem is with the vessel shadows. Deactivating that option clears the issue. I'm trying to track down the problem mesh(es).

 

[1hippienaut]

Challenger and Atlantis5thmod are almost completed
awaiting the newer versions of Columbia
i really appreciate those last 2 photos

 

[DaveS]

Problem mesh and mesh group have been identified. I'm in the process of fixing it now.

---------- Post added at 11:08 PM ---------- Previous post was at 10:56 PM ----------

I have checked in a updated orbiter mesh that should fix the problem. Please confirm that the problem is gone.

 

[SiameseCat]

hhmmm, that's the part that I was refering to in the begining of my previous post... there needs to be a discussion on whether I upload to the trunk of create a branch (need to read about that). Anyway I'd like to have everything done before upload. In the meantime I could post that portion of the code here...

Can you post a bit more information on what exactly is being changed? If you've already made all the changes required (and everything works) and the only thing left is to fix the positions to work with the new mesh, you may as well go ahead and check everything in, and DaveS can update the positions. The main advantage of creating a branch is that you can check stuff in (and potentially break existing code) without disrupting regular development. Creating a branch for the helium system is probably overkill.

I'm hoping to release SSU v2.1 with the new meshes fairly soon, once the remaining tickets on sourceforge are dealt with. How long will it take to complete the helium system work?