Jump to content
  • Advertisement
Sign in to follow this  
ollyb342

FPS collision detection in a 3D town

This topic is 2989 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey guys,

I'll begin by explaining my intentions. I'm going to model a little 3D town that the user can navigate using an FPS style camera. the model will be exported in .x format.

My only experience with collision detection so far has been a little bit of AABB, and I don't think that this'll be sufficient for a "town" full of houses that have both interiors and exteriors that I'd like the camera to collide with.

Soooo basically what I'm asking is: What's the best approach to writing collision detection for a lot of intricate meshes?

My API is DX9 and my language is C++.

Another note (not directly related to DirectX I know, but still pertinent.) should I be programming each house in a seperate .X file and then putting it all together in code, or is it perfectly normal to model the ground plane and the houses all in one big .x file?

Thanks in advance for any help.

Ollie.

Share this post


Link to post
Share on other sites
Advertisement
Quote:

Soooo basically what I'm asking is: What's the best approach to writing collision detection for a lot of intricate meshes?

Export a simplified mesh (you can drop a LOT of the detail elements, and aproximate large areas with less poligons). Import that mesh into a physics engine like PhysX, Havok, ODE, or Bullet. Even if you don't use all the physics features, that will give you fast collision detection for ray and shape checks against your world.

Quote:

Another note (not directly related to DirectX I know, but still pertinent.) should I be programming each house in a seperate .X file and then putting it all together in code, or is it perfectly normal to model the ground plane and the houses all in one big .x file?

I wouldn't put anything together in code. Do all of this in data somewhere.
The most common approach is to model all unique items in individual files.

Then, the simplest approach to compose them would be to import all those objects into a new file, arrange them, and export it. That way you can make the most out of reusing your art assets. As long as nothing in the scene has to move, you are good.

The more time consuming, but professional, approach is to make a level editor that lets you export your own level format that contains model names, object types, and their 3d locations. You'd then use that level file to load and place the models at runtime. 3D tools like Maya or Blender let you write custom plugins and export scripts, allowing you to use them as your level editor if you want as well.

Share this post


Link to post
Share on other sites
I endorse what KuSeran said, particularly in regard to creating objects in small pieces.

X-files are convenient, but, if you use a collision/physics engine (as KuSeran mentioned), it's likely you'll want separate collision data and rendering data.

The collision data (again as KuSeran mentioned) can be much simpler than graphics data. A wall in a house may be made of many triangles for graphics reasons (pictures, windows, etc.). For collision purposes, a single quad for that wall may be sufficient (2 triangles).

As a much weaker alternative, if you have, for instance, separate meshes for each house (or even a single floor in a house), you can "shoot" a limited number of rays from your player's position and use D3DXIntersect. Culling meshes from the collision detection will be pretty easy since (most) houses are cubic and you'll only need to detect collisions for meshes that the player is "inside."

There are drastic limitations using a ray-shooting technique which you may very quickly get tired of. Consider one of the listed engines.

Share this post


Link to post
Share on other sites
Thankyou for the information regarding using a physics library for collision detection, I shall look into that.

However I'm slightly confused, when I said "put it all together in code" I meant import each .x file and specify their world positions manually, rather than just importing one single .x file which contains the entire modelled town.

Which approach would you suggest?

I'm afraid a level editor simply isn't viable for me at the minute, I'm battling with learning DirectX 9 and I'm trying to do everything as quickly and painlessly as possible at the minute!

Thanks for the reply man.

Ollie.

Share this post


Link to post
Share on other sites
Sorry Buckeye it looks like we posted at similar times,

Thanks for the information regarding keeping the mesh simple to speed up collision detection, I hadn't really thought of that!

I'll look into the engines =)

Thanks,

Ollie.

Share this post


Link to post
Share on other sites
Perhaps we were cross-posting. I think you definitely want to break up the town into pieces - a separate house per x-file or even more fine than that.

If you get into a physics engine, you (probably) won't be using the mesh buffers for collision detection. With separate pieces, you won't have to check collision detection with the entire town - perhaps just one house at a time.

Triangular mesh collision detection is the most "expensive" detection to do. So keep the number of faces in one collision object to a minimum.

EDIT: [wink] looks like we're back in sync.

EDIT2: you may want to use your "editor" in two phases - create a very blocky house, undecorated. Export that as the collision data. Then refine the house, adding textures, pictures, etc., export that and use it for the graphics.

Share this post


Link to post
Share on other sites
Ahh okey doke, that seems like a logical approach. each house can essentially be broken down into a bunch of quads for collision detection purposes then.

I've just registered for the PhysX SDK and I'm awaiting confirmation now. Is it reasonably simple to get cracking with?

Cheers,
Ollie.

Share this post


Link to post
Share on other sites
Quote:
each house can essentially be broken down into a bunch of quads for collision detection purposes then.

Triangles are fine. I'm not familiar with PhysX, but most collision/physics engine support collision objects such as a capsule (a cylinder with a half-sphere at either end) which works pretty well as a "player" object.

You can then do collision detection (or other geometry object of your choice) against each triangle in the objects you specify to be tested that frame. Obviously, fewer objects and fewer triangles tested each frame is desireable.

Share this post


Link to post
Share on other sites
Yeah that makes sense.

I guess the best way to learn it is just to get the SDK and try and get something colliding!

Thanks for all the help guys!


Ollie.

Share this post


Link to post
Share on other sites
Quote:

I've just registered for the PhysX SDK and I'm awaiting confirmation now. Is it reasonably simple to get cracking with?

Bullet is free to download, without waiting for any registration or anything. It supports triangle meshes (they are "slow" compared to the other collision shapes, but for your world mesh, that doesn't matter so much). It comes with a lot of samples, and it is fairly easy to get running. The "core" of it comes down to only a couple functions. The "complication" comes in how complex you want to make the object creation. Ragdolls take a lot of setup. A static house should only take a few lines (a btBvhTriangleMesh shape, a btRigidBody, and maybe a btMotionState.) And to get cracking with it, you can forgo the mesh collision on your first pass, and just use btBoxShapes for your houses, just to get a feel for the whole setup.

Quote:

I'm afraid a level editor simply isn't viable for me at the minute, I'm battling with learning DirectX 9 and I'm trying to do everything as quickly and painlessly as possible at the minute!

At the very least, I'd say put together a text file format that you load up for your level. Something simple like

mesh 0 model=tree.x collision=tree_col.obj
mesh 1 model=house.x collision=house_col.obj
object 0 mesh=1 pos=<5,5,5>
object 1 mesh=0 pos=<3,2,1>
object 2 mesh=0 pos=<3,3,3>

It makes things a LOT faster when you can just reload a text file, vs having to recompile your code to make a couple quick position changes. Expecially if you build your game with the idea of loading these on the fly. You then wouldn't even have to restart your game to make edits.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!