New Release D3D9Client Development

[jarmonik]

Is this what I should be seeing?
(Orbiter with inline client is 5 Dec 2015 [v.151205])

Yes, the date displayed in the screen shot is incorrect. It should be 5 Dec 2015 [v.151205] as well.

Just click "SVN Update" for your Orbiter installation folder and it should do the trick.

 

[JMW]

Well, have done that. Even deleted orbiter.exe and Orbiter_ng.exe and updated but keep getting versions as shown.....?
:compbash2:

 

[jarmonik]

The file that matters is:

/Modules/Server/orbiter.exe

r.44 = 1 412 096 bytes
r.43 = 1 424 384 bytes

Try to delete orbiter.exe from /Modules/Server/ and then Update.

But anyway, if I run the client with Orbiter r.43 then I can reproduce the sky rendering issue. It will render the sky exactly the same way as in your screen shots.

 

[JMW]

ISSUE SOLVED

Yep, that's done it!
Thank you so much jarmonik and sorry for your trouble.:tiphat:

 

[Abloheet]

Ok. One problem with the latest d3d9beta for rev 44. There are no shadows for surface base objects. Everything else is 100% fine. This prob is not there in the inline version.
And, no shadows of vessel, and base objects, on mars and moon

 

[Tex]

I've installed the latest Orbiter BETA and D3D9 client, and it looks great! One hiccup I've had is while running D3D9: I keep getting CTD when pressing F8 in the default delta glider to change from the virtual cockpit to the glass cockpit. I'm only seeing this when running D3D9. I haven't had a chance to read through this entire thread yet to see if others had this issue. I'm just wondering if I'm missing something obvious. I'm sure no one else is having this issue since the default delta glider appears to be compatible. I get the same issue with GDI Compatibility mode enabled.

Edit -- Some additional info. I've created a new BETA install (r.44) with the latest D3D9 client (Beta12). No add ons were installed, not even sound. The problem persists when I load the scenario "DG-S ready for takeoff" with Orbiter_ng and attempted to change into the glass cockpit by pressing F8 in the delta glider. I tried to load a scenario with the Shuttle-A and it simply crashed before loading. I don't understand the log below, but it shows some warnings and errors in the log I posted last night.

Edit 2 -- Well it might help if I used the latest D3D9 beta version... :facepalm: I just noticed beta 14 in this thread. That seems to be working now. Sorry and thanks!

 

[rstr]

Missing Texture Files Flagged by D3D9 Beta13c Client

Hi. While trying to assess compatibility of various add-ons with D3D9 beta13c and Orbiter2015 (orbiter_ng.exe) r.44 in response to Dr. M.'s survey request, I'm seeing D3D9ClientLog.html flag some missing textures, namely:

Fcd07_n.dds, Fcd08_n.dds, Fcd09_n.dds, Fcd10_n.dds, Fcd14_n.dds, Fcd15_n.dds, Roof01_n.dds, Roof02_n.dds, Wall01_n.dds, Door01_n.dds, Solpanel_n.dds, Runway2_n.dds, Ball_n.dds, Cape17_n.dds, Cape18_n-dds, Cape19_n.dds, Cape20_n.dds, Cape21.dds, Cape21_n.dds, Concrete1_n.dds.

I have indeed not found these in the Orbiter2015 Texture folder, while corresponding dds-files without the "_n" suffix are existing. In Orbiter2010P1 all these files, with and without "_n", had been present (though with differing contents compared to Orbiter2015).
I've also scanned the cfg/msh files for any references to these above-mentioned "*_n.dds" textures, but to no avail.
Hence I'm confused about as to what is triggering D3D9 client to try to load these files, what the function of the "*_n.dds" files are, and how to fix the above issues.

Any hints appreciated - thanks in advance - Rob
(and again, thanks so much for D3D9 client, and Orbiter2015 - marvellous work !! :tiphat.

 

[Face]

Hi. While trying to assess compatibility of various add-ons with D3D9 beta13c and Orbiter2015 (orbiter_ng.exe) r.44 in response to Dr. M.'s survey request, I'm seeing D3D9ClientLog.html flag some missing textures, namely:

Fcd07_n.dds, Fcd08_n.dds, Fcd09_n.dds, Fcd10_n.dds, Fcd14_n.dds, Fcd15_n.dds, Roof01_n.dds, Roof02_n.dds, Wall01_n.dds, Door01_n.dds, Solpanel_n.dds, Runway2_n.dds, Ball_n.dds, Cape17_n.dds, Cape18_n-dds, Cape19_n.dds, Cape20_n.dds, Cape21.dds, Cape21_n.dds, Concrete1_n.dds.

I have indeed not found these in the Orbiter2015 Texture folder, while corresponding dds-files without the "_n" suffix are existing. In Orbiter2010P1 all these files, with and without "_n", had been present (though with differing contents compared to Orbiter2015).
I've also scanned the cfg/msh files for any references to these above-mentioned "*_n.dds" textures, but to no avail.
Hence I'm confused about as to what is triggering D3D9 client to try to load these files, what the function of the "*_n.dds" files are, and how to fix the above issues.

Any hints appreciated - thanks in advance - Rob
(and again, thanks so much for D3D9 client, and Orbiter2015 - marvellous work !! :tiphat.

IIRC, these textures are not part of the O2010P1 distribution. Perhaps they are part of the D3D9Client distribution for O2010P1, then they might have been left out for the beta D3D9Client. Bump-maps?

 

[rstr]

Missing Texture Files Flagged by D3D9 Beta13c Client (follow-up #2)

IIRC, these textures are not part of the O2010P1 distribution. Perhaps they are part of the D3D9Client distribution for O2010P1, then they might have been left out for the beta D3D9Client. Bump-maps?

Thanks for your hint, Face. I need to correct one statement of mine:
The mentioned texture files were *not* part of O2010P1 but remnants of add-ons (a subset is stemming from "Spikes Base Textures", others I'm still about to identify) - apologies for this :facepalm: .

BUT:

I have again run a clean minimal installation of Orbiter2015 r.44 (via Subversion) plus texture packs EarthLo / Earth_Cloud / MoonLo / MarsLo / MinorBodies (the updated one) plus D3D9 Client Beta13c-for-Rev43 into an empty folder.

Still the D3D9ClientLog.html reports the before-mentioned files as missing.

What confuses me: I always thought any texture file to be loaded needs to be enlisted in a .msh or .cfg file, but even when running a text scan e.g. for "fcd07_n" via WinGrep or AgentRansack over the complete Orbiter folder with its 36348 items (all file types) still does not find any file containing a reference to the flagged missing texture file(s) ! Where does the D3D9 client then retrieve any information to attempt to load those mentioned texture files ?!?!?
Regards & thanks in advance for caring - Rob

 

[DaveS]

Thanks for your hint, Face. I need to correct one statement of mine:
The mentioned textures were *not* part of O2010P1 but remnants of an add-on (probably from "Spikes Base Textures") - apologies for this :facepalm: .

BUT:

I have again run a clean minimal installation of Orbiter2015 r.44 (via Subversion) plus texture packs EarthLo / Earth_Cloud / MoonLo / MarsLo / MinorBodies (the updated one) plus D3D9 Client Beta13c-for-Rev43.

Still the D3D9ClientLog.html reports the before-mentioned files as missing.

What confuses me: I always thought any texture file to be loaded needs to be enlisted in a .msh or .cfg file, but even when running a text scan e.g. for "fcd07_n" via WinGrep or AgentRansack over the complete Orbiter folder with its 36348 items (all file types) still does not find any file with a reference to the flagged missing texture files ?!?!? Where does the client retrieve any information to attempt to load those mentioned texture files ?!?!?
Regards & thanks in advance for caring - Rob

Those textures are used by the basic surface base building items such as HANGAR, BLOCK, SOLARPLANT etc. These elements are generated by Orbiter itself and not any custom meshes. The suffix _n indicates that it is a night version of the texture that is labeled before the suffix such as "fcd07".

 

[rstr]

Missing Texture Files Flagged by D3D9 Beta13c Client (follow-up #3)

Those textures are used by the basic surface base building items such as HANGAR, BLOCK, SOLARPLANT etc. These elements are generated by Orbiter itself and not any custom meshes. The suffix _n indicates that it is a night version of the texture that is labeled before the suffix such as "fcd07".

DaveS, thank you so much for this clarification. (What a truly great and friendly community of Orbinauts this is )

I'd like to contribute in providing those missing "night" textures to the community if one cared to tell me about the basic procedure to generate these out of the existing "daytime" texture files.

Kind Regards - Rob

 

[DaveS]

DaveS, thank you so much for this clarification.

I'd like to contribute in providing those missing "night" textures to the community if one cared to tell me about the basic procedure to generate these out of the existing "daytime" texture files.

Kind Regards - Rob

They're not generated but actual bitmap textures. Only the actual in-game meshes are generated by Orbiter. So creating night versions of those textures are not that difficult as long as you use the original texture as a base.

 

[orb]

I'd like to contribute in providing those missing "night" textures to the community

Well, they aren't missing if they weren't existing previously. They are completely optional. The "daytime" textures are used also at night and the "night" textures are layered on top of them as lightmaps/glowmaps only if they are present. They are reported as "missing" just because they are searched and not found.

If you don't have any night lights / glow maps required for them to be visible at night, you have a choice either to not create them or create black textures (which will use more resources than no texture).

Of course if you want some part of concrete glowing at night you can create a "Concrete1_n.dds" texture with colors brighter than black.

 

[jarmonik]

D3D9ClientBeta15 - forRev 45

Here is a new version updated for the Orbiter beta rev. 45

- Vessel and surface base shadows should be visible now.

 

[Fabri91]

Browsing the Orbiter Screenshot thread an idea for a possible feature popped up: in Kerbal Space Program there is a setting which makes it possible to increase the resoution for screenshot-taking, e.g. it's possible to have the game run normally at 1080p and have screenshots taken at 4K resolution, giving beautiful results while not murdering the framerate to death.

Would something similar be possible here?

 

[Ripley]

A heads-up for the "D3D9 guys" just in case:
http://www.orbiter-forum.com/showthread.php?p=524732&postcount=10

 

[jarmonik]

Would something similar be possible here?

I'll try to keep it in mind.

 

[jarmonik]

Uploaded a new version of the client in the Orbiter Beta thread.

Looks like the atmospheric scattering model is no-go. Due to increased vertex count, a vertex based method is no longer an option because of very high performance impact. We need to go to some kind of pre-computed model and run it in a pixel shader.

 

[SolarLiner]

Uploaded a new version of the client in the Orbiter Beta thread.

Looks like the atmospheric scattering model is no-go. Due to increased vertex count, a vertex based method is no longer an option because of very high performance impact. We need to go to some kind of pre-computed model and run it in a pixel shader.

Maybe the implementation used in Space Engine? https://hal.archives-ouvertes.fr/inria-00288758/document

C++/OpenGL, but hopefully easy to port.

 

[jarmonik]

Are a feature branches supposed to hang-around forever in the branches or are they supposed to be deleted after merging ? or after becoming obsolete ?