New Release D3D9Client Development

[Wolf]

Oh boy, I didn't know we had the IR view with the Camera!

STS-31R post OMS-2 and PB opening

 

[kuddel]

@Jarmonik: I've tried the "Debug-Builds" you've posted (Post 4713) and they seem a bit odd...
Did you build them from the HEAD revision of SVN? Or are there any local changes included?
I'm asking because they are very different from any build I can make from the SVN sources. (e.g. "DockingCamera" appears under "Miscellaneous", not under "MFD Modes" as expected as to the DockingCamera.rc file...)
Another point: It looks like you do not have the most current version of Visual Studio
(VisualStudioVersion = 14.0.25123.0 vs. VisualStudioVersion = 14.0.25420.1). Maybe an update of VS is a good thing...
I don't expect the VS update to do the trick, but that update (Update 3) is the stable version for quite a while.

If I had to guess, I would blame a Runtime-Library mixup (static vs dynamic) to be the cause for Wolf's issues.

@Wolf: Just to check if "my builds" do change the behavior, would you please try the attached debug-builds?
While writing this post Wolf posted too::ninja:
It seems that Wolf is able to run the Client & DockingCamera :thumbup:, so I've removed the attachment.

 

[Wolf]

If I had to guess, I would blame a Runtime-Library mixup (static vs dynamic) to be the cause for Wolf's issues.

@Wolf: Just to check if "my builds" do change the behavior, would you please try the attached debug-builds? It seems that Wolf is able to run the Client & DockingCamera :thumbup:, so I've removed the attachment.

I really really appreciate your help. Unfortunately as I posted above I still cannot run the latest release. I am using a previous version which seems to be running ok here...
the debug description does not seem to be useful to jarmonik so I do not know what I can do to make the latest release working on my end..

 

[jarmonik]

@Jarmonik: I've tried the "Debug-Builds" you've posted (Post 4713) and they seem a bit odd...
Did you build them from the HEAD revision of SVN? Or are there any local changes included?

No, there are no local changes. It's a regular build I always use for testing and development. Using the project files stored in SVN.

But, I did resently update my DirectX SDK from February 2010 to June 2010. D3D9Client version 3.4 is the first one build with June 2010 setup.

There is also a new build of the gcAPI.lib. Build with visual studio 2008. I tried to include a debug build of the gcAPI_dbg.lib in debug build of the client but I got some weird errors. So, a release build of gcAPI is incuded instead like is always has.

Another point: It looks like you do not have the most current version of Visual Studio
(VisualStudioVersion = 14.0.25123.0 vs. VisualStudioVersion = 14.0.25420.1). Maybe an update of VS is a good thing...
I don't expect the VS update to do the trick, but that update (Update 3) is the stable version for quite a while.

Thanks about leting me know. I thought it would auto-update like everyting else these days.

If I had to guess, I would blame a Runtime-Library mixup (static vs dynamic) to be the cause for Wolf's issues.

Shouldn't it effect everybody in a same way ?

---------- Post added at 18:34 ---------- Previous post was at 18:23 ----------

the debug description does not seem to be useful to jarmonik so I do not know what I can do to make the latest release working on my end..

I would essentially need the Fault offset and Module information, so that I could look at the source code at that location.


Faulting application name: orbiter.exe, version: 0.0.0.0, time stamp: 0x57c23356
Faulting module name: D3D9Client.dll, version: 3.4.0.0, time stamp: 0x5c224375
Exception code: 0xc0000005
Fault offset: 0x0004b1f4
Faulting process id: 0x31a4
Faulting application start time: 0x01d49c6298d7d792
Faulting application path: C:\Software\Orbiter2016-Official\modules\server\orbiter.exe
Faulting module path: C:\Software\Orbiter2016-Official\Modules\Plugin\D3D9Client.dll
Report Id: e0703dde-1c71-47ba-99ff-854f9480607b
Faulting package full name:
Faulting package-relative application ID:


Also a screen shot from the debugger showing the Callstack and disassemply of the fault location would be helpful.

---------- Post added at 18:59 ---------- Previous post was at 18:34 ----------

Wait a minute, There was an issue that might explain the problem.

Latest Docking Camera release for Orbiter 2016 is infact a debug build. Where as the build for Orbiter Beta is a release build. My compiler refused the compile a release build for O2016 and I did not have time to start investigating the problem so I made a debug build instead. So, does it now require a debug runtime libraries ?

edit: No, the runtimes are statically linked.

 

[kuddel]

I really really appreciate your help. Unfortunately as I posted above I still cannot run the latest release. I am using a previous version which seems to be running ok here...
the debug description does not seem to be useful to jarmonik so I do not know what I can do to make the latest release working on my end..

O.K. So here's the ZIP (debug-builds[*] by me, on my machine).
You might try these. I expect these to not crash at all, but as usual expectations and real behavior might differ.


[*] "not for production use"

 

[kuddel]

But, I did resently update my DirectX SDK from February 2010 to June 2010. D3D9Client version 3.4 is the first one build with June 2010 setup.

That update should not change how the linker incorporates .rc files (...explaining the wrong "Modules Category").
I don't think that the June 2010 SDK update does any harm. I was using that all the time (since December 2016).

There is also a new build of the gcAPI.lib. Build with visual studio 2008. I tried to include a debug build of the gcAPI_dbg.lib in debug build of the client but I got some weird errors. So, a release build of gcAPI is incuded instead like is always has.

Yeah! I've tried the same (although I do not have VS 2008 available) and the dynamic/static debug/release linking oddities still raises big question-marks above my head :shrug:

Thanks about leting me know. I thought it would auto-update like everyting else these days.

You're welcome. And yes I also find it odd, that Visual Studio isn't updated through Windows Update. Although I kind of understand that decision; as it is very annoying that a build process might fail just because of "automatic background update of any kind". Visual Studio is a special application.

Shouldn't it effect everybody in a same way ?

Yes it should :thumbup: I was just throwing in thoughts...

 

[jarmonik]

@Kuddel: Are you using VS 2015 or 2017 ?

 

[kuddel]

2015 (2017 is only used @ work as a proof of concept & to spice up my lunch-time :lol: )

 

[DaveS]

Quick question: Is there any way to disable self shadow generation for specific mesh groups? I've tried using FLAG 1 as indicated by the 3DModel.pdf document, but that doesn't seem to work.

 

[jarmonik]

Quick question: Is there any way to disable self shadow generation for specific mesh groups? I've tried using FLAG 1 as indicated by the 3DModel.pdf document, but that doesn't seem to work.

I checked the code and everything seems fine. Is this problem related to a transparent clipper objects ? (i.e. Cutting a hole in a mesh ?)


What is the inline engine's response to a FLAG 2. Does it disable a ground shadow and the caster or just the caster object but not the shadow ?

 

[DaveS]

I checked the code and everything seems fine. Is this problem related to a transparent clipper objects ? (i.e. Cutting a hole in a mesh ?)

This is correct. In this case it is two flat squares for rendering the insides of the two External Tank umbilical wells on the orbiter.



What is the inline engine's response to a FLAG 2. Does it disable a ground shadow and the caster or just the caster object but not the shadow ?[/QUOTE]
I tested this on a different mesh group (the main fuselage) and it works both in the inline engine and D3D9Client. And I think you meant FLAG 1, not FLAG 2, however both works.

---------- Post added at 04:06 PM ---------- Previous post was at 03:44 PM ----------

This screenshot shows the problem: https://www.dropbox.com/s/66ygqpluikudpmt/ET_umb_well_shadows.jpg?dl=0

As you can see, the ET umbilical wells are completely shaded (IE, entirely black) when there should only be partial shading.

 

[GLS]

This screenshot shows the problem: https://www.dropbox.com/s/66ygqpluikudpmt/ET_umb_well_shadows.jpg?dl=0

As you can see, the ET umbilical wells are completely shaded (IE, entirely black) when there should only be partial shading.

Why not save the "original" bottom surface group for future reference, and cut a door-shaped hole on the bottom surface? :shrug:

 

[DaveS]

Why not save the "original" bottom surface group for future reference, and cut a door-shaped hole on the bottom surface? :shrug:

Sometimes that leaves nasty artifacts that are nigh-on impossible to get rid of. And sometimes it doesn't work at all. Thankfully this time, it worked: https://www.dropbox.com/s/n429qnd30hih2w1/ET_umb_well_shadows2.jpg?dl=0

 

[jarmonik]

And I think you meant FLAG 1, not FLAG 2, however both works.

I was meaning the FLAG 2. But anyway, Here's a modified test build that should fix the issue with the shadows.

The flag settings would need to be checked. What is the right behavior ? Currently for the self shadows:

FLAG 1 - Will disable the shadow, but not the caster. It will be rendered.
FLAG 2 - Will disable a mesh group, but not the shadow it casts.

So, to disable both, a mesh group and the shadow it casts, FLAG 3 is required. Is this correct responce ?

For the Clipper objects FLAG 1 is required.

Here's a DLL for Orbiter Beta.

 

[DaveS]

I was meaning the FLAG 2. But anyway, Here's a modified test build that should fix the issue with the shadows.

The flag settings would need to be checked. What is the right behavior ? Currently for the self shadows:

FLAG 1 - Will disable the shadow, but not the caster. It will be rendered.
FLAG 2 - Will disable a mesh group, but not the shadow it casts.

So, to disable both, a mesh group and the shadow it casts, FLAG 3 is required. Is this correct responce ?

For the Clipper objects FLAG 1 is required.

Here's a DLL for Orbiter Beta.

Thanks, that one works. Although, I had to change over from Orbiter 2016 to the beta. I'm getting a severe frame rate reduction with the beta D3D9Client. In Orbiter 2016 I'm getting a nice steady 100 fps but with the beta with the same scenario and the same settings, I'm getting no more than 46 fps.

Edit:
It seems like there's some conflict going on here. A clean Orbiter beta installation shows no issues. So I'll start do a clean SSU installation and see if that clears things up as well.
Edit 2: Clean installation fixed that up, so ignore the report. Not sure what caused it but things have returned to normal.

 

[Donamy]

Why not save the "original" bottom surface group for future reference, and cut a door-shaped hole on the bottom surface? :shrug:

I believe I made holes in the mesh. :hmm:

 

[DaveS]

I believe I made holes in the mesh. :hmm:

You did but I had to remove the original floor of the aft engine compartment as it was had a few faults, one of being noted by GLS: "aft compartment bottom isn't flat (not exactly sure how it should be, but it doesn't look good as is)".

I couldn't fix the original so I decided to start with a clean slate. And since we were already using the "clipper method" for the star trackers, midbody vent doors and the aft RCS nozzles, I thought "why not use it for the ET umbilical wells" as well?

 

[Donamy]

Do you add the flags to the mesh file ?

 

[DaveS]

Do you add the flags to the mesh file ?

Yes. The FLAG parameter goes along with LABEL, MATERIAL, TEXTURE and GEOM. More information is available in the 3DModel.pdf document which can be found in the Doc subfolder of the main OrbiterSDK folder.

 

[Abdullah Radwan]

D3D9 client causes Orbiter to not display scenarios description. Orbiter 2016 with latest D3D9 client (r1038M). The problem occurs only on startup, which means if I started Orbiter with D3D9 de-activated then I activated it later, it works. It doesn't work only if D3D9 client is enabled on startup.