New Release D3D9Client Development

[kuddel]

I may have found the problem. Could you add following lines in IProcess.cpp ImageProcessing::Execute() somewhere near the line 352[...]

Did that, but flashing is still there - slightly different, but still there

 

[jarmonik]

Thanks for the tests and texture samples. It is now clear what ever is wrong is about the ImageProcessing shader or shader pipeline configuration. Those textures were clean, nothing there that could cause this. I'll keep searching...

 

[kuddel]

@jarmonik Would a TeamViewer session help you "see" the things? My machine is all yours if you like

 

[jarmonik]

@jarmonik Would a TeamViewer session help you "see" the things? My machine is all yours if you like

I am not familiar with that and not sure if there's anything to be seen other that what we already know. If you can still confirm that "Irrad.Probe" is clean of anomalous flickering pixels at the problem regions. I have made few commits to d3d9_noise_problem branch, if you can check if it fixes the problem. If not then you could change PSPreInteg() code to this. Number of flashing pixels should drop but are they all gone ?

float4 PSPreInteg(float x : TEXCOORD0, float y : TEXCOORD1) : COLOR
{
    float2 p = float2(x, y);
    return float4(tex2D(tSrc, p).rgb, 1);
}

 

[kuddel]

I will so that as soon as I am Back Home.
And you should get your well deserved sleep

 

[martins]

@kuddel Just in case you don't have enough work assigned yet could you also have a quick look at this pull request? It updates the way the force vector and object frame axis display options are accessed by the graphics clients. For the D3D9 client it removes the need for the dialog message loop hooks in OapiExtension. I edited the OapiExtension code quite extensively, and since I think you are the author, you should probably make sure it's fine. I think it all works ok. The only issue I noticed is that the frame axis vectors for celestial bodies and surface bases are not displayed, but I am not sure if that was ever implemented in the D3D9 client.

 

[kuddel]

I'll look into it too. No problem.

[...]The only issue I noticed is that the frame axis vectors for celestial bodies and surface bases are not displayed, but I am not sure if that was ever implemented in the D3D9 client.

That never was implemented, so nothing to worry about - another issue/feature request to be addressed

 

[kuddel]

So I've managed to do some "real work" - for Orbiter that is

[...]If you can still confirm that "Irrad.Probe" is clean of anomalous flickering pixels at the problem regions[...]

Yes, I can confirm not anomalies in "Irrad.Probe" - solid blackness of space

​

[...]have made few commits to d3d9_noise_problem branch, if you can check if it fixes the problem[...]

Checked and it did not make any difference. Same as above: "Irrad.Probe" is clean, "IrdPreItg" is full of noise.

[...]then you could change PSPreInteg() code to this. Number of flashing pixels should drop but are they all gone ?

With that shader change the noise (and therefore the flashing) is completely gone!

It basically went from (1) noisy to (2) clean:​

Next assigned work from you will be in the next post

 

[kuddel]

I've checked the changes from this PR (283-api_forcevector_objectaxis) and all the D3D9Client parts look O.K.
There is an occasional exception @ intptr_t PlanetarySystem::FindNext (intptr_t fh, _finddata_t *fdata, char *fname) of Orbiter Core, but that might be due to the storage and read-back of currently changing visual-helper flags...it looks like it only happens once when I switch between the different branches, so nothing to worry about now.
I might take a look into the "missing feature" of celestial body- and bases-axes. I think moving that code to VObject (like it's done in D3D7Client) is the way to go.

 

[DaveS]

Would it possible to implement a way to make D3D9Client use common advanced textures specified in the GC\*.cfg file(s) if your vessel makes use of multiple common diffuse textures.

I'm mainly thinking how SSU/SSV can load different diffuse textures depending on what it is commanded to load through the mission file. Right now you need to create different advanced textures for each diffuse texture when it would be more efficient to just use a common set as the mapping doesn't change.

 

[jarmonik]

Would it possible to implement a way to make D3D9Client use common advanced textures specified in the GC\*.cfg file(s) if your vessel makes use of multiple common diffuse textures.

After the DX7 is separated from the Orbiter we are likely to dump the "GC\*.cfg" system overboard because it's was very clumsy to begin with. I would prefer a system that would allow to store all mesh related data in the mesh files them-selves. And we could have some kind of mesh editor that would help to manage materials, textures, group-flags, mesh group names, etc.. and save the setting to mesh files directly. Like an advanced version of D3D9Debug controls.

To address the problem you mentioned we could have a function that would allow to load "advanced" textures independently and assign them to a selected diffuse texture. That should be pretty easy and quick to implement. You can create an issue on Orbiter's Git page.

 

[jarmonik]

Next assigned work from you will be in the next post

Could it be that Intel drivers won't tolerate nested loops like that. Could you try this, add the "[unroll]" directives.

float4 PSPreInteg(float x : TEXCOORD0, float y : TEXCOORD1) : COLOR
{
    float3 color = 0;
    float2 p = float2(x, y);
    [unroll] for (int j = 0; j < 8; j++) {
        [unroll] for (int i = 0; i < 8; i++) {
            color += tex2D(tSrc, p + (float2(i, j) - 4) * fD).rgb;
        }
    }
    return float4(color * (1.0f/64.0f), 1);
}

 

[kuddel]

Could it be that Intel drivers won't tolerate nested loops like that. Could you try this, add the "[unroll]" directives.

No, sorry that did not make any difference.

Even "hand unrolling" made no difference:

float4 PSPreInteg(float x : TEXCOORD0, float y : TEXCOORD1) : COLOR
{
    float3 color = 0;
    float2 p = float2(x, y);

    color += tex2D(tSrc, p + (float2(0, 0) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(1, 0) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(2, 0) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(3, 0) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(4, 0) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(5, 0) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(6, 0) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(7, 0) - 4) * fD).rgb;

    color += tex2D(tSrc, p + (float2(0, 1) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(1, 1) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(2, 1) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(3, 1) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(4, 1) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(5, 1) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(6, 1) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(7, 1) - 4) * fD).rgb;

    color += tex2D(tSrc, p + (float2(0, 2) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(1, 2) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(2, 2) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(3, 2) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(4, 2) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(5, 2) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(6, 2) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(7, 2) - 4) * fD).rgb;

    color += tex2D(tSrc, p + (float2(0, 3) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(1, 3) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(2, 3) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(3, 3) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(4, 3) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(5, 3) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(6, 3) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(7, 3) - 4) * fD).rgb;

    color += tex2D(tSrc, p + (float2(0, 4) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(1, 4) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(2, 4) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(3, 4) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(4, 4) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(5, 4) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(6, 4) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(7, 4) - 4) * fD).rgb;

    color += tex2D(tSrc, p + (float2(0, 5) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(1, 5) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(2, 5) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(3, 5) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(4, 5) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(5, 5) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(6, 5) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(7, 5) - 4) * fD).rgb;

    color += tex2D(tSrc, p + (float2(0, 6) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(1, 6) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(2, 6) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(3, 6) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(4, 6) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(5, 6) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(6, 6) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(7, 6) - 4) * fD).rgb;

    color += tex2D(tSrc, p + (float2(0, 7) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(1, 7) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(2, 7) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(3, 7) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(4, 7) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(5, 7) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(6, 7) - 4) * fD).rgb;
    color += tex2D(tSrc, p + (float2(7, 7) - 4) * fD).rgb;

    return float4(color * (1.0f/64.0f), 1);
}

 

[jarmonik]

I can't really understand what's going on there. Could the "fD" be nonsense ?

// Result flat grey image R128: G128: B128
float4 PSPreInteg(float x : TEXCOORD0, float y : TEXCOORD1) : COLOR
{   
    return float4(fD*64.0f, 0.5f, 1.0f);
}

 

[GLS]

To address the problem you mentioned we could have a function that would allow to load "advanced" textures independently and assign them to a selected diffuse texture.

I agree with adding a function to load an advanced texture.

A somewhat related question that I have some time now: when I load a texture and use it to replace a texture in a mesh, is that replaced mesh texture unloaded or does it stay in memory and maybe causes a performance hit? I'm not reporting a problem, I'm just wondering what happens.

 

[kuddel]

I can't really understand what's going on there. Could the "fD" be nonsense ?

// Result flat grey image R128: G128: B128
float4 PSPreInteg(float x : TEXCOORD0, float y : TEXCOORD1) : COLOR
{  
    return float4(fD*64.0f, 0.5f, 1.0f);
}

This results in a solid grey env-map (as expected, I think):


As I've mentioned further up and as you are wondering about yourself, I would not rule out my Intel graphic-drivers for the whole flashing issue.

 

[DaveS]

To address the problem you mentioned we could have a function that would allow to load "advanced" textures independently and assign them to a selected diffuse texture. That should be pretty easy and quick to implement. You can create an issue on Orbiter's Git page.

Issue created: https://github.com/orbitersim/orbiter/issues/289

 

[jarmonik]

As I've mentioned further up and as you are wondering about yourself, I would not rule out my Intel graphic-drivers for the whole flashing issue.

Yes, that was correct result. I don't know what I was expecting. Why does the flashing appear in this instance, rendering of "Blur 1" map is almost identical in many ways. Is there a way to downgrade the drivers to older one. I wonder, could the high number of repetitive texture reads cause driver to fail somehow, let's reduce repeat count.

float4 PSPreInteg(float x : TEXCOORD0, float y : TEXCOORD1) : COLOR
{
    float3 color = 0;
    float2 p = float2(x, y);
    [unroll] for (int j = 0; j < 3; j++) {
        [unroll] for (int i = 0; i < 3; i++) {
            color += tex2D(tSrc, p + (float2(i, j) - 1) * fD).rgb;
        }
    }
    return float4(color * (1.0f/9.0f), 1);
}

 

[jarmonik]

I agree with adding a function to load an advanced texture.

A somewhat related question that I have some time now: when I load a texture and use it to replace a texture in a mesh, is that replaced mesh texture unloaded or does it stay in memory and maybe causes a performance hit? I'm not reporting a problem, I'm just wondering what happens.

What kind or graphics hardware you have since you also saw those flickers/flashes ?

The original texture remains in a memory since it could still be used by other vessels of the same class, it's shared. It doesn't cause performance issue of any-kind.

 

[kuddel]

Do these ERRORs (from D3D9ClientLog.html) have anything to do with it?

...
(285: 11.1s 454.04ms)(0x898) Compiling a Shader [Modules/D3D9Client/IPI.hlsl] function [VSMain]...
(286: 11.1s 09.91ms)(0x898) Compiling a Shader [Modules/D3D9Client/EnvMapBlur.hlsl] function [PSBlur]...
(287: 11.2s 90.52ms)(0x898) Compiling a Shader [Modules/D3D9Client/IPI.hlsl] function [VSMain]...
(288: 11.2s 09.37ms)(0x898) Compiling a Shader [Modules/D3D9Client/IrradianceInteg.hlsl] function [PSPreInteg]...
(289: 11.2s 32.30ms)(0x898) Compiling a Shader [Modules/D3D9Client/IrradianceInteg.hlsl] function [PSInteg]...
(290: 11.9s 678.64ms)(0x898) Compiling a Shader [Modules/D3D9Client/IrradianceInteg.hlsl] function [PSPostBlur]...
(291: 18.3s 6419.26ms)(0x898) [ERROR] LOWORD(2058), HIWORD(0x9)
(292: 18.3s 01.89ms)(0x898) [ERROR] LOWORD(2058), HIWORD(0x1)
(293: 18.3s 30.11ms)(0x898) [ERROR] LOWORD(2058), HIWORD(0x9)
(294: 18.3s 01.66ms)(0x898) [ERROR] LOWORD(2058), HIWORD(0x1)
(295: 18.4s 34.50ms)(0x898) [ERROR] LOWORD(2058), HIWORD(0x9)
(296: 18.4s 01.50ms)(0x898) [ERROR] LOWORD(2058), HIWORD(0x1)
(297: 18.4s 61.59ms)(0x898) [ERROR] LOWORD(2058), HIWORD(0x9)
(298: 18.4s 02.04ms)(0x898) [ERROR] LOWORD(2058), HIWORD(0x1)
(299: 19.2s 729.13ms)(0x898) [ERROR] LOWORD(2058), HIWORD(0x9)
(300: 19.2s 02.11ms)(0x898) [ERROR] LOWORD(2058), HIWORD(0x1)
(301: 19.6s 425.77ms)(0x898) [ERROR] LOWORD(2058), HIWORD(0x9)
(302: 19.6s 00.73ms)(0x898) [ERROR] LOWORD(2058), HIWORD(0x1)
(303: 19.7s 90.50ms)(0x898) [ERROR] LOWORD(2058), HIWORD(0x9)
(304: 19.7s 01.52ms)(0x898) [ERROR] LOWORD(2058), HIWORD(0x1)
(305: 20.3s 568.33ms)(0x898) [ERROR] LOWORD(2058), HIWORD(0x9)
(306: 20.3s 01.59ms)(0x898) [ERROR] LOWORD(2058), HIWORD(0x1)
(307: 33.0s 12689.58ms)(0x898) [ERROR] LOWORD(2058), HIWORD(0x9)
(308: 33.0s 01.76ms)(0x898) [ERROR] LOWORD(2058), HIWORD(0x1)
(309: 41.6s 8639.95ms)(0x898) ================ clbkCloseSession ===============
(310: 41.6s 00.09ms)(0x3C2C) TileBuffer::LoadTile thread terminated
(311: 41.6s 00.93ms)(0x24C4) TileLoader::Load thread terminated
(312: 41.6s 01.10ms)(0x898) ================= Deleting Scene ================
...

But I think they only appear when the DebugDialog is open to show the env-map(s).

Edit: I found out myself Those have nothing to do with the original issue