New Release D3D9Client Development

GLS

Addon Developer
Addon Developer
Joined
Mar 22, 2008
Messages
3,923
Reaction score
48
Points
73
Right now any application using it will need to be recompiled after every change made to the interface.
You mean for current library version, right? With that new interface, unless the signature of the functions gets changed, a new version will be transparent to the code of the client. It will be like a dll. :thumbup:
 

jarmonik

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,104
Reaction score
61
Points
48
Website
users.kymp.net
You mean for current library version, right?

I am not exactly sure what you mean but you can get a pointer to gcCore interface in the latest 4.1 build. I am unsure but most of the standard features should be on-line via gcCore in 4.0 too.

---------- Post added at 13:57 ---------- Previous post was at 13:50 ----------

I was just about to publish my latest work with the TerrainToolKit but when I tried a release build I noticed a tons of problems...

From switch one is this:

If I have an interface compiled as a Debug build

class MyInt
{
virtual void MyFunc(std::string &lbl);
}

And I call the function from a module compiled as release:
...
pInterface->MyFunc(string("Hello World"));
...

I get a debug assertion in std::string :facepalm:
If the modules are both debug or release builds it works.
 

GLS

Addon Developer
Addon Developer
Joined
Mar 22, 2008
Messages
3,923
Reaction score
48
Points
73
I am not exactly sure what you mean but you can get a pointer to gcCore interface in the latest 4.1 build. I am unsure but most of the standard features should be on-line via gcCore in 4.0 too.

---------- Post added at 13:57 ---------- Previous post was at 13:50 ----------

I was just about to publish my latest work with the TerrainToolKit but when I tried a release build I noticed a tons of problems...

From switch one is this:

If I have an interface compiled as a Debug build

class MyInt
{
virtual void MyFunc(std::string &lbl);
}

And I call the function from a module compiled as release:
...
pInterface->MyFunc(string("Hello World"));
...

I get a debug assertion in std::string :facepalm:
If the modules are both debug or release builds it works.
That's probably due to memory being allocated on one side, and then accessed on the other, and each side is using a different CRT library (debug vs release). The solution would be to have a debug dll and release dll.... not sure what issues that would cause in Orbiter if both dlls are installed.
Thank you micro$oft... :compbash:
 

jarmonik

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,104
Reaction score
61
Points
48
Website
users.kymp.net
Luckily there is a simple fix to replace the std::string with "const char *". Sometimes the old way is better then a can of new ones it appears :lol:.
 

GLS

Addon Developer
Addon Developer
Joined
Mar 22, 2008
Messages
3,923
Reaction score
48
Points
73
Issue with lights: it looks like the range parameter in AddPointLight() is not being respected. The function description isn't 100% clear, but my understanding of it (and what MOGE apparently does) is create an distance/intensity curve from the att_x parameters, and then cut that curve at the distance specified by the range parameter, so the entire universe isn't lit up (the formula never goes to 0).
Using R4.0 for Orbiter 2016.
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
1,487
Reaction score
19
Points
38
As far as I know one should not pass objects around DLL boundaries.
Most libraries offer their API in extern "C" to avoid problems.
Like:
PHP:
extern "C" {
   void foo();
   // ...
}
Arguments are passed either as plain old data-types (char *) or must be acquired and released by the API itself (IIRC).
 

jarmonik

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,104
Reaction score
61
Points
48
Website
users.kymp.net
Issue with lights: it looks like the range parameter in AddPointLight() is not being respected. The function description isn't 100% clear, but my understanding of it (and what MOGE apparently does) is create an distance/intensity curve from the att_x parameters, and then cut that curve at the distance specified by the range parameter, so the entire universe isn't lit up (the formula never goes to 0).
Using R4.0 for Orbiter 2016.

As I remember the range is not being used in D3D9. We compute the range from the att_x parameters. So, the range is automatically set to 2% illumination or something like that. For a mesh outside of that range the light source is off-line. Is there a problem ?
 

GLS

Addon Developer
Addon Developer
Joined
Mar 22, 2008
Messages
3,923
Reaction score
48
Points
73
As I remember the range is not being used in D3D9. We compute the range from the att_x parameters. So, the range is automatically set to 2% illumination or something like that. For a mesh outside of that range the light source is off-line. Is there a problem ?
It shouldn't be a problem, just something I noticed when I had a very small range, and it was doing what I expected in MOGE, but in D3D9 the whole mesh was lit.
My "concern" was more in the performance side of things: if the intensity wasn't being limited, then all meshes would be lit (even if a tiny amount), which would eat a bit of fps. But if there is a cutoff, then it shoudn't be a problem. :shrug:
 

JMW

Aspiring Addon Developer
Joined
Aug 5, 2008
Messages
542
Reaction score
17
Points
18
Location
Marooned In Brazil
Hi Guys.

Big problem for me.
Is fine normally, but now illuminating everything (360 deg) in D3D9Client.

Code:
000219.985: 
000219.985: **** Creating simulation session
000219.985: D3D9: [DirectX 9 Initialized]
000219.985: D3D9: 3D-Adapter = Intel(R) HD Graphics 4000
000219.985: D3D9: MaxTextureWidth........: 8192
000219.985: D3D9: MaxTextureHeight.......: 8192
000219.985: D3D9: MaxTextureRepeat.......: 8192
000219.985: D3D9: VolTexAddressCaps......: 0x3F
000219.985: D3D9: NumSimultaneousRTs.....: 4
000219.985: D3D9: VertexDeclCaps.........: 0x37F
000219.985: D3D9: XNA Math Support.......: Yes
000219.985: D3D9: Vertex Texture.........: Yes
000219.985: D3D9: Shadow Mapping.........: Yes
000219.985: D3D9: D3DFMT_A16B16G16R16F...: Yes
000219.985: D3D9: D3DFMT_A32B32G32R32F...: Yes
000219.985: D3D9: D3DFMT_D32F_LOCKABLE...: No
000219.985: D3D9: D3DFMT_A2R10G10B10.....: Yes
000219.985: D3D9: D3DDTCAPS_DEC3N........: No
000219.985: D3D9: D3DDTCAPS_FLOAT16_2....: Yes
000219.985: D3D9: D3DDTCAPS_FLOAT16_4....: Yes
000219.985: D3D9: Available Texture Memory = 1781 MB
000219.985: D3D9: [3DDevice Initialized]
000219.985: D3D9: [Loading Constellations]
000219.985: D3D9: [D3D9Client Initialized]
000000.000: Module Sun.dll ............... [Build 160828, API 160828]
VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
000000.000: Module Mercury.dll ........... [Build 160828, API 160828]
VSOP87(B) Mercury: Precision 1e-005, Terms 167/7123
000000.000: Module Venus.dll ............. [Build 160828, API 160828]
000000.000: Module VenusAtm2006.dll ...... [Build 160828, API 160828]
VSOP87(B) Venus: Precision 1e-005, Terms 79/1710
000000.000: Module Earth.dll ............. [Build 160828, API 160828]
000000.000: Module EarthAtmJ71G.dll ...... [Build 160828, API 160828]
VSOP87(B) Earth: Precision 1e-008, Terms 2564/2564
000000.000: Module Moon.dll .............. [Build 160828, API 160828]
ELP82: Precision 1e-005, Terms 116/829
000000.000: Module Mars.dll .............. [Build 160828, API 160828]
000000.000: Module MarsAtm2006.dll ....... [Build 160828, API 160828]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
000000.000: Module Phobos.dll ............ [Build ******, API 060425]
000000.000: Module Deimos.dll ............ [Build ******, API 060425]
000000.000: Module Galsat.dll ............ [Build 160828, API 160828]
000000.000: Module Jupiter.dll ........... [Build 160828, API 160828]
VSOP87(B) Jupiter: Precision 1e-006, Terms 1624/3625
000000.000: Module Io.dll ................ [Build 160828, API 160828]
000000.000: Module Europa.dll ............ [Build 160828, API 160828]
000000.000: Module Ganymede.dll .......... [Build 160828, API 160828]
000000.000: Module Callisto.dll .......... [Build 160828, API 160828]
000000.000: Module Satsat.dll ............ [Build 160828, API 160828]
000000.000: Module Saturn.dll ............ [Build 160828, API 160828]
VSOP87(B) Saturn: Precision 1e-006, Terms 2904/6365
000000.000: Module Mimas.dll ............. [Build 160828, API 160828]
SATSAT Mimas: Terms 113
000000.000: Module Enceladus.dll ......... [Build 160828, API 160828]
SATSAT Enceladus: Terms 33
000000.000: Module Tethys.dll ............ [Build 160828, API 160828]
SATSAT Tethys: Terms 101
000000.000: Module Dione.dll ............. [Build 160828, API 160828]
SATSAT Dione: Terms 59
000000.000: Module Rhea.dll .............. [Build 160828, API 160828]
SATSAT Rhea: Terms 68
000000.000: Module Titan.dll ............. [Build 160828, API 160828]
SATSAT Titan: Terms 100
000000.000: Module Iapetus.dll ........... [Build 160828, API 160828]
SATSAT Iapetus: Terms 605
000000.000: Module Uranus.dll ............ [Build 160828, API 160828]
VSOP87(B) Uranus: Precision 1e-006, Terms 1827/5269
000000.000: Module Miranda.dll ........... [Build ******, API 060425]
000000.000: Module Ariel.dll ............. [Build ******, API 060425]
000000.000: Module Umbriel.dll ........... [Build ******, API 060425]
000000.000: Module Titania.dll ........... [Build ******, API 060425]
000000.000: Module Oberon.dll ............ [Build ******, API 060425]
000000.000: Module Neptune.dll ........... [Build 160828, API 160828]
VSOP87(B) Neptune: Precision 1e-006, Terms 391/2024
000000.000: Finished initialising world
000000.000: Module J-F-35B.dll ........... [Build 200127, API 161124]
000000.000: Module ShuttleA.dll .......... [Build 160828, API 160828]
000000.000: Finished initialising status
000000.000: Finished initialising camera
000000.000: Finished setting up render state
000000.000: D3D9: [Scene Initialized]
000000.000: Finished initialising panels
000019.022: D3D9: [Session Closed. Scene deleted.]
000019.022: D3D9: [Destroy Render Window Called]
000019.022: **** Closing simulation session
D3D9: ERROR: Invalid Window !! RenderWndProc() called after calling clbkDestroyRenderWindow() uMsg=0x82
 

Attachments

jarmonik

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,104
Reaction score
61
Points
48
Website
users.kymp.net
Edit: Uploaded "Before" image

Ok, Thanks. I can reproduce the issue. Looks like the local lights code has gone broken during some cleanups are code reorganizations. I am looking into it. I also try to implement the range parameter so that the actual range is either the input range or 2% illumination range, which one is shorter.
 

GLS

Addon Developer
Addon Developer
Joined
Mar 22, 2008
Messages
3,923
Reaction score
48
Points
73
The planet "dots" are not being updated: when focused on a planet, zooming out until it it becomes a dot and then moving the camera, the F9 yellow box moves as it should but the dot stays put relative to the stars.
This also causes planets (actually their dots) to show up in places, but the planets aren't there (zooming in only shows the dot).
Using D3D9 R4.0 in Orbiter 2016.
 

GLS

Addon Developer
Addon Developer
Joined
Mar 22, 2008
Messages
3,923
Reaction score
48
Points
73
I noticed that when inside a vc, if the viewport is pointed away from Earth the frame rate is higher that when it is pointer in the direction of Earth, but, because of the vc mesh the Earth is never visible in either view.
So the (probably dumb) question is: shouldn't the object that isn't in view not be rendered? I'd expect that since the Earth isn't in view, it shouldn't matter where I'm looking, so the framerate should not change... :shrug: Or is this an "advanced feature" of graphics engines, that isn't implemented? Or even something that doesn't exist, and I'm here showing that I don't know as much about rendering as I thought I knew?
BTW, the reaction is the same in MOGE.
 

DaveS

Space Shuttle Ultra Project co-developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
8,769
Reaction score
31
Points
123
Just checking here: Is local light sources unable to cast shadows in D3D9Client? If this isn't case, then I've a bug to report. As seen in attached screenshot from a video of PLBD closure for landing, the stowed RMS casts a shadow on the left PLB radiator panels (this is in full orbital night so the PLB flood-lights were on, the left door began moving shortly after sunset, you can see the limb of the Earth), but in D3D9Client there's no sign of the RMS shadow. Also, there's no sign of any specular reflections from the lights either, despite this should be the case as shown in the screenshot.

Just to be sure this had nothing to do with the environmental cams, I disabled those, so this is a pure as it gets.
 

Attachments

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
1,487
Reaction score
19
Points
38
@DaveS No, the local light sources (currently?!) do not cast shadows, sorry.
They only cast light cones ;)
 

Attachments

DaveS

Space Shuttle Ultra Project co-developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
8,769
Reaction score
31
Points
123

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
1,487
Reaction score
19
Points
38
That would definitely be a question for Jarmonik[1]



[1] or any other volunteer with knowledge of how these "Shaders" work :shrug:
 

jarmonik

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,104
Reaction score
61
Points
48
Website
users.kymp.net
OK, thanks for answer. How hard would be to implement? Along with the specular reflections?

The local lights sources do have two different modes (Partial, Full) the "Partial" lights won't cast specular reflections, this is sort of a low weight mode for laptops. The "Full" mode should cast specular reflections. If they don't then it might be related to "No specular reflectins in PBR mode" you reported later on. Is there a pre-build binary package for the SSU that could be used for debugging the specular issue ?


Implementing shadows for local lights isn't that difficult from source code point of view. But it's kinda performance heavy. So, let's say that shadow casing is limited to 2 or 4 local light sources (depending on settings) then which one ? How should the client know which lights should cast shadow ? Finding a solid answer to that question would make the case half solved.

---------- Post added at 14:17 ---------- Previous post was at 14:10 ----------

So the (probably dumb) question is: shouldn't the object that isn't in view not be rendered?

Of course, they shouldn't be rendered but it is very very difficult to detect (efficiently) if an object is obscured by on other one. Especially if texture transparency is taken in account. There would need to be some kind of low-poly mesh to help with visibility detection. This is unlikely going to happen. Too complex, too little benefits.
 

DaveS

Space Shuttle Ultra Project co-developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
8,769
Reaction score
31
Points
123
The local lights sources do have two different modes (Partial, Full) the "Partial" lights won't cast specular reflections, this is sort of a low weight mode for laptops. The "Full" mode should cast specular reflections. If they don't then it might be related to "No specular reflectins in PBR mode" you reported later on. Is there a pre-build binary package for the SSU that could be used for debugging the specular issue ?
Here you go: https://www.dropbox.com/s/p03i0psduchso3y/SSU_v5.0r3247.zip?dl=0, full package.
 
Top