New Release D3D9Client Development

[kuddel]

Hey,
another small question to the experts
My DeltGlider flashes strangely (or fancy whatever you like) for quite some time now.
I'm not sure what I've done to make it do this, but can someone maybe give me a hint on what I might have done (wrong)?
Some metallness shader mess I assume.

 

[GLS]

Hey,
another small question to the experts
My DeltGlider flashes strangely (or fancy whatever you like) for quite some time now.
I'm not sure what I've done to make it do this, but can someone maybe give me a hint on what I might have done (wrong)?
Some metallness shader mess I assume.
View attachment 30815

Oh, you got a much colorful flashing... mine is just bright red.

 

[kuddel]

@GLS : I would love to have a "boring red one". Can we exchange[*]?

[*] "Nur an Selbstabholer" / "Only for pickup"

 

[jarmonik]

I haven't seen anything like that before. Could it be broken Local lights producing some random noise. Try to isolate them from the shaders.
I'll have to make x86 test build to see if it's all right there. Usually I forgot to enable Win32 and I got x64 build.

 

[kuddel]

Thanks Jarmo, I'll see whether I can isolate the local lights.
BTW: This happens in both x64 and 32bit builds, which share many things (via symbolic links).
This indicates a "configuration" issue present in both - so .hlsl and/or .fx files might be a good guess.
I'm currently some days away from an Orbiter-machine, so don't expect results too soon.

 

[GLS]

@GLS : I would love to have a "boring red one". Can we exchange[*]?

[*] "Nur an Selbstabholer" / "Only for pickup"

It is very hard to capture it, as it doesn't flash as much as that, maybe a couple of flashes in a row and them normal for several seconds.

 

[jarmonik]

I just made a 32-bit build and I don't see DG at all. Atlantis seems to work. Some scenarios give an instant CTD on launch. It have used to work before so what now..

EDIT: Bad Exe format. It seems that switching from x64 to x86 doesn't rebuild all modules.

 

[jarmonik]

In a clean 32-bit build I don't see anything abnormal in DG (never had) therefore it's very difficult to pinpoint the source of the problem. Does is still "flash" if you disable every optional feature such as (Local Lights, Reflections, Shadows). Is there a revision in the repository that doesn't have the problem ? It's obviously bad data coming to the shader but from which variable or structure.

 

[gamer19]

looks cool tho
can you release it


i know i know.... joking

 

[kuddel]

I am pretty sure that it is something I have tried at the shaders...
I've build it on a clean machine (at work ...don't tell by boss) and it works as expected (no flashing).
I'll just have to work it step by step - I am a bit excited what it will be

 

[GLS]

On the Debug D3D9.dll not loading, I checked the dependencies and it depends on d3dx9d_43.dll, which I'm guessing is a debug DirectX file, which I probably didn't install, so that is one mystery is solved.

The terrain in the Edwards area is now normal again.

The local lights now work again... but only illuminate the ground. Vessels, self and others, are still in the dark. This prevents me from testing the 4- vs 8-light flickering issue.

While flying the DG at sunset I found another problem: the building shadows also "shadow" the runway lights. Flying thru them, I realized they were above the ground. Plus, they are too dark for a planet with atmosphere, which will have some diffuse light. In MOGE they disappear before reaching the runway, so I can't tell if they shadow the lights, but they are also too dark and above the ground.

On D3D9 only, sometimes the shadows flip direction and head towards the Sun.

The red flashing on the DG still happens: day, night and dawn/dusk, with or without the main engines firing, but not when landed. I have everything enabled in the Visual Effects tab, and here is the D3D9 config file:

FrameRate = 200
EnableLimiter = 0
CustomCamMode = 1
PlanetPreloadMode = 0
PlanetTexLoadFreq = 50
Anisotrophy = 4
SceneAntialias = 4
SketchpadFont = 1
PreLoadBaseVisuals = 0
EnableNormalMapping = 1
NearClipPlaneMode = 1
RwyLightAnimate = 1
RwyLightAngle = 120
RwyBrightness = 1
NightLightsAngle = 10
BumpMapAmplitude = 1
PlanetGlow = 0.7
EnvMapSize = 256
EnvMapMode = 2
EnvMapFaces = 2
ShadowMapMode = 3
ShadowMapFilter = 2
ShadowMapSize = 2048
TerrainShadowing = 2
EnableGlass = 1
EnableMeshDbg = 1
TileMipmaps = 1
TextureMips = 1
TileDebug = 0
StereoSeparation = 65
StereoConvergence = 0.2
DebugLvl = 4
VCNearPlane = 0.1
LightConfiguration = 4
DisableDrvMgm = 0
NVPerfHUD = 0
DebugLineFontSize = 18
DisableVisualHelperReadout = 0
LODBias = 0
MeshRes = 1
MicroMode = 1
MicroFilter = 3
BlendMode = 1
MicroBias = 3
CloudMicro = 1
PostProcess = 0
ShaderDebug = 0
PresentLocation = 1
PlanetTileLoadFlags = 3
LabelDisplayFlags = 3
GDIOverlay = 0
gcGUIMode = 0
AbsoluteAnimations = 0
NormalmappedClouds = 1
TerrainFlats = 1
DebugBreak = 0
ShaderCacheUse = 1
OrbitalShadowMult = 0.85
GFXIntensity = 0.380392
GFXDistance = 1
GFXThreshold = 1.1
GFXGamma = 1
GFXSunIntensity = 1.2
GFXLocalMax = 0.5
SolCfg = Sol
DebugLineFont = Fixed

I am a bit excited what it will be

I'm guessing you want to turn it into a feature.

 

[kuddel]

Hey,
it seems I've found the "feature switch"...
Whenever I enable the Reflection Mode (any option other than "Disable" will do), my ship gets fancy


The sub-settings "Custom Cameras" and "Update Rate" do not appear to have any influence. Neither do the "Reflection Mode"s "Planet Only" or "Full Scene" change it.
So: To get a flashing DeltaGlider - just switch in on/off here

Could it be that the material of the DeltaGlider is flagged somehow as being "camera surface"?

 

[jarmonik]

Could it be that the material of the DeltaGlider is flagged somehow as being "camera surface"?

I don't know really. It would need a bad material and a bad camera surface. You could check if the "reflection camera" "sees" a proper view from the D3D9Debug controls. (2nd page) after that you could replace Config/GC/Deltaglider.cfg with a one from a fresh build. So far, I haven't been able to produce any anomalous behavior in DG exterior. Other than texture mipmaps don't load as they are supposed to leading some tearing effects in textures.

EDIT: might be good idea to backup the old Deltaglider.cfg if there's some interesting bad data in it.

 

[jarmonik]

The local lights now work again... but only illuminate the ground. Vessels, self and others, are still in the dark. This prevents me from testing the 4- vs 8-light flickering issue.

That's odd. I checked the DeltaGlider "Docked at ISS" scenario and docking/landing lights will lit the station while using Debug or Release builds. If it's not too much trouble could you try clean installation. It could be some old shader file that refuses to replace with a new one.

EDIT: I will look into the shadows you reported, thanks.

@kuddel Does local lights work for you ?

 

[jarmonik]

Rendering order independent transparency is now implemented (not yet merged to main) and can be enabled with MeshGroup flag 0x20. This will only work with one-bit-alpha i.e. either fully transparent or opaque.
I have also fixed a missing mipmaps and there is a small change that flashy DG seen by @kuddel and @GLS been cause by this issue.

 

[kuddel]

@kuddel Does local lights work for you ?

No, not on this machine (have to check it on my main rig this evening)
but it seems that the env-map (as seen here in Generic Camera View) does get it ....


Note: The bluish ISS is because "Highlight selected mesh" from the "D3D9Client Debug Controls" is activated - else I could not see anything.
BTW: The scenario I used is \Scenarios\2016 Edition\Spotlights.scn

The latest changes regarding this are in this branch, right?

 

[kuddel]

I am a bit puzzled by this part of the code (Scene.cpp around line 933) - see my comments ( ////// )

void Scene::UpdateCamVis()
{
    // ...
    // Process Local Light Sources -------------------------------------
    if (bLocalLight) {

        ClearLocalLights(); ////// This sets 'this->nLights' of the Scene-instance to zero

        VOBJREC *pv = NULL;
        for (pv = vobjFirst; pv; pv = pv->next) {
            if (!pv->vobj->IsActive() || !pv->vobj->IsVisible() || pv->vobj->GetScene()->nLights < 1) continue; ////// Here 'pv->vobj->GetScene()->nLights' will be zero
                                                                                                                ////// ...and isn't 'pv->vobj->GetScene()' equal to 'this' ?
            OBJHANDLE hObj = pv->vobj->Object();
            if (oapiGetObjectType (hObj) == OBJTP_VESSEL) {
                VESSEL *vessel = oapiGetVesselInterface (hObj);
                DWORD nemitter = vessel->LightEmitterCount();
                for (DWORD j = 0; j < nemitter; j++) {
                    const LightEmitter *em = vessel->GetLightEmitter(j);
                    if (em->GetVisibility() & LightEmitter::VIS_EXTERNAL) AddLocalLight(em, pv->vobj);          ////// AddLocalLight() is what would increment 'this->nLights'
                }
            }
        }
    }
    // ...
}

When i just remove the last check from the expression like so:
if (!pv->vobj->IsActive() || !pv->vobj->IsVisible()) continue;
Local lights work.

Is the call to ClearLocalLights(); maybe "shifted up" too much?


EDIT: Ahhhh I see you've already changed that in the d3d9_local_lights branch.

 

[jarmonik]

The latest changes regarding this are in this branch, right?

Yes, that branch. And your comments in the code are right. The initial cause for the failure was incorrect "|| pv->vobj->GetScene()->nLights < 1" in the code.
You got your code from a wrong branch and it did work because of that, right ? Is this the case with @GLS too ?

 

[kuddel]

This github "upstream" "origin" "fork" "whatever..." overkill makes me dizzy.

I usually only test main (or master or whatever it is called at github). Testing local lights was not very high on my priority list, so I just looked at the code during (lunch) break.
At home I'll try to fork & pull & whatever-is-needed the d3d9_local_lights branch...

The "flashy Delta-glider issue" might be fixed by that, too - but I can not tell yet.

 

[GLS]

Yes, that branch. And your comments in the code are right. The initial cause for the failure was incorrect "|| pv->vobj->GetScene()->nLights < 1" in the code.
You got your code from a wrong branch and it did work because of that, right ? Is this the case with @GLS too ?

My comments yesterday came from running the d3d9_local_lights branch.

This github "upstream" "origin" "fork" "whatever..." overkill makes me dizzy.