New Release D3D9Client Development

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

 

[martins]

@jarmonik : I think I fixed the problem with the black elevation grid labels. It seems that the texture needed to be reapplied. I also slightly modified the label tech to use the grid colour for the labels, and only pull the alpha channel from the texture. Having grid and labels in the same colour makes it visually easier to connect them, than having all labels in white.

It would be good if you checked my edits to the shader file. It seems to work, but I just guessed the syntax, so maybe there is a better way of doing this.

When you are happy, I think it's ready to merge.

 

[jarmonik]

@martins I didn't notice earlier that texture was set to a device instead of an effect. It's ok that way but one must ensure a correct index bind from a shader side so that c++ and fx use the same index. Therefore added "register (s0)" in the shader file.

Go for merge.

 

[BrianJ]

Hi,
can anyone tell me how D3D9 Graphics Client is currently handling meshes for celestial bodies? e.g. asteroids, comets, etc.
Default Orbiter2016 rendering requires a 1m radius mesh and scales it by the size in the body's .cfg.
The D3D9 Graphics Client I'm using (very old I think, R1) requires a full-scale mesh.
Any change to that these days? Or planned?
Many thanks,
BrianJ

 

[martins]

I can't speak for the D3D9 client with any authority, but since the source data (meshes, tile elevation files) are shared between all clients, it stands to reason that they must have compatible scaling strategies.

Currently, there are two separate ways of defining non-spherical celestial object surfaces: either by defining a single mesh for the entire body, or by using the multi-level quad-tree tile strategy described in Doc/PlanetTextures.pdf. The former is mainly used for small bodies which don't need a scalable approach (and which are not landed on, since there is no collision mechanism in place other than a virtual sphere at the mean radius). The latter is used for larger bodies, where rendering the entire surface even when in close proximity would be prohibitively inefficient, and where vessel-surface interaction handling is important.

I am assuming you are referring to the whole-mesh version - is that correct? The data format for the quad-tree approach should be reasonably well described in the documentation, but let me know if anything is unclear.

As regards the whole-mesh approach, you are correct - the vertex coordinates are expected in units of the planet 'Size' parameter (as defined by its config file). This was originally done for internal reasons (to make the transformation matrices used by the renderer compatible with the other planet render mechanisms), but it also has the added benefit of allowing to change (or correct) the planet size by changing just a single config parameter, rather than having to scale the entire mesh. This is how the DX7-based engines (inline and D3D7 client) are handling it. If the D3D9 client is doing something different I am unaware. Maybe to test it you could try the latest Orbiter development build from the github page. This should minimise the risk of using an out-of date D3D9 client.

In general, I would discourage the use of whole-mesh rendering strategies for new projects, for the above mentioned limitations. Using the quad-tree approach is a bit more complex, but is more versatile. In any case, I have no plans of changing the way the whole-mesh rendering works (other than maybe eventually phasing it out).

 

[Abloheet]

Is there anyway one can convert the meshes for asteroids and minor gas giant moons(available as add-ons) into the quad tree format to get Landable surfaces?

 

[BrianJ]

Hi martins

I am assuming you are referring to the whole-mesh version - is that correct?

that's correct.
For any celestial body that has a real-world height map, or for anything that will be landed on, I would definitely go with the elevation quad-tree option. But, since I'm too dim to figure out how to automate the required image processing (resizing, chopping into squares, adding pixel rows and columns, etc.), making a whole-mesh is only about 5% of the work, just for a bit of eye-candy.
Anyhow, I find the most recent D3D9 GC that I have, version 4.11 (07 Sep 2020) does indeed use the same mesh-scaling-method as default Orbiter2016 (unlike the old D3D9 GC version 2.1 that I have in my main Orbiter2016 installation). Very good! I can go with the "unit radius" mesh.

Many thanks,
Brian