New Release D3D9Client Development

[DaveS]

Quick Q: What does SHADOW_THRESHOLD in Common.hlsl do? Currently it is set to 0.1 but the comment suggests the lowest limit is 0.3 and the highest limit is 7.0.

 

[jarmonik]

Terrain editing is very much welcome, but the current terrain seams bug is pretty nasty.
I know it's not your fault but it got worse today after updating Nvidia drivers.
I just tried the Alps 2016 scenario and the black seams become visible as soon as the terrain loads....

Due to nature of the problem I can't imagine how a driver update could make things worse. Does there exists a version of the client where the seams won't exists ? I tried revision 787 which is the oldest we got for Orbiter 2016 (September-2016) and it did have the seams. As far as I can remember the seems have been there.

You can reduce the seams by moving the "Texture Bias" slider higher but it comes with a performance cost.

 

[jarmonik]

Quick Q: What does SHADOW_THRESHOLD in Common.hlsl do? Currently it is set to 0.1 but the comment suggests the lowest limit is 0.3 and the highest limit is 7.0.

If I recall it should set the threshold where vessel self shadows appear. The math that controls the shadows may have changed and the comment is outdated.

 

[jarmonik]

I was wondering though, is it possible to set the elevation of an area, without having it rendered?

Possible but problematic. We should have an official way to do something like that. Client side hack doesn't sound like a good idea. It's getting too messy. Lot of things are already too messy.

 

[n72.75]

Just messing around, not official dev work...yet.

 

[Mr. Residuals]

NASSP needs an external texture overhaul for the CSM anyway.

If I had to be honest, this is really true. If somebody were to make it happen then I would appreciated greatly.

 

[GLS]

In todays Orbiter source code dive I found information on all the mesh flags that MOGE uses, and maybe the D3D9 folks could take a look and implement some (or all) of them. It all begins in file Mesh.cpp:958, where the mesh file is parsed.

 

[jarmonik]

We probably should create a branch for Orbiter r.90 and repurpose the trunk for Orbiter x64. I tried to compile the client as x64 and the amount of errors was much less than I feared.

 

[Fabri91]

We probably should create a branch for Orbiter r.90 and repurpose the trunk for Orbiter x64. I tried to compile the client as x64 and the amount of errors was much less than I feared.

@Face also managed to get a "working" version compiled. Didn't expect it so soon!

 

[Face]

We probably should create a branch for Orbiter r.90 and repurpose the trunk for Orbiter x64. I tried to compile the client as x64 and the amount of errors was much less than I feared.

Replacing the libs, casting DLGPROC and refactoring the CPU context logging was all I had to do (besides adding an x64 target, of course). Very well crafted code-base!

 

[kuddel]

Unfortunately I can not get enough time to work on this as I would like to....
But here's the changes I've made to the D3D9Client (2016.branch based).
You might take a look if these fit your changes. A proper merging is beyond my time limit unfortunately. But I try to sneak some time in.

Regarding "branching for r90" and make 'trunk' the main x64 development branch: It's fine with me. Should we name the branch "2016-P1"[*] "2019"[**] ?

[*] calling it "something BETA" seems odd now
[**] "2019" would be appropriate as r90 was from September 14th 2019

 

[kuddel]

I've created the '2019' branch (svn://mirror.orbiter-radio.co.uk/D3D9client/branches/2019) so 'trunk' might become the main x64 development place.

But his means that we "break" existing working copies out there, referencing 'trunk' which expect it to be for 32-bit Orbiter BETA!
Those will update and suddenly have a complete mess on their working-copy....
Only if they know that this happened and they switch to the new branch before doing an update will they prevent pain!

It might be better to do the x64 development in a branch. This way we don't break already checked-out working copies.

Nothing has changed on 'trunk' yet, so we can still go any direction.

 

[dbeachy1]

We could also do the x64 build using #ifdef's and #typedef's to keep the changes all in the same branch (that's how we did it at work in a previous life) so we don't have to constantly merge two branches to keep changes in sync. But either way would work.

 

[GLS]

It might be better to do the x64 development in a branch.

I don't have a vote, but IMO this is better.

 

[Lucy]

All I'd say on that is that SVN handles branches very differently from git, be careful....

 

[kuddel]

SVN is kind of home territory to me.... git is foreign

 

[n72.75]

SVN is kind of home territory to me.... git is foreign

Other way around for me

 

[Face]

What should I say? I'm between the chairs with Mercurial .

 

[DaveS]

I don't want to disturb the transition from x86 to x64 that's going here, but I think I have discovered a bug with D3D9Client. And that bug is that the sun is visible through the planet! I have attached a screenshot of this. You can see the sun where you shouldn't be able to. Scenario is also attached to recreate the bug, uses nothing but the default Project Alpha ISS. Orbiter 2016 with D3D9Client R4.24.

 

[fatcat]

Hi,
For the latest D3D9 releases (4.22-4.24) for Orbiter 2016, I get a black rendering when viewing planets at low angles at certain zooms. Older D3D9Client.dll do not give this.
Horizontal haze disable in the video settings removes the black.

Happy to do any testing of settings if it helps.
Sorry if I'm repeating something that has been identified.