New Release D3D9Client Development

[DaveS]

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]

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]

This is how the SRBs are set up mesh-wise:

            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]

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]

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.

 

[FordPrefect]

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.

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

Just wanted to point that out.

 

[kuddel]

@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]

@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]

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]

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]

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]

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]

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

BTW: thanks for the help above with the textures.

 

[BigMac]

Apologies if this isn't the right place to ask, however I'm running in to a problem building a project incorporating both the latest D3D9 client build against the beta (r1436), and the most recent release of OrbiterSound (5.0).
It appears that both libraries are built using different Runtime Libary settings - MT for Orbiteround, and MD for the D3D9 client, which means that I can include one or the other but trying to add both throws a LNK 2038 error.

Has anyone run in to a similar issue, or might have any suggestions as to how to get around this?

Thanks in advance.

 

[jarmonik]

If you are trying to compile your own add-on then you shouldn't try to link into the D3D9 at all. The linkage is established through Orbiter core.
But a different link library setting shouldn't be a problem as far as I can tell. Of course, I may have forgotten something. What version of Visual Studio are you using ?

 

[BigMac]

If you are trying to compile your own add-on then you shouldn't try to link into the D3D9 at all. The linkage is established through Orbiter core.
But a different link library setting shouldn't be a problem as far as I can tell. Of course, I may have forgotten something. What version of Visual Studio are you using ?

Thanks for the response.
Sorry if I wasn't clear in my original post - I'm using VS 2017 and linking specifically with the gcAPI library, as I am making use of some of the functionality around custom cameras.

It's entirely possible that I'm being a bit stupid and missing something obvious.

 

[jarmonik]

Thanks for the response.
Sorry if I wasn't clear in my original post - I'm using VS 2017 and linking specifically with the gcAPI library, as I am making use of some of the functionality around custom cameras.

It's entirely possible that I'm being a bit stupid and missing something obvious.

Don't link into gcAPI.lib it is obsolete due to difficulties it creates. Use gcCore interface instead which doesn't require any link libraries.

#include "gcCore.h"

void VESSEL::YourInitProg()
{
    CAMERAHANDLE hCam = NULL;
    gcCore *pCore = gcGetCoreInterface();
    if (pCore) {
        hCam = pCore->SetupCustomCamera(...);
    }
}

 

[BigMac]

Don't link into gcAPI.lib it is obsolete due to difficulties it creates. Use gcCore interface instead which doesn't require any link libraries.

#include "gcCore.h"

void VESSEL::YourInitProg()
{
    CAMERAHANDLE hCam = NULL;
    gcCore *pCore = gcGetCoreInterface();
    if (pCore) {
        hCam = pCore->SetupCustomCamera(...);
    }
}

Just what I was looking for - thanks for the help!

 

[Blake]

I'm getting an error running SR71-R with the latest D3D9Client branch from github. Orbiter.log is below.

This appears to be happening while I'm trying to bitblt the MFD buttons from a texture.

Thanks.

**** Orbiter.log
000000.000: Build Feb 2 2022 [v.602931718]
000000.000: Timer precision: 1e-07 sec
000000.000: Found 0 joystick(s)
000000.000: Module AtlantisConfig.dll .... [Build 220121, API 220121]
000000.000: Module AtmConfig.dll ......... [Build 220121, API 220121]
000000.000: Module DGConfigurator.dll .... [Build 220121, API 220121]
000000.000: ---------------------------------------------------------------
000000.000: BaseDir : D:\git\orbiter-sr71r\Orbiter\
000000.000: ConfigDir : D:\git\orbiter-sr71r\Orbiter\Config\
000000.000: MeshDir : D:\git\orbiter-sr71r\Orbiter\Meshes\
000000.000: TextureDir : D:\git\orbiter-sr71r\Orbiter\Textures\
000000.000: HightexDir : D:\git\orbiter-sr71r\Orbiter\Textures2\
000000.000: ScenarioDir: D:\git\orbiter-sr71r\Orbiter\Scenarios\
000000.000: ---------------------------------------------------------------
000000.000: D3D9 DLLs : C:\WINDOWS\SYSTEM32\d3d9.dll [v 10.0.19041.1387]
000000.000: ---------------------------------------------------------------
000000.000: Module D3D9Client.dll ........ [Build 220202, API 220121]
000000.000:
000000.000: **** Creating simulation session
000000.000: D3D9: [DirectX 9 Initialized]
000000.000: D3D9: 3D-Adapter.............. : NVIDIA GeForce GTX 1660 Ti
000000.000: D3D9: MaxTextureWidth......... : 16384
000000.000: D3D9: MaxTextureHeight........ : 16384
000000.000: D3D9: MaxTextureRepeat........ : 8192
000000.000: D3D9: VolTexAddressCaps....... : 0x3F
000000.000: D3D9: NumSimultaneousRTs...... : 4
000000.000: D3D9: VertexDeclCaps.......... : 0x30F
000000.000: D3D9: MiscCaps................ : 0x2FCEF2
000000.000: D3D9: Vertex Texture.......... : Yes
000000.000: D3D9: Separate AlphaBlend..... : Yes
000000.000: D3D9: Shadow Mapping.......... : Yes
000000.000: D3D9: D3DFMT_A16B16G16R16F.... : Yes
000000.000: D3D9: D3DFMT_A32B32G32R32F.... : Yes
000000.000: D3D9: D3DFMT_D32F_LOCKABLE.... : Yes
000000.000: D3D9: D3DFMT_A2R10G10B10...... : Yes
000000.000: D3D9: D3DFMT_L8............... : Yes
000000.000: D3D9: D3DDTCAPS_DEC3N......... : No
000000.000: D3D9: D3DDTCAPS_FLOAT16_2..... : Yes
000000.000: D3D9: D3DDTCAPS_FLOAT16_4..... : Yes
000000.000: D3D9: Runs under WINE......... : No
000000.000: D3D9: D3D9Build Date.......... : 220202
000000.000: D3D9: Available Texture Memory : 4077 MB
000000.000: D3D9: [3DDevice Initialized]
000000.000: D3D9: [Loading Constellations]
000000.000: D3D9: [D3D9Client Initialized]
000000.000: Module Sun.dll ............... [Build 220121, API 220121]
000000.000: VSOP87(E) Sun: Precision 1.0e-06, Terms 554/6634
000000.000: Module Mercury.dll ........... [Build 220121, API 220121]
000000.000: VSOP87(B) Mercury: Precision 1.0e-05, Terms 167/7123
000000.000: Module Venus.dll ............. [Build 220121, API 220121]
000000.000: Module VenusAtm2006.dll ...... [Build 220121, API 220121]
000000.000: VSOP87(B) Venus: Precision 1.0e-05, Terms 79/1710
000000.000: Module Earth.dll ............. [Build 220121, API 220121]
000000.000: Module EarthAtmJ71G.dll ...... [Build 220121, API 220121]
000000.000: VSOP87(B) Earth: Precision 1.0e-08, Terms 2564/2564
000000.000: Module Moon.dll .............. [Build 220121, API 220121]
000000.000: ELP82: Precision 1.0e-05, Terms 116/829
000000.000: Module Mars.dll .............. [Build 220121, API 220121]
000000.000: Module MarsAtm2006.dll ....... [Build 220121, API 220121]
000000.000: VSOP87(B) Mars: Precision 1.0e-05, Terms 405/6400
000000.000: Module Phobos.dll ............ [Build ******, API 060425]
000000.000: Module Deimos.dll ............ [Build ******, API 060425]
000000.000: Module Galsat.dll ............ [Build 220121, API 220121]
000000.000: Module Jupiter.dll ........... [Build 220121, API 220121]
000000.000: VSOP87(B) Jupiter: Precision 1.0e-06, Terms 1624/3625
000000.000: Module Io.dll ................ [Build 220121, API 220121]
000000.000: Module Europa.dll ............ [Build 220121, API 220121]
000000.000: Module Ganymede.dll .......... [Build 220121, API 220121]
000000.000: Module Callisto.dll .......... [Build 220121, API 220121]
000000.000: Module Satsat.dll ............ [Build 220121, API 220121]
000000.000: Module Saturn.dll ............ [Build 220121, API 220121]
000000.000: VSOP87(B) Saturn: Precision 1.0e-06, Terms 2904/6365
000000.000: Module Mimas.dll ............. [Build 220121, API 220121]
000000.000: SATSAT Mimas: Terms 113
000000.000: Module Enceladus.dll ......... [Build 220121, API 220121]
000000.000: SATSAT Enceladus: Terms 33
000000.000: Module Tethys.dll ............ [Build 220121, API 220121]
000000.000: SATSAT Tethys: Terms 101
000000.000: Module Dione.dll ............. [Build 220121, API 220121]
000000.000: SATSAT Dione: Terms 59
000000.000: Module Rhea.dll .............. [Build 220121, API 220121]
000000.000: SATSAT Rhea: Terms 68
000000.000: Module Titan.dll ............. [Build 220121, API 220121]
000000.000: SATSAT Titan: Terms 100
000000.000: Module Iapetus.dll ........... [Build 220121, API 220121]
000000.000: SATSAT Iapetus: Terms 605
000000.000: Module Uranus.dll ............ [Build 220121, API 220121]
000000.000: VSOP87(B) Uranus: Precision 1.0e-06, Terms 1827/5269
000000.000: Module Miranda.dll ........... [Build ******, API 060425]
000000.000: Module Ariel.dll ............. [Build ******, API 060425]
000000.000: Module Umbriel.dll ........... [Build ******, API 060425]
000000.000: Module Titania.dll ........... [Build ******, API 060425]
000000.000: Module Oberon.dll ............ [Build ******, API 060425]
000000.000: Module Neptune.dll ........... [Build 220121, API 220121]
000000.000: VSOP87(B) Neptune: Precision 1.0e-06, Terms 391/2024
000000.000: Finished initialising world
000000.000: Module SR71R.dll ............. [Build 220120, API 220121]
000000.000: Finished initialising status
000000.000: Finished initialising camera
000000.000: Finished setting up render state
000000.000: D3D9: [Scene Initialized]
000000.000: Finished initialising panels
000000.010: D3D9ERROR: oapiBlt() Failed (End)
000000.010: D3D9ERROR: Source Rect (0,0,60,40) (w=60,h=40)
000000.010: D3D9ERROR: Target Rect (16,1547,76,1587) (w=60,h=40)
000000.010: D3D9ERROR: Source Data Below: ----------------------------------
000000.010: D3D9ERROR: Surface name is [clbkCreateSurfaceEx] OAPI_Handle=0x158572D8
000000.010: D3D9ERROR: OAPI_Attribs: OAPISURFACE_RENDERTARGET,
000000.010: DX9_DUMP: Type = Surface
000000.010: DX9_DUMP: Usage = RENDERTARGET
000000.010: DX9_DUMP: Pool = D3DPOOL_DEFAULT
000000.010: DX9_DUMP: Format = OAPISURFACE_PF_XRGB (22)
000000.010: DX9_DUMP: Multisample = 0
000000.010: DX9_DUMP: Size = (60, 40)
000000.010: D3D9ERROR: Target Data Below: ----------------------------------
000000.010: D3D9ERROR: Surface name is [SR71R_100_VC2.dds] OAPI_Handle=0x158578F0
000000.010: D3D9ERROR: Has a Surface Interface
000000.010: D3D9ERROR: OAPI_Attribs: OAPISURFACE_TEXTURE, OAPISURFACE_RENDERTARGET,
000000.010: DX9_DUMP: Mips = 1
000000.010: DX9_DUMP: Type = Texture
000000.010: DX9_DUMP: Usage = RENDERTARGET
000000.010: DX9_DUMP: Pool = D3DPOOL_DEFAULT
000000.010: DX9_DUMP: Format = OAPISURFACE_PF_ARGB (21)
000000.010: DX9_DUMP: Multisample = 0
000000.010: DX9_DUMP: Size = (2048, 2048)