New Release D3D9Client Development

igel

Addon Developer
Joined
Mar 28, 2008
Messages
252
Reaction score
119
Points
43
Website
www.pin-plus.ca
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
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
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
..."dynamic change session"...was meant to be more like "dynamic change request session" ;)
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
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
    Earth_glow_visible_through_PLB.jpg
    942.1 KB · Views: 18

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
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"?
So, instead of...
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
Joined
May 13, 2010
Messages
245
Reaction score
95
Points
43
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
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: 3

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
Please don't forget to write up something in the manual about all these (new) features.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
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.
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
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 :D
 

yitianetie

Member
Joined
Mar 24, 2020
Messages
50
Reaction score
18
Points
23
Location
Brittany
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 ===
; ref: see www.orbiter-forum.com/showthread.php?t=8185
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
;Ecliptic LAN (rad): 3.986297968
;Ecliptic Obliquity (rad): 0.1223424276
;Ecliptic SidRotOffset (rad): 1.614667355
;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
    Orbiter2016_D3D7.JPG
    35.1 KB · Views: 14
  • Orbiter2016_D3D9.JPG
    Orbiter2016_D3D9.JPG
    40.2 KB · Views: 14
  • Orbiter_log.txt
    9.9 KB · Views: 4
Last edited:

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
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
Joined
Mar 24, 2020
Messages
50
Reaction score
18
Points
23
Location
Brittany
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
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
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? :ROFLMAO:
 

yitianetie

Member
Joined
Mar 24, 2020
Messages
50
Reaction score
18
Points
23
Location
Brittany
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.
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
What's your recommendation for emulating orbiters default "ambient color" feature when using metalnes shader? Right now my stuff all turns pitch black when it goes into earths shadow...
 
Top