New Release D3D9Client Development

[jarmonik]

A request for help with implementing a new feature in the D3D9 client:

PR 294 contains a nice new feature to render the bright stars of the Hipparcos and Tycho datasets as a texture map, in addition to the current pixel rendering. I found some very nice high resolution maps here: https://svs.gsfc.nasa.gov/4851. To support this, I have extended the celestial sphere manager (CSphereMgr.{h,cpp}) to render (up to) two background texture sets:

I have taken a look at the code and noticed a small code conflict with the rendering code with "atmosphere_remake" branch which will replace the old FX framework with direct HLSL and constant buffers, that's the architecture that DX11 and Vulkan use, making the D3D9Client easier to translate in the future. I am not sure what's the best way to resolve this.

A) I could add the rendering modifications using the old FX framework to "stellar_background" branch to get it operational and then replace it when "atmosphere_remake" is ready for merge.
B) Or I could pull the changes from "stellar_background" to "atmosphere_remake" and make the rendering code changes in there. But in that case stellar background in D3D9 wouldn't be operational until atmosphere remake is merged. (which is hopefully no more than 7 days.)

I guess it might be easier to go with option (A)

 

[jarmonik]

Done. Being able to change the background image and intensity on the fly is actually great, nice. "ESA Gaia" is probably my new favorite.

 

[Ripley]

Any idea about when we "normal end users" will be able to see these new features?

 

[martins]

Any idea about when we "normal end users" will be able to see these new features?

Once this branch has been merged, you should be able to pick up the corresponding installation image as a build artifact from the github page:

• go to https://github.com/orbitersim/orbiter
• click "Actions"
• select the latest merge action
• download the Orbiter-x64 and/or Orbiter-x86 artifact.
• after unpacking, make sure to redirect the planetary texture search path to your existing Orbiter 2016 installation by setting the PlanetTexDir entry in Orbiter.cfg

 

[martins]

@jarmonik: I just spotted (and hopefully fixed) a bug in the 288 branch: The star background image was bleeding through the atmosphere background colour because it wasn't scaled with the background level. I think I fixed that in all clients including D3D9 with the last commit, but since I don't really know my way around shader code, it's probably best if you double-check.

 

[Ripley]

Once this branch has been merged, you should be able to pick up the corresponding installation image as a build artifact from the github page:...

Thanks Martin, do I need to have an account?
I sounds easy, but I can't seem to be able to find (or understand how to find) what you posted.

 

[martins]

Thanks Martin, do I need to have an account?
I sounds easy, but I can't seem to be able to find (or understand how to find) what you posted.

@Ripley: you are right, I just realised that the build artifacts are available as download links only if I am logged into my github account. I had assumed that these are accessible to everyone.

Does anybody familiar with github know how to make the build artifacts public? Is it a case of changing file or directory permissions?

 

[jarmonik]

@jarmonik: I just spotted (and hopefully fixed) a bug in the 288 branch: The star background image was bleeding through the atmosphere background colour because it wasn't scaled with the background level. I think I fixed that in all clients including D3D9 with the last commit, but since I don't really know my way around shader code, it's probably best if you double-check.

It looks perfect. Also tested coordinate and force vector displays and they seem normal to me.

 

[martins]

Thanks. I have merged this branch now.

 

[martins]

@Ripley: After a lot of trial and error I have updated the github workflow script to generate a "pre-release" package with the latest development state every time a commit or PR is pushed to the main branch. You should be able to access it from here: https://github.com/orbitersim/orbiter/releases.
Click on "Assets" and download the x86 and/or x64 package. This should be accessible to everyone, but let me know if you have any more problems. Just remember that this is the bleeding edge, so potentially unstable and no guarantees for backward and forward compatibility.

 

[Fabri91]

Can confirm that I'm able to download the latest release this way, even when not logged in. Thanks for setting it up!

 

[Ripley]

I logged in and downloaded it yesterday (I forgot I already had an account, thanks anyway).
At first I was not able to make my PlanetTexDir edit persist (maybe I forgot a trailing backslash), now it's fine.
I even resurrected one of your old posts to read it again just to be sure:

Saving space with multiple orbiter installations

Since multiple orbiter installations seem to be quite popular, and can take a significant amount of disk space, it occurred to me that many people may not be aware of a fairly easy way to save space: Most of the disk space of an orbiter installation is taken up by the Textures and Textures2...

www.orbiter-forum.com

 

[Ripley]

• after unpacking, make sure to redirect the planetary texture search path to your existing Orbiter 2016 installation by setting the PlanetTexDir entry in Orbiter.cfg

Hi @martins I've just noticed that this new parameter is not present in Orbiter2016 cfg file, which only has TextureDir and HitexDir.
What is its difference vs. the other two older variables? Sorry to ask here, but I couldn't find the pdf manual.

 

[kuddel]

You have to set
EchoAllParams = TRUE in the cfg file.
Then start and shutdown the LaunchPad window. After that all parameter will be written to the config.
This behaviour has not changed, it just is hidden as it always was

 

[Ripley]

Yes I know, and I did it, that's why I saw the 3 variables.
My question was different, thanks anyways.

 

[kuddel]

Oh sorry, now I see!
But still, every "Dir"- parameter seems to be there:

; === ORBITER Master Configuration File ===
EchoAllParams = TRUE
LPadRect = 320 102 1068 744

; === Subdirectory locations
ConfigDir = .\Config\
MeshDir = .\Meshes\
TextureDir = .\Textures\
HightexDir = .\Textures2\
PlanetTexDir = .\Textures\
ScenarioDir = .\Scenarios\

; === Logical parameters ===
...

(haven't run & checked the current HEAD revision, though)

 

[jarmonik]

Hi @martins I've just noticed that this new parameter is not present in Orbiter2016 cfg file, which only has TextureDir and HitexDir.
What is its difference vs. the other two older variables? Sorry to ask here, but I couldn't find the pdf manual.

PlanetTexDir is a new feature in Open Orbiter and doesn't exist in Orbiter 2016. It will let your Orbiter to fetch planet textures form an other Orbiter installation. The two other parameters are search paths for mesh textures.

 

[martins]

Another request to D3D9 developers: In PR 309 I am adding tick labels to the various grids projected on the celestial sphere, to make them actually useful. The labels are implemented as a mesh and texture (rather than via Sketchpad). It works for inline and D3D7 client. I also tried to implement it for D3D9, but couldn't get the texture alpha channel to be applied. I am guessing there is just some small setting missing, but instead of me fishing around in the dark, it may be quicker if a D3D9 client developer has a look and fixes it. Also please check if the rest of the D3D9-related stuff I wrote for this PR is ok. Thanks!

 

[jarmonik]

Another request to D3D9 developers: In PR 309 I am adding tick labels to the various grids projected on the celestial sphere, to make them actually useful. The labels are implemented as a mesh and texture (rather than via Sketchpad). It works for inline and D3D7 client. I also tried to implement it for D3D9, but couldn't get the texture alpha channel to be applied. I am guessing there is just some small setting missing, but instead of me fishing around in the dark, it may be quicker if a D3D9 client developer has a look and fixes it. Also please check if the rest of the D3D9-related stuff I wrote for this PR is ok. Thanks!

I have added a rendering tech for the labels and checked the other sections as well and they look fine to me. I noticed that some labels appear as black boxes but I guess that it's simply not finished yet.

 

[martins]

Thanks for that! There shouldn't be black boxes but I'll check that when I get home.