New Release D3D9Client Development

[kuddel]

So back to the "flashy bit"...

I've checked out a clean build;
Local lights in Orbiter main are enabled; although "Local lights" in D3D9Client extended config is set to "None";
In the debug Dialog I've turned on the "IrdPre ltg" env map display (as suggested by Jarmo);

Here's what I see:

Could this be some kind of memory overwrite in a shaders memory? Frequency is something like 2-5 Hz.

 

[kuddel]

FYI: With local lights enabled I can confirm that those do work!

 

[kuddel]

Addendum:
I can turn off flashing when I remove \Config\GC\DeltaGlider.cfg (which was unmodified from the checkout & build process - it's referencing MESH DG\deltaglider_ns ...don't exactly know where it is coming from, though)

 

[jarmonik]

So back to the "flashy bit"...
Here's what I see:
Could this be some kind of memory overwrite in a shaders memory? Frequency is something like 2-5 Hz.

Thanks a lot, you found a major clue. I have no idea (yet) where those come from but now I have a solid lead to follow. Memory overwrite shouldn't happen with GPU but reading data from an uninitialized texture has caused weird graphics anomalies before.

 

[GLS]

Local lights in Orbiter main are enabled; although "Local lights" in D3D9Client extended config is set to "None";

This wasn't enabled...

But how does the ground get lit with the (D3D9) lights disabled?
Also, maybe the None option should not exist there, as it already exists globally in the Visuals tab. The lights on/off control would be done by the base configuration, and then each graphics engine would handle whatever options they might have, if the lights are on.

So, tested the PLB light flickering and there seems to be no issues, both at x4-partial and x4-full.
The bad news is that there is a very noticeable problem when I launch with the pad lights on: as the vehicle lifts off and leaves the light cones, it stays lit. A few seconds later it goes "back to normal" but, if I decrease the apparent size of the vessel (moving the camera away or zooming out) it gets lit as if it was back on the pad. This threshold seems to be related to how far the vehicle is from the pad lights, which are not pointing up but have 180º opening. If I focus the launch pad, where the lights are, then the vehicle leaves the light cones as expected.

BTW: I'm getting some CTDs right after loading, which debugging with a Release build point to the d3d9x_43.dll... I'll try to install the debug stuff from DirectX to track this one.

 

[kuddel]

Thanks a lot, you found a major clue. I have no idea (yet) where those come from but now I have a solid lead to follow. Memory overwrite shouldn't happen with GPU but reading data from an uninitialized texture has caused weird graphics anomalies before.

Good to hear it's not a bug no one can explain

Do these errors (from Orbiter.log) have something to do with it?

...
000021.504: D3D9: NewShader [DG\deltaglider_ns]=4
000021.517: D3D9: NewShader [DG\deltaglider_ns]=4
000021.831: D3D9ERROR: CreateShaderCache: CreateFile Error: 0x3
000021.832: D3D9ERROR: Path=[Cache/Shaders/IPIVS_VSMain_IPI.hlsl.bin]
000021.862: D3D9ERROR: CreateShaderCache: CreateFile Error: 0x3
000021.863: D3D9ERROR: Path=[Cache/Shaders/IPIPS_PSBlur_EnvMapBlur.hlsl.bin]
000021.947: D3D9ERROR: CreateShaderCache: CreateFile Error: 0x3
000021.947: D3D9ERROR: Path=[Cache/Shaders/IPIVS_VSMain_IPI.hlsl.bin]
000021.987: D3D9ERROR: CreateShaderCache: CreateFile Error: 0x3
000021.987: D3D9ERROR: Path=[Cache/Shaders/IPIPS_PSPreInteg_IrradianceInteg.hlsl.bin]
000022.819: D3D9ERROR: CreateShaderCache: CreateFile Error: 0x3
000022.820: D3D9ERROR: Path=[Cache/Shaders/IPIPS2_PSInteg_IrradianceInteg.hlsl.bin]
000022.832: D3D9ERROR: CreateShaderCache: CreateFile Error: 0x3
000022.833: D3D9ERROR: Path=[Cache/Shaders/IPIPS2_PSPostBlur_IrradianceInteg.hlsl.bin]

Edit: It doesn't seem to make a difference. If I disable ShaderCache in D3D9Client.cfg (ShaderCacheUse = 0) the errors went, but flashing stays.

 

[jarmonik]

Here's what I see:

I have looked at the code and found nothing yet. One thing I don't quite understand is this: The cube texture displayed on the image in only 16x16 pixels stretched to fit the screen, it's a simple copy blit no programmable GPU involved. How can a low resolution image store those abnormal shapes ? @GLS Can you see any abnormal shapes there, "red" in your case ?

@kuddel Could you replace a function located in IrradianceInteg.hlsl with this one, it will write the image you see with a constant flat grey color. Do the abnormal shapes still appear ?

float4 PSPreInteg(float x : TEXCOORD0, float y : TEXCOORD1) : COLOR
{
    return float4(0.2f, 0.2f, 0.2f, 1);
}

 

[jarmonik]

So, tested the PLB light flickering and there seems to be no issues, both at x4-partial and x4-full.
The bad news is that there is a very noticeable problem when I launch with the pad lights on: as the vehicle lifts off and leaves the light cones, it stays lit. A few seconds later it goes "back to normal" but, if I decrease the apparent size of the vessel (moving the camera away or zooming out) it gets lit as if it was back on the pad. This threshold seems to be related to how far the vehicle is from the pad lights, which are not pointing up but have 180º opening. If I focus the launch pad, where the lights are, then the vehicle leaves the light cones as expected.

BTW: I'm getting some CTDs right after loading, which debugging with a Release build point to the d3d9x_43.dll... I'll try to install the debug stuff from DirectX to track this one.

Thanks for testing the PLB lights issue. If you can track the CTD where it's coming from, that would be very helpful.
It's kinda odd that the lighting conditions depend on camera distance. 180deg opening could break the math and lead to a division by zero. 175deg is a safe maximum. The world in the Orbiter is centered on the camera. Maybe the math computing light positions is broken and move along with the camera, somehow. I'll look into that.

 

[GLS]

Can you see any abnormal shapes there, "red" in your case ?

Yep! Red squares, usually less than 3 at the same time, at maybe 0.5-1Hz, both in SSV and DG. Not seeing any side effects in SSV, but in the DG some of them coincide with the red flashes (or maybe all of them, but it's hard to see the vehicle with the debug output).

 

[kuddel]

@kuddel Could you replace a function located in IrradianceInteg.hlsl with this one, it will write the image you see with a constant flat grey color. Do the abnormal shapes still appear ?

No change at all, ... strange I would have assumed that at least the background would be solid grey...
That's with the same Version of Orbiter/DeltaGlider of last time.


With the current "HEAD" (if that's what it's called in git) of d3d9_local_lights branch it's a bit blockier, but still "flashy" :/

 

[kuddel]

Grrr that nasty ninja build process always overwrites any changes made to the output (IrradianceInteg.hlsl shader in this case) !

Here's what it looks like, now:


...so as expected it's solid grey and no flashing.

I'll try to add one line after the other into PSPreInteg(float x : TEXCOORD0, float y : TEXCOORD1) and see if I can isolate something

I am starting to suspect my Drivers[*] ... I have had mixed experience (2 out of 10 Versions were good) with them

[*]https://www.intel.com/content/www/us/en/download/19344/intel-graphics-windows-dch-drivers.html

 

[jarmonik]

I'll try to add one line after the other into PSPreInteg(float x : TEXCOORD0, float y : TEXCOORD1) and see if I can isolate something

There is not much choice there. The artifacts must come from the texture sampling but what creates them in the source texture from the first palce.

Could you restore the original shader "IrradianceInteg.hlsl" and then disable everything else except the following line from Scene::RenderSecondaryScene() subroutine just to be sure that the artifacts doesn't come from any scene drawing routine.

// Clear the viewport
HR(pDevice->Clear(0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER | D3DCLEAR_STENCIL, 0, 1.0f, 0L));

If the artifacts still appear then could you try even more direct clearing of the source texture by adding one line in this code section in Scene::IntegrateIrradiance() subroutine.

    // ---------------------------------------------------------------------
    // Pre-Integrate Irradiance Cube
    //
    pIrradiance->Activate("PSPreInteg");
    pIrradiance->SetFloat("fD", &D3DXVECTOR2(1.0f / float(desc.Width), 1.0f / float(desc.Height)), sizeof(D3DXVECTOR2));

    for (DWORD i = 0; i < 6; i++)
    {
        pSrc->GetCubeMapSurface(D3DCUBEMAP_FACES(i), 0, &pSrf);
        pIrradTemp->GetCubeMapSurface(D3DCUBEMAP_FACES(i), 0, &pTgt);
        
        pDevice->StretchRect(pSrf, NULL, pTmp2, NULL, D3DTEXF_POINT);

        pDevice->ColorFill(pTmp2, NULL, 0); //// <---- ADD THIS LINE

        pIrradiance->SetOutputNative(0, pTgt);
        pIrradiance->SetTextureNative("tSrc", pIrradTemp2, IPF_POINT | IPF_CLAMP);

        if (!pIrradiance->Execute(true)) {
            LogErr("pIrradiance Execute Failed");
            return false;
        }

        SAFE_RELEASE(pTgt);
        SAFE_RELEASE(pSrf);
    }

 

[kuddel]

Hi,

I've done step 1 ( "[...]restore the original shader "IrradianceInteg.hlsl[...]" & "[...]disable everything else except the following line from Scene::RenderSecondaryScene()[...]" )
and the Ship stays solid red!

Now all the env-maps (from the D3D9Client Debug Dialog) show black "unfolded boxes" except for shadow ...) like this - as expected I think:


...sorry for the 50 minute delay I watched some "curious marc"

 

[kuddel]

Hey,
out of curiosity I've thought: Let's re-enable the disabled parts of RenderSecondaryScene() step by step:
Surely, enabeling the part before HR(pDevice->Clear(0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER | D3DCLEAR_STENCIL, 0, 1.0f, 0L)); made no change;
But as soon as the "render planets" part (only) was enabled the flashing came back!



...just to inform you

Good night

 

[jarmonik]

...sorry for the 50 minute delay I watched some "curious marc"

That's no problem really, my delays are much longer.

Yeah, the boxes are expected to be all black. Which indicates that the clearing works at least.

I checked pretty much every shader and none of them are writing on that area on the map. Could it be that some surface base is playing tricks, or something. Does it work in a clean installation on your computer ?

I guess the next step is to turn the planet rendering and then the local lights back on to see if the artifacts reappear. If it's the planet rendering code then try to disable features on a planet level like base rendering, runway lights, etc... until the artifacts disappear.

 

[jarmonik]

Good night

Good night.

 

[jarmonik]

The bad news is that there is a very noticeable problem when I launch with the pad lights on: as the vehicle lifts off and leaves the light cones, it stays lit.

Can you check if this problem is fixed.

 

[kuddel]

[...] Could it be that some surface base is playing tricks, or something. Does it work in a clean installation on your computer ?[...]

I think I am using a "clean installation":

• new directory;
• git checkout ...;
• open in Visual Studio;
• build (Debug_x64);
• Execute out\Orbiter_ng;
• select D3D9Client in Video Tab; enable the "Reflection Mode" setting in D3D9CLient Advanced Setup Dialog (set to "Full Scene")
• run Scenario

I am not even including hi-res planet textures any more

[...] I guess the next step is to turn the planet rendering and then the local lights back on to see if the artifacts reappear. If it's the planet rendering code then try to disable features on a planet level like base rendering, runway lights, etc... until the artifacts disappear.

You mean the code-sections in Scene::RenderSecondaryScene(), right?
I'll try isolating the affecting code as much as I can (once I'm back on my home-machine).

Edit: refined "the list"

 

[jarmonik]

You mean the code-sections in Scene::RenderSecondaryScene(), right?

Yes.

 

[kuddel]

1st I have to add, that I have to refine my "clean" setup procedure two posts above a bit: I surely had to enable the "Reflection Mode" setting in D3D9CLient Advanced Setup Dialog (set to "Full Scene")

2nd: The flashing will not appear as long as the "render planets" part in Scene::RenderSecondaryScene() is commented out.

3rd: l just changed the line 2272

bool isActive = plist[i].vo->IsActive();​

to​

bool isActive = plist[i].vo->IsActive() && plist[i].vo->IsVisible();​

​

to see what this will change and found that it reduces the flashing area (see image)​

​

​

...maybe this helps isolate the issue?

I will continue to look for anything that might shed some light.