Hi all,

I've managed to implement a skybox shader in my d3d engine, which functionally is 'OK'.

Never the less there are a few things I can't figure out yet.

Rendering order;

- I know render the skybox first thing each frame, with zbuffer and zwrite disabled, enabled after draw skybox

- after this I render the scene/ meshes

Clipping;

- when objects reach the far clipping plane, they are clipped inside the skybox.

This sounds logically but doesn't look ok. Here are 2 screenshots:

My questions;

1. would there be an advantage in rendering the skybox after the meshes/ last thing per frame?

I tried it out with zbuffer true and zwrite false. When scaling my skybox x15 (or so) this functionally works, but I don't see the advantage. Enlarging the skybox rather doesn't feel good.

2. what could I with the ugly clipping? I could change the far plane so objects or completely culled or not, instead of 'clipped'. Are make the far plane even farther so you won't notice that much (performance impact?).

Or maybe you have other ideas on this.

Here's the code of my draw skybox function and pseudo code of my renderframe function;

bool CD3dskybox::Render(D3DXVECTOR3 pPlayerPosition, CD3dcam *pCam, LPDIRECT3DDEVICE9 pD3ddev)
{
	mSkyBoxMesh.mWorldPos = mPlayerPosition;
	mSkyBoxMesh.UpdateWorldMatrix();
	D3DXVECTOR3ToFloat3(pPlayerPosition, mPlayerPosition);

	if(D3DERR_INVALIDCALL ==	mSkyBoxEffect->SetTechnique("SkyBoxShader")) return false;
	if(D3DERR_INVALIDCALL ==	mSkyBoxEffect->SetMatrix("ViewProj", &pCam->mMatViewProjection)) return false;
	if(D3DERR_INVALIDCALL ==	mSkyBoxEffect->SetFloatArray("CameraPosition", mPlayerPosition, 3)) return false;
	if(D3DERR_INVALIDCALL ==	mSkyBoxEffect->SetTexture("SkyBoxTexture", mSkyBoxTexture)) return false;
	if(D3DERR_INVALIDCALL ==	mSkyBoxEffect->SetMatrix("World", &mSkyBoxMesh.mMatWorld)) return false;
	if(D3D_OK !=				pD3ddev->SetStreamSource(0, mSkyBoxMesh.mVtxBuffer, 0, mSkyBoxMesh.mVtxSize)) return false;
	if(D3D_OK !=				pD3ddev->SetIndices(mSkyBoxMesh.mFaceBuffer)) return false;

	if(D3D_OK != pD3ddev->SetRenderState(D3DRS_ZENABLE, D3DZB_FALSE)) return false;
	if(D3D_OK != pD3ddev->SetRenderState(D3DRS_ZWRITEENABLE, FALSE)) return false;
	if(D3D_OK != pD3ddev->SetRenderState(D3DRS_CULLMODE, D3DCULL_CW)) return false;

	mSkyBoxEffect->Begin(&mNumPasses, 0); // D3DXFX_DONOTSAVESTATE);	
	for(unsigned int i=0;i<1;++i)
	{
		mSkyBoxEffect->BeginPass(i);
		mSkyBoxMesh.RenderAll(pD3ddev, LIST);
		mSkyBoxEffect->EndPass();
	}
	mSkyBoxEffect->End();

	if(D3D_OK != pD3ddev->SetRenderState(D3DRS_ZENABLE, D3DZB_TRUE)) return false;
	if(D3D_OK != pD3ddev->SetRenderState(D3DRS_ZWRITEENABLE, TRUE)) return false;
	if(D3D_OK != pD3ddev->SetRenderState(D3DRS_CULLMODE, D3DCULL_CCW)) return false;

	return true;
}

bool CD3d::RenderFrameV2(CD3dscene *pD3dscene, CD3dcam *pCam)
{
	if(!CheckDevice()) { mDeviceLost = true; return true; }
	mObjRendered = 0;	mAttrRendered = 0;
	
	pCam->Update();

	mD3ddev->Clear(0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, D3DCOLOR_XRGB(0, 0, 0), 1.0f, 0);
	mD3ddev->BeginScene();

	// SKY BOX; SHADER RENDERING
	if(pD3dscene->mSkyBoxInScene) 
		if(!pD3dscene->mSkyBox.Render(pCam->mPosition, pCam, mD3ddev)) return false;

	// WORLD MESHES; SHADER RENDERING
	for(ec=0;ec<pD3dscene->mNrEffects;++ec)
	{
		if(!SetVertexShader(pD3dscene, ec, "BasicShader", pCam)) return false;
		pD3dscene->mEffect[ec]->Begin(&pD3dscene->mEffectNumPasses[ec], 0); //D3DXFX_DONOTSAVESTATE);

		// loop through all materials, meshes and subobjects, drawprimitives etc.

		pD3dscene->mEffect[ec]->End();
	}
	// FFP rendering
	PrintSceneInfo(pCam, mObjRendered, mAttrRendered);		

	mD3ddev->EndScene();
	HRESULT hr = mD3ddev->Present(NULL, NULL, NULL, NULL); 

	return true;
}

Sorry; the screenshots:

www.sierracosworth.nl/gamedev/skybox_farlimit1.jpg

www.sierracosworth.nl/gamedev/skybox_farlimit2.jpg

1. No real advantage, no. Perhaps some marginal benefit from reduced overdraw, but I doubt that it's enough to be reflected in your framerate. However, if you render the skybox first, then you can perhaps use it as your z-clear by enabling z-write and disable z-test.

2. Your z-far looks unusually close to the camera by modern standards, I think most users would expect greater draw distances. So first up I'd increase it as much as possible. But then you're still going to have clipping somewhere, if it's still a problem then there's a few tricks to help reduce the impact:

- You could use fogging (although it can be tricky to blend convincingly to the skybox)

- You could add a bit more relief to your terrain, at the moment it's very flat which accentuates the draw distance cut-off.

- You could try the approach of artificially curving your terrain (your vertex shader would modify vertex positions based on distance from camera), so that your flat terrain gains a horizon. I've only seen this in very arcadey RPG games though, not sure if you can pull it off in your style.

- You could fade out the geometry into the skybox. It's tricky to alpha fade the world geometry without requiring lots of code to handle draw order, so the trick is to render your skybox last and somehow use the depth of the scene at a point to determine the opacity. There's a few ways to do this, but writing a 'skybox opacity' value into the frame buffer's alpha is the most straightforward.

Thanks both.

@Phantom; does this mean you would go for:

- clear (zbuffer and target)

- render all meshes/ scene

- disable zwrite only, keep ztesting true/ active

- render skybox

- enable zwrite

next frame same story.

This would mean I need to scale everything better then I do now :)

And having a skybox based on specific dimensions. If I understand correct, the dimensions of the skybox then will also influence the 'clipping' against the skybox instead of farplane.

Is this what you mean?

@Columbo; I will get into fogging soon to see what I can do with it regarding the 'clipping'.

As easy as what you said sounds "but writing a 'skybox opacity' value into the frame buffer's alpha is the most straightforward.", I have no idea what you mean with this :)

To make your sky geometry always appear to be at infinite depth, you can edit it's vertex shader so it outputs w as z.

e.g. right at the end, after computing the position: OUT.Position.z = OUT.Position.w;

@Columbo As Phantom said -- it's important to actually issue clear commands for the z-buffer on modern hardware. If you instead just clear it yourself by rendering distant objects, you'll basically be disabling the Hi-Z feature.

Great, that works and prevents me from having to scale the skybox * same factor as far clipping plane.

I now do the following:

- Clear zbuffer and target surface

- rending all my meshes using shaders

- render the skybox; disable zwrite, cullmode clockwise, draw, enable zwrite, cullcode ccw

- render sort off hud, scene statistics (lpd3dxfont), using ffp

- present

The scene is outdoor and my far plane is now 1000 (was 170). Doesn't seem to be that high, does it?

Not sure yet if I have an avantage in setting default renderstates after rendering the skybox in combination with D3DXFX_DONOTSAVESTATE with the effects/ shader rendering. If the default setting saving and setting renderstates by the 'effect' d3dx functions, is with say 30 renderstates and I set manually only about 5 to 10, then this might bring me something, or am I overseeing something?

@Hodgman; although it's working now without rescaling the skybox, don't exactly yet why. Can you explain what the 'w' position exactly contains and how's it's generated? (I don't use W for Z-buffering, at least I think, not setting it at least).

@Phantom; just played around abit with the near plane, I got it up till 4.65 (float) without messing up the rendering of the scene.

If I understand correcly, with 4.65 near and 750 far, there's less Z buffer 'capability' wasted in 0.0 up till 4.65, which is 'extra' and is now used from 4.65 to 750 (far).

Doesn't feel that much do, 4.65 instead of 1.0.

Any other options to 'trick things' and get near plane further without affecting visiblity?