New Release D3D9Client Development

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,877
Reaction score
2,869
Points
188
Website
github.com
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
611
Reaction score
52
Points
43
Location
Happy Wherever
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

  • 360.jpg
    360.jpg
    93.2 KB · Views: 31

JMW

Aspiring Addon Developer
Joined
Aug 5, 2008
Messages
611
Reaction score
52
Points
43
Location
Happy Wherever
Edit: Uploaded "Before" image
 

Attachments

  • D3D9 before.jpg
    D3D9 before.jpg
    97.3 KB · Views: 42

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,877
Reaction score
2,869
Points
188
Website
github.com
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,877
Reaction score
2,869
Points
188
Website
github.com
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

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
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

  • STS114_PLBD_closure.jpg
    STS114_PLBD_closure.jpg
    315 KB · Views: 23
  • STS114_PLBD_closure_D3D9Client.jpg
    STS114_PLBD_closure_D3D9Client.jpg
    218.8 KB · Views: 18

kuddel

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

Attachments

  • CurrentState.jpg
    CurrentState.jpg
    106.9 KB · Views: 21

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
That would definitely be a question for Jarmonik[1]



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

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Another shader bug I believe, no specular reflections in PBR mode:
 

Attachments

  • No_specular_reflections_D3D9Client_PBR_mode.jpg
    No_specular_reflections_D3D9Client_PBR_mode.jpg
    343.4 KB · Views: 32

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
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

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
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.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,877
Reaction score
2,869
Points
188
Website
github.com
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.

Thanks!
A couple a things I found in file gcConst.h:
line 495: nameless structs containing variables with same name
line 578: missing return
 

llarian

Well-known member
Joined
Apr 1, 2009
Messages
575
Reaction score
159
Points
58
Location
Ottawa
Mouse unavailable after loading ...

When I am setting up a session in orbiter-ng my mouse works fine. When I launch the mouse will respond to movement but mouse click on any selection is not recognized. Any idea what I did and how to get it back? Oh, yes in the parameters focus follows mouse is set.
 

4throck

Enthusiast !
Joined
Jun 19, 2008
Messages
3,502
Reaction score
1,008
Points
153
Location
Lisbon
Website
orbiterspaceport.blogspot.com
Implementing shadows for local lights isn't that difficult from source code point of view. But it's kinda performance heavy.

Since performance will depend on unknowns (number of lights, mesh complexity and CPU power) the only answer it to let the user decide. But it should be implemented for all lights of course.
So a "Compute local light shadows ON/Off" switch would do.
 

Trekkie

Starfleet Head of Ship Design
Addon Developer
Donator
Joined
Feb 6, 2016
Messages
350
Reaction score
89
Points
43
Location
Starfleet Ship Design Bureau
I was Testing my system in the D3d9Client, and i have Meshes that Play as Planets.. but in the D3D9 client they are not showing up.. anyone any Idea how to fix this?
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
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 ----------




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.

Since performance will depend on unknowns (number of lights, mesh complexity and CPU power) the only answer it to let the user decide. But it should be implemented for all lights of course.
So a "Compute local light shadows ON/Off" switch would do.
I agree with this option as it is an option seeing in many modern AAA games. Another shadow related bug is that what shadows are seen depends on what vessel is in focus. This is an old bug that I have reported earlier: https://www.orbiter-forum.com/showthread.php?p=579460&postcount=4566
 
Top