# New ReleaseD3D9Client Development

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
Let's check if the sheen really comes from the Ambient (indirect) light. So, could you add line 266 "cAmbient = length(cAmbient)" in metalness.fx and see if the sheen has disappeared.

Code:
    // Apply base ambient light
cAmbient = max(cAmbient, gSun.Ambient);
cAmbient = length(cAmbient);
#else

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
Let's check if the sheen really comes from the Ambient (indirect) light. So, could you add line 266 "cAmbient = length(cAmbient)" in metalness.fx and see if the sheen has disappeared.

Code:
    // Apply base ambient light
cAmbient = max(cAmbient, gSun.Ambient);
cAmbient = length(cAmbient);
#else
Added line 266 to Metalness.fx and this is the result.

#### Attachments

• SRMS_metalness_modified.jpg
63.8 KB · Views: 24

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
I have uploaded a new version. Could you check if the sheen and frame rate issues are fixed.

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
Frame rate issue with shadows: Not fixed. Getting the same FPS no matter what ShadowMapSize in D3D9Client.cfg is set to.

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
Another issue: I decided to change the SRBs over to the Metalness shader (they're D6AC steel tubes after all) but only the aft segments are rendered using the Metalness shader as shown in the included screenshots. The weird thing is that they're rendered just fine when the D3D9Client Debug Controls window is open, screenshot showing this is attached.

#### Attachments

65.5 KB · Views: 48
73.9 KB · Views: 50

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
Another issue: I decided to change the SRBs over to the Metalness shader (they're D6AC steel tubes after all) but only the aft segments are rendered using the Metalness shader as shown in the included screenshots. The weird thing is that they're rendered just fine when the D3D9Client Debug Controls window is open, screenshot showing this is attached.
The shader needs to be applied to each mesh separately, it's likely that the segments are separate meshes not just mesh groups.

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
The shader needs to be applied to each mesh separately, it's likely that the segments are separate meshes not just mesh groups.
Sorry for the late reply, but this is correct. In SSU the SRBs are made up of separate individual meshes, rather than a single mesh group for the entire thing, this is to enable stacking of the individual SRB elements in the VAB (KSC) or directly on the Launch Mount (Vandenberg).

Is there anything that could be done or is it a limitation of D3D9Client?

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
Is there anything that could be done or is it a limitation of D3D9Client?
That's how it's designed to work. It would be possible to control a shader in per mesh group basis but that would be headache for developers due to insufficient tools and large amount of groups. So, per mesh basis is chosen as compromise between per vessel and per group basis.

Is there a problem ?

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
This is how the SRBs are set up mesh-wise:

Code:
            hSRMSegmentMesh[0] = oapiLoadMeshGlobal("SSU/STS1_LSRB_aft_segment");
hSRMSegmentMesh[4] = oapiLoadMeshGlobal("SSU/STS1_LSRB_fwd_skirt_assy");

As you can see, the SRB is multi-mesh vessel. And yes, the each SRB is a separate vessel with a common module. The entire Space Shuttle is made of separate vessels (Orbiter, External Tank, Left SRB and Right SRB) held together by attachment points. When it is time to jettison we simply send a command through the OAPI to detach and Orbiter handles the rest.

#### GLS

##### Well-known member
Orbiter Contributor
So I'm doing some early playing with the "advanced D3D9" materials and textures and I have some questions:
• there are different lists of "*_abcd.dds" textures in the D3D9Client.pdf and in the D3D9GraphicsGuide.pdf docs... is one of them incomplete, old info or something else?
• I assume that the textures serve to provide per-pixel "material control" (e.g., shiny bolts on a dull surface, without the need to have separate meshes and materials). If I'm correct, is there a list or table to relate the textures to the materials? Also, does the presence of a texture override the corresponding material?
• in the Advanced control window there are materials starting with an underscore, what do they control?
• the material indexes in the GC/vessel.cfg folder files, they are 0-based as opposed to the 1-based indexes in the meshes, right?

#### Ajaja

##### Active member
Interesting. Using D3D9Client with DXVK ( https://github.com/doitsujin/dxvk ) I get ~20% more fps on Windows 10 than without DXVK.
There are some glitches though.

Last edited:

#### FordPrefect

Donator
Hi jarmonik! Just wanted to say the Earth and Moon now looks amazing with your graphics client. I love the vessel self-shadowing and reflective surfaces and the shadow of the LM on the lunar surface during approach...gorgeous! I did a new global moon texture without shadows so that these are solely created by the actual terrain (surfaces pointing away from the sun) and local lighting conditions.
And I was wondering, do you have any plans to add terrain-self-shadowing for your client as well? That would be a dream! Thank you for your hard work!

#### jacquesmomo

Hello

Just one thing I noticed... but it's nothing, really

I just wanted to add 2 ILS in a base file.

RUNWAY
END1 2224.587 0 8326.635
END2 2485.728 0 7195.669
WIDTH 20
ILS1 110.3
ILS2 110.4
NRWSEG 4
RWSEG1 1 5.23560209424084E-03 0.5 0.75 0.97 1
RWSEG2 1 2.61780104712042E-02 0.5 0.75 0.75 0.95
RWSEG3 12 0.942408376963351 0.5 0.75 0.01 0.75
RWSEG4 1 2.61780104712042E-02 0.5 0.75 0.75 1
RWTEX Runway973
END

as I didn't want the runway, I simply wrote :

RUNWAY
END1 2224.587 0 8326.635
END2 2485.728 0 7195.669
WIDTH 20
ILS1 110.3
ILS2 110.4
END

This works fine for Orbiter without the D3D9 graphical client. But NOT with D3D9 it is necessary to declare the runway.

I spent some time to understand (I do my tests without the D3D9 graphical client, and I check later with D3D9.)

Just wanted to point that out.

#### kuddel

##### Donator
Donator
@jacquesmomo : Funny that it has never been noticed before, but ...
RUNWAY has never been implemented in D3D9Client
(must have been totaly overlooked when RUNWAYLIGHTS were implemented.)

#### GLS

##### Well-known member
Orbiter Contributor
@jacquesmomo : Funny that it has never been noticed before, but ...
RUNWAY has never been implemented in D3D9Client
(must have been totaly overlooked when RUNWAYLIGHTS were implemented.)
I remember using runway textures in D3D9, which had anti-aliasing and caused me some problems... maybe it was removed for Orbiter 2016?

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
Funny that it has never been noticed before, but ...
RUNWAY has never been implemented in D3D9Client
(must have been totaly overlooked when RUNWAYLIGHTS were implemented.)
As far as I can tell the Orbiter handles the RUNWAY and converts it to a mesh. Also, it's kinda odd that ILS works differently on D3D9 since it's not graphics related at all.

#### GLS

##### Well-known member
Orbiter Contributor
I stopped by the D3D9 branch in git today, and I'm seeing many changes going in there that are not really D3D9 related thus, IMO, should be done in the main branch. With these "mixtures", when time comes to merge the D3D9 branch into the main branch, it will forcibly be "D3D9 + other changes"... an all or nothing situation, which IMO is not desirable as it introduce even more changes, not all D3D9 related.

So I'm doing some early playing with the "advanced D3D9" materials and textures and I have some questions:
• there are different lists of "*_abcd.dds" textures in the D3D9Client.pdf and in the D3D9GraphicsGuide.pdf docs... is one of them incomplete, old info or something else?
• I assume that the textures serve to provide per-pixel "material control" (e.g., shiny bolts on a dull surface, without the need to have separate meshes and materials). If I'm correct, is there a list or table to relate the textures to the materials? Also, does the presence of a texture override the corresponding material?
• in the Advanced control window there are materials starting with an underscore, what do they control?
• the material indexes in the GC/vessel.cfg folder files, they are 0-based as opposed to the 1-based indexes in the meshes, right?
Any info on this?

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
there are different lists of "*_abcd.dds" textures in the D3D9Client.pdf and in the D3D9GraphicsGuide.pdf docs... is one of them incomplete, old info or something else?

Sadly, Neither is up to date. But D3D9GraphicsGuide.pdf is newer. For a new models it's recommended to use the "Metalness" shader (i.e. Metalness Workflow) instead of the old legacy shader documented in D3D9GraphicsGuide.pdf

Here's some info about the metalness workflow (the video compares it to a specular workflow so don't be confused when speaking of specular maps)

The main Textures or Material properties required by the shader are:
• Regular "diffuse" texture map as used by the DX7 as an example.
• Grey scale Roughness texture "*_rghn.dds" and/or roughness material property. The texture is modulated by material just like in a case of the diffuse texture. 0.0 is tough and 1.0 is smooth/glossy.
• Grey scale Metalness texture "*_metal.dds" or metalness material property. The "metalness" value is 1.0 for metals and 0.0 for non-metals. Values between the two are rare. The "metalness" can be in most cases set by using the material property without need of a texture.

Optional texture maps supported by the shader:
• Normal Map "*_norm.dds"
• Transluciency "*_transl.dds" and Transmittance "_transm.dds" (Tested OK)
• Emission map "*_emis.dds"
• Specular Map "*_spec.dds" (Only use this if you know what you are doing)

• Reflection Map "*_refl.dds"

• in the Advanced control window there are materials starting with an underscore, what do they control?
• the material indexes in the GC/vessel.cfg folder files, they are 0-based as opposed to the 1-based indexes in the meshes, right?

The materials starting with underscore like "_refl" was used for real time tuning of input textures (for preview only), the configuration is not saved anywhere. They are supposed to be removed from the latest version. So, just ignore them.

As for being zero based. I don't recall that but it's very likely. But since the Orbiter is now open it might be more practical to store a mesh configuration in the mesh files instead of vessel specific configuration file. So, this may change in the future.

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
I stopped by the D3D9 branch in git today, and I'm seeing many changes going in there that are not really D3D9 related thus, IMO, should be done in the main branch. With these "mixtures", when time comes to merge the D3D9 branch into the main branch, it will forcibly be "D3D9 + other changes"... an all or nothing situation, which IMO is not desirable as it introduce even more changes, not all D3D9 related.

I have considered the main branch as Martin's territory. It might have been practical to create a new branch for those non-related changes but too many branches is also messy.
I don't see problem there. How many commits there are in main branch those haven't been merged to d3d9branch ?

#### GLS

##### Well-known member
Orbiter Contributor