New Release D3D9Client Development

[jarmonik]

When doing debugging I noticed a problem in a tile elevation cache and fixed it (at-least, so I thought). I did plenty of testing with the new cache and never saw any issues. So, those screen shots are pretty concerning.. Something is a miss but what exactly.

Is the flat area always under the camera ?
Could you send your D3D9Client.cfg and Orbiter_NG.cfg

Anyone else seeing that ?
I'll review the code changes again tomorrow.

 

[misha.physics]

Is the flat area always under the camera ?

Yes (if I understand correctly). The hills shown in the first picture become flat after the camera approcahing them (second picture):



I also tried Mesh resolution=16, and those black gaps remain, but less often (it seems so to me), than for Mesh resolution=32. I get those black gaps even immediately after the first launch of a scenario. Firstly I thought I use the bad setting:



I attach two files (I changed *.cfg to *.txt) you mentioned after these black gaps happened. And Orbiter.log, too.

The problem with immersed DG at large distances seems to be related with the elevation problem.

You could use "The Alps in 3D" scenario in "2016 Edition" folder. It's very noticeable how mountains become flat under the camera:

 

[johnnymanly]

I'm seeing it as well. This is on Linux/Wine.

 

[Buck Rogers]

cannot confirm (at least not as bad as above), I have the occasional persistant black triangle that "repairs" by zooming in and out.
presumeably a load cache problem

 

[jarmonik]

I still haven't been able to reproduce the problem but I did found a memory zero initialization problem that might have cause the issue. Here's a new binary for testing, could you check if the problem is fixed. Copy the file in /Modules/Server/ folder. This is x86 binary.

 

[johnnymanly]

Still.

 

[jarmonik]

Thanks for testing. I'll restore the previous cache code so that we can be sure that's it's cache problem. Problem is that the cache is for a physics. Graphics has it's own independent elevation management.

 

[jarmonik]

I have restored the old cache. So, let's see how this goes ? The binary goes in /Modules/Server/
Have you checked if the problem appears with the DX7 inline engine, if you are able to run it ?

 

[johnnymanly]

Still bad. DX7 as well.

 

[misha.physics]

@jarmonik, I've tried your two Orbiter.exe files as well (with D3D9 Client, Windows 10). The black gaps and flat textures remain. It occurs for different levels:



The first picture looks like the default elevation settings for a runway of Cape Canaveral doesn't work.

I still haven't been able to reproduce the problem

Do you not notice this problem on your computer?

 

[jarmonik]

Do you not notice this problem on your computer?

No, everything is working perfectly fine. Those caps that shows in your screen shots are very hard to miss. I am a bit puzzled by the problem.
I have reverted the Orbiter Main back to it's previous state. Could you check that it works as usual ?

 

[misha.physics]

Yes, I will try it right now and let you know.

 

[misha.physics]

I've tried. Yes, it works fine without any black gaps and flat tiles.

And I should to add: those black gaps and flat ground aren't a random problem. I notice it always after a few seconds after terrain loading. Firstly the terrain is elevated but a little bit later it becomes flat.

I think it's strange you don't notice this problem on your PC.

 

[N_Molson]

Had the exact same issue. It is worse in Brighton Beach. Olympus Mons looks good, though.

Video clip :

https://filebin.net/d7kixm4elbkvm9z5/bandicam_2024-03-11_19-22-57-342.mp4

 

[Buck Rogers]

I've noticed that (part of) the shadow problem is caused by normals, a face only casts a shadow if the light hits its "normal" positive side.
Is it possible for d3d9 to cast shadows for all normals, or is it advisable to make double walls where needed?

 

[kuddel]

@jarmonik : I've run CppCheck on the current D3D9Client sub directory (out of curiosity) and found some uninitialized members and a couple of other things that have been fixed a long time ago, but re-appeared again...
I'll wait a little as I don't want to interfere with your current troubles and I don't know about the quality of the current HEAD.
Those "some see the issue, but others don't" always makes me think of uninitialized members

 

[jarmonik]

The current HEAD should be Ok. I have detected some problems with zero-initialization, so, maybe the whole code base should be checked.

D3DXVECTOR3 myVec = {0}  // Compiles fine but fails to zero initialize

struct myStr {
    myStr() { }
    int a = 0;
    int b = 0;
}
auto x = new std::vector<myStr>(10);  // This fails to initialize the content, random content


struct myStr2 {
    myStr2() : a(0), b(0) { }
    int a, b;
}
auto x = new std::vector<myStr2>(10);  // This appears to be ok 

std::vector<myStr2> myVec;
myVec.resize(10);  // Unknown, must be checked

 

[kuddel]

Hi Jarmo,

I believe you are getting into the same situation I get: Once git gets on my nerves so much that I can't even get the simplest things done (brain is used up by compaining ..grumpy... grumpy ... grumpy...)

The current HEAD should be Ok. I have detected some problems with zero-initialization, so, maybe the whole code base should be checked.

D3DXVECTOR3 myVec = {0}  // Compiles fine but fails to zero initialize

I would have used 'list-initialization' like this (no assignment, as that operator might be different):

D3DXVECTOR3 myVec{0};

struct myStr {
    myStr() { }
    int a = 0;
    int b = 0;
}
auto x = new std::vector<myStr>(10);  // This fails to initialize the content, random content

Usually in this case I would have ommitted the default c'tor as it's dumb anyway:

struct myStr {
    myStr() = default; // compiler generated default c'tor
    int a = 0;
    int b = 0;
}

The exact reason why your code did not initialize the array/vector elements might be due to the fact std::array / vector behaves that way with () operator/c'tor:
"[...]initializes the array following the rules of aggregate initialization (note that default initialization may result in indeterminate values for non-class T)[...]"
See: https://en.cppreference.com/w/cpp/container/array rsp. https://en.cppreference.com/w/cpp/container/vector/vector
Although I thought your usage would be O.K....
Creating a pointer to a vector of myStr however might be the reason - I have to try it myself later


Edit: Seems to be O.K. ... see Compiler Explorer ... hmmm

 

[n72.75]

@jarmonik, I've tried your two Orbiter.exe files as well (with D3D9 Client, Windows 10). The black gaps and flat textures remain. It occurs for different levels:

View attachment 37223View attachment 37224

The first picture looks like the default elevation settings for a runway of Cape Canaveral doesn't work.

Do you not notice this problem on your computer?

Was there anything special you did to make this appear, settings-wise.

@jarmonik I'm testing pr#445 Earth and Moon seem to be fine, no issues like in the above image.

Mars on the other hand, has issues like below. this comes and goes with camera position and distance





Vesta is showing something similar:


Deimos:



For those last two in particular, it looks like the surface textures are loading with spherical geometry instead of the elevation data. There is probably some weird edge-case causing this.


Reloading orbiter does not fix the problem. If I go back to the launch pad and immediately reload the scenerio, it looks exactly like above. buuut if I completely close and re-open Orbiter:

Perfectly spherical Deimos, which stays spherical until I move the camera.

• I think something still isn't initialized because of the behavior on re-load.
• I don't remember exactly how the elevation LOD works, but it seems like parts or the whole of the planet/moon thinks it should be at the lowest level (I think that's correct? Lowest Elevation LOD is just a sphere?). This could potentially be caused by the above point

 

[jarmonik]

Thanks for the report. I can actually see it on Mars now, the cache is obvious thing to blame but this could be something else. Have to check the planet rendering code. There were some changes on there as well.