New Release D3D9Client Development

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
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

Well-known member
Joined
Dec 22, 2021
Messages
394
Reaction score
513
Points
108
Location
Lviv
Preferred Pronouns
he/him
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):

1.png2.png

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:

Без імені.png

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:

a.png
 

Attachments

  • Orbiter.log
    9.1 KB · Views: 0
  • Orbiter_NG.txt
    4.5 KB · Views: 2
  • D3D9Client.txt
    1.4 KB · Views: 1
Last edited:

Buck Rogers

Major Spacecadet
Joined
Feb 26, 2013
Messages
349
Reaction score
269
Points
63
cannot confirm (at least not as bad as above), I have the occasional persistant black triangle that "repairs" by zooming in and out.0006.jpg
presumeably a load cache problem
 

Attachments

  • D3D9Client.txt
    1.4 KB · Views: 0
  • Orbiter.txt
    33.5 KB · Views: 0
  • Orbiter_NG.txt
    2 KB · Views: 0

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
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.
 

Attachments

  • Orbiter.zip
    825.5 KB · Views: 2

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
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 ?
 

Attachments

  • OrbiterTest2.zip
    825.1 KB · Views: 5

misha.physics

Well-known member
Joined
Dec 22, 2021
Messages
394
Reaction score
513
Points
108
Location
Lviv
Preferred Pronouns
he/him
@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:

1.png2.png

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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
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

Well-known member
Joined
Dec 22, 2021
Messages
394
Reaction score
513
Points
108
Location
Lviv
Preferred Pronouns
he/him
Yes, I will try it right now and let you know.
 

misha.physics

Well-known member
Joined
Dec 22, 2021
Messages
394
Reaction score
513
Points
108
Location
Lviv
Preferred Pronouns
he/him
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.
 
Last edited:

Buck Rogers

Major Spacecadet
Joined
Feb 26, 2013
Messages
349
Reaction score
269
Points
63
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

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
@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 :D
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
The current HEAD should be Ok. I have detected some problems with zero-initialization, so, maybe the whole code base should be checked.

C++:
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

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
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 :D ..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.

C++:
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):
C++:
D3DXVECTOR3 myVec{0};


C++:
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:
C++:
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
 
Last edited:

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,694
Reaction score
1,352
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
@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

1710299522984.png
1710299794298.png
1710299811458.png

Vesta is showing something similar:
1710300002930.png

Deimos:

1710300058693.png

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:
1710300593292.png
Perfectly spherical Deimos, which stays spherical until I move the camera.


1710300690292.png



  • 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
 

Attachments

  • D3D9Client.cfg.txt
    1.4 KB · Views: 1
  • Orbiter.log
    42.9 KB · Views: 1
  • Orbiter_NG.cfg.txt
    4.4 KB · Views: 0
Last edited:

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
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.
 
Top