New Release D3D9Client Development

[jarmonik]

Is there something that can be done to fix this uneven lighting issue on meshes?

Yes, by switching lighting computation to work in per-pixel basis instead of per-vertex basis. If the client architecture would be switched from forward rendering to a deferred rendering a pixel light sources would become much cheaper with a better normal-map light interaction. I have given a lot of though for that and a switch to a deferred architecture may actually happen.

Light attenuation is usually defined as:

1.0 / (a + bx + cx^2)

What's the importance of the linear term bx, would it be Ok to ignore it to save one per-pixel-per-light-source square root ?

 

[GLS]

So, I'm making a lakebed runway texture for White Sands (and maybe Edwards), and in MOGE (Martin's Own Graphics Client) everything looks good, but in D3D9 this happens (see attached image). Looks like there's some "bleeding" from other runway "blocks" in the texture (horizontal lines). Is there a way around this?

 

[jarmonik]

So, I'm making a lakebed runway texture for White Sands (and maybe Edwards), and in MOGE (Martin's Own Graphics Client) everything looks good, but in D3D9 this happens (see attached image). Looks like there's some "bleeding" from other runway "blocks" in the texture (horizontal lines). Is there a way around this?

It must be something in the texture it-self. Can you attach the texture ?

Have you specified a black border color for the texture by accident ?

 

[GLS]

It must be something in the texture it-self. Can you attach the texture ?

Have you specified a black border color for the texture by accident ?

Here it is.
I'm using "blocks" of 64x64 on the runway, and yes some have black lines next to the border, but they are all contained inside the respective blocks, so no problems should occur (and it works fine in MOGE). BTW, there should be no rounding problems as the UV coordinates on the runway all belong to this set {0, 0.25, 0.5, 0.75, 1}.

 

[jarmonik]

Here it is.
I'm using "blocks" of 64x64 on the runway, and yes some have black lines next to the border, but they are all contained inside the respective blocks, so no problems should occur (and it works fine in MOGE). BTW, there should be no rounding problems as the UV coordinates on the runway all belong to this set {0, 0.25, 0.5, 0.75, 1}.

It is very likely a texture filtering issue. The filtering is causing a pixels outside the texture rectangle also effecting into a results. You can replace the filter description from D3D9Client.fx with the one below to get a MOGE response.

That will lead back to the original question that's been a problem from the beginning. Do we need to stop Orbiter from evolving because every change we do can cause a problem (or a difference with a MOGE) in a rare cases ?



Line 187 in D3D9Client.fx

sampler WrapS = sampler_state       // Primary Mesh texture sampler
{
    Texture = <gTex0>;
    MinFilter = POINT;
    MagFilter = POINT;
    MipFilter = NONE;
    MaxAnisotropy = ANISOTROPY_MACRO;
    MipMapLODBias = 0;
    AddressU = WRAP;
    AddressV = WRAP;
};

 

[GLS]

It is very likely a texture filtering issue. The filtering is causing a pixels outside the texture rectangle also effecting into a results. You can replace the filter description from D3D9Client.fx with the one below to get a MOGE response.

That will lead back to the original question that's been a problem from the beginning. Do we need to stop Orbiter from evolving because every change we do can cause a problem (or a difference with a MOGE) in a rare cases ?



Line 187 in D3D9Client.fx

sampler WrapS = sampler_state       // Primary Mesh texture sampler
{
    Texture = <gTex0>;
    MinFilter = POINT;
    MagFilter = POINT;
    MipFilter = NONE;
    MaxAnisotropy = ANISOTROPY_MACRO;
    MipMapLODBias = 0;
    AddressU = WRAP;
    AddressV = WRAP;
};

I did this change, and although it looks more normal, there's still some very, very thin bleeding. Here's the runway definition so you can see exactly what it looks:

BEGIN_OBJECTLIST
RUNWAY ;17/35
    END1 -5450 0 -572.6255
    END2 5133.8796 0 -1909.6804
    WIDTH 91.44
    NRWSEG 25
    RWSEG1 1 	0.008571 	0.5 	0.25 	0.75 	0.5
    RWSEG2 1 	0.061920 	0.25 	0 	1 	0.75
    RWSEG3 1 	0.008571 	0.5 	0.25 	0.5 	0.25
    RWSEG4 2 	0.020000 	0.25 	0 	0.75 	0.5
    RWSEG5 1 	0.008571 	0.25 	0 	0.5 	0.25
    RWSEG6 17 	0.149509 	0.25 	0 	0.75 	0.5
    RWSEG7 1 	0.008571 	0.75 	0.5 	0.75 	0.5
    RWSEG8 1 	0.010000 	0.75 	0.5 	0.5 	0.25
    RWSEG9 1 	0.010000 	0.75 	0.5 	0.5 	0.25
    RWSEG10 1 	0.008571 	1 	0.75 	0.75 	0.5
    RWSEG11 7 	0.061518 	1 	0.75 	0.25 	0
    RWSEG12 1 	0.008571 	1 	0.75 	0.5 	0.25
    RWSEG13 32	0.271254	1 	0.75 	0.25 	0
    RWSEG14 1 	0.008571 	1 	0.75 	0.25 	0.5
    RWSEG15 7 	0.061518 	1 	0.75 	0 	0.25
    RWSEG16 1 	0.008571 	1 	0.75 	1 	0.75
    RWSEG17 1 	0.010000 	0.5 	0.75 	0.25 	0.5
    RWSEG18 1 	0.010000 	0.5 	0.75 	0.25 	0.5
    RWSEG19 1 	0.008571 	0.75 	0.5 	1 	0.75
    RWSEG20 17 	0.149509 	0 	0.25 	0.75 	0.5
    RWSEG21 1 	0.008571 	0.25 	0 	0.25 	0
    RWSEG22 2 	0.020000 	0 	0.25 	0.75 	0.5
    RWSEG23 1 	0.008571	0.5 	0.25 	0.25 	0
    RWSEG24 1 	0.061920 	0.25 	0 	1 	0.75
    RWSEG25 1 	0.008571	0.5 	0.25 	1 	0.75
    RWTEX NOR1735tex
END

 

[jarmonik]

I can reproduce the issue but according to documentation it is working as expected.

https://msdn.microsoft.com/en-us/library/windows/desktop/bb147229(v=vs.85).aspx

You should use nearest-point sampling carefully, because it can sometimes cause graphic artifacts when the texture is sampled at the boundary between two texels. This boundary is the position along the texture (u or v) at which the sampled texel transitions from one texel to the next.

Texture coordinates like 0.25, 0.5, 0.75 are lying exactly between texels and the hardware doesn't know which one to pick resulting bleeding. Obviously DX7 is handling the case differently. It would be practical to design the textures so that a transition from a tile to an other occurs in a smooth position instead on a border of black and white lines.

 

[GLS]

I can reproduce the issue but according to documentation it is working as expected.

https://msdn.microsoft.com/en-us/library/windows/desktop/bb147229(v=vs.85).aspx



Texture coordinates like 0.25, 0.5, 0.75 are lying exactly between texels and the hardware doesn't know which one to pick resulting bleeding. Obviously DX7 is handling the case differently. It would be practical to design the textures so that a transition from a tile to an other occurs in a smooth position instead on a border of black and white lines.

... and textures just got more complicated. :facepalm:
So, a very quick read of that tells me if I bump up the size of the texture this effect (might) be reduced. Also, if I choose those coordinates in little bit differently, maybe 0.501 instead of 0.5, it might work. Am I correct?

 

[jarmonik]

... and textures just got more complicated. :facepalm:
So, a very quick read of that tells me if I bump up the size of the texture this effect (might) be reduced. Also, if I choose those coordinates in little bit differently, maybe 0.501 instead of 0.5, it might work. Am I correct?

Based on my understanding Yes, Adding or subtracting 0.001 depending on which corner it is, should be sufficient enough. With +-0.001 offsets the same uv-coordinates should work up-to a resolution 512x512.

For an example lower-right corner would be 0.499, 0.499 and upper-left corner 0.501, 0.501

 

[GLS]

Based on my understanding Yes, Adding or subtracting 0.001 depending on which corner it is, should be sufficient enough. With +-0.001 offsets the same uv-coordinates should work up-to a resolution 512x512.

For an example lower-right corner would be 0.499, 0.499 and upper-left corner 0.501, 0.501

So I tried 0.001, and even 0.01, but this problem still persists. Worse, looking at the "center" of the runway, there seems to be some bleeding from the touchdown markers, which are 10px away from the end of their "box". I think the safe bet here is to move up to 512x512, which would give 128x128 square boxes, and then leave a margin of maybe 10px around each box. Not a very efficient area usage, but I'm not seeing many more alternatives...

 

[jarmonik]

Worse, looking at the "center" of the runway, there seems to be some bleeding from the touchdown markers, which are 10px away from the end of their "box".

Yes, I can reproduce the problem. It would be a good idea to gain a better understanding of why is this happening.

If you replace the texture sampler specs with the ones posted earlier and you disable anti-aliasing from D3D9, then it will render exactly the same way as the MOGE.

So, anti-aliasing is one factor that is effecting to the results. Since, the anti-aliasing is done in a screen space it is possible that when an off-center pixel coordinates are mapped from screen space to texture space they can be pretty far outside the UV rectangle when the surface is viewed from a very shallow angle.

 

[GLS]

Yes, I can reproduce the problem. It would be a good idea to gain a better understanding of why is this happening.

If you replace the texture sampler specs with the ones posted earlier and you disable anti-aliasing from D3D9, then it will render exactly the same way as the MOGE.

So, anti-aliasing is one factor that is effecting to the results. Since, the anti-aliasing is done in a screen space it is possible that when an off-center pixel coordinates are mapped from screen space to texture space they can be pretty far outside the UV rectangle when the surface is viewed from a very shallow angle.

I managed to improve the situation since yesterday: changed to a 512px texture, used just the center 114x114 of a 128x128 area, and moved the image parts around so that the bleeding parts are less noticeable. It's far from optimum but it works.
BTW: is there a way to disable (the "main") runway lights? Those lakebed runways only have PAPI and VASI, and in MOGE if set "COUNT1 1" it puts just a light at each end (also can't disable them, but this is the minimum). In D3D9, it always puts that pretty light show regardless of the "COUNT1" parameter.

 

[jarmonik]

BTW: is there a way to disable (the "main") runway lights? Those lakebed runways only have PAPI and VASI, and in MOGE if set "COUNT1 1" it puts just a light at each end (also can't disable them, but this is the minimum). In D3D9, it always puts that pretty light show regardless of the "COUNT1" parameter.

It's currently not possible to disable them but I can define a new CATEGORY 3 setting for the next version of the client that will disable the main lights. Only PAPI(s) and VASI remains enabled. Is that Ok ?

Should the client use POINT filter for runways by default instead of ANISOTROPIC ?

 

[GLS]

It's currently not possible to disable them but I can define a new CATEGORY 3 setting for the next version of the client that will disable the main lights. Only PAPI(s) and VASI remains enabled. Is that Ok ?

Yes, I think that would work. Thanks!

Should the client use POINT filter for runways by default instead of ANISOTROPIC ?

In all honesty, I don't know. Right now, with the defaut settings, it looks good. If this setting needs change or not, I'll leave it to your better judgement. :thumbup:

 

[DaveS]

It's currently not possible to disable them but I can define a new CATEGORY 3 setting for the next version of the client that will disable the main lights. Only PAPI(s) and VASI remains enabled. Is that Ok ?

Should the client use POINT filter for runways by default instead of ANISOTROPIC ?

What is the difference? If the runway lights could be changed to resemble the ones in FSX, then that would be great.

 

[DaveS]

I wonder if more environment cams could be added? Currently D3D9Client only supports 1 environment cam per vessel. I'd like to see support for more than one cam per vessel to get more accurate reflections.

 

[aldarion]

(962: 62.86s 498467478us)(0x18C4) Sketchap Exiting... All resources released
(963: 62.86s 498467487us)(0x18C4) Clearing Font Cache... 14 Fonts are stored in the cache
(964: 62.86s 498467986us)(0x18C4) ====== D3D9Effect Global Exit =======
(965: 62.86s 498468513us)(0x18C4) Mesh 0x8AD3400 Removed from catalog
(966: 62.86s 498469464us)(0x18C4) Deleting Surface 0x8C4E618 (Null.dds) (16,16)...
(967: 62.86s 498469488us)(0x18C4) Deleting Surface 0x8C4E4F0 (D3D9Noise.dds) (128,128)...
(968: 62.86s 498469508us)(0x18C4) ============ Checking Object Catalogs ===========
(969: 62.86s 498469517us)(0x18C4)[ERROR] UnDeleted Surface(s) Detected
(970: 62.87s 498473361us)(0x18C4)[ERROR] Surface 0x8AFAAB8 (DG\blitsrc1.dds) (512,512)
(971: 62.87s 498476145us)(0x18C4) Deleting Surface 0x8AFAAB8 (DG\blitsrc1.dds) (512,512)...
(972: 62.87s 498476188us)(0x18C4)[ERROR] Surface 0x8AFDD18 (clbkCreateSurface) (680,49)
(973: 62.88s 498480582us)(0x18C4) Deleting Surface 0x8AFDD18 (clbkCreateSurface) (680,49)...
(974: 62.88s 498480781us)(0x18C4)[ERROR] Surface 0x8B18D50 (clbkCreateSurface) (850,40)
(975: 62.88s 498483895us)(0x18C4) Deleting Surface 0x8B18D50 (clbkCreateSurface) (850,40)...
(976: 62.88s 498484195us)(0x18C4)[ERROR] Surface 0x8B17D20 (clbkCreateSurface) (850,40)
(977: 62.88s 498486842us)(0x18C4) Deleting Surface 0x8B17D20 (clbkCreateSurface) (850,40)...
(978: 62.88s 498487145us)(0x18C4) ========== Destroying framework objects ==========
(979: 63.94s 499544875us)(0x18C4) [DirectX Device Reset Succesfull]
(980: 63.94s 499544911us)(0x18C4) Deleting Framework
(981: 63.96s 499562241us)(0x18C4)[ERROR] Invalid Window !! RenderWndProc() called after calling clbkDestroyRenderWindow()
(982: 71.93s 507539299us)(0x18C4) Node[0] = (Current state) (0x19857358)
(983: 71.93s 507539335us)(0x18C4) Scenario = .\Scenarios\(Current state).scn
(984: 71.99s 507594367us)(0x18C4) D3D9Client destructor called
(985: 71.99s 507594403us)(0x18C4) --------------ExitModule------------
(986: 71.99s 507598838us)(0x18C4) Log Closed

D3D9 with Orbiter Beta r23 sometime freezes when I click something from the panel above the screen (e.g. function, display, info butto).

 

[gattispilot]

I am trying to run d3d9 on Windows 10. I downloaded and installed d3D9r15. But I get no video client
down loaded libraries and now it works

 

[Abloheet]

Bug report for r25 d3d9beta client.
Meshes of surface bases, and runways, are rendered at the sphere level, instead of actual surface level.
I remember, in older versions, this problem wasn't there.
Otherwise, very good job! Very stable! :thumbup:

 

[jroly]

Yeah I noticed the surface bases can be seen through the mountains as well, but I didn't bother reporting it cause it is fairly obvious.