New Release D3D9Client Development

[Pioneer]

Is this for the high-res Mercury textures? I remember the description on those mentioning that they only work with the latest beta. That may have something to do with it.

 

[jedidia]

Another question just popped up, since I'm now trying to apply materials adjusted in the debug control as texture maps.

So I created both a _metal and a _rghn dds map for a material, then took the config file out of the picture to confirm that I'm getting equal results. I do, but there's a big BUT: When loading orbiter, the old shader is applied, despite there not being a reflection or specular map (and therefore, understandably, looking ugly). I can switch the shader to metalness shader in the debug controls, and everything looks as it should, but of course that's not that helpful if the shader isn't applied right away.

 

[yitianetie]

Is this for the high-res Mercury textures? I remember the description on those mentioning that they only work with the latest beta. That may have something to do with it.

Not only for High-res textures. I have the issue with low-res textures too. But both work fine with D3D7. The issue only appear with D3D9 client.
The High-res Mercury textures are supposed to work fine Both with Orbiter 2016 and Orbiter Beta, except for the label.tree file that can be only used with Orbiter Beta.

 

[jarmonik]

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

This will be fixed in next release.

 

[jarmonik]

Another question just popped up, since I'm now trying to apply materials adjusted in the debug control as texture maps.
So I created both a _metal and a _rghn dds map for a material, then took the config file out of the picture to confirm that I'm getting equal results. I do, but there's a big BUT: When loading orbiter, the old shader is applied, despite there not being a reflection or specular map (and therefore, understandably, looking ugly). I can switch the shader to metalness shader in the debug controls, and everything looks as it should, but of course that's not that helpful if the shader isn't applied right away.

Have you pressed the "Save Materials" button after selecting the Metalness shader ?

The configuration file should read something like:

CONFIG_VERSION 3
; =============================================
MESH MeshIdx-0
SHADER Metalness
SAFEGUARD 1

The selected shader should apply automatically but it's possible that bugs may exists. This whole configuration file interface should be reworked if we add configuration parameters for other visual effects in it like, condensation effects, particle effects, engine exhausts etc...

 

[DaveS]

Have you pressed the "Save Materials" button after selecting the Metalness shader ?

The configuration file should read something like:

CONFIG_VERSION 3
; =============================================
MESH MeshIdx-0
SHADER Metalness
SAFEGUARD 1

The selected shader should apply automatically but it's possible that bugs may exists. This whole configuration file interface should be reworked if we add configuration parameters for other visual effects in it like, condensation effects, particle effects, engine exhausts etc...

This has always worked great for me. So there shouldn't be any issues.

 

[jedidia]

The selected shader should apply automatically but it's possible that bugs may exists.

No, that part works fine. But it won't switch to the shader if I remove the file but have the necessary maps for it. I would have expected it to switch to the shader automatically when a material has a diffuse map, a metal map and a roughness map. I take it that means that you need to have that file present to at least set the shader, then? For each mesh in the vessel, and one file per kind of vessel? That may get a bit inconvenient for my purposes, but I guess I can make it work...

 

[4throck]

I too confirm an issue with Mercury. I have an old savegame (saved on Nov. 2018) with a DG landed at Discovery Rupes.
When I load it now the DG is landed as expected, but well below the visible surface.

Pasting the scenario so that others can replicate the issue:

BEGIN_DESC

END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 54753.7444437087
  Help CurrentState_img
END_ENVIRONMENT

BEGIN_FOCUS
  Ship GL-01S
END_FOCUS

BEGIN_CAMERA
  TARGET GL-01S
  MODE Extern
  POS 1682.815933 -81.049612 124.847671
  TRACKMODE GlobalFrame
  FOV 50.00
END_CAMERA

BEGIN_HUD
  TYPE Docking
  NAV 0
END_HUD

BEGIN_MFD Right
  TYPE Orbit
  PROJ Ship
  FRAME Ecliptic
  ALT
  REF Mercury
END_MFD

BEGIN_SHIPS
GL-01S:DG-S
  STATUS Landed Mercury
  POS -38.0000000 -56.0000000
  HEADING 284.59
  ALT 2.534
  AROT 171.170 25.464 29.301
  AFCMODE 7
  PRPLEVEL 0:0.712318 1:0.699040 2:0.993788
  THLEVEL 0:1.000000 1:1.000000
  NAVFREQ 94 524 84 114
  XPDR 0
  HOVERHOLD 0 1 0.0000e+000 0.0000e+000
  TRIM 0.270000
  GEAR 1.0000 0.0000
  AAP 0:0 0:0 0:0
  PSNGR 2 3 4
  TANKCONFIG 1
END
END_SHIPS

 

[yitianetie]

While looking for a solution or turn-around for Mercury (in vain), I have discovered one thing : there is small altimetry problems (vessel in the emptyness above the ground) with celestial bodies using .tex format as Textures, like Ariel. For other planets and satellites which use .bmp/.dds formats as textures (like Pluto I have downloaded from OHM) and if we set the MaxPatchResolution to 19, the sphere is perfect and the vessel is well positionned on the ground.

Apparently, Mercury has its Mercury.tex file in the Textures folder but it's not the case for other planets. I have deleted the file as I have put the Hires textures files in the Archive folder but it does not change anything.

 

[yitianetie]

New snapshoots to illustrate the elevation issue on Mercury. The elevation rendering is clearly not the same between the D3D9 and native D3D7 client. Mountains seem to be smaller with the D3D9 client. Increase Mesh resolution does not change anything. Disable Terrain flatening has also no effect, as Face has said on another thread.

Honestly, I don't know where is the issue exactly but I suspect more a problem with D3D9 client than the elevation tile. And it is above my knowledge. Let us wait that Doctor Jarmonik try to find a fix.

 

[4throck]

It's client related

I suspect more a problem with D3D9 client than the elevation tile....

It's client related since it worked back in 2018 (same date as the Mercury high res textures). So the client worked back then. Something changed afterwards ....

 

[Face]

To take terrain flattening completely out of the picture, the current client could be re-compiled with the hooking process for the core-patching commented out. The flag alone is early-returning the function on false, but the patching is still present. I don't think that it is a problem that will result in these symptoms, but it would help to narrow down the issue.

 

[4throck]

Can't we simply install older D3D9 versions and see where the problem started ?
I have 4.7 (from Aug 2020 I think) on a different install (to run TerrainTools) and I can confirm that the problem is present....

 

[Face]

As there are often multiple changes between versions, I think you can't really tell if a specific feature is the culprit without explicitly deactivating that feature in the given version. Of course bisecting through the previous versions can give a good hint. According to the commit log, flattening got in between 4.7 and 4.8. Anybody tried those versions?

 

[4throck]

@Face read my previous post ;-) The problem is present on 4.7

 

[Face]

@Face read my previous post ;-) The problem is present on 4.7

Huh? How did I miss that? I could swear that was not there when I wrote my comment...

 

[jarmonik]

D3D9Client 4.17 is out

• The "Extended Map MFD" polygon render problem should be fixed.
• Metalness Map should now enable Metalness shader if no configuration file is present. (not tested)
• Global Ambient light level is now included in Metalness shader.
• "Mercury" elevation issue should be fixed as fas as it's possible. (see notes)

If Orbiter Beta specific elevation is used in Orbiter 2016 elevation scale factor can be incorrect in Physics and Graphics. In a case of the Mercury, mountains and valleys are twice as high or deep as they should be.

 

[asbjos]

• The "Extended Map MFD" polygon render problem should be fixed.

Wow, what a nice surprise! Made the MFD much better. And I didn't even need to ask!
Kiitos!

 

[yitianetie]

D3D9Client 4.17 is out

• The "Extended Map MFD" polygon render problem should be fixed.
• Metalness Map should now enable Metalness shader if no configuration file is present. (not tested)
• Global Ambient light level is now included in Metalness shader.
• "Mercury" elevation issue should be fixed as fas as it's possible. (see notes)

If Orbiter Beta specific elevation is used in Orbiter 2016 elevation scale factor can be incorrect in Physics and Graphics. In a case of the Mercury, mountains and valleys are twice as high or deep as they should be.

Thanks Jarmonik,

That explains why the vessel don't collide with the surface on Mercury (even approximately). Let us wait your next update...

 

[yitianetie]

While testing the Extended Map MFD which runs fine. I have noticed that the virtual cockpit of the Delta Glider has a sort of wallpaper. Amazing ! What is happening ?