# New ReleaseD3D9Client Development

#### igel

I can publish a new version of the Client for Orbiter 2010 with the cockpit reflections re-enabled. Also, have you noticed the surface elevation checkbox in the visual options. It will make the earth a flat sphere. As for the O2016 I try to find some ways to get the reflection camera issues sorted out for the interior and exterior reflections. It would be nice to have a better vessel configuration file interface since the amount of data will likely increase a lot.
May be a good idea to return internal reflections to a would-be-latest 2010 client. Not critical, "nice to have". Vostok is probably the only vessel to use it, but Vostok is sufficiently popular addon . If no, I can simply document recomendation to downgrade client version for just Vostok.

My addons are "reasonably intense" when it comes to setting up client, so I always document detailed instructions. For pre-flattening 2016 clients, disabling surface elevation was an absolute requirement - otherwise launchpads did not stand level, and rockets could not launch from them, period. Flattening allowed to restore 3D terrain for other things - like landings, which already looks better than 2010 (and will become even better when I restore "sticking to the ground").

And my vessel configs are already quite filled - with my own stuff. Even though all vessels have DLLs, a lot of things are configured in cfg rather than hard-coded in the dll. So adding 2016-style TDPs should not be that hard... It is just so many vessels to update

#### jarmonik

Beta Tester
The old PBR shader also fails now. The latest 5.0 revision can be obtained here: https://www.dropbox.com/s/rbzhm14zi19vsu7/SSU_v5.0r3273.zip?dl=0
I've attached a scenario which shows the problem as well.

I have looked at the problem and it looks like the "Range" parameter is set to a very low setting only 2 meters. So, the Client won't apply lighting due to out of range condition. If the "range" is set too high then the Client will automatically reduce it to a practical level which is a range of 1% light level (i.e. 31m with PLB Floodlights). The next version of the Client will have a light cone visualization option in DebugControls.

#### kuddel

##### Donator
Donator
..."dynamic change session"...was meant to be more like "dynamic change request session"

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
Another thing that should addressed is that Earth glow is visible through meshes when it shouldn't be. Example screenshot attached. In it the bottom of the orbiter should be block any Earth glow on elements inside the PLB, but as illustrated on the bottom of the RMS, it isn't.

#### Attachments

• Earth_glow_visible_through_PLB.jpg
942.1 KB · Views: 18

#### kuddel

##### Donator
Donator
Hey Jarmo,
I took the liberty and merged the changes from branch 2016 to trunk.
Each "version bump" step is presented as one merge (and a "version bump"), so there should be a correlation between branch-2016- and trunk-versions.
This is not important per se, but who knows ...

While doin' that I realized something on gcConst.h:
Shouldn't all compound assignment operators[1] be modifying "this"?
C++:
        inline FVECTOR4& operator*= (float f)
{
return FVECTOR4(x * f, y * f, z * f, w * f);
}
...shouldn't it be more like...
C++:
        inline FVECTOR4& operator*= (float f)
{
x *= f; y *= f; z *= f; w *= f;
return *this;
}
...don't you think?

[1] *=, /= %=, += -=, <<=, >>=, &=, ^=, |=

#### Felix24

##### Active member
What will be the recommended process for creating multi-layer materials?

I find that solar panels (and things with foil surfaces like Hubble) can be made to look very realistic with multi-layer materials. Is it possible to have a shader that defaults to metalness without a specular map, but when a specular map is present, the sun and local light specular reflections are defined by the specular map instead of metal/smoothness? All other lighting and environment reflections would still obey the metalness rules.

I want to switch over to the metalness workflow for developing textures because it'll be easier and faster, but I also want to retain direct control of specular only in situations where I need it.

#### jarmonik

Beta Tester
Shouldn't all compound assignment operators[1] be modifying "this"?
Yes, probably. I haven't checked how the code is compiled. The above solution might allocate unnecessary temporary object. So, using "this" might be faster. So, yeah, we can make the switch.

#### jarmonik

Beta Tester
What will be the recommended process for creating multi-layer materials?

I find that solar panels (and things with foil surfaces like Hubble) can be made to look very realistic with multi-layer materials. Is it possible to have a shader that defaults to metalness without a specular map, but when a specular map is present, the sun and local light specular reflections are defined by the specular map instead of metal/smoothness? All other lighting and environment reflections would still obey the metalness rules.

I want to switch over to the metalness workflow for developing textures because it'll be easier and faster, but I also want to retain direct control of specular only in situations where I need it.

Sounds good to me. So, let's make it happen. We probably should use "smoothness" instead of "specular power" or what do you think ? You probably have a better understanding of how exactly it should work than I do. So, can you make the modifications to the shader ? I have included a new binary that enables the specular map for the shader.

#### Attachments

• D3D9Client.zip
546.1 KB · Views: 2

#### jarmonik

Beta Tester
Another thing that should addressed is that Earth glow is visible through meshes when it shouldn't be. Example screenshot attached. In it the bottom of the orbiter should be block any Earth glow on elements inside the PLB, but as illustrated on the bottom of the RMS, it isn't.
That is a very tricky thing to fix. Right now I don't have any solution in mind. I'll start thinking about it when I got the time for it.

#### GLS

Please don't forget to write up something in the manual about all these (new) features.

#### jarmonik

Beta Tester
D3D9ClientR16.10 for Orbiter 2010-P1 Released.

This build restores VC reflections. There is a checkbox added in setup dialog from where the feature can be enabled. The default is off-line since it may cause problems with some add-ons.

#### igel

Thanks a lot! Will get it and try it ASAP!

#### kuddel

##### Donator
Donator
Yes, probably. I haven't checked how the code is compiled. The above solution might allocate unnecessary temporary object. So, using "this" might be faster. So, yeah, we can make the switch.
I'll commit that changes soon, then.
And yes, there might be a speed-up, but more importantly it fulfills the expectations:
One would not assume that a v1 *= 4; instruction will change the address of v1.
If it runs faster, that's nice too

#### yitianetie

##### Member
Hi,

I have found a big issue with elevation rendering on Mercury with the D3D9 client (same issue in Orbiter Beta and with HD textures). With the D3D9 client (last beta release r.1392), the elevation seems to be well detected by the vessel but the texture is not well rendered, like a invisible mountain.

I have tried some options : disable terrain flattening, change mesh resolution, edit the file Mercury.cfg by change the MaxPatchResolution value but nothing change. I have also checked that I have downloaded the right files.

Anyways, the issue seems to be clearly related to the D3D9 client, otherwise I would see the same rendering problem with the D3D7 client.

Below, the configuration file for Mercury :
Code:
; === Configuration file for planet Mercury ===
Name = Mercury
Module = Mercury
ErrorLimit = 1e-5
SamplingInterval = 39          ; interpolation sampling interval [s]
; (interpolation error ~2.8m)

; === Physical Parameters ===
Mass = 3.301880e+23
Size = 2.440e+6                ; mean radius
JCoeff = 0.00006               ; J2 coefficient for gravitational potential
AlbedoRGB = 0.48 0.33 0.15

; === Rotation and precession parameters ===
PrecessionLAN = 3.981463274
PrecessionObliquity = 0.1224024085
PrecessionPeriod = 995828.2664
LAN = 1.674482844
LAN_MJD = 51544.5
Obliquity = 0.0005931973805
SidRotOffset = 0.2687078469
SidRotPeriod = 5067034.512
;SidRotPeriod (days): 58.64623278
;SidRotPeriod (days - node to node): 58.64968677
;Precession Period (years): 2726.429203
;Obliquity (deg): 0.03398770632
;Axis RMS Error (deg): 0.304377661
;Lat/Lon RMS Error (deg): 0.00299152648

; === Data for the Visual ===
TileFormat = 2
LabelFormat = 2
MaxPatchResolution = 13         ; highest sphere patch level
HorizonExcess = 0.014   ; prevent mountain tops beyond sphere horizon from disappearing

And I also attached my orbiter.log file (too many characters to display directly in the message).

#### Attachments

• Orbiter2016_D3D7.JPG
35.1 KB · Views: 14
• Orbiter2016_D3D9.JPG
40.2 KB · Views: 14
• Orbiter_log.txt
9.9 KB · Views: 4
Last edited:

#### jarmonik

Beta Tester
One would not assume that a v1 *= 4; instruction will change the address of v1.
Yes, I agree there. I never thought of that.

#### yitianetie

##### Member
I have checked on other planets. The issue that i have talked about only occurs on Mercury, whatever using hd or default textures. I hope that Jarmonik will update the D3D9 client so that we can land on Mercury like on Mars .

Cheers.

#### kuddel

##### Donator
Donator
Hmmm, the Mercury issue is odd. It seems like the size of the surface-map does not match the size of the elevation-map.
But why only Mercury has this issue is puzzling.

#### GLS

Hmmm, the Mercury issue is odd. It seems like the size of the surface-map does not match the size of the elevation-map.
But why only Mercury has this issue is puzzling.
Gravity too strong near the Sun?

#### yitianetie

##### Member
Hmmm, the Mercury issue is odd. It seems like the size of the surface-map does not match the size of the elevation-map.
But why only Mercury has this issue is puzzling.
Yes. And it is only while using D3D9 client. We don't see the issue with the native/D3D7 client.