New Release D3D9Client Development

Well, your log there still shows the CameraMFD.dll loading.

Odd, I did uncheck it. But here's what I get after ensuring that it is off:

Code:
**** Orbiter.log
Build Aug 30 2010 [v.100830]
Timer precision: 4.05195e-007 sec
Found 0 joystick(s)
Module AtlantisConfig.dll .... [Build 100830, API 100830]
Module AtmConfig.dll ......... [Build 100830, API 100830]
Module DGConfigurator.dll .... [Build 100830, API 100830]
Module D3D9Client.dll ........ [Build 130923, API 100830]
Module AeroBrakeMFD.dll ...... [Build ******, API 100830]
---------------------------------------------------------------
>>> WARNING: Obsolete API function used: oapiRegisterMFDMode
At least one active module is accessing an obsolete interface function.
Addons which rely on obsolete functions may not be compatible with
future versions of Orbiter.
---------------------------------------------------------------
Module AtmDataMFD.dll ........ [Build ******, API 060425]
Module DVToolsMFD.dll ........ [Build 120331, API 100830]
Module Lagrange.dll .......... [Build ******, API 060425]
Module LagrangeMFD.dll ....... [Build ******, API 060425]
Module Load.dll .............. [Build 110920, API 100830]
Module Map3DMFD.dll .......... [Build 101102, API 100830]
Module Telescope.dll ......... [Build 110413, API 100830]
Module OrbiterSound.dll ...... [Build 121120, API 100830]
Module ExtMFD.dll ............ [Build 100830, API 100830]
Module ScnEditor.dll ......... [Build 100830, API 100830]
Module transx.dll ............ [Build 100824, API 100823]

**** Creating simulation session
D3D9Client: [DirectX 9 Initialized]
D3D9Client: Sytem has XNA math support
D3D9Client:WARNING: [Hardware has only a limited non-power of 2 texture support]
D3D9Client: [3DDevice Initialized]
D3D9Client: [Compiling Effects for Shader Model 3.0]
D3D9Client: [Loading Stars]
D3D9Client: [Loading Constellations]
D3D9Client: [D3D9Client Initialized]
Module Sun.dll ............... [Build 100830, API 100830]
VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
Finished initialising world
Module IMS.dll ............... [Build 130413, API 100830]
Finished initialising status
Finished initialising camera
Finished initialising panels
Finished setting up render state
Base Object 0x1B67F8 = 'obj1' not cataloged
D3D9Client: [Scene Initialized]

and again with almost all of the plugins shut down:

Code:
**** Orbiter.log
Build Aug 30 2010 [v.100830]
Timer precision: 4.05195e-007 sec
Found 0 joystick(s)
Module AtlantisConfig.dll .... [Build 100830, API 100830]
Module AtmConfig.dll ......... [Build 100830, API 100830]
Module DGConfigurator.dll .... [Build 100830, API 100830]
Module D3D9Client.dll ........ [Build 130923, API 100830]
Module OrbiterSound.dll ...... [Build 121120, API 100830]
Module ScnEditor.dll ......... [Build 100830, API 100830]

**** Creating simulation session
D3D9Client: [DirectX 9 Initialized]
D3D9Client: Sytem has XNA math support
D3D9Client:WARNING: [Hardware has only a limited non-power of 2 texture support]
D3D9Client: [3DDevice Initialized]
D3D9Client: [Compiling Effects for Shader Model 3.0]
D3D9Client: [Loading Stars]
D3D9Client: [Loading Constellations]
D3D9Client: [D3D9Client Initialized]
Module Sun.dll ............... [Build 100830, API 100830]
VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
Finished initialising world
Module IMS.dll ............... [Build 130413, API 100830]
Finished initialising status
Finished initialising camera
Finished initialising panels
Finished setting up render state
Base Object 0x3037B0 = 'obj1' not cataloged
D3D9Client: [Scene Initialized]
 
Last edited:
And looky here, no error anymore.

Just to make sure that I ask this at some point: You did replace your D3D9Client.dll with the one in the patch, didn't you?
 
And looky here, no error anymore.

Just to make sure that I ask this at some point: You did replace your D3D9Client.dll with the one in the patch, didn't you?

Yes I did. Just for the record, what do you get when running D3D9 v12 & IMS without the IMS patch?
 
It depends. If you have a module with a classname of more than 62 characters, you get a crash at startup. You'll also get crashes when integrating anything after integrating a module with animations, although the behavior is not quite consistent without a debugger crashing it when it detects a heap corruption. So let's just say that all kinds of weird stuff can happen in that situation.
Anyways, this doesn't really belong here... :shifty:
 
It depends. If you have a module with a classname of more than 62 characters, you get a crash at startup. You'll also get crashes when integrating anything after integrating a module with animations, although the behavior is not quite consistent without a debugger crashing it when it detects a heap corruption. So let's just say that all kinds of weird stuff can happen in that situation.
Anyways, this doesn't really belong here... :shifty:

Agreed. Could you start a RC3 thread in the IMS group?
 
Hey guys, I've been getting a weird error lately and I don't understand what it means. Here is the log:
Code:
**** Orbiter.log
Build Aug 30 2010 [v.100830]
Timer precision: 4.46221e-007 sec
Found 1 joystick(s)
Module AtlantisConfig.dll .... [Build 100830, API 100830]
Module AtmConfig.dll ......... [Build 100830, API 100830]
Module DGConfigurator.dll .... [Build 100830, API 100830]
Module ScnEditor.dll ......... [Build 100830, API 100830]
Module D3D9Client.dll ........ [Build 130712, API 100830]
Module AeroBrakeMFD.dll ...... [Build ******, API 100830]
---------------------------------------------------------------
>>> WARNING: Obsolete API function used: oapiRegisterMFDMode
At least one active module is accessing an obsolete interface function.
Addons which rely on obsolete functions may not be compatible with
future versions of Orbiter.
---------------------------------------------------------------
Module BaseSyncMFD.dll ....... [Build 100616, API 100603]
Module BurnTimeCalculator.dll  [Build 110301, API 100830]
Module DVToolsMFD.dll ........ [Build 120331, API 100830]
Module IEATMFD.dll ........... [Build ******, API 060425]
Module InterMFD55.dll ........ [Build 100826, API 100704]
Module RendezvousMFD.dll ..... [Build ******, API 050206]
Module UnivPTG.dll ........... [Build 110305, API 100830]
Module OrbiterSound.dll ...... [Build 121120, API 100830]
Module HUDDrawer.dll ......... [Build 130423, API 100830]
Module LaunchMFD.dll ......... [Build 130525, API 100830]
Module transx.dll ............ [Build 110130, API 100830]

**** Creating simulation session
D3D9Client: [DirectX 9 Initialized]
D3D9Client: Sytem has XNA math support
D3D9Client: [3DDevice Initialized]
D3D9Client: [Compiling Effects for Shader Model 3.0]
D3D9Client: [Loading Stars]
D3D9Client: [Loading Constellations]
D3D9Client: [D3D9Client Initialized]
Joystick throttle: SLIDER 0
Joystick throttle control detected
Module Sun.dll ............... [Build 100830, API 100830]
VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
Module Mercury.dll ........... [Build 100830, API 100830]
VSOP87(B) Mercury: Precision 1e-005, Terms 167/7123
Module Venus.dll ............. [Build 100830, API 100830]
Module VenusAtm2006.dll ...... [Build 100830, API 100830]
VSOP87(B) Venus: Precision 1e-005, Terms 79/1710
Module Earth.dll ............. [Build 100830, API 100830]
Module EarthAtmJ71G.dll ...... [Build 100830, API 100830]
VSOP87(B) Earth: Precision 1e-008, Terms 2564/2564
BaseObject: Parse error
Module Moon.dll .............. [Build 100830, API 100830]
ELP82: Precision 1e-005, Terms 116/829
Module Mars.dll .............. [Build 100830, API 100830]
Module MarsAtm2006.dll ....... [Build 100830, API 100830]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
Module Phobos.dll ............ [Build ******, API 060425]
Module Deimos.dll ............ [Build ******, API 060425]
Module Galsat.dll ............ [Build 100217, API 100215]
Module Jupiter.dll ........... [Build 100830, API 100830]
VSOP87(B) Jupiter: Precision 1e-006, Terms 1624/3625
Module Io.dll ................ [Build 100217, API 100215]
Module Europa.dll ............ [Build 100217, API 100215]
Module Ganymede.dll .......... [Build 100217, API 100215]
Module Callisto.dll .......... [Build 100217, API 100215]
Module Satsat.dll ............ [Build 100215, API 100212]
Module Saturn.dll ............ [Build 100830, API 100830]
VSOP87(B) Saturn: Precision 1e-006, Terms 2904/6365
Module Mimas.dll ............. [Build 100215, API 100212]
SATSAT Mimas: Terms 113
Module Enceladus.dll ......... [Build 100215, API 100212]
SATSAT Enceladus: Terms 33
Module Tethys.dll ............ [Build 100215, API 100212]
SATSAT Tethys: Terms 101
Module Dione.dll ............. [Build 100215, API 100212]
SATSAT Dione: Terms 59
Module Rhea.dll .............. [Build 100215, API 100212]
SATSAT Rhea: Terms 68
Module Titan.dll ............. [Build 100215, API 100212]
SATSAT Titan: Terms 100
Module Iapetus.dll ........... [Build 100215, API 100212]
SATSAT Iapetus: Terms 605
Module Uranus.dll ............ [Build 100830, API 100830]
VSOP87(B) Uranus: Precision 1e-006, Terms 1827/5269
Module Miranda.dll ........... [Build ******, API 060425]
Module Ariel.dll ............. [Build ******, API 060425]
Module Umbriel.dll ........... [Build ******, API 060425]
Module Titania.dll ........... [Build ******, API 060425]
Module Oberon.dll ............ [Build ******, API 060425]
Module Neptune.dll ........... [Build 100830, API 100830]
VSOP87(B) Neptune: Precision 1e-006, Terms 391/2024
Finished initialising world
Module ISS.dll ............... [Build 100905, API 100830]
Module PMA.dll ............... [Build 100904, API 100830]
Module P6.dll ................ [Build 100904, API 100830]
Module SSRMS.dll ............. [Build 100905, API 100830]
Module MBS.dll ............... [Build 100904, API 100830]
Module CETA.dll .............. [Build 100902, API 100830]
Module Strela.dll ............ [Build 100904, API 100830]
Module APFR.dll .............. [Build 100902, API 100830]
Module ESP3.dll .............. [Build 100904, API 100830]
Module Unity.dll ............. [Build 100904, API 100830]
Module SouyzTMA.dll .......... [Build 100902, API 100830]
Module Progress_M1.dll ....... [Build 100902, API 100830]
Module UCGOCars.dll .......... [Build 121103, API 100830]
Module mpx.dll ............... [Build ******, API 060425]
---------------------------------------------------------------
>>> WARNING: Obsolete API function used: VESSEL::SetBankMomentScale
At least one active module is accessing an obsolete interface function.
Addons which rely on obsolete functions may not be compatible with
future versions of Orbiter.
---------------------------------------------------------------
Module mpxl.dll .............. [Build 101009, API 100830]
Module LPad.dll .............. [Build 110918, API 100830]
Module Spacecraft3.dll ....... [Build ******, API 060425]
Module Zarya.dll ............. [Build 100904, API 100830]
Module sdo.dll ............... [Build ******, API 060425]
Module multistage2.dll ....... [Build ******, API 050206]
Finished initialising status
Finished initialising camera
Finished initialising panels
Finished setting up render state
**** WARNING: Mesh not found: .\Meshes\.msh
**** WARNING: Mesh not found: .\Meshes\.msh
**** WARNING: Mesh not found: .\Meshes\.msh
**** WARNING: Mesh not found: .\Meshes\.msh
D3D9Client: [Scene Initialized]
Orbiter Version 100830
D3D9Client Build [Jul 12 2013]
Exception Code=0xC0000005, Address=0x77E5E3BE
EAX=0x00540054 EBX=0x0B51D4F8 ECX=0x02290000 EDX=0x0B51D4F8 ESI=0x53619FF6 EDI=0x0B51D4F0 EBP=0x009FF614 ESP=0x009FF5E0 EIP=0x77E5E3BE
C:\Windows\SysWOW64\ntdll.dll EntryPoint=0x00000000, Base=0x77E30000, Size=1572864
Exception in clbkRenderScene()
!!! Abnormal Program Termination !!!
 
I think I experienced the same with the Buran VC with working dials using LUA.
Those animations are added after everything is loaded and they crash the Client. Vanilla Orbiter works fine.

I've found a solution for this problem.

Add all the VC (separate mesh) mesh groups that are animated from LUA to the SC3 configuration as a single animation.

It makes no sense, since SC3 only animates the external mesh, and probably some of the groups will not even exist on it, but it doesn't crash.

A better solution would be the possibility of adding an "animation config" to the client, on a scenario/vessel basis, as a quick fix for this kind of situation. Another option would be to have the client read the LUA script and get the mesh groups from there.
 
Last edited:
It makes no sense, since SC3 only animates the external mesh, and probably some of the groups will not even exist on it, but it doesn't crash.

It makes perfect sense, because this way all animations are defined in one go, circumventing the problem I had to deal with in IMS.
 
But the meshes are diferent! Sure, adding all animations makes sense, adding all for mesh zero doesnt. Anyway, who cares ? I can now add working gauges to lots of spacecraft.. and that is cool!
 
Hey this is a semi random question. How would I use a bump map for a planet in this client?
 
Its a shame that work on the client has come to a halt, it has so many great features and Jarmo had more planned.

It really has made a massive difference to my orbiter experience and the amount of immersion the sim provides. :cheers:
 
A Vessel with a reflection map could not reflect any parts from the vessel it self. Unless we find some means to render the reflection maps for some specific mesh groups.

Actually, I've been thinking about this some time ago. What if we port the reflection map to mesh groups render? An "extra beautiful" option on the settings, disabled by default, that allow that? Maybe a tag in for the materials with the D3D9 Client Debug window ...
Because now, the default ISS lacks self-reflections, and the Thorton one that I'm experiencing some Normal/Reflection map work, has a cubemap activated for almost every part (easier to see bumps with) and I'm still at 180 FPS where I'd be at 190-200 normally. And on the best settings ;)
 
Actually, I've been thinking about this some time ago. What if we port the reflection map to mesh groups render? An "extra beautiful" option on the settings, disabled by default, that allow that? Maybe a tag in for the materials with the D3D9 Client Debug window ...
You can't have an environmental camera for every mesh group in a vessel because there are just too many of them. But it would be possible to define, lets say, 4 env-cams for every vessel and then bind the mesh-groups to a specific cameras. The default camera used by a mesh-group could be the closest one. This is already partially implemented.

Because now, the default ISS lacks self-reflections, and the Thorton one that I'm experiencing some Normal/Reflection map work, has a cubemap activated for almost every part...
That could be configuration issue as well. The ISS is made from a several vessels attached together. Each attachment has it's own environment (reflection) map. But all attachments are omitted from a camera view by default. However, docked vessels are not.

Let's have a small example with the XR2 with a reflective hull and the env-cam is located in a center of the vessel. The vessel it-self must be omitted from the camera view otherwise it would block the env-camera view for the reflections. But that's not enough, the cargo containers attached to a cargo bay must be omitted otherwise they would also block the env-camera view.

Default camera behavior can be overridden by using a camera configuration file located in /Config/GC/ [vessel_name]_ecam.cfg

Here is an example file AMSO_crew_EVA_ecam.cfg that will place the camera in the helmet.

PHP:
BEGIN_CAMERA 0
LPOS 0.0 0.85 0.0
END_CAMERA

Additional Params:
OMITATTC [id] // Omit an attachment of specified id. Only one 'id' per line, so, multiple lines may be needed.
OMITDOCK [id] // Omit a vessel docked in a specific dock port id
CLIPDIST [meters] // Camera near-plane clip radius (Omit everything inside the clip radius)
OMIT_ALL_ATTC // Omit all attachments
OMIT_ALL_DOCKS // Omit all docked vessels
DO_NOT_OMIT_FOCUS // Do not omit the focus vessel it-self

NOTE1: Most of these additional flags are never tested.
NOTE2: Only 1 camera index 0 is allowed at a moment.
 
Last edited:
I tested the ecam settings and they work great. Is there a way to make one meshgroup take precedence over another? Take a look at this screenshot:

Self_reflection.jpg


I want the PLB and PLB door meshgroups to fill in all of the reflection on the Ku band antenna but as you can see in the red rectangle, part of the reflection is the exterior and the main fuselage meshgroup. Is there a way to change this?
 
I want the PLB and PLB door meshgroups to fill in all of the reflection on the Ku band antenna but as you can see in the red rectangle, part of the reflection is the exterior and the main fuselage meshgroup. Is there a way to change this?
You would need a second camera for the antenna to make it work properly. Other possibility is to set the camera clip radius to 0.1 and lowering the camera further into the payload bay and probably closer to the antenna but other reflections could get worse after that. You can also debug reflections by looking at the reflection cube by using "Display env mapping" from the debug controls. It will display all 6 faces in a cross shaped form on a screen.
 
After getting "serious" again with Orbiter after a few months I noticed that I'm still running R11c. I never installed R12 until now.

Anyway, I just had to revert back to R11c because I still get the old flickering issue.

The posts describing the issue are just before the R12 release post here:
http://orbiter-forum.com/showthread.php?p=428712&postcount=2519
 
Anyway, I just had to revert back to R11c because I still get the old flickering issue.

Ah... so that's where the flickering is coming from. I've noticed it for months but didn't realize it was a problem in R12. I reverted back to R11c and the flickering is gone. (Why does it say Lights=0 in the bottom left though? And how do I turn that off?)

Is R13 on the way to resolve the flickering?
 
Here is a new build of the client for testing the lighting issue. I have no idea what's wrong with the local lights and I can't reproduce the problem and I can't find anything wrong from the code. So, if you could test the new build and see if it still produces the local lights problem.

If the problem is still present.
1) Then find D3D9Client.fx file from /Modules/D3D9Client/
2) Locate the following code section

PHP:
[...]
and replace it with this one

PHP:
[...]
After making the change, local lights won't work properly. (color and distance attenuation is gone) But does it remove the "black" artifacts from the local lights ?

There is also a frame rate limiter added. The first parameter in D3D9Client.cfg. Zero will disable the limiter, also a low values will produce a lot of tearing so a minimum practical value is about 200. (This is unrelated to the lighting issue)


I did some testing with this old fix in R12, only using it "partially".

This works:
PHP:
void LocalVertexLight(out float4 diff, out float4 spec, out float4 dir, in float3 nrmW, in float3 posW)
{
    float3 diffuse = 0;
    float3 specular = 0;
    float3 direction = 0;

    int i;
    for (i=0;i<gLightCount;i++) 
    {
        float  dist  = distance(posW,gLights[i].position);
        float3 relpW = normalize(posW-gLights[i].position);

        float att    = saturate(1.0f / (gLights[i].attenuation[0] + gLights[i].attenuation[1]*dist + gLights[i].attenuation[2]*dist*dist));
        float spt    = saturate((dot(relpW, gLights[i].direction)-gLights[i].param[Phi]) * gLights[i].param[Theta]);
        
        float d      = saturate(dot(-relpW, nrmW));
        float s      = pow(saturate(dot(reflect(relpW, nrmW), normalize(-posW))), gMtrl.specular.a);

        if (gMtrl.specular.a<2.0 || d==0) s = 0.0f;
        if (gLights[i].type==1) spt = 1.0f;         // Point light -> set spotlight factor to 1

        float dif = (att*spt);
        

        //diffuse   += gLights[i].diffuse.rgb * (dif * d);
        specular  += gLights[i].specular.rgb * (dif * s);
        
        float dif2 = 1.0;//



        diffuse   += float3(1,1,1) * (dif2 * d);//
        //specular  += float3(1,1,1) * (dif2 * s);//
        direction += relpW * (dif * d);
    }  
   
    diff = float4(1.5 - exp(-1.0*diffuse.rgb)*1.5, 0);
    spec = float4(1.5 - exp(-1.0*specular.rgb)*1.5, 0);
    dir  = float4(normalize(direction), 0);
}
But this has the black flicker:
PHP:
void LocalVertexLight(out float4 diff, out float4 spec, out float4 dir, in float3 nrmW, in float3 posW)
{
    float3 diffuse = 0;
    float3 specular = 0;
    float3 direction = 0;

    int i;
    for (i=0;i<gLightCount;i++) 
    {
        float  dist  = distance(posW,gLights[i].position);
        float3 relpW = normalize(posW-gLights[i].position);

        float att    = saturate(1.0f / (gLights[i].attenuation[0] + gLights[i].attenuation[1]*dist + gLights[i].attenuation[2]*dist*dist));
        float spt    = saturate((dot(relpW, gLights[i].direction)-gLights[i].param[Phi]) * gLights[i].param[Theta]);
        
        float d      = saturate(dot(-relpW, nrmW));
        float s      = pow(saturate(dot(reflect(relpW, nrmW), normalize(-posW))), gMtrl.specular.a);

        if (gMtrl.specular.a<2.0 || d==0) s = 0.0f;
        if (gLights[i].type==1) spt = 1.0f;         // Point light -> set spotlight factor to 1

        float dif = (att*spt);
        

        diffuse   += gLights[i].diffuse.rgb * (dif * d);
        //specular  += gLights[i].specular.rgb * (dif * s);
        
        float dif2 = 1.0;//



        //diffuse   += float3(1,1,1) * (dif2 * d);//
        specular  += float3(1,1,1) * (dif2 * s);//
        direction += relpW * (dif * d);
    }  
   
    diff = float4(1.5 - exp(-1.0*diffuse.rgb)*1.5, 0);
    spec = float4(1.5 - exp(-1.0*specular.rgb)*1.5, 0);
    dir  = float4(normalize(direction), 0);
}
So it obviously has to do something with "diffuse".

It would be great if someone with a compiler set up for this could rebuild R11c without the "Lights = %u" debug line.
 
I'm working on improving the sunrise/set colors to better match the real ones. I have however run into a problem. Is there a way to have different colors for this when items are inside the atmosphere and outside the atmosphere?

I have managed to get the colors pretty close for on-orbit sunrises/sunsets but it seems like the code that controls on-orbit color also controls in atmosphere colors.
 
Back
Top