Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 Jan 2006
Offline Last Active Dec 18 2012 09:11 AM

Topics I've Started

Z-fighting ?

27 April 2009 - 07:51 AM

I am currently programming a simple 3D engine and currently I'm working on more "advanced" features such as terrain. Now here is the problem, I've just added a water plane and on the intersection between this plane and the hills from my terrain, bothering "jaggies" appear. I've put a screenshot. http://img232.imageshack.us/img232/6866/jaggies.jpg I thought it could be the pixel shaders (there are pixel shaders applied on both the terrain and the water), but after quick tests I came to the conclusion that it was not. I've tried also to replace the indexed primitive rendering used for the terrain by normal primitive rendering, and still got the same result. So, my conclusion is that it may be a z-fighting problem. Am I right ? It seems kind of logical because at the particular point where the water plane and the terrain slope meet, the pixels are at the exact same position. So if it is really z-fighting, is there any simple soluion in that case ? The only solution I found myself was to make a custom shape following (but not crossing) the shoreline for the water plane, but it adds alot of useless work and removes alot of freedom. Any thought ? Thanks !

Simle HLSL cubemap reflection

17 April 2009 - 09:25 AM

I recently started to play around with HLSL shaders. I'm currently trying to make real simple water, with bump mapping and cubempa reflection. Now my problem is with that actual cubemap reflection. The code is pretty simple, and for once I undertsand it all. However, it seems to procude strange results. I find it quite annoying because nobody seems to have problems and I do, and I just can't point the source. So I wondered if any of you pros could help me ;). I've put two screenshots to show the results. I apply the shader on a simple square made from 4 vertices with their normal upward (0, 1, 0). This screen shot shows how the cubemap projection on the plane just mess up when the camera is positionned according to particular angles. http://img21.imageshack.us/img21/6876/screen1tso.th.jpg The second one shows the main problem, it seems that something's wrong with the coords interpolation between the opposite corners. There is clearly (easier to see when its moving) a seem between the two triangles. http://img21.imageshack.us/img21/238/screen2uhk.th.jpg I've put the HLSL code here, you'll see that it's quite simple.
float4x4 WorldViewProj : WORLDVIEWPROJ;
float4x4 World : WORLD;
float ElapsedTime;
float3 Eye;

texture ReflectionTexture;

samplerCUBE ReflectionSampler : TEXUNIT3 = sampler_state
	Texture = (ReflectionTexture);

struct VS_IN
	float4 Position : POSITION;
	float3 Normal : NORMAL;
	float2 Texture : TEXCOORD0;

struct VS_OUT
	float4 Position : POSITION;
	float3 Texture0 : TEXCOORD0;

struct PS_OUT
	float4 Color : COLOR0;

VS_OUT vs_func(in VS_IN In)
	VS_OUT Out;

	Out.Position = mul(In.Position, WorldViewProj);

	float3 WorldPos = mul(In.Position, World).xyz;

	float3 WEye = mul(World, Eye);

	float3 V = normalize(WorldPos - Eye);

	float3 Normal = normalize(mul(World, In.Normal));
	Out.Texture0 = reflect(V, Normal);

	return Out;

PS_OUT ps_func(in VS_OUT In)
	PS_OUT Out;
	float4 color = texCUBE(ReflectionSampler, In.Texture0);

	Out.Color = color;
	return Out;

technique Technique0
	pass p0
		FogEnable = FALSE;
		Lighting = FALSE;

		Sampler[0]= (ReflectionSampler);
		VertexShader = compile vs_1_1 vs_func();
		PixelShader  = compile ps_2_0 ps_func();

Basically, I compute the view direction by substracting the eye position (camera position) from the vertex position, both in world space. I use this view direction along with the normal (which i'll recall is always (0,1,0)) to get a reflection vector which is actually used as my 3d coords for the cubemap. So, any idead why that wouldn't work ? P.S. : The cubemap has nothing to do with the skybox, it's normal :P [Edited by - GLForce on April 17, 2009 4:54:05 PM]

C++ strange line

12 January 2006 - 12:41 PM

I tought i knew C++ well, but after what ive seen and can just admit i'm wrong. I've followed a tutorial on collision (the collision part is not really revelent), and some line got me a headache. First, ive never seen such a syntax in C++, and this is from where comes my question. First, look a the code : //In the defines typedef unsigned int uint32; #define in(a) ((uint32&)a); //Somewhere in a bool function return (( in(z)& ~(in(x)|in(y)) ) & 0x80000000); Now, ok, is it C++ ? Because my compiler (VC++ 6) does not seem to undertsand anything about that. Is it a compiler specific syntax ? If it is not C++ or the syntaz is not correct, what do you undertsand of that and what should i do to make it work in VC++ 6 ? Thnaks

DirectInput, tilde key

11 January 2006 - 04:24 AM

Does someone know what is the code for the tilde key (~, the one commonly used to show console), for directinput keystate. Ive searched like crazy and never found it. Thanks.

FPS Weapon

09 January 2006 - 03:43 AM

This could be a general subject, but im searching for a precise answer in relation with DirectX. I'm currently working on a game engine and now im on the first person wepon part. You know the arm with a gun who always follow you everywhere ? So, that was hard to make it follow correctly the camera, but i finally did it. Now that this work, my problem is that the weapon get trough things. I thought that wasn't a problem since with collision the gun should never get trough walls, but to have a good size at the screen the weapon has to be big, and so the collision box could be strange. So, is there a way to say to directx to always draw the gun over the rest (but not over gui of course), or another solution ? thanks !