Space Shuttle Ultra 1.25 Revision B development

[DaveS]

Are they really separated? I think they would be used simpler as one mesh file, at least they should be made a single vessel for using it.

Once the orbiter is vertical, the aft sling is disconnected from the main sling that goes around the orbiter and moved away and lowered to the transfer aisle floor.

Then the OV is twisted 45°s and lifted and moved into the high bay.

Here's a photo from the STS-114 demate operation. The aft sling can be seen attached to 175 ton crane with the OTS in the background in the Low Bay. Discovery is coming from High Bay 1: http://www-pao.ksc.nasa.gov/kscpao/images/large/05pd1219.jpg

 

[Urwumpe]

Once the orbiter is vertical, the aft sling is disconnected from the main sling that goes around the orbiter and moved away and lowered to the transfer aisle floor.

Then the OV is twisted 45°s and lifted and moved into the high bay.

Here's a photo from the STS-114 demate operation. The aft sling can be seen attached to 175 ton crane with the OTS in the background in the Low Bay. Discovery is coming from High Bay 1: http://www-pao.ksc.nasa.gov/kscpao/images/large/05pd1219.jpg

Ok, thank you for scattering my dreams of this being an easy task. I'll take a look at it, maybe I can find a solution. That the aft sling is disconnected makes things not really easier, possible that I need to make the "other" crane move in concert with the controlled crane to keep the visual sane.

 

[DaveS]

That the aft sling is disconnected makes things not really easier, possible that I need to make the "other" crane move in concert with the controlled crane to keep the visual sane.

Well, it is really coordinated effort as it involves two independent cranes. And it does happen that the 175 ton crane ends up a bit behind.

So going the "simulated" route might be the best course of action.

 

[Urwumpe]

So going the "simulated" route might be the best course of action.

At least it would be simpler as going the maximum route, have the crane tow swing around below the cranes and destroy the sling and the Orbiter when you exceed the limits. Better simpler, but implemented in this century.

---------- Post added 03-20-10 at 10:25 PM ---------- Previous post was 03-19-10 at 11:10 PM ----------

I think we should really do something against the mesh sizes and loading times for SSU. This is no longer tolerable.

When just testing with the orbiter, I get 1 minute of loading until the scenario starts or CTD manifests. When I have VAB, Launch complex, MLP and stack in the scenario, the loading takes 12 minutes until I have the CTD.

I am pretty sure, the age of my computer only amplifies the problem, the loading times for other users should also be excessive. I'd rather have lower quality for the meshes, and faster loading, than waiting longer for loading, than it takes for reaching orbit.

 

[DaveS]

I think we should really do something against the mesh sizes and loading times for SSU. This is no longer tolerable.

When just testing with the orbiter, I get 1 minute of loading until the scenario starts or CTD manifests. When I have VAB, Launch complex, MLP and stack in the scenario, the loading takes 12 minutes until I have the CTD.

I am pretty sure, the age of my computer only amplifies the problem, the loading times for other users should also be excessive. I'd rather have lower quality for the meshes, and faster loading, than waiting longer for loading, than it takes for reaching orbit.

VAB: Well, not much to do about this one. It has a rather complicated and therefore triangle heavy interior.
LC-39: Well, lots of stuff here! And big stuff! So with the physical size, the need for more sides on the cylinders and more segments on the spheres goes up.
MLP: Here I guess it's the many things on the MLP that simply adds up to alot.
CT: Well, not much to do here. Maybe I could delete a few items but it isn't going to add up to alot.

 

[Urwumpe]

VAB: Well, not much to do about this one. It has a rather complicated and therefore triangle heavy interior.
LC-39: Well, lots of stuff here! And big stuff! So with the physical size, the need for more sides on the cylinders and more segments on the spheres goes up.
MLP: Here I guess it's the many things on the MLP that simply adds up to alot.
CT: Well, not much to do here. Maybe I could delete a few items but it isn't going to add up to alot.

That is not really helpful... In a world with only the VAB interior, I already get down to 8 FPS. Maybe somebody else can post better FPS. But practically, if the meshes are so huge and detailed, that we can only use them for rendering still images, we have not won by having so much visual beauty... or do you think we can wait a few computer generations and orbiter versions until we can use SSU properly?

It must be possible to solve this and get the meshes optimized. Even if we loose detail. At least for having the option to choose between maximum visual beauty and performance.

 

[Donamy]

I agree with you Urwumpe, people won't use a slide show. Practicality would dictate, non essential vehicles need to go on a strict diet.

 

[Urwumpe]

I agree with you Urwumpe, people won't use a slide show. Practicality would dictate, non essential vehicles need to go on a strict diet.

Yeah, at least to the point that we are in a good FPS range again. I want to get the assembly and turn around into SSU, but not at any price.

 

[Donamy]

The best way to do it, would be to swap some of the detail with textures.

 

[DaveS]

How about this as a compromise: As you're probably aware, you can select whether you want a hi-res mesh/textures of the default Atlantis by using a Launchpad plug-in called called Atlantis Configuration.

I have attached a screenshot of where you can find this config screen. And we do have it with our source code code in the project named "AtlantisConfig". How about we enable it for SSU? That way people can choose which option suits them! If they suffer from bad frame rates, they can easily switch over to the low-res set of meshes/textures.

I believe Kulch does this for his Project Energy add-on.

 

[Urwumpe]

Yes, something like that would be good. But for that we would need lower resolution textures and lower resolution meshes.

 

[DaveS]

Yes, something like that would be good. But for that we would need lower resolution textures and lower resolution meshes.

Already on it. Starting with the MLP. Just want to know what level of detail would be acceptable?

 

[Urwumpe]

Already on it. Starting with the MLP. Just want to know what level of detail would be acceptable?

Hard to tell... so that the ground structures on KSC as whole don't exceed the Shuttle stack poly count?

 

[DaveS]

Hard to tell... so that the ground structures on KSC as whole don't exceed the Shuttle stack poly count?

Well, consider it broken already! By the VAB interior structure! As I wrote eariler, not much to do about that. Unless Donamy has some ideas?

---------- Post added at 05:09 PM ---------- Previous post was at 04:39 PM ----------

Other than the FPS problems, how is things progressing otherwise?

 

[Urwumpe]

Well, consider it broken already! By the VAB interior structure! As I wrote eariler, not much to do about that. Unless Donamy has some ideas?

see above: Reduce details and use more textures. There is not much more that I see, apart of leaving it away completely. I could reduce the number of polygons rendered in the DLL by some ways like for example having the different bays of the VAB separated and rendered at lower resolution depending on visual distance, but the loading time wouldn't be much affected.

Other than the FPS problems, how is things progressing otherwise?

VAB can be tested stand-alone, have only a bug that the external mesh is sometimes not rendered. Possibly related to the large polycount, I have not yet found the cause in the code.

MDM testing goes forward, will include a simplified serial I/O interface for the subsystems since the SIO connections are purely point to point and not bus structures like the Shuttle Bus. No need to have more powerful connections for these and the whole complex communication involved.

Connections to the I/O modules shall be handled by the MDM acting as facade, this way we don't need to publish the IO module class outside the MDM.

The MDM assembler programming language is still in flux, Decided to change the syntax more towards the IBM High-Level Assembler language (Also used for the AP-101) for having a simpler way to declare labels inside the PROM source code. Is pretty necessary for getting symbol tables into C++ header files or simple tab delimited text files and not having to use fixed addresses for the PROM calls or module address.

When the MDMs are done, I can continue working on the GNC subsystems. Also I can do some work on the various pressure/temperature/voltage/etc sensors in the Shuttle.

 

[Donamy]

DaveS,

You can do a reduction on the meshes in AC3D, and it will retain the group structure.

 

[DaveS]

DaveS,

You can do a reduction on the meshes in AC3D, and it will retain the group structure.

Well, that doesn't work for the VAB unfortunately. Beyond about 70% reduction setting, it turns the structure into a badly looking mish-mash.

The VAB is what it is, unfortunately a frame hog. With that one its either all or nothing. No gray zones.

 

[Urwumpe]

The VAB is what it is, unfortunately a frame hog. With that one its either all or nothing. No gray zones.

Sorry, but this is unbelievable. Maybe you should take a step away from the VAB and watch it from some distance, for inspiration. :hello:

Maybe you can't let a piece of silicon do the optimization for you, but that is no reason to say, it is impossible to replace the 3D shape by a different one that just looks similar on the screen.

 

[DaveS]

Sorry, but this is unbelievable. Maybe you should take a step away from the VAB and watch it from some distance, for inspiration. :hello:

Maybe you can't let a piece of silicon do the optimization for you, but that is no reason to say, it is impossible to replace the 3D shape by a different one that just looks similar on the screen.

Are you thinking of replacing the 3D boxes with 2D planes? That could work. It's going to mean alot of rework but that should be able to bring down the VAB poly count but it still going to be rather high at around 25k to 35k.

Does that sound like a better range or is it still to high for a low-detail version?

 

[Urwumpe]

Are you thinking of replacing the 3D boxes with 2D planes? That could work. It's going to mean alot of rework but that should be able to bring down the VAB poly count but it still going to be rather high at around 25k to 35k.

Yes, exactly.

Does that sound like a better range or is it still to high for a low-detail version?

Well, if you are haggling with me, I think 25k is already a good step in the right direction, maybe you can get it down to 15k*

*Which just means I think 20k is a reasonable scale for the VAB in first iteration.


If you could get the general details a bit lower in polys, we could maybe get some budget free for adding detail meshes during run-time for having more level of detail near the camera. Like adding some detail to the next work platform near the player.