New Release D3D9Client Development

[jarmonik]

Still somehow the number of missing symbols got greatly reduced with kuddel's build. Now I get only this:

Those link errors appear because the gcAPI.lib is compiled with newer version of VC++ and some of the C library functions are missing.

What errors does the original build have (the lib distributed with the client) ?
What version of VC you have ?

I just compiled some of my test apps with VC2008 and VC2015 without errors. It could be compiler configuration issue.

Edit: Do you have VC2008 runtimes installed ? (There's something odd since the runtimes should be statically linked in the gcAPI.lib)

 

[Enjo]

I looked into the Sketchpad2 header and I think you're right on both points now. Indeed, I use an antique VC2005, because of wanting to keep backward compatibility, but this does not apply to Topographic Map MFD. I will switch the project to VC2015 and let you know.

Could you please point me to your example apps, if they're public?

 

[jarmonik]

Could you please point me to your example apps, if they're public?

Here's the only one of them that actually does something. http://www.orbiter-forum.com/showthread.php?t=37171

 

[SolarLiner]

Tried to implement the Lens Flare I talked about earlier as a second screen space post-processing effect. I did so by creating an ImageProcessing pFlare and trying to copy as close as I could the code of pLightBlur; but without any luck.

LensFlare.hlsl + diff patch in the zip file for anyone interested.

 

[DaveS]

Any progress on this I which reported earlier:

The sunrise/sunset effects in the beta version are still a bit off. There's just too much yellow. This video tweeted by Jeff Williams a few hours ago shows things really well: https://twitter.com/Astro_Jeff/status/731071859211440134

 

[jarmonik]

Tried to implement the Lens Flare I talked about earlier as a second screen space post-processing effect. I did so by creating an ImageProcessing pFlare and trying to copy as close as I could the code of pLightBlur; but without any luck.

#define ORB_FLARE_COUNT 6;

Extra semicolon here.

BackBuffer = D3DFMT_R8G8B8;

This may not work. Try D3DFMT_X8R8G8B8 instead.

D3DXVECTOR3 sunPos = D3DXVECTOR3(0.0, 0.0, 0.0);
pFlare->SetFloat("vLightPos", &sunPos, sizeof(D3DXVECTOR3));

The world in a graphics clients is camera centric. Sun isn't in the origin the camera is.

D3DMATRIX worldProjMatrix = pDevice->ProjectionMatrix;
pFlare->SetFloat("WorldProjMatrix", &worldProjMatrix, sizeof(D3DMATRIX));

This is non-sense. I have no idea what pDevice->ProjectionMatrix does. Likely a fixed function stuff. Try:
pFlare->SetFloat("WorldProjMatrix", GetProjectionViewMatrix(), sizeof(D3DXMATRIX));

Is the tBack initialized ? I am not seeing pFlare->SetTextureNative("tBack", ptgBuffer[GBUF_COLOR], IPF_LINEAR | IPF_CLAMP) call in the diff.

---------- Post added at 14:04 ---------- Previous post was at 13:57 ----------

HR(D3DXCreateTexture(pDevice, viewW / BufSize, viewH / BufSize, 1, D3DUSAGE_RENDERTARGET, BackBuffer, D3DPOOL_DEFAULT, &ptgBuffer[GBUF_COLOR]));

This shouldn't be divided by BufSize.

---------- Post added at 14:05 ---------- Previous post was at 14:04 ----------

Could you zip and post your copy of Scene.cpp

---------- Post added at 14:16 ---------- Previous post was at 14:05 ----------

Any progress on this I which reported earlier:

No progress. The color should be pretty close at-least with the settings I have. The atmospheric model should be redesigned so that it would use a color lookup from a textures which would give more control over the colors.

Since the current model isn't totally broken, it's not on a top of the todo - list.

 

[kuddel]

Hi jarmo,
I've added some more love to the 'multiline' annotations during my lunch-break (mainly r706).
The TextBox method still doesn't respect the given box sizes for wrapping, but at least it honors any line-breaks ("\r\n")

But during quick look over D3DPad class I saw several other places, where the len parameter of string handling methods is not taken into account. I think this will bite us sooner or later.

 

[SolarLiner]

Extra semicolon here.
(snip)

Good catch! Otherwise, this is what happens when I, with limited knowledge in graphics, come to try this :lol:

I thought that the star in the solar system was defined at the center of the world, hence the origin vector; but also mainly as a placeholder.

And tBack isn't even initialized indeed, but it wouldn't have been because pFlare->IsOK() returns false anyway. The problem is in pDevice->CreateRenderTarget() which doesn't return S_OK (the log prints "Creation of Offscreen render target failed (LensFlare)"). So I guess I'm missing something here.

 

[jarmonik]

But during quick look over D3DPad class I saw several other places, where the len parameter of string handling methods is not taken into account. I think this will bite us sooner or later.

Ok, I'll try to fix that issue.

---------- Post added at 16:04 ---------- Previous post was at 15:41 ----------

The problem is in pDevice->CreateRenderTarget() which doesn't return S_OK (the log prints "Creation of Offscreen render target failed (LensFlare)"). So I guess I'm missing something here.

There's no need to create the backbuffer or any other color buffers twice.

This should work (not tested):

if (Config->PostProcess) {

		pLightBlur = new ImageProcessing(pDevice, "Modules/D3D9Client/LightBlur.hlsl", "PSMain");
		pFlare = new ImageProcessing(pDevice, "Modules/D3D9Client/LensFlare.hlsl", "PSMain");

		int BufSize = pLightBlur->FindDefine("BufferDivider");
		int BufFmt = pLightBlur->FindDefine("BufferFormat");

		D3DFORMAT BackBuffer = D3DFMT_A2R10G10B10;
		if (BufFmt == 1) BackBuffer = D3DFMT_A16B16G16R16F;

		LPDIRECT3DSURFACE9 pBack = gc->GetBackBuffer();
		D3DSURFACE_DESC desc;
		pBack->GetDesc(&desc);

		if (pDevice->CreateRenderTarget(viewW, viewH, BackBuffer, desc.MultiSampleType, desc.MultiSampleQuality, false, &pOffscreenTarget, NULL) == S_OK) {
			HR(D3DXCreateTextureFromFileA(pDevice, "Textures/D3D9Noise.dds", &pTextures[TEX_NOISE]));
			HR(D3DXCreateTextureFromFileA(pDevice, "Textures/D3D9CLUT.dds", &pTextures[TEX_CLUT]));
			HR(D3DXCreateTexture(pDevice, viewW, viewH, 1, D3DUSAGE_RENDERTARGET, BackBuffer, D3DPOOL_DEFAULT, &ptgBuffer[GBUF_COLOR]));
			HR(D3DXCreateTexture(pDevice, viewW / BufSize, viewH / BufSize, 1, D3DUSAGE_RENDERTARGET, D3DFMT_A2R10G10B10, D3DPOOL_DEFAULT, &ptgBuffer[GBUF_BLUR]));
			HR(D3DXCreateTexture(pDevice, viewW / BufSize, viewH / BufSize, 1, D3DUSAGE_RENDERTARGET, D3DFMT_A2R10G10B10, D3DPOOL_DEFAULT, &ptgBuffer[GBUF_TEMP]));
		}
		else {
			LogErr("Creation of Offscreen render target failed (LensBlur)");
			SAFE_DELETE(pLightBlur);
			SAFE_DELETE(pFlare);
		}
	}

One problem that remains is that how to combine the results from pLightBlur and pFlare in the actual backbuffer. But it's not an issue right now. (pFlare would need to work first). Currently pFlare will replace/overwrite the results from pLightBlur.

 

[SolarLiner]

IT WORKS! :woohoo:

... at least partially. The shader works, now I have to make it follow the sun.
But it is working, that is something!

 

[SolarLiner]

Oh hey, didn't see your post before mine. (That means I got it working by myself, which is already an achievement!)
I'll implement your changes to see, because the CreateTexture is indeed redundant.

---------- Post added at 13:20 ---------- Previous post was at 13:13 ----------

I got the lens flare to follow the sun... though not quite. Looks like it follows the movement of the camera, but it isn't tied to the sun position.

---------- Post added at 13:27 ---------- Previous post was at 13:20 ----------

Here's the section that ties the data to the shader; given how badly I had done it the first time, maybe I didn't do better this time:

if (pFlare->IsOK())
{
	OBJHANDLE hSun = oapiGetObjectByName("Sun");
	VECTOR3 sunPos = _V(0, 0, 0);
	oapiGetGlobalPos(hSun, &sunPos);

	pDevice->StretchRect(pOffscreenTarget, NULL, psgBuffer[GBUF_COLOR], NULL, D3DTEXF_POINT);
	pFlare->SetTextureNative("tBack", ptgBuffer[GBUF_COLOR], IPF_LINEAR | IPF_CLAMP);

	pFlare->SetBool("bObstructed", false); // TODO: Check sunlight obstruction

	D3DXVECTOR3 sun = D3DXVEC(sunPos);
	pFlare->SetFloat("vLightPos", &sun, sizeof(D3DXVECTOR3));

	pFlare->SetFloat("WorldProjMatrix", GetProjectionViewMatrix(), sizeof(D3DMATRIX));

	D3DXVECTOR2 res = D3DXVECTOR2(float(colr.Width), float(colr.Height));
	pFlare->SetFloat("vResolution", &res, sizeof(D3DXVECTOR2));

	float len = float(length(sunPos));
	pFlare->SetFloat("fSize", &len, sizeof(float));

	float brightness = 1.0f; //TODO: Implement brightness config
	pFlare->SetFloat("fBrightness", &brightness, sizeof(float));

	// -------------------------
	pFlare->SetOutputNative(0, gc->GetBackBuffer());

	if (!pFlare->Execute()) LogErr("pFlare Execute Failed");
}

(Note that fSize and fBrightness don't have any effect yet).

 

[jarmonik]

This isn't correct:

  OBJHANDLE hSun = oapiGetObjectByName("Sun");
    VECTOR3 sunPos = _V(0, 0, 0);
    oapiGetGlobalPos(hSun, &sunPos);

    pDevice->StretchRect(pOffscreenTarget, NULL, psgBuffer[GBUF_COLOR], NULL, D3DTEXF_POINT);
    pFlare->SetTextureNative("tBack", ptgBuffer[GBUF_COLOR], IPF_LINEAR | IPF_CLAMP);

Need to subtract GetCameraGPos() to make is camera centric.

VECTOR3 sunPos = _V(0, 0, 0);
oapiGetGlobalPos(hSun, &sunPos);
sunPos -= GetCameraGPos(); // sunPos relative to camera

 

[SolarLiner]

That, with some correction on the shader, makes for a working, customizable, lens flare shader!

I also added vLightColor in the hope that I could get the diffuse color the sun emits, so that it would also "red-shift". Lastly we need to test for the sun being occluded or not. That coul either be done via ray-tracing (from the code and through bOstructed) or depth-checking (from the shader through a depth sampler and check).
Also the lens flare seems to also be happening in the opposite direction the sun is at. And there, I have no idea why.

The lens flares also scales according to the distance from the light source:

(Left to right: on Mercury, Earth, and Io)

 

[SolarLiner]

Lens Flare occlusion works for planets, using the code used for the light color calculation on models. It works, but it has to cycle through and calculate for all bodies, which added an additional 18 ms to the frame rendering. I thought vPlanet.bOmit would do the planet selection for me but apparently every planet is being omitted at the time it gets called, so right now it calculates through (literally) every body.
https://gfycat.com/PopularPoisedAfricangoldencat

The thing is, this results in a purple lens flare at sunrise/sunset, which is more than weird.

 

[GLS]

Small "issue": D3D9 shows the text 1px above (i.e. with a 1px smaller y coordinate) when compared with GDI. I'm using the skp->Text() and the TextOutA() functions in Sketchpad and GDI respectively. But when comparing text of SurfaceMFD, in MOGE vs D3D9, there seems to be no difference (I didn't check all the text). GDI problem?

 

[jarmonik]

Small "issue": D3D9 shows the text 1px above (i.e. with a 1px smaller y coordinate) when compared with GDI. I'm using the skp->Text() and the TextOutA() functions in Sketchpad and GDI respectively. But when comparing text of SurfaceMFD, in MOGE vs D3D9, there seems to be no difference (I didn't check all the text). GDI problem?

I have no idea what's going on. Do you use SetOrigin() by any chance ? Or maybe SurfaceMFD is using it, I'll check it out.

 

[GLS]

I have no idea what's going on. Do you use SetOrigin() by any chance ? Or maybe SurfaceMFD is using it, I'll check it out.

Nop, in MOGE I start by getting the DC from skp->GetDC() and then it's nothing but SetTextColor(), SelectObject(), MoveToEx() and LineTo(), Rectangle() and TextOut(), and in D3D9 it's the equivalant Sketchpad functions.
I just checked with another font (Courier) to make sure it wasn't my new font, and the difference still appears...
Thanks!

 

[SolarLiner]

I got the two shaders to work with one another, simply by making them use both gc->GetBackBuffer() as targets.
I deleted the code for shifting the lens flare color as it took too much time, leaving the Lens Flare to shine through everything.
Thus, I disabled the billboard rendering of the star - but that made me think about the possibility of using that texture to keep the customization in place instead of using the procedurally generated glare. But that will bring back the possible drawbacks of using a texture - the seams in particular.

 

[Matias Saibene]

That, with some correction on the shader, makes for a working, customizable, lens flare shader!

I also added vLightColor in the hope that I could get the diffuse color the sun emits, so that it would also "red-shift". Lastly we need to test for the sun being occluded or not. That coul either be done via ray-tracing (from the code and through bOstructed) or depth-checking (from the shader through a depth sampler and check).
Also the lens flare seems to also be happening in the opposite direction the sun is at. And there, I have no idea why.

The lens flares also scales according to the distance from the light source:

(Left to right: on Mercury, Earth, and Io)

The J. J. Abrams add-on?
:thumbup::thumbup::thumbup:

 

[SolarLiner]

Not the "Star Trek: Into Darkness" edition :lol:

I've been working on getting every piece of emiting light source up to "HDR standards" by bringing their intensities above 1 to compensate for the tonemapping, along with the atmosphere. CLUT color correction and bloom are also functional, but disabled since I need to get them right.