Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Feb 2009
Offline Last Active Nov 30 2014 02:25 PM

Posts I've Made

In Topic: Rotating camera around player origin

17 May 2012 - 11:04 PM

Do you need a 3rd person camera rotating around the player?

If so, I recommend you to use quaternions. It's much easier.

If not, can you describe what you want more clearly?

Btw, I don't recommend you to deal with LookAt and Eye vectors. You can define a world transform for your camera because it's quite easy to perform some transformations (translate, rotate etc.) over a world matrix. And when you need a view matrix, just take the inverse of this world matrix.

In Topic: Problem with shaders

09 April 2012 - 08:10 AM

I think your problem comes from depth output:
// Pixel shader output structure
struct PS_OUTPUT
		float4 Color[4] : COLOR0;
		float  Depth  : DEPTH;

PS_OUTPUT  ps_main (void)
	Out.color = blah;
	Out.Depth = 1.f;	//WHY THIS?

	return Out;

Why are you writing 1.f to DEPTH semantic output?

I think this will cause that all pixels' depth value would be 1.f; so everything would be invisible (according to your Z-Buffer config.).

Sorry, I didn't read your last sentence about you fixed it. Never mind :)


In Topic: Mesh collisions

06 April 2012 - 08:26 AM

Physics engines are not designed for a specific graphics library such as DX or GL. Their main goal is to make physical calculations and return final transformations of registered objects/primitives. And your job is to get that transformation data and use for your needs.

PhysX is the most popular physics engine. Now it became free for commercial and non-commercial applications. You can use it. The first important thing you must know about it is that the matrix structure of the engine is column-major but in it's row-major in DX.

On the other hand, Bullet is another popular engine. It's open source and developed by a Sony R&D employee. I know it's used in some animation movies like Toy Story.


In Topic: Question about occlusion culling

05 April 2012 - 11:34 PM

I think there's a good explanation about occlusion culling in GPU Gems 3. You can find it on nVidia's website; it's free to read.

Btw, I don't use occlusion culling. I don't know whether this will be helpful or not, but here's a list of what I'm doing:
1) Checking visibility: By using view frustum and bounding volumes. It's quite easy.
2) Filling Z-Buffer: First, setting ZWriteEnable to TRUE, ZEnable to TRUE and ZFunc to LESSEQUAL. Then I'm rendering the visible objects (returned from the prev. step) to only Z-Buffer (i.e. don't touch the front-buffer or any pixel) with a front-to-back order (Ordering is calculated in view space).
3) Rendering with Z-Culling: First, setting ZWriteEnable to FALSE, ZEnable to TRUE and ZFunct to EQUAL then rendering the objects.

This technique is called "Early Z Culling" and works well for forward renderers (like CryEngine 2 and Doom 3 Engines). With this technique, pixel shader won't be executed for invisible pixels (maybe invisible objects). I cannot say anything about performance comparison between occ. culling and this one; try and see.


In Topic: Mesh collisions

05 April 2012 - 11:19 PM

As dAND3h said, the cheapest way is to check bounding volume collisions. You can use either bounding box or bounding sphere according to the shape of your mesh. For example, a box would be best for a television and a sphere for a beach volleyball Posted Image


This wont work if you are rotating the meshes though.

Why? I think you're wrong. Because we can transform bounding boxes (AABBs) and check them for collisions.

F. Luna's book (Introduction to 3D Game Programming with DirectX 9.0c: A Shader Approach; this is available in Google Books) has a good explanation about bounding volumes: creation, transformation and checking.

I think the most accurate way is to create a low-poly version of your mesh manually (i.e. with a 3D modeling software) and send it to your physics engine. There're a lot of physics/collision engines around the net.