New Release D3D9Client Development

jarmonik

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

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

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
I have uploaded a new version. Could you check if the sheen and frame rate issues are fixed.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Frame rate issue with shadows: Not fixed. Getting the same FPS no matter what ShadowMapSize in D3D9Client.cfg is set to.
Metalness shader issue: Fixed.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
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

  • Metalness_shader_not_applied.jpg
    Metalness_shader_not_applied.jpg
    65.5 KB · Views: 52
  • Metalness_shader_applied.jpg
    Metalness_shader_applied.jpg
    73.9 KB · Views: 53

jarmonik

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

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
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
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
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

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
This is how the SRBs are set up mesh-wise:

Code:
            hSRMSegmentMesh[0] = oapiLoadMeshGlobal("SSU/STS1_LSRB_aft_segment");
            hSRMSegmentMesh[1] = oapiLoadMeshGlobal("SSU/STS1_LSRB_aft_center_segment");
            hSRMSegmentMesh[2] = oapiLoadMeshGlobal("SSU/STS1_LSRB_fwd_center_segment");
            hSRMSegmentMesh[3] = oapiLoadMeshGlobal("SSU/STS1_LSRB_fwd_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
Addon Developer
Joined
Mar 22, 2008
Messages
5,877
Reaction score
2,869
Points
188
Website
github.com
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?
 

FordPrefect

Addon Developer
Addon Developer
Donator
Joined
Feb 7, 2008
Messages
407
Reaction score
41
Points
28
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

Addon Developer
Addon Developer
Joined
Jun 14, 2008
Messages
611
Reaction score
449
Points
78
Location
FRANCE
Website
francophone.dansteph.com
Hello :salute:

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

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

Instead of writing :

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.) :unsure:

Just wanted to point that out. :hailprobe:
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
@jacquesmomo : Funny that it has never been noticed before, but ...
RUNWAY has never been implemented in D3D9Client o_O
(must have been totaly overlooked when RUNWAYLIGHTS were implemented.)
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,877
Reaction score
2,869
Points
188
Website
github.com
@jacquesmomo : Funny that it has never been noticed before, but ...
RUNWAY has never been implemented in D3D9Client o_O
(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
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
Funny that it has never been noticed before, but ...
RUNWAY has never been implemented in D3D9Client o_O
(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
Addon Developer
Joined
Mar 22, 2008
Messages
5,877
Reaction score
2,869
Points
188
Website
github.com
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
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
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)
https://www.youtube.com/watch?v=mrNMpqdNchY

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)

Not Supported by the shader:
  • 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
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
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
Addon Developer
Joined
Mar 22, 2008
Messages
5,877
Reaction score
2,869
Points
188
Website
github.com
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 ?
No new branches are needed, at least not in the Orbiter repository.
If someone external to the project finds and fixes an issue, or adds a new feature, they should create a PR to the appropriate branch so those changes get incorporated into the project by internal personnel. The internal personnel can always make the change directly in a branch without a PR.

But it's actually a bit more than just OCD: a fix to, e.g., a memory leak in the VESSEL4 class (a "generic" problem, not related to feature work) that gets placed in a feature branch, means that all other branches will only get that fix when that branch gets merged back into the main branch. Yes, there's always copy-past and revision picking, but the best way is to put that fix in the main branch where it belongs, and then that, and other changes, get disseminated to the feature branches when they update themselves to the main.

In the end it all gets merged together and there should be no problems, but IMO things should be placed in the right places to minimize the probability of future issues.
You got to keep your worlds apart :ROFLMAO:

BTW: thanks for the help above with the textures. (y)
 
Top