so i didn't use a height map to create my terrain cause I want to add buildings and whatnot and I also want the location of everything to be precisely the way it was made in the modeling program.

Question 1: Should I separate the terrain from my building models and other static models?

Question 2: How should I go about creating a collision with the ground? Should I parent my camera to a temporary model(to represent my character model) and try to detect collisions between the terrain and that model?

Question 3: How do i go about creating this collision with multiple floors(multistory buildings)? (what floor am I supposed to be on?)

Question 4: Physics? I may not use physics in this game if it is too hard to implement when the time comes but in future projects, it might be useful. I'm sure if I can get good information on the collision with my terrain, collision in the x, y, z vectors wont be an issue. The part I'm sure I'll end up snagged on is the rotation(yaw, pitch, roll).

I am making a FPS by the way. I know many frown on this idea for many have been made and most have failed epically. But, before I even start on this project, my first goal is to build a very basic physics engine. I know I can use some pre-made engine but the whole point of this project is to learn how to build it myself and not have unused code or such in my project.

In short, the answers I am looking for are links to good tutorials, code samples that have as many notes as lines of code, any suggestions, and anything you think that may be of help.

Thank you very much!
      ~Willshire~

In a typical simple game engine, you separate objects into "objects that collide as proxies (boxes/sphere/capsules/etc)" and "object that collide as meshes." Because general mesh/mesh intersection solutions are really hard and expensive, you typically make the rule that mesh objects don't move. Within that framework, what you need to develop is proxy/proxy collision functions (box/box, box/sphere, sphere/sphere, etc), and proxy/mesh collision functions (box/mesh, sphere/mesh, etc).

So, within this framework, for terrain, you load a mesh, and for your player, you create a sphere or a capsule. You then place the player in the world wherever it's supposed to be. Each time step, you move the sphere a little bit based on velocity, and then you run collision testing. If the sphere intersects with the mesh, you push the sphere out, and you adjust the sphere velocity to not go into the surface you collided with. For multiple stories, you simply build meshes with multiple stories, and sufficient clearance between floor and ceiling that the player will have lots of space to move around.

Mesh collisions generally are one-sided (you only collide if your velocity goes against the surface normal of the triangle), and they are generally thin -- once you're entirely through the mesh, you can't tell that you're "inside" the mesh. You will want to build a spatial index of the triangles in the mesh, to quickly find the triangles that may intersect each proxy object you collide against the mesh -- testing hundreds or thousands of triangles against a sphere will quickly deteriorate frame rates :-)

jwatte:

In a typical simple game engine, you separate objects into "objects that collide as proxies (boxes/sphere/capsules/etc)" and "object that collide as meshes." Because general mesh/mesh intersection solutions are really hard and expensive, you typically make the rule that mesh objects don't move. Within that framework, what you need to develop is proxy/proxy collision functions (box/box, box/sphere, sphere/sphere, etc), and proxy/mesh collision functions (box/mesh, sphere/mesh, etc).

So, within this framework, for terrain, you load a mesh, and for your player, you create a sphere or a capsule. You then place the player in the world wherever it's supposed to be. Each time step, you move the sphere a little bit based on velocity, and then you run collision testing. If the sphere intersects with the mesh, you push the sphere out, and you adjust the sphere velocity to not go into the surface you collided with. For multiple stories, you simply build meshes with multiple stories, and sufficient clearance between floor and ceiling that the player will have lots of space to move around.

Mesh collisions generally are one-sided (you only collide if your velocity goes against the surface normal of the triangle), and they are generally thin -- once you're entirely through the mesh, you can't tell that you're "inside" the mesh. You will want to build a spatial index of the triangles in the mesh, to quickly find the triangles that may intersect each proxy object you collide against the mesh -- testing hundreds or thousands of triangles against a sphere will quickly deteriorate frame rates :-)

I understood most of what you said here. I am going to go build my capsule to represent my character model and parent my camera to it. instead of being a true capsule though, it's going to be very low polygonal. I'm doing this to hopefully save my fps. I was wondering if you could give me any code samples/examples.

Willshire,

Question 1: Should I separate the terrain from my building models and other static models?

Ultimately, I believe all models should be treated the same and not be separated.  This is because you will want to be able to do the same things with all of them - such as standing on them.

Question 2: How should I go about creating a collision with the ground? Should I parent my camera to a temporary model(to represent my character model) and try to detect collisions between the terrain and that model?

Collision with the ground should be done between a bounding-sphere or bounding-box and the ground, rather than between the model and the ground.  I like using a sphere because it helps prevent the camera from ending up under-ground (when you are right next to a steep slope, for example).

You should do per-triangle collision with the ground if you want to do physics - this allows you to apply a force to your model based upon the slope (or normal) of the ground you are closest to (touching).

Question 3: How do i go about creating this collision with multiple floors(multistory buildings)? (what floor am I supposed to be on?)

This is solved automatically if you treat all objects as the same.  Standing on a floor is just the same as standing on the ground, on stairs, or on a box.

Question 4: Physics? I may not use physics in this game if it is too hard to implement when the time comes but in future projects, it might be useful. I'm sure if I can get good information on the collision with my terrain, collision in the x, y, z vectors wont be an issue. The part I'm sure I'll end up snagged on is the rotation(yaw, pitch, roll).

Simple physics are - well - simple.  If you know the normals of everything you touch, you just add those normals to your current velocity.  In XNA this is fairly straight-forward, since your velocity and location would be all be Vector3's and the normals are also Vector3's.  In a nutshell, you add your collision normals to your velocity and you add your velocity to your location:

       myVelocityVector3 += collisionNormalVector3;
       myLocationVector3 += myVelocityVector3;

We have been working on an interesting combination of RTS and RPG for about a year now in XNA.  A by-product of this effort was an infinite terrain! 

If you have any questions, please ask.  If you are interested in seeing some screen shots, check this out: Terra Infinitum

Regards,
-db

instead of being a true capsule though, it's going to be very low polygonal

A true capsule is a lot cheaper to test against a triangle mesh than even a single triangle! That's because a true capsule can be treated as a line-swept-sphere, or alternatively, as a thick line, or, more correctly, as the Minkowski sum of a line and a sphere.

If you read up on collision testing in Christer Ericssons great book "real time collision detection," you'll find the very elegant and simple math for intersecting a capsule/LSS with a triangle.

I decided to use a bounding sphere. not sure if it is the best idea but I am going for it for now. there's actually a few things I want to do at this point.

I want to make my bounding sphere visible when I run the game so I can be sure it fuctions properly and is the correct size and at the correct position.

I also want to display text on my screen to display specific information.

and I still need to detect collisions with my ground model...

any help will be greatly appreciated.

I totally got the whole text thing figured out! woot! now i just5 need to either find the depth of my terrain from my position or I need to always test for collision with a bounding sphere. it seems like it would be easier to find the depth at my x and z location and then do something else for wall collision... any thoughts or input would be greatly appreciated.