SSU Development Thread (2.0 to 3.0)

[GLS]

Check your mail

They were committed.

 

[Urwumpe]

There is a minimal divergence between the ODS ring extension rods and their drive units visible at full extension, the coordinates would need a minimal tweaking, but I would not consider the incident a show stopper.

 

[DaveS]

They were committed.

Now we have this. From what I can tell, the ODS is in the right spot but the External Airlock itself isn't. And the height issue is still undealt with leading to hatch/tunnel misalignment.

---------- Post added at 09:30 PM ---------- Previous post was at 09:23 PM ----------

As a solution to the ODS camera view issue, how about binding its offset to the offset of the airlock itsefl? Currently we have it like this:

case VC_DOCKCAM: //Docking camera
		DisplayCameraLabel(VC_LBL_DOCKCAM);
		SetCameraOffset(_V(orbiter_ofs.x + 0.00175, orbiter_ofs.y - 1.03/*EXTERNAL_AIRLOCK_POS.y*/ + 1.15, orbiter_ofs.z + pMission->GetExternalAirlockZPos() - 0.3275));
		SetCameraDefaultDirection(_V(0.0, 1.0, 0.0), PI);
		SetCameraRotationRange(0, 0, 0, 0);
		oapiVCSetNeighbours(-1, -1, VC_PLBCAMFL, VC_AFTPILOT);

---------- Post added at 09:37 PM ---------- Previous post was at 09:30 PM ----------

And here's the reason why the view is so bad. The ODS doesn't fit the airlock, or the offset is bad.

 

[GLS]

Now we have this. From what I can tell, the ODS is in the right spot but the External Airlock itself isn't. And the height issue is still undealt with leading to hatch/tunnel misalignment.

---------- Post added at 09:30 PM ---------- Previous post was at 09:23 PM ----------

As a solution to the ODS camera view issue, how about binding its offset to the offset of the airlock itsefl? Currently we have it like this:

case VC_DOCKCAM: //Docking camera
		DisplayCameraLabel(VC_LBL_DOCKCAM);
		SetCameraOffset(_V(orbiter_ofs.x + 0.00175, orbiter_ofs.y - 1.03/*EXTERNAL_AIRLOCK_POS.y*/ + 1.15, orbiter_ofs.z + pMission->GetExternalAirlockZPos() - 0.3275));
		SetCameraDefaultDirection(_V(0.0, 1.0, 0.0), PI);
		SetCameraRotationRange(0, 0, 0, 0);
		oapiVCSetNeighbours(-1, -1, VC_PLBCAMFL, VC_AFTPILOT);

---------- Post added at 09:37 PM ---------- Previous post was at 09:30 PM ----------

And here's the reason why the view is so bad. The ODS doesn't fit the airlock, or the offset is bad.

You look carefully, can see that the ODS camera position always depends on the external airlock position (pMission->GetExternalAirlockZPos()).
As for the ODS/airlock relative positioning I think I left the numbers it they were before.
About the ODS camera issues you are having... I can't reproduce them. I've tried both graphics clients, both airlock positions, with and without ODS, with and without TAA. Is anybody else having this camera issue?

 

[DaveS]

You look carefully, can see that the ODS camera position always depends on the external airlock position (pMission->GetExternalAirlockZPos()).
As for the ODS/airlock relative positioning I think I left the numbers it they were before.
About the ODS camera issues you are having... I can't reproduce them. I've tried both graphics clients, both airlock positions, with and without ODS, with and without TAA. Is anybody else having this camera issue?

Could you try in D3D9Client.cfg setting NearClipPlaneMode to 1 and VCNearPlane to 0.01? This is to avoid clipping of meshes in VC mode.

---------- Post added at 09:54 PM ---------- Previous post was at 09:52 PM ----------

And this shows that the ODS is off-center relative to the airlock. The red cross-hair is the center of the airlock hatch.

 

[GLS]

Could you try in D3D9Client.cfg setting NearClipPlaneMode to 1 and VCNearPlane to 0.01? This is to avoid clipping of meshes in VC mode.

Now it shows! That +/- "fixes" the airlock VC position view... there's no more clipping, but the main VC mesh still shows....
BTW, just noticed (and corrected) that the ODS sight wires were missing from the ring animation.

---------- Post added at 11:59 PM ---------- Previous post was at 09:08 PM ----------

So, are we moving the non-SSU specific documentation out of svn (and the release package) and into a dedicated download folder in SF? I would do it, but I don't have enough access at SF to add downloads, so either I get promoted or somebody with access do it please.

 

[Urwumpe]

So, are we moving the non-SSU specific documentation out of svn (and the release package) and into a dedicated download folder in SF? I would do it, but I don't have enough access at SF to add downloads, so either I get promoted or somebody with access do it please.

I have done it now, I also moved the old source code documentation there.

You can find the files now here:

https://sourceforge.net/projects/shuttleultra/files/References/

---------- Post added at 11:35 AM ---------- Previous post was at 11:20 AM ----------

We should better add a readme to the folder, so there are no doubts that this is not our own documentation (except the old source code documentation), but NASA publications.

Any suggestion how to formulate this? After all, its not GPL documentation.

 

[GLS]

I have done it now, I also moved the old source code documentation there.

You can find the files now here:

https://sourceforge.net/projects/shuttleultra/files/References/

Thanks! That's a load off the release package. I've corrected the release file list and will update with the updated manual. Is this enough? "Additional documentation containing background information about the shuttle and its systems can be found here (http://sourceforge.net/projects/shuttleultra/files/References/)."

We should better add a readme to the folder, so there are no doubts that this is not our own documentation (except the old source code documentation), but NASA publications.

Any suggestion how to formulate this? After all, its not GPL documentation.

How about: "These files are not part of Space Shuttle Ultra, but are instead NASA publications. They are provided here as background information about the Space Shuttle."

 

[Urwumpe]

How about: "These files are not part of Space Shuttle Ultra, but are instead NASA publications. They are provided here as background information about the Space Shuttle."

Done

 

[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]