|01-07-2017, 10:55 AM||#4246|
Fix for Sudden Failure of Stereoscopic 3D with NVidia for any D3D9Client release !!
So here's the story:
At first I have studied the CodePlex Source Code "howto", and compiled a differently tagged D3D9-2016R1 version from the source trunk with linked 32-bit NVidia R375 API lib / headers using Visual Studio 2017 + 2010 VC++/ DirectX SDK. The D3D9ClientLog.html shows NVidia API is now initialized, this and the Orbiter.log files indicate no problems; also the Orbiter-ng.exe behaves correctly ... BUT: still no 3D stereo .
Now things were getting really strange:
When I just renamed the installation folder, without any other change stereo 3D worked again. Renaming it back made stereo 3D defunct again.. Now, as we know: the installation folder name or location should not have any effects on Orbiter's function, right !?!.
So next thing I did in the root cause analysis was to re-establish the original D3D9Client.dll 2016R1 onto my otherwise unchanged Orbiter2016 installation with the original folder name and defunct 3D stereo. Guess what: as soon as I just renamed the installation folder, 3D stereo worked despite the "Not compiled with nVidia API" log message from the original client !! Same happened for my second also 3D-stereo-broken installation on the Beta versions: fixed by folder rename.
Next step was to analyze nVidia and/or DirectX influence.
Adding orbiter.exe, orbiter-ng.exe, and/or Modules/Server/orbiter.exe in the nVidia Control Panel section for "Program Settings" did not have any effect on 3D stereo functioning or being defunct. Also nVidia registry entries did not have an impact.
Then I finally found the "smoking gun" ... Direct3D
There are entries in the registry done by DirectX for 3D operation at [HKEY_USERS\<...my user SID...>\SOFTWARE\Microsoft\Direct3D\Shims\Maximize dWindowedMode]
In my installation these were:
"E:\\Programs\\Orbiter2016BetaR65+D3D9-Beta25_2-for-Rev65\\modules\\server\\orbiter.exe" = dword:00000001
"E:\\Programs\\Orbiter2016\\modules\\server\\orbit er.exe" = dword:00000001
Deleting these entries made the defunct stereo 3D work again even with the original folder names being kept !!
I do not have any idea what action causes these entries being made, but if these are being created by whatever cause they render stereo 3D defunct. Maybe we have to look at possible impacts from D3D9Client's "advanced video" tab, but this is just a wild guess.
So in a nutshell:
A) The original D3D9Client.dll 2016R1 on Orbiter2016 works for NVidia stereo 3D even if not compiled with the nVidia API. The same is true for D3D9-Beta25_2-for-Rev65 on Orbiter2016BetaR65.
B) If for whatever reason the 3D stereo function goes dead, a simple rename of the installation folder for Orbiter, or deletion of the before-mentioned registry entry/entries below [HKEY_USERS\<...user SID...>\SOFTWARE\Microsoft\Direct3D\Shims\Maximize dWindowedMode] fixes it.
As usual: be extra careful when fiddling around in the registry, do an export of the entries and a double-check for the correct HKU-location before deleting, and if in doubt, or unexperienced better leave the registry as is and rename the Orbiter installation folder instead of risking to brick your complete Windows installation ... it's your choice, and I don't take any responsibility for application of this registry hack, or any side-effects from it.
If unsure about your user SID: just run
"wmic useraccount get sid,name"
in a CMD window to list all SIDs including the one you're logged in to find the correct HKU entry.
C) I am still puzzled as to why the nVidia 3D stereo works with original D3D9Client.dll despite the "not compiled with nVidia API" log message. My re-compiled dll with the _NVAPI_H define and linked nVidia API lib/headers also works but I do not even see a performance or functional impact for the 3D stereo aside from the "nVidia API initialized" message in the log.
Attached plz find the logs and the compiled NVidiaAPI-enabled D3D9Client.dll ("2016R1+ for Orbiter2016") for the Modules/Plugin folder plus the VirusTotal report (for whatever reason it's flagged 1/55, as the original 2016R1 dll also does .. probably some too nosy heuristic test by 1 of the 55 applied scanners ?!?).
Dear Fellow Orbinauts: Plz note that this attached dll is NOT INTENDED for the user community, and has no authorization or endorsement for public usage by the OVP developers.
Cheers - Rob
Last edited by rstr; 01-14-2017 at 02:57 AM.
|01-13-2017, 07:47 PM||#4248|
shoemaker without legs
Say, I have two somewhat technical questions.
The first, is it possible to write custom shaders for a vessel for D3D9client?
And the second, how does D3D9 client handle draw calls of objects that are composed of several meshes (like bases, or vessels that consist of multiple meshes). Is there one pass per material in the entire object, or is there a pass per material per mesh?
Last edited by jedidia; 01-13-2017 at 10:59 PM.
|01-13-2017, 10:46 PM||#4249|
Technically it would be possible to specify a name of a custom shader in a material section of a mesh file. But currently the mesh files are read by the Orbiter and there's not much we can do about it.
To optimize the rendering, mesh groups should be pre-ordered in a mesh file by material and texture to minimize material and texture changes. When dealing with a very complex constructions the optimizations can give about +33% into the frame-rate.
|Quick Links||Need Help?|