New Release D3D9Client Development

[GLS]

Finally got around to compiling D3D9, and it doesn't work with a Debug build. With everything in Debug I get

Failed loading module Modules\Plugin\D3D9Client.dll (code 126)
[Orbiter::LoadModule | D:\repos\orbiter\Src\Orbiter\Orbiter.cpp | 619]

in the log when opening the Launchpad, but if I recompile D3D9 in Release, keeping the rest of Orbiter in Debug, then it works as usual.
0 errors or warnings in build either configuration.

Another issue is the local lights not working, but they work in MOGE. Of note is that it seems they work for the vc meshes, I turn on the Payload Bay lights and some of it hits the vc mesh, and that still happens, but nothing is lit outside.

I also get these in the log:

D3D9ERROR: CreateShaderCache: CreateFile Error: 0x3
D3D9ERROR: Path=[Cache/Shaders/IPIVS_VSMain_IPI.hlsl.bin]
D3D9ERROR: CreateShaderCache: CreateFile Error: 0x3
D3D9ERROR: Path=[Cache/Shaders/IPIPS_PSBlur_EnvMapBlur.hlsl.bin]
D3D9ERROR: CreateShaderCache: CreateFile Error: 0x3
D3D9ERROR: Path=[Cache/Shaders/IPIVS_VSMain_IPI.hlsl.bin]
D3D9ERROR: CreateShaderCache: CreateFile Error: 0x3
D3D9ERROR: Path=[Cache/Shaders/IPIPS_PSPreInteg_IrradianceInteg.hlsl.bin]
D3D9ERROR: CreateShaderCache: CreateFile Error: 0x3
D3D9ERROR: Path=[Cache/Shaders/IPIPS2_PSInteg_IrradianceInteg.hlsl.bin]
D3D9ERROR: CreateShaderCache: CreateFile Error: 0x3
D3D9ERROR: Path=[Cache/Shaders/IPIPS2_PSPostBlur_IrradianceInteg.hlsl.bin]

On the positive side, I managed to find the correct file to include and got SSV to compile!
Then I went to Edwards and saw this scene out of the movie 2012...

Changing the interpolation option had no effect. Things look normal in Florida, but there are a extra few "peaks and valleys" in Vandenberg, but nothing like the image above.
Orbiter_ng.exe with MOGE shows a gray scene and CTDs in a few seconds without any info in the log, and with Orbiter.exe everything works fine.

 

[GLS]

Also, I'm noticing a bright red reflection on the outside of the DG, just flickering sometimes.... can't tell much more, it still happens when paused and it doesn't seem to be related to the direction of the Sun.

 

[jarmonik]

I haven't seen any red reflections lately. There's been a few like seeing a specular reflection of Mars in the past. If you see it then check the reflection map if there's any anomalous dots in it. Or it could be post-processing related.

I never have had problems building a Debug build. Could it be missing debug runtimes ? Check Windows SysWOW64/D3dx9d_43.dll

I'll look into the Log errors. Nothing vital. I got them too.

Orbiter Beta/OpenOrbiter are using different height configuration than Orbiter 2016 which might cause the elevation failure. There are a number of problem with the elevation that should be corrected.

 

[jarmonik]

Yes, looks like the local lights are not working for exteriors. I don't know what's going on there. There shouldn't be any changes. Will look into it.

 

[SpaceBoy2]

Then I went to Edwards and saw this scene out of the movie 2012...
View attachment 30604
Changing the interpolation option had no effect. Things look normal in Florida, but there are a extra few "peaks and valleys" in Vandenberg, but nothing like the image above.
Orbiter_ng.exe with MOGE shows a gray scene and CTDs in a few seconds without any info in the log, and with Orbiter.exe everything works fine.

Antelope is broken for me too

 

[martins]

A small request to the D3D9Client developers:
There is a feature branch pull request that could do with a review from somebody familiar with the D3D9Client.
This started out as an innocuous small feature to add spectral class information to the star database which could be used to provide colour variations for background star rendering. Over time this has grown to a fairly extensive rewrite of the entire CelestialSphere class implementation affecting all graphics clients.
Some of the modifications include:

• The individual client CelestialSphere implementations are now derived from a CelestialSphere base class (which is part of the API) that performs all the client-independent functions such as loading the databases from file and preprocessing them. The clients now only have to do graphic-engine specific stuff such as mapping the data to device data structures and rendering them.
• Some functions for loading star and constellation databases have been moved from the global API (oapi namespace) to the CelestialSphere class.
• The celestial sphere now is assumed to be the unit sphere (radius 1), so it is no longer necessary to multiply coordinates on it by some arbitrary radius.
• Rendering the celestial sphere is now done in the CelestialSphere class instead of the Scene class.
• Some general cleaning up of the code, e.g. use of std::vector and std::string instead of manual heap allocation.
• Oh, and the original feature of providing colour information for background stars has been implemented as well, but it is very subtle. Still, if you look at Orion and compare Betelgeuse to Rigel, you should see a difference.

Since the branch does contain changes to the D3D9Client code, I didn't want to merge it before you guys had a look at it.

 

[kuddel]

Maybe it's just me, but it seems like the Celestial-Sphere-Background-Image is not rendered.
I haven't looked very deep into this to check whether main branch also had this issue.

The rendering of the stars (dots) itself seems to work as expected, though

 

[martins]

It's not just you. Fixing it now. Hang on ...

Edit: Should be fixed now. The problem was that I had overlooked one instance of an arbitrary radius applied to the celestial sphere. In this case, the mesh used for rendering the background image was set to a radius of 2000, which meant that it was beyond the camera far plane (set to 10 for celestial sphere rendering) and so was cut off. I've fixed this now to radius 1, which also makes the code look a little bit nicer. Can you try again please?

Also, can you check if "planetarium" features (constellations, grids, stellar markers) work as expected? (F9, Ctrl-F9 and activate grids, constellation and celestial markers)

Finally, it would be good if the performance (frame rate) could be compared between main branch and the 257 feature branch for a couple of different scenarios and camera positions, just in case I messed something up with hidden tile removals or a sketchpad call at the wrong position causing a GPU lock. I'll do it myself, but getting samples from different hardware should make the result more reliable.

 

[kuddel]

The celestial background is fixed!
Most of the "planetarium" features work as expected ,
except "Target Equator" checkbox isn't...

...so just some minor code that seems to be missing

void D3D9CelestialSphere::Render(LPDIRECT3DDEVICE9 pDevice, const VECTOR3& skyCol)
        // ...

        // render equator of target celestial body
        if (renderFlag & PLN_EQU) {
            // ...
        }
       // ...

Thanks for the quick fix!

 

[martins]

Most of the "planetarium" features work as expected ,
except "Target Equator" checkbox isn't...

Good catch - keep them coming!
Should be fixed now.

 

[SpaceBoy2]

Finally, it would be good if the performance (frame rate) could be compared between main branch and the 257 feature branch for a couple of different scenarios and camera positions, just in case I messed something up with hidden tile removals or a sketchpad call at the wrong position causing a GPU lock. I'll do it myself, but getting samples from different hardware should make the result more reliable.

There's no performance drop for me

 

[jarmonik]

A small request to the D3D9Client developers:
There is a feature branch pull request that could do with a review from somebody familiar with the D3D9Client.
This started out as an innocuous small feature to add spectral class information to the star database which could be used to provide colour variations for background star rendering. Over time this has grown to a fairly extensive rewrite of the entire CelestialSphere class implementation affecting all graphics clients.

Nice, the star field looks much better now. I have reviewed the changes and I didn't spot anything wrong. The performance is the same that I have used to, so, no issues there. It also passed all of my tests without problems. The Sketchpad should be pretty safe to use, if something goes wrong a debug assert should be triggered.
I have been a bit busy and tired but I really hope to get back to speed soon.

Go for Merge

 

[kuddel]

Should be fixed now.

...is fixed now ! Quick fix - as usual

 

[kuddel]

One minor thing:
As DrawOrbits (D3D9Client Sample) is strongly related to planetarium mode, I checked and found a small issue.
Some files were stored with the wrong encoding - resulting in garbish-characters display.
And as I am not sure whether I can/should change that direct in the 257-hipparcos_spectral_type branch, here's the changed files:

If you can incorporate these into the PR (branch), great! If not, I'll make that in a dedicated PR.

Changes:
- fixed (wrong) encoding (from UTF-8 to ANSI) - minor warning fix (type oveerflow DWORD to size_t)

 

[martins]

Branch is merged now. Thanks for all your help!

One minor thing:
As DrawOrbits (D3D9Client Sample) is strongly related to planetarium mode, I checked and found a small issue.
Some files were stored with the wrong encoding - resulting in garbish-characters display.
And as I am not sure whether I can/should change that direct in the 257-hipparcos_spectral_type branch, here's the changed files:

If you can incorporate these into the PR (branch), great! If not, I'll make that in a dedicated PR.

Is included in the 257 PR.

Since I am already on the celestial sphere and planetarium mode now, one other thing I want to include is the constellation boundaries. I found a database for that, so shouldn't take too long.

 

[martins]

Then I went to Edwards and saw this scene out of the movie 2012...
View attachment 30604
Changing the interpolation option had no effect. Things look normal in Florida, but there are a extra few "peaks and valleys" in Vandenberg, but nothing like the image above.
Orbiter_ng.exe with MOGE shows a gray scene and CTDs in a few seconds without any info in the log, and with Orbiter.exe everything works fine.

I have posted a pull request that addresses this issue. Would be good if people who observed this problem could try it, and if a D3D9 developer could have a look at the code.
Note that this only addresses problems with the D3D9Client. I couldn't find any problems with the D3D7Client. Does this:

Orbiter_ng.exe with MOGE shows a gray scene and CTDs in a few seconds without any info in the log

still happen with the latest sources, and do I need to do something specific to reproduce it?

 

[SpaceBoy2]

I have posted a pull request that addresses this issue. Would be good if people who observed this problem could try it, and if a D3D9 developer could have a look at the code.
Note that this only addresses problems with the D3D9Client. I couldn't find any problems with the D3D7Client. Does this:

Orbiter_ng.exe with MOGE shows a gray scene and CTDs in a few seconds without any info in the log

still happen with the latest sources, and do I need to do something specific to reproduce it?

Can confirm it works with D3D7. At least for me.

Also some issues that I think needs fixing as soon as possible though you and Jarmonik probably know these:
1) Local lights not working (not working in D3D7 too)
2) Elevation issues already discussed
3) Landing pads of bases clipping into terrain

 

[DaveS]

As far as missing things go, here's two big ones:

1)Celestial objects casting shadows on other celestial objects. This prevents eclipses from being a thing currently.
2)Diffuse particle streams not affected by shadows be it vessel or celestial objects. This makes them visible even during the dead of night which is wrong.

 

[jarmonik]

2) Elevation issues already discussed

This was addressed in Martins previous post. See Pull Request

3) Landing pads of bases clipping into terrain

I have fixed this problem 2-3 times and it keeps re-appearing. This is non trivial problem, you have to choose between "see through terrain landing pads" or "clipping landing pads". Fix is simple by disabling depth test but it will trade one problem to an other. I am working on an atmospheric-remake and this process would include an auxiliary floating point depth buffer for an other use, but that could also provide new options to fix the "clip through terrain" problem. Also it might work if the depth test is enabled/disabled based on camera distance to the base or pad.

1) Local lights not working (not working in D3D7 too)

They should work in D3D7 have you forgotten to enable them ? I will look into the Local lights problem in D3D9.

 

[SpaceBoy2]

As far as missing things go, here's two big ones:

1)Celestial objects casting shadows on other celestial objects. This prevents eclipses from being a thing currently.
2)Diffuse particle streams not affected by shadows be it vessel or celestual objects. This makes them visible even during the dead of night which is wrong.

This was addressed in Martins previous post. See Pull Request


I have fixed this problem 2-3 times and it keeps re-appearing. This is non trivial problem, you have to choose between "see through terrain landing pads" or "clipping landing pads". Fix is simple by disabling depth test but it will trade one problem to an other. I am working on an atmospheric-remake and this process would include an auxiliary floating point depth buffer for an other use, but that could also provide new options to fix the "clip through terrain" problem. Also it might work if the depth test is enabled/disabled based on camera distance to the base or pad.


They should work in D3D7 have you forgotten to enable them ? I will look into the Local lights problem in D3D9.

Yes I just meant the work on elevation issues are super important.
For looking at the bases.
And about the lights: let me try it again.

Edit: Yep , sorry, it works