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

[DaveS]

Can you make a normal map that mimics the surface of the real rail? :hmm:

(And maybe use this normal map to maybe also replace some triangles, looks relatively high poly for a such a small part, but then, it might be seen from close)

It's indeed an object that can be viewed up close. The photo is rotated and cropped from this one which looks like it was taken from the aft flightdeck: https://spaceflight.nasa.gov/gallery/images/shuttle/sts-131/hires/s131e009470.jpg
Other hardware that appears prominently is the left forward radiator retract hose in its fully extended position, the elbow MPM for the SRMS and two of the drive mechanisms for the left payload bay door.

 

[Urwumpe]

It's indeed an object that can be viewed up close. The photo is rotated and cropped from this one which looks like it was taken from the aft flightdeck: https://spaceflight.nasa.gov/gallery/images/shuttle/sts-131/hires/s131e009470.jpg
Other hardware that appears prominently is the left forward radiator retract hose in its fully extended position, the elbow MPM for the SRMS and two of the drive mechanisms for the left payload bay door.

Exactly. Also, during an EVA or by using the payload bay cameras, the aft rails would also be visible from close.



But still, the rails are candidates that could be optimized by hiding them or reducing their poly count, while they are not visible or the observer is too far away.

 

[GLS]

If we "audit" the meshes and get rid of the hidden faces, that's already a big gain in performance at no expense in detail. IMO (other) optimizations can wait.

 

[Urwumpe]

If we "audit" the meshes and get rid of the hidden faces, that's already a big gain in performance at no expense in detail. IMO (other) optimizations can wait.

Sure. I think the audits are great tool.



Also we are still on the "good" side compared to recent standard hardware in terms of graphics, so the need to optimize is not that urgent yet.



Still, I wonder what to do/play with the next full release. And when the MMCAs come, will the SRMS also be ported to use them?

 

[DaveS]

If we "audit" the meshes and get rid of the hidden faces, that's already a big gain in performance at no expense in detail. IMO (other) optimizations can wait.

The the PLBD EVA handrails already have had all their hidden faces deleted so there's not much to do there.

 

[GLS]

Still, I wonder what to do/play with the next full release. And when the MMCAs come, will the SRMS also be ported to use them?

The Crawler is the other item on the TODO list for the release (after the small DPS upgrade and new Entry/TAEM/AL guidance)...

 

[Urwumpe]

The Crawler is the other item on the TODO list for the release (after the small DPS upgrade and new Entry/TAEM/AL guidance)...

If we but so much work into GNC... what about using it for some station building focus?

 

[DaveS]

If we but so much work into GNC... what about using it for some station building focus?

We do have this bug to worry about as far as the RMS is concerned. Also alot of RMS ops does involve the DPS but not GNC but rather SM. Namely SM 94 PDRS CONTROL. AFAIK we don't do SM in our barebone DPS only GNC so the CRT MAJOR FUNC switches on C2 and R11L are useless.

 

[GLS]

If we but so much work into GNC... what about using it for some station building focus?

Right now I'm trying to get to the runway, whatever altitude it happens to be. (btw, mainly I'm doing the "G" part, the rest can remain "cheated")
Rendezvous, good idea. Issue #1: launch into the correct plane... we can't do that well (especially with the pad being in the wrong place because of the Earth not being of the correct shape). Regardless of the shape of the Earth, I'd like to get all that IY-plane stuff working... but I only have 2 hands. Landing got "broken" with Orbiter 2016, so that gets priority. :shrug:

 

[Urwumpe]

Right now I'm trying to get to the runway, whatever altitude it happens to be. (btw, mainly I'm doing the "G" part, the rest can remain "cheated")
Rendezvous, good idea. Issue #1: launch into the correct plane... we can't do that well (especially with the pad being in the wrong place because of the Earth not being of the correct shape). Regardless of the shape of the Earth, I'd like to get all that IY-plane stuff working... but I only have 2 hands. Landing got "broken" with Orbiter 2016, so that gets priority. :shrug:

Well, lets see what can be improved there... But first let me let the star trackers see the light...

 

[GLS]

Just committed the final work in deleting hidden faces (there's more to do, but I'll leave that to the graphics department), this time it was the TAA, ODS and External Airlock.
The now usual list:
TAA
* ~6% reduction

ODS
* ~2% reduction
* sleeves might be a bit too expensive (over 25% of the mesh on a +/- small item)
* docking ring guide plates don't match ring or have a hole at the bottom outside part

> ExtAL
* ~10% reduction

> general
* match TAA, ExtAL and ODS materials to PLB
* are TAA, ExtAL and ODS handrails similar or not to PLB ones?
* hatch window frames appear to be non-concentric, making on side "smooth" and another with "steps" (don't know if this is correct or not)

And now I'll get back to the guidance world.

 

[DaveS]

There is a difference between the handrails in the orbiter PLB and on the TAA and Ext A/L and ODS. This photo of Columbia's payload bay for STS-107 shows the TAA handrails: https://www.dropbox.com/s/q3vl9l97bdglodt/02pd0977.jpg?dl=0

And this photo show's Discovery's Ext A/L/ODS being reinstalled in her payload bay following her OMDP-J3/OMM-3 at KSC: https://www.dropbox.com/s/8hn9bt8u3xedvoo/04pd1138.jpg?dl=0

 

[Urwumpe]

Does that have any impacts on the project right now?

 

[DaveS]

The orbiter is pretty much done at last. Now we need to discuss the texture situation. Should we go for Wolf's hi-res textures?

 

[GLS]

The orbiter is pretty much done at last. Now we need to discuss the texture situation. Should we go for Wolf's hi-res textures?

I read that they don't work in MOGE... so that's a no go...
No problem with a scaled-down version.

 

[Wolf]

I read that they don't work in MOGE... so that's a no go...
No problem with a scaled-down version.

Pardon me, what is MOGE?

 

[DaveS]

Pardon me, what is MOGE?

It's GLS's own name for the inline DX7 client ("orbiter.exe").

 

[Face]

It's GLS's own name for the inline DX7 client ("orbiter.exe").

Martin's Own Graphics Engine

 

[Urwumpe]

Pardon me, what is MOGE?

"martins own graphics engine"


Sounds way better than this cryptic dx7 or directx7....

 

[Wolf]

If the team is commited to the inline engine ok, but I have two points in my mind:
1) How many orbinauts still use DX7?
2) Does it make sense to "downgrade" an addon to the default GC or wouldn't it be better that the users upgrade their GC (free and harmless BTW) to meet the addon requirements?

Maybe there are other reasons behind that I ignore but to me it makes very little sense to down scale photoreal textures (unless this would be a munor res reduction which turns to be running well with DX7 with no or very little impact on the textures quality)