New Release D3D9Client Development

[misha.physics]

@jarmonik, thanks so much for updating your TerrainToolKit with 20-21 levels. Now it's clear how this work. And especially BIG THANKS YOU for the tile MIP maps for all tile levels. It's just a wonder!!! I really dreamed about this feature!

Now we have such crisp textures with a significant reduction of flickering. On these screens I chose the highest Texture Bias and Mesh resolution in D3D9Client:



Do I understand correctly that these MIP Maps for high levels don't work for water "textures" and that's why they still flicker?

 

[misha.physics]

I detected numerous crashes to desktop on the last Orbiter x32 build on github. I made some tests. At first I thought it's due to the two additional levels 20-21, not to the MIP maps for all levels, because these crashes didn't happen when I enable All levels for Tile mipmap policy in D3D9Client, and restrict Max. resolution level to 19 on Launchpad. But after some time I get crashes even for this case too. I haven't noticed such crashes in the previous build where levels 20-21 were added, but MIP Maps for all levels not yet, but I didn't play that build for long. My Orbiter.log and a screenshot are attached. Hope these can help.

 

[jarmonik]

Out of Video Memory, Keep mesh resolution at 32 (not 64)

 

[misha.physics]

Out of Video Memory, Keep mesh resolution at 32 (not 64)

Thanks, I'll try it tomorrow and write results.

 

[misha.physics]

I reduced Mesh resolution to 32, and those crashes disappear. I don't even notice the significant difference in graphics between 32 and 64 values. It's a little noticeable in Cape Canaveral (64 value makes more hills), but this difference is complitely invisible on my custom highly detailed tiles.

Out of Video Memory

Is it not related to my Video RAM? Since I have 4 Gb, and Orbiter uses only ~1.4.Gb at 64 mesh resolution.

What could cause these crashes in the current build? They didn't happen earlier when I used 64 mesh resolution in the previous build. It's strange because these crashes remains if I enable MIP Maps for only low level and restrict Max. res. level to 19. Maybe it's due to something other changes in the new build?

 

[jarmonik]

We probably should remove the 64 option because the impact to memory consumption is high and benefit very small.
The error code and the function that fails indicates "Out of Video Memory". I made some testing and didn't notice any memory leaks during simulation. Of course there is a possibility that some algorithm might still be stuck at level 19 and might cause a failure with level 20+ tiles but I haven't had time to test that yet. Memory statistics can be monitored with [Shift+Alt+Ctrl+C]

Has anyone else noticed a problem there ?

 

[misha.physics]

Once I've get the texture problem (as on the picture above) even with a 16 value, but without a crash.

Here are my 16 and 32 causes:



And once the following happened. I run a scenario (with a 16 value), flew for a while, and noticed that ~2.4 Gb of my Video Memory is used. Then I completely closed Orbiter, opened it again, run the same scenario, flew for the same time in the same area, and noticed that only ~1.4 Gb of my Video Memory is used (I monitored it with MSI Afterburner). And I haven't run other applications.

 

[jarmonik]

If you set the tile mipmap policy to "low level" or "none" does the texture problem still occur ?

 

[jarmonik]

Can you produce the texture problem without errors in the log ?
Does the problem only occur after re-launching the orbiter without fully exiting/closing the launchpad ?

 

[misha.physics]

@jarmonik, today-tomorrow I will made series (for some statistical reproduction) of such tests with various sets and write here together with attached screenshots and logs.

 

[misha.physics]

Set 1
Mesh res.=32
Tile mipmap policy=All levels
Max. res. level=21

I did six tests and it works without problems. First I tried the same scenario three times, and ~1.4 Gb of Video RAM was used. But hen I tried the same scenario running it as "Current State" on Launchpad and ~2.2-2.5 Gb of Video RAM was used (all these last three times). No texture problems and no crashes. See 32.log. I couldn't reproduce that one case I mentioned above.

Set 2
Mesh res.=64
Tile mipmap policy=All levels
Max. res. level=21

It's almost immediately causes texture problems, crashes and freeze every time. I did five tests (with the same scenario and my actions). Sometimes Orbiter crashes after a few seconds after the ship accelerates. Also, I noticed that sometimes I can't make screenshots with Prt Sc key on keyboard and insert it to Paint, so I had to open some other window like Logitech Profiler to make a screenshot). Here are screens of tests 1, 2, 5 and log files of tests 1-5.



Set 3
Mesh res.=64
Tile mipmap policy=Low level only
Max. res. level=21

The same textrue artifacts (even crazier (look at the sky) and crashes:



Set 4
Mesh res.=64
Tile mipmap policy=All levels
Max. res. level=19

The same texture problems.

Set 5: Orbiter 2016 with Mesh res.=64

It works without problem.

Set 6: OpenOrbiter build from 6 Jun 2023 with Mesh res.=64

It also works fine.


So, it seems to be caused only by 64 mesh resolution in the latest builds. Sadly I haven't a previous Orbiter build where 20-21 levels were added, but MIP Maps for all levels not yet. Maybe it makes sence to try it with 64 mesh resolution. I just deleted that build and don't know where to find it now.

Added: Oh, I'm very sorry, here:

Once I've get the texture problem (as on the picture above) even with a 16 value, but without a crash.

Here are my 16 and 32 causes:

And once the following happened. I run a scenario (with a 16 value), flew for a while, and noticed that ~2.4 Gb of my Video Memory is used. Then I completely closed Orbiter, opened it again, run the same scenario, flew for the same time in the same area, and noticed that only ~1.4 Gb of my Video Memory is used (I monitored it with MSI Afterburner). And I haven't run other applications.

I made a mistake. Here are my 32 (not 16) and 64 (not 32) cases. And once I've get the texture problem even with a 32 value (NOT 16), but without a crash. But now I couldn't reproduce texture problems/crashes with 32 mesh resolution. Maybe this happens very rarely or I was wrong with that one case. I hope more tests will be done by other users.

 

[jarmonik]

Thanks. Based on your test reports I was able to reproduce the texture issue which is cause by memory issue of some kind. What exactly is unclear, could be shared video memory that's running out. The mipmaps and few additional tile levels may have push the memory consumption over the edge. I'll disable the 64 tile size and I try to reduce the size of the vertex data.

 

[misha.physics]

Although in some cases the 16 value can look nicer (smoother) than 32. Just try switching between these two pictures of 16 and 32. Maybe these two options could be saved for selection, namely not to remove the 16 one... It would just be nice to have a choice (more settings) if it works...

 

[misha.physics]

I suppose it's a known issue that the light is visible through objects:

 

[gamer19]

didn't even knew DeltaGlider has a light

thank you

 

[jarmonik]

I suppose it's a known issue that the light is visible through objects:

I have no plans to add support for shadows for local lights. It would have heavy performance impact and there are some other problems with the implementation as well. There are more important things to do.

 

[n72.75]

I have no plans to add support for shadows for local lights. It would have heavy performance impact and there are some other problems with the implementation as well. There are more important things to do.

That sounds like something best accomplished with the successor to D3D9.

 

[jarmonik]

That sounds like something best accomplished with the successor to D3D9.

Maybe. For an example the KSP supports shadows for local lights in a very limited manned and the range is no more than 3-4 meters from a source and the light count is around 2-4 light sources. Which in Orbiter would probably not work too well at all, it doesn't work too well in KSP either. I don't know any games with an extensive support for local light shadows.

 

[n72.75]

Well they're all clearly fooling me haha. I didn't actually notice that.

 

[jarmonik]

I guess the shadows could be implementable but wide angle lights 120deg cone angle the max range would be about 3-6 meters, narrow angle 20deg could give a range of 50-100 meters. The ranges could be higher if the observer is in the source of the light. The main problem is that behavior of shadows would be chaotic with difficulties to predict how the shadows really behave it particular scenario/setup.