FPS collision detection in a 3D town

Started by
9 comments, last by Atrix256 13 years, 9 months ago
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.
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.
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.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

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.
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.
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.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

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.
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.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

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.
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.objmesh 1 model=house.x  collision=house_col.objobject 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.

This topic is closed to new replies.

Advertisement