New Release D3D9Client Development

Felix24

Member
Joined
May 13, 2010
Messages
204
Reaction score
9
Points
18
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

Donator
Donator
Joined
Apr 1, 2008
Messages
1,627
Reaction score
151
Points
63
@Felix24: Could you try and disable the gcGUI Mode.

Via dialog:
attachment.php


Or direct in D3D9Client.cfg:
Code:
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

New member
Joined
May 19, 2020
Messages
2
Reaction score
0
Points
0
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

Member
Joined
May 13, 2010
Messages
204
Reaction score
9
Points
18
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

Donator
Donator
Joined
Apr 1, 2008
Messages
1,627
Reaction score
151
Points
63
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

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,188
Reaction score
188
Points
63
Website
users.kymp.net
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

Donator
Donator
Joined
Apr 1, 2008
Messages
1,627
Reaction score
151
Points
63
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 :cheers:,
Kuddel​
 

Ripley

Tutorial translator
Donator
Joined
Sep 12, 2010
Messages
2,958
Reaction score
187
Points
78
Location
Rome
Website
www.tuttovola.org
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
 
Last edited:

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
1,627
Reaction score
151
Points
63
Any newer release always includes all previous changes (except when it's found erroneous later on).
So the "new DX9ExtMFD" is in there.
 

asbjos

tuanibrO
Addon Developer
Joined
Jun 22, 2011
Messages
659
Reaction score
148
Points
58
Location
This place called "home".
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.
 

Attachments

  • CurrentState – Kopi.jpg
    CurrentState – Kopi.jpg
    33.5 KB · Views: 21
  • CurrentState – Kopi (2).jpg
    CurrentState – Kopi (2).jpg
    160.6 KB · Views: 22
Last edited:

Nikogori

Donator
Donator
Joined
Mar 14, 2015
Messages
159
Reaction score
21
Points
33
Location
Osaka
Website
orbinautjp.github.io
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.

ROnjyAc.png


It becomes non-spherical when you get closer.

VkI3tWB.png


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

kNevl30.png
 

Marg

Active member
Joined
Mar 20, 2008
Messages
410
Reaction score
37
Points
28
So Phobos IS an alien reconfigurable spacecraft, as Shklovsky (?) proposed... :)
 

n72.75

Addon Developer
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
1,900
Reaction score
290
Points
83
Location
Biddeford ME
Website
www.adabsurdumpublishing.com
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

Space Shuttle Ultra Project co-developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
8,941
Reaction score
246
Points
153
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).
 

Attachments

  • D3D9Client_ground_too_dark.jpg
    D3D9Client_ground_too_dark.jpg
    66.5 KB · Views: 26
  • STS114_rollout1.jpg
    STS114_rollout1.jpg
    316 KB · Views: 24

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
1,627
Reaction score
151
Points
63
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).
 
Last edited:

DaveS

Space Shuttle Ultra Project co-developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
8,941
Reaction score
246
Points
153
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.
 

Attachments

  • D3D9Client_ground_too_dark2.jpg
    D3D9Client_ground_too_dark2.jpg
    109.2 KB · Views: 19

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
1,627
Reaction score
151
Points
63
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

Space Shuttle Ultra Project co-developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
8,941
Reaction score
246
Points
153
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.
 

Attachments

  • D39DClient_sunset.scn
    3.2 KB · Views: 1

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
1,627
Reaction score
151
Points
63
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:
Code:
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:
Code:
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
 
Top