New Release D3D9Client Development

[Weirdo Earthtorch]

And looking good here too. But the runway lights disappear when overhead (happened in the previous RC too). I thought edge lights were omnidirectional?

Thanks for your collective work!

[Edit]
Hmm, I think vanilla Orbiter changes the approach lighting (from one end to the other) as your overhead camera view passes through the vertical, but the edge and centreline lights remain visible. It's not a biggie, I've not tested it in flight yet, just moved the camera around.

 

[Cras]

Just test out RC42, added that line about TD Disp line as well. Runway light brightness is much better. Thank you! Great implementation, can see them clearly, finally had fun landing at night again!

 

[Bibi Uncle]

Oups! I forgot to send the config file of Cape Canaveral. The additionnal flags are defined in there. All the datas were copied from asmi's version.

Replace your Config\\Earth\\Base\\Canaveral.cfg file by this one: View attachment Canaveral.zip

 

[Ripley]

Dansteph has posted on his forum about DGIV-2 not working in D3D9!!

http://orbiter.dansteph.com/forum/read.php?f=2&i=15062&t=15062

 

[cslevine]

Better and Better : Runways lights now !
So nice that i would like to have them ON not only during night, but during day too :
is that possible ?

 

[n122vu]

Noticed a bug with RC41, will check RC42 to see if it exists.

Steps to recreate:

- Load any daytime scenario at KSC
- Pause
- Open Scenario Editor
- Go to Date
- Move time forward one hour at a time until first point that runway lights activate
- Move time back one hour (runway lights should turn off

At this point I was seeing all meshes turn 'black' as if there was no sunlight. They remained this way through time acceleration throughout the night and following day. After a full day/night cycle, the following sunrise the meshes were appearing normally.

Also noticing black rings around the bases of all the hills on Ascension Island\WIA.

Will test RC42 this evening to see if these still occur and post screenshots if so.

 

[jarmonik]

Noticed a bug with RC41, will check RC42 to see if it exists.

Steps to recreate:

- Load any daytime scenario at KSC
- Pause
- Open Scenario Editor
- Go to Date
- Move time forward one hour at a time until first point that runway lights activate
- Move time back one hour (runway lights should turn off

At this point I was seeing all meshes turn 'black' as if there was no sunlight. They remained this way through time acceleration throughout the night and following day. After a full day/night cycle, the following sunrise the meshes were appearing normally.

I can reproduce this bug with the latest build. Taking a look into it.

Also noticing black rings around the bases of all the hills on Ascension Island\WIA.

That sounds like a base object shadow flag bug. Currently the 'SHADOW' flag isn't working in the Orbiter_ng. Using the 'UNDERSHADOWS' flag with the hills should fix or reduce the problem. Also, the Object shadows can be disabled from the launchpad.

---------- Post added at 20:43 ---------- Previous post was at 20:43 ----------

Better and Better : Runways lights now !
So nice that i would like to have them ON not only during night, but during day too :
is that possible ?

Yes, but it would require a configuration flag into a D3D9Client.cfg

---------- Post added at 20:50 ---------- Previous post was at 20:43 ----------

And looking good here too. But the runway lights disappear when overhead (happened in the previous RC too). I thought edge lights were omnidirectional?

Yes, they will disappear. I don't know about the edge lights being omnidirectional in KSC. Maybe there could be a configuration paramater in the runway lights data in a base configuration file that would allow to specify the behaviour for every runway separately.
Currently, you can set the 'RwyLightAngle' parameter from D3D9Client.cfg to 270. But it will effect in every light in the runway.

---------- Post added at 21:01 ---------- Previous post was at 20:50 ----------

Hello Jarmonik,

very nice progress you're making here. I just discovered by a post in the screenshot forum that you implemented the ability for use of normalmaps and specular maps for vessels! Outstanding! :thumbup:

...now, not wanting to be annoying, but do you plan for the near future, to start working on integrating the new atmospheric rendering code (Eric Bruneton - style) into your engine? I am nearly desperately waiting so much that we finally have much more realistic orbital sunrises/-sets, a spectacular skydome rendering and a beautiful, realistic atmosphere around Earth to gaze at from orbit...
(You may check Vladimir Romanyuk's SpaceEngine ver.095, it looks so dazzling real, you just gotta love his work in the visual department, and he is using Eric Bruneton's code as well, that one is simply unparalleled in any real-time simulation, IMHO!)
:tiphat:

Thanks, I'll take a look into the SpaceEngine to see how it looks like. But it's not a simple thing to implement because it will effect in everything. I would very much like to implement that feature but it could take a half a year of work and during that time I wouldn't be able to provide a stable updates for the client. I would like to finish some "smaller" things and make an official release of D3D9Client before starting to work something as big as the atmospheric scattering.

Here are some development plans and thoughts:
http://orbiter-forum.com/showthread.php?p=340175&postcount=1182

 

[Bibi Uncle]

Eric Bruneton's work is outstanding, and he wrote very good papers about his work. His ocean renderer and his atmospheric scattering effets are just incredible. A must-see website:
http://www-evasion.imag.fr/Membres/Eric.Bruneton/

 

[jarmonik]

Eric Bruneton's work is outstanding, and he wrote very good papers about his work. His ocean renderer and his atmospheric scattering effets are just incredible. A must-see website:
http://www-evasion.imag.fr/Membres/Eric.Bruneton/

Real-time planet rendering IV: ocean - YouTube

It's really cool. But what do you guys think about the twilight ? Isn't the darkness coming far too soon after the sun set ?

 

[luki1997a]

Ur right Bibi U.
I'm curious how long would implementing these take in D3D9Client. Can you, jarmonik answer, if it would took less than year or half an year? It's so great and I think, by the fact that Orbiter is a space flight sim, you should start to try to implement basics such as atmospheric scattering, planet shadows and sun flares(right? :S). Of course IMHO.

P.S.
Would you try to implement my easy and realistic reentry effect as posted here?

and :hail: jarmonik

 

[littleplatonian]

GX-720 Intel Core Duo [email protected]
Windows 7 Pro x64 Service Pack 1
Nvidia Geforce 130M 512MB
driver 295.73 x64
directx_feb2010_redist
automatic symbolic links created from advanced menu
Pre-load base visuals at start up enabled
Full Screen video at 1440x900
Disabled Vertical Sync
Disabled Full Screen Window
Disabled GDI compatibiltiy
All Visual Effects and Parameters enabled

Orbiter2010 patched with orbiter100830-100606diff
Vinka_full_pack thanks to Ripley
OrbiterSound35.exe

D3D9ClientRC39

F4 Dialog box doesn't appear on screen during simulations when pressed. I must alt-Tab to the desktop where I'm notified that "Connection to Direct3DDevice was lost. Exit simulation with Ctrl+Q and restart." If I click on the Orbiter icon in the task bar the missing F4 dialog box is sitting on top of a blank white screen.

D3D9ClientRC41

I'm getting the exact same behavior with the new client.

In modules two clients are listed; D3D9Client and D3D9Client_111105.
With the second client I get the error message "The procedure entry point ?clbkEndBltGroup@GraphicsClient@oapi@@UAEHXZ could not be located in the dynamic link library Orbiter.exe"

I hope this is the right place to post this...

 

[orb]

In modules two clients are listed; D3D9Client and D3D9Client_111105.
With the second client I get the error message "The procedure entry point ?clbkEndBltGroup@GraphicsClient@oapi@@UAEHXZ could not be located in the dynamic link library Orbiter.exe"

That's because it's for Orbiter beta 111105, and you're using Orbiter 100830.

 

[n122vu]

That sounds like a base object shadow flag bug. Currently the 'SHADOW' flag isn't working in the Orbiter_ng. Using the 'UNDERSHADOWS' flag with the hills should fix or reduce the problem. Also, the Object shadows can be disabled from the launchpad.

Confirmed. Disabling Object Shadows removed the black 'rings' around the hills on Ascension Island.

Thanks.
n122vu

 

[jarmonik]

F4 Dialog box doesn't appear on screen during simulations when pressed. I must alt-Tab to the desktop where I'm notified that "Connection to Direct3DDevice was lost. Exit simulation with Ctrl+Q and restart." If I click on the Orbiter icon in the task bar the missing F4 dialog box is sitting on top of a blank white screen.

Check this: http://orbiter-forum.com/showthread.php?p=230031&postcount=261

Thanks about reporting this. I can confirm the problem and it seems to be related in multisampling in a fullscreen mode. So, disabling the multisampling from a video tab or using a windowed mode should help. I'll take a look if there is something I can do to fix it.

EDIT: It's very well said in the ducumentation that there can be no multisampling with Win32/GDI based dialog boxes in a fullscreen mode.

D3D9Client doens't support Alt-Tabing and no such thing will be implemented. It's much more easier to convert the D3D9Client to use DX10 in the future that trying to get the Alt-Tabing to work in DX9.
EDIT: Alt-Tabbing is working perfectly fine in the windowed fullscreen mode.

 

[littleplatonian]

Thanks for responding so quickly.

You could do like Artlav does with his long development threads and keep the first post updated with the latest release links/notes...

I was so eager to try out the client I didn't read all of the posts.

-----------------------------------------------------------------------------------------

Multisampling was enabled in my Nvidia control panel. I disabled it. I updated Orbiter with the latest OVP beta 111105 and followed all of the directions at the beginning of this thread. The function key drop down menu for F4 is a huge improvement to me. My framerates range between 180 and 400 with a basic install and I've noticed no problems with OrbiterSound. Now I get to throw higher textures at my install to milk all the quality I can out of my current hardware. I added all the best hi-res textures I could find from the various Orbiter affiliated sites and now my laptop is unadulterated portable orbital joy. I can say goodbye to Virtualbox and Xp. Thanks guys for improving my Orbiter experience so I can get back to learning my favorite piece of software.

 

[kuddel]

Hi jarmonik,

I've tested your code against Orbiter (BETA) [v111105] and wondered about two things:
First, why don't you get the ScenarioTree IDC dynamically? Like

[COLOR="Green"]// scenario selection tree (Orbiter v100830) : 1088
// scenario selection tree (Orbiter v111105) : 1090[/COLOR]
[COLOR="Blue"]#define[/COLOR] IDC_SCENARIO_TREE (oapiGetOrbiterVersion()>=111105 ? 1090 : 1088)

and use the define? But that might be work in progress

Second: Is it really neccessary, that you have to get the currently selected scenario?
This fails for example if you start Orbiter with the '-s <scenario_name>' command line parameter[1]. In that case the Launchpad is not created at all.
In that case no Runway Lights

I'm not sure if you have to have that scenario information, but I would recommend, that it should be handled 'optional'.

Apart from that 'issue' it runs very well with v111105 !

Thanks for the fantastic work,
Kuddel

[1] That's how I usually start the debugging in VisualStudio

 

[jarmonik]

Hi jarmonik,

I've tested your code against Orbiter (BETA) [v111105] and wondered about two things:
First, why don't you get the ScenarioTree IDC dynamically? Like

[COLOR=Green]// scenario selection tree (Orbiter v100830) : 1088
// scenario selection tree (Orbiter v111105) : 1090[/COLOR]
[COLOR=Blue]#define[/COLOR] IDC_SCENARIO_TREE (oapiGetOrbiterVersion()>=111105 ? 1090 : 1088)

and use the define? But that might be work in progress

Not in a progress yet, but thanks, I'll do that. I haven't tried RC42 under 111105 yet. But I'll give RC43 a shot.

Second: Is it really neccessary, that you have to get the currently selected scenario?

I wouldn't have hacked the launchpad like that if I wouldn't feel it's necessary. The problem is that my pretty small Orbiter installation contains four different configuration files for Cape Canaveral and without knowing the scenario there is no way to tell which one is the correct one. Loading a wrong one can mess-up things and the runway lights won't work.

This fails for example if you start Orbiter with the '-s <scenario_name>' command line parameter[1]. In that case the Launchpad is not created at all.

Sorry, I forget that complitely. It should be pretty easy to provide a work-a-round that should work in most cases by going after the default Sol.cfg or an other Sol.cfg that's defined in D3D9Client.cfg

 

[Ripley]

Exceptionally good news from Dansteph!!

http://orbiter.dansteph.com/forum/read.php?f=2&i=15062&t=15062

 

[kuddel]

Sorry, I forget that complitely.

No need for sorry! I'm just trying to undrstand what's done and maybe provide some assistance

By the way, in VideoTab::SelectWidth() and VideoTab::SelectHeight() the nMaxCount parameter of GetWindowText is accidently to big (127). it schould be 32

  GetWindowText(GetDlgItem(hTab, IDC_VID_WIDTH),  cbuf, [COLOR=Red][s]127[/s][/COLOR] [B][COLOR=Blue]32[/COLOR][/B]); w = atoi(cbuf);
  GetWindowText(GetDlgItem(hTab, IDC_VID_HEIGHT), cbuf, [COLOR=Red][s]127[/s][/COLOR] [B][COLOR=Blue]32[/COLOR][/B]); h = atoi(cbuf);

cbuf is just not that big

In the meantime I am thinking about using some Windows Hook functions to get access to the Visual Helpers Dialog settings ("Body forces" etc.) maybe this can be used to get those settings until Martin decides to provide API for those.
/Kuddel

 

[jarmonik]

By the way, in VideoTab::SelectWidth() and VideoTab::SelectHeight() the nMaxCount parameter of GetWindowText is accidently to big (127). it schould be 32

Ok, thanks, fixed.

In the meantime I am thinking about using some Windows Hook functions to get access to the Visual Helpers Dialog settings ("Body forces" etc.) maybe this can be used to get those settings until Martin decides to provide API for those.

The implementation will be tricky but it could work if the Orbiter will pre-create the window during Orbiter startup.