# New ReleaseD3D9Client Development

#### jarmonik

Beta Tester
New build is out

New builds are published for Orbiter 2016 and Beta. Available from additional downloads section due to "Beta" status.

- Dave's reflection issue should be fixed
- Donamy's local lights issue in GenericCameraMFD should be fixed
- An attempt is made to fix Clipper's planet issue. Feedback required.
- Kuddel's local lights on lunar surface issue should be fixed.
- Some animation related bugs have been fixed. (Related to a use of negative amin state)
- Some other lunar surface rendering issues have been fixed.
- Cloud shadow intensity over water has been increased.
- Nightlights intensity has been increased. (Plenty of nights visibility problems exists. Missing from certain tiles. Corrupted textures ???)

- SSU Over saturation issue remains. Proper fix is still unknown.

---------- Post added at 22:50 ---------- Previous post was at 22:47 ----------

Can't run D3D9 as it shuts down my PC....
I am sorry to hear that. We have invested a quite lot of efforts to keep the client available as many as possible.

Do you know why it doesn't run ? If not then could you post the logs ?

#### Attachments

• 110.6 KB Views: 42
Last edited:

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
I can confirm that the issues reported by me has been fixed except for the over saturation issue. Two issues still remain though, shadows not affecting diffuse particle streams and of course the atmosphere rendering.

#### GLS

- SSU Over saturation issue remains. Proper fix is still unknown.
Is it only SSU? If so, then we might be doing something wrong... :shifty:

I am sorry to hear that. We have invested a quite lot of efforts to keep the client available as many as possible.

Do you know why it doesn't run ? If not then could you post the logs ?
I'm 99% certain it's hardware, probably not even the GPUs. It started to shut down the PC when I tried to run D3D9 in the NVIDIA, but it still worked in the Intel GPU. That was until a week or so ago, when it started to do the same in the Intel.
When I have time I'll try to debug this further, but you guys are almost certainly innocent.

#### Donamy

Donator
Beta Tester
New builds are published for Orbiter 2016 and Beta. Available from additional downloads section due to "Beta" status.

- Dave's reflection issue should be fixed
- Donamy's local lights issue in GenericCameraMFD should be fixed
- An attempt is made to fix Clipper's planet issue. Feedback required.
- Kuddel's local lights on lunar surface issue should be fixed.
- Some animation related bugs have been fixed. (Related to a use of negative amin state)
- Some other lunar surface rendering issues have been fixed.
- Cloud shadow intensity over water has been increased.
- Nightlights intensity has been increased. (Plenty of nights visibility problems exists. Missing from certain tiles. Corrupted textures ???)

- SSU Over saturation issue remains. Proper fix is still unknown.

---------- Post added at 22:50 ---------- Previous post was at 22:47 ----------

I am sorry to hear that. We have invested a quite lot of efforts to keep the client available as many as possible.

Do you know why it doesn't run ? If not then could you post the logs ?

Lighting issue in generic camera is fixed. :thumbup:

#### clipper

##### New member
New builds are published for Orbiter 2016 and Beta. Available from additional downloads section due to "Beta" status.

- Dave's reflection issue should be fixed
- Donamy's local lights issue in GenericCameraMFD should be fixed
- An attempt is made to fix Clipper's planet issue. Feedback required.
- Kuddel's local lights on lunar surface issue should be fixed.
- Some animation related bugs have been fixed. (Related to a use of negative amin state)
- Some other lunar surface rendering issues have been fixed.
- Cloud shadow intensity over water has been increased.
- Nightlights intensity has been increased. (Plenty of nights visibility problems exists. Missing from certain tiles. Corrupted textures ???)

- SSU Over saturation issue remains. Proper fix is still unknown.

---------- Post added at 22:50 ---------- Previous post was at 22:47 ----------

I am sorry to hear that. We have invested a quite lot of efforts to keep the client available as many as possible.

Do you know why it doesn't run ? If not then could you post the logs ?
I haven't been able to test it on my main hardware as I'm away, but I tested it on a different hardware and it seems to work perfectly well, so thank you very much for the effort and implementation.

By the way, I'm not sure if this is an issue with D3D9 or not, but when running the sim in Window with Taskbar mode, the MFDs in the default glass cockpit appear rather blurry as compared to when running with the other two full screen modes. I managed to replicate this on two different systems and I also compared it to Orbiter 2010 Window with Taskbar mode and the MFDs appear exactly the same as in the other two modes, so this seems to be an Orbiter 2016-specific issue.

EDIT: So after some more tinkering, it seems that this issue only occurs when using a Generic MFD size of 3 or less (which I do on a regular basis), otherwise the MFDs appear just as they should. However, this still isn't the case in Orbiter 2010 where MFDs appear smooth regardless of the selected size.

#### Attachments

• 89.9 KB Views: 34
Last edited:

#### fred18

Donator
Hello guys,

so, following to this conversation https://www.orbiter-forum.com/showthread.php?p=591865&postcount=40

I am here asking if possible to implement the following function in a test version of D3D9.

given a set of values which is:
- center coordinates
- size
- altitude
- shape factor

a rectangular terrain area will be rendered simply flat with possibly its edges smoothly linked to the surrounding and this rectangle will have the following characteristics:
- center at center coordinates
- long side = 2*size
- short side = shape factor * long side
- altitude = constant altitude as per input value

This flat area should be rendered overriding the terrain elevation tiles, simply when it's time to be rendered it will be flat instead of following terrain tiles.

If the set of values is removed then the regular terrain shall be rendered

I gave a look at the code of the tile manager of D3D9 and I am available to participate actively also to the coding part, but I need at least help to get a grasp of what is going on in those functions before I could touch anything there.

Will someone be so kind to make this test or to help me through it?

thank you very much in advance for any attention

Fred

Last edited:

#### jarmonik

Beta Tester
EDIT: So after some more tinkering, it seems that this issue only occurs when using a Generic MFD size of 3 or less (which I do on a regular basis), otherwise the MFDs appear just as they should. However, this still isn't the case in Orbiter 2010 where MFDs appear smooth regardless of the selected size.

I can reproduce the problem and I think I know what is causing it. Haven't had time to fix it.

---------- Post added at 07:48 ---------- Previous post was at 07:42 ----------

so, following to this conversation https://www.orbiter-forum.com/showthread.php?p=591865&postcount=40

I am here asking if possible to implement the following function in a test version of D3D9.

This flat area should be rendered overriding the terrain elevation tiles, simply when it's time to be rendered it will be flat instead of following terrain tiles.

If the set of values is removed then the regular terrain shall be rendered

I gave a look at the code of the tile manager of D3D9 and I am available to participate actively also to the coding part, but I need at least help to get a grasp of what is going on in those functions before I could touch anything there.

If you want to flatten a terrain in D3D9 then the easiest way is to do it in a vertex shader especcially if you can settle down to a circle instead of a square as an shape. You could feed a reference point (i.e. a vector [x, y, z, radius]) to a shader and flatten the terrain within the reference radius and smoothed the edges with vertex blending. Even if relatively easy to implement it has one major flaw that the orbiter's surface collision logic wouldn't take the modified terrain in count.

So, it would be more practical to create somekind of patch utility to apply a terrain flattening described in a configuration file to elevation data on a harddrive. Which would work without any modifications to the Orbiter or to the Client.

Back when I was working with the surface micro-textures, I got an idea of micro-elevation which would require some kind of tile-server in order to be implementable. Right now the Client requests a tile elevation file with it's tile-number from a harddrive. If a tile-server would be in place then the request/number would be passed to the server which would then load the file and preprocess the elevation data using a pixel-shader before forwarding it to a terrain manager for rendering. This would allow us to do more extensive real-time processing with the elevetion data. This idea came to a halt due to fact that the Orbiter's surface collision logic wouldn't know about the modified terrain.

So, technically it would sound more practical approach if the Orbiter would request the surface elevation data from the Client directly instead of loading it from a data file. Client could easily return elevation and normal for a requested lng, lat.

#### fred18

Donator
If you want to flatten a terrain in D3D9 then the easiest way is to do it in a vertex shader especcially if you can settle down to a circle instead of a square as an shape. You could feed a reference point (i.e. a vector [x, y, z, radius]) to a shader and flatten the terrain within the reference radius and smoothed the edges with vertex blending. Even if relatively easy to implement it has one major flaw that the orbiter's surface collision logic wouldn't take the modified terrain in count.

So, it would be more practical to create somekind of patch utility to apply a terrain flattening described in a configuration file to elevation data on a harddrive. Which would work without any modifications to the Orbiter or to the Client.

Back when I was working with the surface micro-textures, I got an idea of micro-elevation which would require some kind of tile-server in order to be implementable. Right now the Client requests a tile elevation file with it's tile-number from a harddrive. If a tile-server would be in place then the request/number would be passed to the server which would then load the file and preprocess the elevation data using a pixel-shader before forwarding it to a terrain manager for rendering. This would allow us to do more extensive real-time processing with the elevetion data. This idea came to a halt due to fact that the Orbiter's surface collision logic wouldn't know about the modified terrain.

So, technically it would sound more practical approach if the Orbiter would request the surface elevation data from the Client directly instead of loading it from a data file. Client could easily return elevation and normal for a requested lng, lat.
I never done a shader in my life so I don't know where to start from :embarrassed:

anyway you are surely right that having a client which stands in between Orbiter core and the planetary textures would be a very good organization. Actually the point would all be there: put something in the middle between the hard drive files and orbiter to override the terrain definition when (where) needed. I was thinking about creating temporary files that orbiter will then parse and acquire, but I don't know if that is feasible

#### Donamy

Donator
Beta Tester
Or in vain, if future changes in Orbiter break it.

#### 4throck

##### Enthusiast !
put something in the middle between the hard drive files and orbiter to override the terrain definition

Don't know it the graphic client could be used to generate them.
If it could, it would be great. Do it all from within Orbiter...

#### Face

Beta Tester
anyway you are surely right that having a client which stands in between Orbiter core and the planetary textures would be a very good organization. Actually the point would all be there: put something in the middle between the hard drive files and orbiter to override the terrain definition when (where) needed. I was thinking about creating temporary files that orbiter will then parse and acquire, but I don't know if that is feasible
If you put some area definitions into a text file, you can parse it and use the information at the end of "bool SurfTile::LoadElevationData ()" inside of Surfmgr2.cpp to manipulate the "elev" field in the tile, which is nothing but an 259x259 array of INT16. It is what the renderer will eventually put on screen.

So there you can iterate over all the shape definitions, check if they are relevant for the tile at hand (tile boundaries), then project the shape onto the tile and set the covered pixel to the altitude value you want.

It will not make the collision thing work, but it will demonstrate what the idea could accomplish in terms of developer experience. It will also demonstrate the impact on the frame-rate.

#### fred18

Donator
Thank you, I will surely try this, I am very curious to see where it does end up. I have an issue anyway: I can't compile the D3D9 client, it seems that I don't have the right redistributables, but if I try to install them I get the error s1023 or something like that which means that I have a newer set. I use VS community 2019. Anyone knows a workaround?

#### kuddel

##### Donator
Donator
To compile D3D9Client, the redistributables are not enough! You need the DirectX SDK.

[*] ...some points in that document are not very up to date I must say :blush:, it was last updated May 2014!
Let's see if I can find the SDK Link for you...
This should be it:

Last edited:

#### fred18

Donator
To compile D3D9Client, the redistributables are not enough! You need the DirectX SDK.

[*] ...some points in that document are not very up to date I must say :blush:, it was last updated May 2014!
Let's see if I can find the SDK Link for you...
This should be it:
thank you very much but that is what I was talking about:

#### fred18

Donator
It looks like I have to do a whole new chapter on "how to setup & build D3D9Client"
yes, please... I managed to get the dxsdk but then I had to do this:

https://stackoverflow.com/questions/17015088/missing-files-directx-sdk-d3dx9-lib-d3dx9-h

And now I am fighting against the NVAPI because I get a bunch of lnk2019 errors relevant to that but he is winning...

---------- Post added 13th Apr 2019 at 00:00 ---------- Previous post was 12th Apr 2019 at 23:56 ----------

I did it, adding the nvapi.lib file to the project...

Donator
Beta Tester

#### fred18

Donator
anyway, even if I manage to compile the code, when I try to run it I get this error

---------- Post added at 00:21 ---------- Previous post was at 00:19 ----------

from orbiter.log
Code:
000000.000: **** Creating simulation session
000000.000: D3D9: [DirectX 9 Initialized]
000000.000: D3D9: 3D-Adapter = NVIDIA GeForce GTX 1080
000000.000: D3D9: MaxTextureWidth........: 16384
000000.000: D3D9: MaxTextureHeight.......: 16384
000000.000: D3D9: MaxTextureRepeat.......: 8192
000000.000: D3D9: NumSimultaneousRTs.....: 4
000000.000: D3D9: VertexDeclCaps.........: 0x30F
000000.000: D3D9: XNA Math Support.......: Yes
000000.000: D3D9: Vertex Texture.........: Yes
000000.000: D3D9: D3DFMT_A16B16G16R16F...: Yes
000000.000: D3D9: D3DFMT_A32B32G32R32F...: Yes
000000.000: D3D9: D3DFMT_D32F_LOCKABLE...: Yes
000000.000: D3D9: D3DFMT_A2R10G10B10.....: Yes
000000.000: D3D9: D3DDTCAPS_DEC3N........: No
000000.000: D3D9: D3DDTCAPS_FLOAT16_2....: Yes
000000.000: D3D9: D3DDTCAPS_FLOAT16_4....: Yes
000000.000: D3D9: Available Texture Memory = 4059 MB
000000.000: D3D9: [3DDevice Initialized]
000000.000: D3D9: ERROR: D3D9Effect.cpp Line:252 Error:-2147467259 D3DXCreateEffectFromFileA(pDev, name, macro, 0, D3DXSHADER_NO_PRESHADER, 0, &FX, &errors)
000000.000: D3D9: ERROR: Effect Error: C:\Orbiter2016\Modules\D3D9Client\D3D9Client.fx(96,33): error X3004: undeclared identifier 'KERNEL_SIZE'
C:\Orbiter2016\Modules\D3D9Client\D3D9Client.fx(96,26): error X3074: 'kernel': implicit array missing initial value