New Release D3D9Client Development

[Felix24]

I've noticed a couple of problems and I want to know if it's something I'm doing wrong...

1. Mouse wheel in external view seems to be disabled most of the time - I can't change the view distance anymore. Sometimes it works, but when I leave the scenario and then resume the scenario it doesn't work anymore. But not consistently. I've been testing with default scenarios, like DG Mk4 in Orbit.

2. I am unable to open the D3D9 Debug Controls panel at all.

Both of these problems are in D3D9 r1264 and r1297, but everything works fine in r1224. Any ideas? Thanks!

 

[kuddel]

@Felix24: Could you try and disable the gcGUI Mode.

Via dialog:

Or direct in D3D9Client.cfg:

gcGUIMode = 0

Please report back if disabling the gcGUI fixes your issue, so we can be sure not to chase a red herring.
:tiphat:

 

[zombiegreedo]

Just curious is D3D9Client still open source? It looks like the OSDN mercurial repo doesn't have the latest. I'm interested to learn how everything works.

 

[Felix24]

Please report back if disabling the gcGUI fixes your issue, so we can be sure not to chase a red herring.
:tiphat:

Maybe it solves the problem?

1. I can always select and open the D3D9 Atmospheric controls after hitting Ctrl-F4, no problem.
2. With gcGUI "windowed", I can select and open the D3D9 Debug Controls only on the first run when I start the Orbiter launchpad. On the second run and after, the debug controls no longer appears in the Ctrl-F4 window. If I completely close and restart Orbiter, I can use it again on the first run, but not on any runs after the first.
3. With gcGUI disabled, it seems to work fine every time.
4. If the dialog isn't working, and then I disable gcGUI, the dialog still doesn't work, but when I restart Orbiter completely it begins working again on the first run and on all runs afterward.

At least I think that's what's happening. I hope this makes sense.

 

[kuddel]

Thanks Felix for reporting your observations :thumbup: I'm sure this helps in finding the root cause of the bug.

---------- Post added at 20:54 ---------- Previous post was at 20:45 ----------

Just curious is D3D9Client still open source? It looks like the OSDN mercurial repo doesn't have the latest. I'm interested to learn how everything works.

• D3D9Client is still open source ( svn://mirror.orbiter-radio.co.uk/D3D9client/ )
• I'm not sure what mercurial repository you are talking about,
  but if you meant the "orbitervis" svn repository ( svn://svn.code.sf.net/p/orbitervis/code/ ) which contains a D3D9Client ( svn://svn.code.sf.net/p/orbitervis/code/D3D9Client ),
  that is a very old copy and will not likely be updated as D3D9Client is in constant change / development.
• There also was a Codeplex site / repository once, but please pretend that it never existed

 

[jarmonik]

New Builds

New builds are out for Orbiter 2016 and Beta

- The gcGUI problem should be fixed by setting default state "Disabled".

- New implementation of animation to operate in absolute or incremental basis by user choice. There is a "Enable absolute animations" checkbox added in configuration dialog.

Incremental (default) animations are little more efficient and should be fully backwards compatible with older addons but incremental animations tend to drift when used over longer period of time which can easily happen in robotic arms.

Absolute animations shouldn't drift but compatibility issues can exists (however currently non is known).

It is recommended to do animation based testing to see if any problems exists in the code.

 

[kuddel]

Hey Jarmo, I felt the need to update the documentation a bit, as it -as usual:hmm:- lacked behind.

I had to skip describing some parts due to "not knowing what to say"
(...and I wanted to avoid the obvious "the setting FOO lets you change the setting of FOO" ).

Would you be so kind and fill out some of the gaps?

It's in the 2016 branch (rev. 1308). The missing parts all have "...to be documented..." instead of meaningful documentation.

...and editing \Orbitersdk\D3D9Client\doc\D3D9Client.html is enough, generation of PDF is not needed!

Drop me a note when you've found time to add some content and I'll do the rest -merge to trunk, (page-break) formatting, PDF generation etc. pp.- afterwards.

Cheers ,

Kuddel​

 

[Ripley]

There are new builds 4.0 and 29.0
...
- New version of DX9ExtMFD is made available which is using the swapchain interface. Unzip it in "/Modules/Plugin/" folder.
...

I don't understand if the (then) new DX9ExtMFD attached to that release (post #5062) was an alternative to the one packaged inside the zip itself...
Or if it has now been merged in the latest release.

Thanks.


Edit:
already asked here
https://www.orbiter-forum.com/showthread.php?p=605570&postcount=5174
but with no 100% sure answer

 

[kuddel]

Any newer release always includes all previous changes (except when it's found erroneous later on).
So the "new DX9ExtMFD" is in there.

 

[GLS]

You folks might be interested in this one: https://www.orbiter-forum.com/project.php?issueid=1471

 

[asbjos]

I have a bug with the terrains of very non-spherical celestial objects (Phobos, Deimos, Vesta, etc.), as they are rendered partially with the terrain, and partially as spherical objects with the textures wrapped around.
Same problem reported here: https://www.orbiter-forum.com/showthread.php?p=606820#post606820
I searched for a solution, but couldn't find any, so I'm reposting the problem in this thread.

I assume the bug is for all celestial objects, but it's then not as jarring due to their high sphericality.

Works all fine in inline client, as seen in attached images. First image is inline, second D3D9.

I'm using latest R4.4, by the way.

 

[Nikogori]

I have a bug with the terrains of very non-spherical celestial objects (Phobos, Deimos, Vesta, etc.), as they are rendered partially with the terrain, and partially as spherical objects with the textures wrapped around.
Same problem reported here: https://www.orbiter-forum.com/showthread.php?p=606820#post606820
I searched for a solution, but couldn't find any, so I'm reposting the problem in this thread.

I assume the bug is for all celestial objects, but it's then not as jarring due to their high sphericality.

Works all fine in inline client, as seen in attached images. First image is inline, second D3D9.

I'm using latest R4.4, by the way.

I have the same problem with R4.4.

Phobos looks completely spherical at certain distance.

It becomes non-spherical when you get closer.

But if you look at it from different angle, it becomes partially spherical.

 

[Marg]

So Phobos IS an alien reconfigurable spacecraft, as Shklovsky (?) proposed...

 

[n72.75]

I just got an assert fail, 12** something. tried to screenshot it but failed apparently.

I was in the latest NASSP commit, main 2d pannel, just after the end of the ascent program, and I clicked a MFD button.

Bam, assert fail from D3D9 client. I know you probably need more info, unless this is known and I shouldn't worry about it.

 

[DaveS]

Anyway of brightening the ground around sunrise/sunset? As shown in the attached screenshots, the ground gets dark way too early currently. The Orbiter screenshot was taken around the same time on the same day as the video screenshot of the first STS-114 rollout on April 6 2005, from the same vantage point (SE corner of the VAB roof).

 

[kuddel]

You should try the "D3D9 Atmospheric Controls", this dialog allows to control various atmospheric parameters and effects.
Lots of parameters you can change there (Gamma might be the first to try -from my guess- ).

You'll find in under the "Custom functions" (top-border-menu "function")...

If you save the settings, these will be saved as Config\GC\<Planet>.atmo.cfg and Config\GC\<Planet>.atms.cfg (for orbital resp. surface parameters),
so you might first backup those (in case you totally ruined them )

Of course you can also directly change the values there.

Note: There is currently only one set of atmospheric parameters per planet, so no way to specify a specific set per scenario (yet).

 

[DaveS]

You should try the "D3D9 Atmospheric Controls", this dialog allows to control various atmospheric parameters and effects.
Lots of parameters you can change there (Gamma might be the first to try -from my guess- ).

You'll find in under the "Custom functions" (top-border-menu "function")...

I've tried that (it was the first go-to, before I posted), with no appreciable difference. I've attached a screenshot with both the terrain brightness and gamma sliders maxed out. This is something that needs to be altered in code.

 

[kuddel]

Hmm... strange.

I've just checked Orbiter 2016 (D3D9Client R4.4) and I could "brighten" up the surface.
Is you scenario using a different earth ("SSU-Earth" or something like that?).
I have never tried the dialog in such a scenario, but I would assume that then Config\GC\SSU_Earth.atmo.cfg and Config\GC\SSU_Earth.atms.cfg would get modified...

 

[DaveS]

Hmm... strange.

I've just checked Orbiter 2016 (D3D9Client R4.4) and I could "brighten" up the surface.
Is you scenario using a different earth ("SSU-Earth" or something like that?).
I have never tried the dialog in such a scenario, but I would assume that then Config\GC\SSU_Earth.atmo.cfg and Config\GC\SSU_Earth.atms.cfg would get modified...

I've attached the scenario I used, it's just a date modified version the standard Delta-glider\DG-S ready for takeoff scenario.


And no, no separate Earth.cfg file used.

 

[kuddel]

I've just checked with SSU and it worked for me...
Saving the setup with "gamma cranced up" created these two configurations:
Earth.atmo.cfg:

Red = 0.6517
Green = 0.55
Blue = 0.4816
RWaveDep = 4.08
MWaveDep = 0
ScaleHeight = 8.11965
DepthClamp = 0.99875
Exposure = 1.034
TGamma = 0.7272
OutScatter = 0.682587
InScatter = 1.1285
RayleighPhase = -0.5085
MiePower = 0.070688
MiePhase = 0.924176
Aux1 = 0.3
Aux2 = 0.044521
Aux3 = 0.94
AGamma = 0.6624
HazeClr = 0.765
HazeIts = 1.3912

Earth.atms.cfg:

Red = 0.6517
Green = 0.559
Blue = 0.4804
RWaveDep = 5.216
MWaveDep = -1.712
ScaleHeight = 8.11965
DepthClamp = 0.99875
Exposure = 1.1045
TGamma = 1.5
OutScatter = 1.04784
InScatter = 1.598
RayleighPhase = 0
MiePower = 0.3872
MiePhase = 0.967558
Aux1 = 0.3
Aux2 = 1
Aux3 = 0
AGamma = 1.5
HazeClr = 0.273
HazeIts = 1.6096

---------- Post added at 23:00 ---------- Previous post was at 22:57 ----------

I've attached the scenario I used, it's just a date modified version the standard Delta-glider\DG-S ready for takeoff scenario.
[...]
And no, no separate Earth.cfg file used.

I figured out already, thanks nevertheless.

So, you don't see any change when sliding the sliders?

---------- Post added at 23:25 ---------- Previous post was at 23:00 ----------

The data flow is: Slider -> ShaderParameter -> Shader -> DISPLAY
So, are you sure your shader (Modules\D3D9Client\Surface.fx) contains some code that uses the shader-parameters fTrGamma and fAtmGamma?
Compare the shader files in your Modules\D3D9Client\ folder with the ones packaged in D3D9ClientR4.4-forOrbiter2016(r1306).zip