SSU Development Thread (2.0 to 3.0)

[GLS]

Done

I'll commit the updated manual and release file list a few minutes then.
As we now have another week :facepalm:, and right now I'm on a "runway mood", I was thinking of adding the White Sands runways to SSU. But as the tarmac runway textures don't really look good as lakebed runways, I had the idea to make a texture for the lakebed runways. And then I realized this could fix the Edwards lakebed runway issues. I think this is worth doing as even with super-duper-high-quality surface tiles/textures the markings on those lakebed runways don't look good. This way we could have the real markings for each runway. The only limitation I see in this method is that the intersection between runways won't be accurate...

 

[GLS]

Quick test:

 

[jarmonik]

Someone made a query about increasing VC MFD resolution in D3D9, there's nothing we can do in D3D9 but it might be possible to create high resolution MFDs by using ExternMFD class instead of standard MFD. ExternMFD allows to define the resolution of rendering surface as well as real time scaling of the surface. The ExternMFD sample code blits the drawing surface into a window but I see no reason why it couldn't be blitted into a texture and then attached to MFD screen mesh group in VC.

A major setback is that ExternMFD doesn't save MFD's state in a scenario. If you have a source code for MFD it might be possible modify it in a way that vessel class could handle the content saving by calling MFD::WriteStatus() and MFD::ReadStatus().

 

[GLS]

Someone made a query about increasing VC MFD resolution in D3D9, there's nothing we can do in D3D9 but it might be possible to create high resolution MFDs by using ExternMFD class instead of standard MFD. ExternMFD allows to define the resolution of rendering surface as well as real time scaling of the surface. The ExternMFD sample code blits the drawing surface into a window but I see no reason why it couldn't be blitted into a texture and then attached to MFD screen mesh group in VC.

A major setback is that ExternMFD doesn't save MFD's state in a scenario. If you have a source code for MFD it might be possible modify it in a way that vessel class could handle the content saving by calling MFD::WriteStatus() and MFD::ReadStatus().

Thanks, but I think SSU is moving away from having the MFD displays in the VC. We'll draw the shuttle's own displays in the VC (somehow) and leave the MFDs to be run in the ExternMFD. This way we could have the 1024x1024 resolution of the original shuttle screens.

 

[Urwumpe]

Thanks, but I think SSU is moving away from having the MFD displays in the VC. We'll draw the shuttle's own displays in the VC (somehow) and leave the MFDs to be run in the ExternMFD. This way we could have the 1024x1024 resolution of the original shuttle screens.

Well, 512 x 512 would already be impressive enough. :lol:

 

[GLS]

Well, 512 x 512 would already be impressive enough. :lol:

Yes, that would already be 4 times the drawing area, which would make things look much better, especially text. Not sure about the performance of the whole thing... this change should be done at the same time, or after, the dps display updates, so we can use the correct refresh rate. Also, having each MDU doing it's drawing at different times would help "spread" the load.

 

[Urwumpe]

Yes, that would already be 4 times the drawing area, which would make things look much better, especially text. Not sure about the performance of the whole thing... this change should be done at the same time, or after, the dps display updates, so we can use the correct refresh rate. Also, having each MDU doing it's drawing at different times would help "spread" the load.

Of course. We could possibly also use a producer-consumer pattern there and let another thread paint the MDU screens in parallel.

 

[jarmonik]

Of course. We could possibly also use a producer-consumer pattern there and let another thread paint the MDU screens in parallel.

In a multi-threaded solution it would be practical to use GDI/Sketchpad to paint the MDUs into a surface stored in system memory to avoid locking video memory and stall the GPU. Then blit the painting surface into a texture.

 

[Urwumpe]

In a multi-threaded solution it would be practical to use GDI/Sketchpad to paint the MDUs into a surface stored in system memory to avoid locking video memory and stall the GPU. Then blit the painting surface into a texture.

That would be much slower than locking the video memory between the rendering cycles of Orbiter.

 

[kerlix]

Sorry if this has been answered, but is there is suitable ISS addon that works well with the latest release of SSU?

And if so, would it just require altering the scn file?

I still have no idea how to translate info from other MFDs into parameters that the SSU GPC can use. So I'm a long way off from rendezvous and docking. And if anybody can also provide help on that, I'd really be grateful. I understand things like the default MFDs can be opened via the F4 menu (which is what I usually use), as well as IMFD and TransX.

I guess my problem is trying to find information on, as well as calculate, the NC/NH burns.

And finally, I know that none of the missions have payloads yet. Does this effect the OMS-2 burn data that comes with the FDF's? I've just been using those but without the added weight of payloads, I could see inaccurate burns happening. I looked everywhere to see if someone had developed a spreadsheet or anything but came up empty handed.


Sent from my iPhone using Tapatalk

 

[Urwumpe]

Sorry if this has been answered, but is there is suitable ISS addon that works well with the latest release of SSU?

Donamys ISS A to Z add-on is the best recommendation I can make there.

[ame="http://orbithangar.com/searchid.php?ID=5633"]US ISS A to Z v.3[/ame]

It uses parts of Thortons ISS add-on:

[ame="http://orbithangar.com/searchid.php?ID=3737"]International Space Station v.3.2[/ame]

 

[Wolf]

Sorry if this has been answered, but is there is suitable ISS addon that works well with the latest release of SSU?

And if so, would it just require altering the scn file?

I still have no idea how to translate info from other MFDs into parameters that the SSU GPC can use. So I'm a long way off from rendezvous and docking. And if anybody can also provide help on that, I'd really be grateful. I understand things like the default MFDs can be opened via the F4 menu (which is what I usually use), as well as IMFD and TransX.

I guess my problem is trying to find information on, as well as calculate, the NC/NH burns.

And finally, I know that none of the missions have payloads yet. Does this effect the OMS-2 burn data that comes with the FDF's? I've just been using those but without the added weight of payloads, I could see inaccurate burns happening. I looked everywhere to see if someone had developed a spreadsheet or anything but came up empty handed.


Sent from my iPhone using Tapatalk

Hi kerlix,
I posted here the same issue a while ago but it seems to be difficult to find those data
http://orbiter-forum.com/showthread.php?t=35409

The good news is that some (unfortnately not all) os the STS missions FDF include a section called "attitude timeline" where you can find all the info you need for orbit insertion and rendezvous (OMS2, NC, NH, etc).
You can try to feed the SSU GPC with those datas and see if they work.
Good luck with your ISS Rendezvous!

PS About your ISS question: I would definetly reccomend the ISS AtoZ, by far the best ISS currently available!

 

[Urwumpe]

I don't want to scare anybody, but if your inbox gets a lot of mails from SF in the next days, its because I start filing tickets for the 4.0 version.

For now, its just the tickets for the Mission Editor/Workbench, but there will be more tickets as we decide on future work for that milestone.

 

[Donamy]

Donamys ISS A to Z add-on is the best recommendation I can make there.

US ISS A to Z v.3

It uses parts of Thortons ISS add-on:

International Space Station v.3.2

Only the Russian parts, but I don't sssupply them.

 

[DaveS]

Donamy: Do you think you could redo the mechanical section thermal blanket texture of the ODS to match the appearance of the real ones as opposed to the mockup that was made for the Atlantis exhibit? If you need photos, there's plenty in the ODS reference package I linked to earlier.

 

[Donamy]

I darkened it. What do you mean ?

 

[DaveS]

I darkened it. What do you mean ?

Take a look at the roughness of it. It also has alot of small squares that are not present in our current version:

 

[Urwumpe]

Take a look at the roughness of it. It also has alot of small squares that are not present in our current version:

Yes, its typical Russian thermal blanket, like often used also on the Russian modules. I am not sure, if such a texture is really easily done.

 

[GLS]

I just added the main runways at White Sands (I'll add the TAL training runway in the future). The issues experienced in D3D9 should now be minimal or non-existing. The runway lights aren't perfect as the parameters don't allow for more customization. The marker boards are missing as the meshes of existing ones have boards for both sides of the runway, and here only one side of the runway has boards.
Don't forget to add the texture names to the Base.cfg file.

 

[Urwumpe]

I discovered a UNIV PTG or stuck thruster bug in STS-1/On Orbit, there is a constant increasing yaw to the right, if you switch from VERN to PRI, the yaw increases much more rapidly. At about 32% fuel left, the thruster firing ceases, the rotation rate stays constant.

Switching to AUTO was not possible on Orbit DAP panel.

Only pressing and holding 1 on the numeric keyboard stops the thruster firing - something wrong with the usage of the thruster groups.