Bug Weird shaking/bending planet textures

[predattak]

Sometimes planets viewed from altitude shake and bend. It's almost like planets are made of rubber, it has a soft bend in it.
Load up a scenario and place a glider in orbit around mars at an altitude of 6488 Km. Look at Olympus mons and half of the planet how they shake inwards and outwards like bosses
It happened on the moon also so i don't think it's for mars only.
I use the D3D9 client r1355- 7 sept 2020.

 

[Marijn]

That doesn't sound right. Are you using the hi-res textures? Can you share the scenario? I can record a short video to show how it looks on my six year old midrange laptop with a nvidia GeForce GTX 950M. This card really isn't all that much and I am still amazed how smoothly Orbiter runs on old hardware.

 

[MaxBuzz]

judging by the beautiful screenshots you have posted, you have ReShade or another rendering program installed. she can't be the culprit?

 

[predattak]

That doesn't sound right. Are you using the hi-res textures? Can you share the scenario? I can record a short video to show how it looks on my six year old midrange laptop with a nvidia GeForce GTX 950M. This card really isn't all that much and I am still amazed how smoothly Orbiter runs on old hardware.

No high res for Mars, High res for the moon. That's all i have atm. ( i will share the scenario if needed but really just open any default scenario, open scn editor, go to orbital parameters and place a ship in orbit around mars at about 6500 Km. Do an orbit of the planet and look at olympus mons)

EDIT: o added the scn file.

judging by the beautiful screenshots you have posted, you have ReShade or another rendering program installed. she can't be the culprit?

I tried it on a brand new orbiter client+D3D installed.. same result sadly

 

[Marijn]

As a reference, this is how the Martian vulcanoes look up close on my old laptop with an outdated D3D9 graphics client and the Mars hi-res textures and elevarion data installed and running the recording software at the same time. I am sure the current version performs equal or better:

If the performance you're getting is worse, something is wrong.

 

[predattak]

As a reference, this is how the Martian vulcanoes look up close on my old laptop with an outdated D3D9 graphics client and the Mars hi-res textures and elevarion data installed and running the recording software at the same time. I am sure the current version performs equal or better:

If the performance you're getting is worse, something is wrong.

You need to be higher, way higher for the bug to show up. Try to replicate it if you can pls. Get an orbiter client , install the last stable D3D patch and run my scenario, get into GL-01 that i spawned and look at mars from there.
It seems that the problem happens at certain altitudes, on mars by example it happens between 6700 Km and 4300 Km. I think there is a problem with the texture rendering at those altitudes .. probably something to do with elevation ?
I also tried it on an old D3D client from 2016 and that has no such problems .. however that client has other problems that have been fixed.

 

[predattak]

Here is how it should look like. Brand new client install, ignore the video res, i wanted the file to be small -> https://streamable.com/vjmhpo
and again, for mars it only happens at altitudes between about 6700 Km to about 4300 Km ... higher or lower than that .. everything is fine

 

[kuddel]

Very strange (funny). It seems like the D3DClient is "on the edge" of deciding whether to render a "flat" spherical texture (as it thinks we're far enough away) and the "elevated" textures (thinking it's closer)...
Should be reproducible, if that really is the case.
What exact version of 3D9Client you're using? (Link or ZIP-name)

 

[GLS]

Here is how it should look like. Brand new client install, ignore the video res, i wanted the file to be small -> https://streamable.com/vjmhpo
and again, for mars it only happens at altitudes between about 6700 Km to about 4300 Km ... higher or lower than that .. everything is fine

Yeah, that looks like Mars has loudspeakers.... really big ones...

Very strange (funny). It seems like the D3DClient is "on the edge" of deciding whether to render a "flat" spherical texture (as it thinks we're far enough away) and the "elevated" textures (thinking it's closer)...
Should be reproducible, if that really is the case.
What exact version of 3D9Client you're using? (Link or ZIP-name)

I agree, it seems to be a border line situation.
I'm not sure how that flat/3D choice is done in the graphics engines, but it probably could be fixed by using 2 border values instead of one. Assume the parameter is distance: instead of, e.g., 5000Km to switch between flat and 3D, use 6000km to switch to flat and 5000Km to switch to 3D.

 

[predattak]

Very strange (funny). It seems like the D3DClient is "on the edge" of deciding whether to render a "flat" spherical texture (as it thinks we're far enough away) and the "elevated" textures (thinking it's closer)...
Should be reproducible, if that really is the case.
What exact version of 3D9Client you're using? (Link or ZIP-name)

I tried both stable versions, same thing.
D3D9ClientR4.11-forOrbiter2016(r1355).zip - (7-Sep-2020)
D3D9ClientR4.7-forOrbiter2016(r1335).zip - (11-Aug-2020)

 

[kuddel]

I agree, it seems to be a border line situation.
I'm not sure how that flat/3D choice is done in the graphics engines, but it probably could be fixed by using 2 border values instead of one. Assume the parameter is distance: instead of, e.g., 5000Km to switch between flat and 3D, use 6000km to switch to flat and 5000Km to switch to 3D.

Yes, I am pretty sure that D3D9Client implements this hysteresis (based on apparent size, not just distance, as the size of the object makes the two limits quite different).
But I haven't actually checked, so my assumption might not be based on facts ?

 

[GLS]

Yes, I am pretty sure that D3D9Client implements this hysteresis (based on apparent size, not just distance, as the size of the object makes the two limits quite different).
But I haven't actually checked, so my assumption might not be based on facts ?

But the apparent size could change beyond the (existing) hysteresis parameters as the planet changes between flat and 3D, so some tuning of the parameters might be in order. Worst case, per-planet settings might be needed.

 

[Marijn]

Try to replicate it if you can pls.

I can reproduce the problem with the D3D9R411 client. Older clients like the R2.1 from 2017 doesn't have the problem.

 

[asbjos]

I can reproduce the problem with the D3D9R411 client. Older clients like the R2.1 from 2017 doesn't have the problem.

It's probably related to the implementation of a fix for a similar problem in July: https://www.orbiter-forum.com/threads/d3d9client-development.16787/post-263101
See that post, and the 20 posts before.

 

[kuddel]

Could you try this one? (I just changed a small bit and compiled it, but I have currently no access to a running system to test it ?‍)

Edit: No it didn't change ...so I removed the attachment.

Edit-Edit: Please try this one

 

[Marijn]

Edit-Edit: Please try this one

The problems seems solved:

 

[predattak]

Yep. It works. The music stopped on mars.
Hope you didn't break 20 other things by fixing this for such is life in software development.. .fix one thing, break 20 others

 

[kuddel]

That fix definitely needs a 2nd look, as I think it's not placed at the perfect position (in code).
But that "release candidate" posted by me was a pretty minor change, nevertheless I've come across "fix one break several others" situations more often than I like.
Usually I make intensive use of regression-tests, but for graphical "glitches" this is very very difficult and creating suitable tests might be as big a project than the client itself.
Therefore the test-coverage is weak, but a strong community usually quickly finds new bugs ?