New Release D3D9Client Development

[n122vu]

I downloaded them also, where do I place the extracted files ?

I just created a folder called DXTemp and extracted them there. I then went into DXTemp and ran DXSetup.exe.

 

[DaveS]

Quick Q on particle streams in D3D9Client: Does it respect the difference between DIFFUSE and EMISSIVE? I ran a test and to me it appears it doesn't. It appears to be only using EMISSIVE and even though the PS has been set in the code to DIFFUSE, nothing changes.

 

[Donamy]

does it use a mesh ?

 

[DaveS]

does it use a mesh ?

How do you mean? It's a standard particle stream, nothing special about it.

 

[Donamy]

Or is it it a sprite or something in the code ?

 

[DaveS]

Or is it it a sprite or something in the code ?

As I wrote, it's a standard particle stream. There's absolutely nothing special about it. It's just that D3D9Client doesn't seem to recognize the DIFFUSE setting. It seems to be locked in to EMISSIVE. I tried the same scenario in the inline D3D7 (orbiter.exe) and it properly recognizes the DIFFUSE setting.

    // RCS exhaust
    RCS_Exhaust_tex = oapiRegisterExhaustTexture ("SSU\\Exhaust_atrcs");
    SURFHANDLE RCS_tex = oapiRegisterParticleTexture("SSU\\ps-rcs2");
    RCS_PSSpec.srcsize=0.1;
    RCS_PSSpec.srcrate=800;
    RCS_PSSpec.v0=60;//100
    RCS_PSSpec.srcspread=0;
    RCS_PSSpec.lifetime=0.2;
    RCS_PSSpec.growthrate=20;
    RCS_PSSpec.atmslowdown=5;
    RCS_PSSpec.ltype=PARTICLESTREAMSPEC::DIFFUSE;
    RCS_PSSpec.levelmap=PARTICLESTREAMSPEC::LVL_FLAT;
    RCS_PSSpec.lmin=1;
    RCS_PSSpec.atmsmap=PARTICLESTREAMSPEC::ATM_FLAT;
    RCS_PSSpec.amin=1;
    RCS_PSSpec.tex=RCS_tex;

 

[jarmonik]

What exactly should be the difference between emissive and diffuse particles ?

Here is the shader "Particle.fx" responsible of rendering the particles and it looks like a diffuse and emissive particles are almost identical.

// ==============================================================
// Part of the ORBITER VISUALISATION PROJECT (OVP)
// Dual licensed under GPL v3 and LGPL v3
// Copyright (C) 2012 - 2014 Jarmo Nikkanen
// ==============================================================

struct EPVERTEX {                          
    float3 posL     : POSITION0;
    float2 tex0     : TEXCOORD0;
};

struct ParticleVS
{
    float4 posH     : POSITION0;
    float2 tex0     : TEXCOORD0;
    float  light    : TEXCOORD1;
};

ParticleVS ParticleDiffuseVS(NTVERTEX vrt)
{
	ParticleVS outVS = (ParticleVS)0;
	outVS.tex0    = vrt.tex0;
    outVS.light   = saturate(dot(-gSun.direction, vrt.nrmL)) + 0.6f;
	outVS.posH    = mul(float4(vrt.posL, 1.0f), gVP);
    return outVS;
}

ParticleVS ParticleEmissiveVS(EPVERTEX vrt)
{
	ParticleVS outVS = (ParticleVS)0;
	outVS.tex0   = vrt.tex0;
	outVS.posH   = mul(float4(vrt.posL, 1.0f), gVP);
    return outVS;
}



// ---------------------------------------------------------------------------------------------
// gMix is the particle opacity computed from time and halflife
// gColor is hardcoded to [1,1,1] in exhaust streams and [1, 0.7, 0.5] in reentry streams
// frg.light is a sun light intensity level illuminating a particles. Light color is [1,1,1]
// ---------------------------------------------------------------------------------------------


float4 ParticleDiffusePS(ParticleVS frg) : COLOR
{
    float4 color = tex2D(WrapS, frg.tex0);
    return float4(color.rgb*frg.light, color.a*gMix);  
}

float4 ParticleEmissivePS(ParticleVS frg) : COLOR
{
    float4 color = tex2D(WrapS, frg.tex0);
    return float4(color.rgb*gColor.rgb, color.a*gMix);
}

float4 ParticleShadowPS(ParticleVS frg) : COLOR
{
    float4 color = tex2D(WrapS, frg.tex0);
    return float4(0,0,0,color.a*gMix);
}



technique ParticleDiffuseTech
{
    pass P0
    {
        vertexShader = compile VS_MOD ParticleDiffuseVS();
        pixelShader  = compile PS_MOD ParticleDiffusePS();

        AlphaBlendEnable = true;
        BlendOp = Add;
        ZEnable = true; 
        SrcBlend = SrcAlpha;
        DestBlend = InvSrcAlpha;    
        ZWriteEnable = false;
    }
}


technique ParticleEmissiveTech
{
    pass P0
    {
        vertexShader = compile VS_MOD ParticleEmissiveVS();
        pixelShader  = compile PS_MOD ParticleEmissivePS();

        AlphaBlendEnable = true;
        BlendOp = Add;
        ZEnable = true; 
        SrcBlend = SrcAlpha;
        DestBlend = InvSrcAlpha;    
        ZWriteEnable = false;
    }

	// ---------------------------------------------------------------------------------------------
	// Ground shadows are rendered only for DIFFUSE particles
	// Shadow rendering is defined here because of identical vertex declarations [EPVERTEX]
	// ---------------------------------------------------------------------------------------------
    pass P1
    {
        vertexShader = compile VS_MOD ParticleEmissiveVS();
        pixelShader  = compile PS_MOD ParticleShadowPS();

        AlphaBlendEnable = true;
        BlendOp = Add;
        ZEnable = true; 
        SrcBlend = SrcAlpha;
        DestBlend = InvSrcAlpha;    
        ZWriteEnable = false;
    }
}

Of course, you can make a small test to see if a DIFFUSE and EMISSIVE particles are directed to a correct shader code: That should verify if the flag in a particle structure is handled correctly.

float4 ParticleDiffusePS(ParticleVS frg) : COLOR
{
    return float4(1,0,0,1);  //Red particles
}

float4 ParticleEmissivePS(ParticleVS frg) : COLOR
{
    return float4(0,1,0,1);  //Green particles
}

 

[DaveS]

What exactly should be the difference between emissive and diffuse particles ?

Well, emissive should behave like a mesh with a emissive material, IE glow. Diffuse should be the the opposite, shaded and affected by shadows.

---------- Post added at 10:49 PM ---------- Previous post was at 10:40 PM ----------

If I were to describe exhaust plumes like the ones generated by conventional RCS thrusters, I would describe them as conical in shape and two main properties, partial translucency and light reflective. This image from the L-1 RCS Hotfire during STS-95 shows what I am describing.

The blue arrows point to the specular reflections caused by the sun while the red arrows point to the main plume.

This video of Soyuz shows of plumes behave on-orbit:
http://www.youtube.com/watch?feature=player_detailpage&v=wBZSxrqnTFg#t=124

https://www.dropbox.com/s/m5fc66o2zf44ppj/RCS_exhaust.jpg?dl=0

 

[kuddel]

Hi there,
before we get lost in discussions about "what is a DIFFUSE or EMISSIVE particle" let's get
back to the original issue.
I see that in the D3D9 (C++) code those different particle types are handled different, so I think this is handled there (or at least it should be )
And as jarmonik pointed out, the *visual* difference is almost not present ("almost identical").
So: One can 'model' a good looking EMISSIVE particle-shader. ...I can't :/
Is the difference in D3D7 better? Or worse?

 

[DaveS]

The difference in D3D7 is much better as you can tell the difference very clearly.

 

[jarmonik]

Which one doesn't work correctly compared to D3D7, Diffuse or Emissive ?

It is currently known that diffuse particles aren't effected by planet shadow in D3D9, could that be the source of the problem ?

Are the diffuse exhausts too bright ?

---------- Post added at 02:32 ---------- Previous post was at 01:38 ----------

Hi Kuddel,

We have some code section like this in the P1 branch:

#ifdef OAPI_BETA
		if (pBltGrpTgt) {
			if (CheckBltGroup(src,tgt)) SURFACE(pBltGrpTgt)->AddQueue(SURFACE(src), &rs, &rt);
			else 						SURFACE(tgt)->CopyRect(SURFACE(src), &rs, &rt, flag);
		}
		else SURFACE(tgt)->CopyRect(SURFACE(src), &rs, &rt, flag);
#else
		SURFACE(tgt)->CopyRect(SURFACE(src), &rs, &rt, flag);
#endif

Should we simplify the code by removing the Beta related code sections from P1 branch or keep them ?

 

[DaveS]

Which one doesn't work correctly compared to D3D7, Diffuse or Emissive ?

It is currently known that diffuse particles aren't effected by planet shadow in D3D9, could that be the source of the problem ?

Are the diffuse exhausts too bright ?

Here's a comparison. D3D7 inline on the left, D3D9Client R14 on the right. It's the diffuse that's the problem, it seems to be way too bright and glowing like the emissive setting.

 

[mjanicki]

I just noticed something unexpected with the latest R14 when running Orbiter under Wine:

Enabling Anti-aliasing (4x) in Launchpad -> Video -> Advanced page causes loss of graphics in MFDs but only for some vessels. Even more interesting, MFDs displayed correctly when using the 'stock' 2d panel (the one that displays just the MFDs) or when using a full 3d Virtual Cockpit. However, when using a graphical 2d panel, the MFD buttons would display the correct button information but the MFD screens remained blank for all MFDs tested.

R12 didn't have this problem that I was ever aware of. I found that setting Anti-aliasing to "none" in R14 allows the MFDs to display in all of the vessel and panel configurations I tried.

Again, this is under Wine so for all I know it would be a Wine video thing. At any rate, I'm using the latest DirectX on a laptop that has an Intel HD Graphic 4000 onboard video card with the i915 chipset.

-- Mike

 

[kuddel]

[...]
Should we simplify the code by removing the Beta related code sections from P1 branch or keep them ?

I think we should remove it. It's called the P1 branch, so it's clearly not for BETA
----- [edit] ----
Sorry for beeing pro-active :
Done in revision 35587 (branch 2010-P1)
Done in revision 35588 (trunk)

 

[Blue_hypergiant]

Hi all,

I´ve tried the D3d9 for the first time, it´s great, and I thank so much to the people who develop this addons for our sim, you´re the best:thumbup:, but I have a small issue, all the ships textures are now blurred, in every single one (default or downloaded), even in the virtual cockpit, also the runway textures and some more.

In the standar Orbiter they look like this:

But when I start the Orbiter_NG, and activate the D3D9 client, they appear like this:

Sorry if this was aked before, but I read a lot of pages in this thread and search on the rest of the forum but I couldn´t find a solution.

I have Orbiter 2010 P1 and D3D9Client R14, I also tried the R10, but I have the same problem, Is there a way to fix it? Thank you very much.

 

[jarmonik]

I have committed a code the CodePlex that will test a few experimental interfaces:

1. Custom Camera Interface: Allows to render a custom camera views into a surfaces/textures.
2. Client Interface API: That will allow user applications to interact with a custom features provided by graphics clients.

I made a small test application called "DockingCameraMFD" to test the interfaces. There are a few minor issues detected so-far:

1. Intellisence doesn't seem to be working.
2. Functions doesn't allow default parameters.

Any thoughts/suggestions ?

EDIT: Unpack in OrbiterSDK/Samples/

EDIT2: OGCI.* files would be normally located in OrbiterSDK/include/ and distributed with a client. Now they are included in a zip for review or preview.

 

[jarmonik]

But when I start the Orbiter_NG, and activate the D3D9 client, they appear like this:

I don't recall seeing anything like that before. It's difficult to start guessing what could be wrong or causing the problem. It's likely a hardware related somehow. Right now, there's nothing I can do about it. If the problem occurs in more than one computer with DirectX 9.0c hardware then we would need to look into it.

Runways do look a little blurred because the client doesn't know what kind of filter it should use for the texture.

---------- Post added at 10:17 ---------- Previous post was at 07:44 ----------

I noticed a problem in the sketchpad and I would need some help tracking it down.

If you choose Video->Advanced and from a Sketchpad Settings "GDI Only" do the MFDs render correctly with R13 or R14 under Orbiter2010-P1 ?

My current working copy and the head revision seem to have major problem with fonts.

Here's a little dummy question about the TortoiseSVN. How can I compare a file from my working copy to some older revision ? Not the head revision.

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

BTW, what's the story behind Beta 1+2 and Beta 3 branches ?

 

[kuddel]

Here's a little dummy question about the TortoiseSVN. How can I compare a file from my working copy to some older revision ? Not the head revision.

Easy:
1. "Show log" context menu on file
2. "Compare with working copy" @ the revision you would like to
compare with.

Side-Note: In "Log" you can also compare two revisions by 'multi selection'
(select two revisions via CTRL-Key and the context menu offers you
"Compare revisions")

BTW, what's the story behind Beta 1+2 and Beta 3 branches ?

Just to check whether I can/should back-port some of the 'new' (trunk) features to older BETAs.
...this was a PM questioned by Ripley, so I thought: give it a try...

Version|Release date
Orbiter2010-P1|100830
Orbiter BETA (1)|111105
Orbiter BETA (2)|121103
Orbiter BETA (3)|130101
Orbiter2014 BETA Rev. 8|140602

Nothin' to do for you. It would be my job (if I continue to do so )
The trunk is the main work-site!

Ah BTW: I would like to delete the 'R13.1'-branch (it got there by accident anyway
and should have been a tag...).
Any problems with that?

/Kuddel

---------- Post added at 13:06 ---------- Previous post was at 11:56 ----------

2. Functions doesn't allow default parameters.

Any thoughts/suggestions ?

What do you mean with that?
Have you put the default arguments in the declaration or in the definition?
It's always best to put #em into the declaration (header file), cause that is
the only way that the caller can 'see' what's possible.
(You can put it into the definition, but it's better to always put them into the declaration)

If however it doesn't work because of some 'DLL_IMPORT'/'DLL_EXPORT' thing:
Have you tried 'overloading' instead? Like:

  // default arguments:
  int foo (int bar, int baz = 0);
  // overloading:
  int foo (int bar);
  int foo (int bar, int baz);

/Kuddel

 

[jarmonik]

Easy:
1. "Show log" context menu on file
2. "Compare with working copy" @ the revision you would like to
compare with.

Thanks, I didn't realize it was under Show Log.


Here is the function in question:

typedef void (__cdecl *_ogciSketchBltEx)(oapi::Sketchpad *pSkp, SURFHANDLE hSrc, LPRECT s, LPRECT t, float alpha = -1, VECTOR3 *color=NULL);

Produces an error related to default parameters.

---------- Post added at 14:59 ---------- Previous post was at 14:54 ----------

Any problems with that?

No, go ahead.

 

[kuddel]

T
Here is the function in question:

typedef void (__cdecl *_ogciSketchBltEx)(oapi::Sketchpad *pSkp, SURFHANDLE hSrc, LPRECT s, LPRECT t, float alpha = -1, VECTOR3 *color=NULL);

Produces an error related to default parameters.

As far as I can see this is because you do a type definition here (typedef).
Types cannot have default parameters, functions / methods can.
You might need to split this into:
- A function declaration (with default parameters)
- and a typedef for convenient use (without default parameters)

(Note however that I have not tried this, so my 'solution' might not work in real life )

/Kuddel

---------- Post added at 21:04 ---------- Previous post was at 20:50 ----------

After some test and further insight I have to correct a little:
The problem is, that you are defining a function-pointer via (__cdecl...) and those cannot have default parameter values.
By the way: What exactly are you trying to accomplish?
A header that can be used in MFD- / Addon-Development, right?
Then you might take a look at others that have done this (like OrbiterSound or similar).
I'll take a look at this once I find some more time (christmas shopping terror, you know )