Usage of Collision Mesh for Games

Not sure what you mean with your first question, but the latter is definitely a matter of choice. In games like Little Big Planet I assume pretty much that the collisions are calculated with the actual drawn meshes, while in games like Need for Speed you rather use a set of a few boxes instead the complete car, since you don't need to check the curves for the trunk and stuff like that.

I'm developing a Beat'em Up. I'm not using the drawn meshes, but I'm creating a set of boxes for the hit zones on the characters; 3 for each leg [foot, lower leg, upper leg], 2 for torso [upper and lower], 3 for each arm [hand, under arm, upper arm] and 1 for head. I don't really care if the punch didn't hit because of 2 inches. Like I said, it's a matter of choice.

I'm speaking as an amateur, so might as well be that I'm completely mistaken ^.^

I'm not sure about other games but my game uses bones with custom shapes which I export to my mesh format. Once exported from the modeler the objects are ready to be used in game.

Hi YoYo,

Collsion Mesh is excactly what you are using for your Beat'em Up. It is a seperate mesh ( apart from you actual visible mesh ) that is used for determining collisions. It is suppose to be much cheaper, if it is implemented correctly, therefore having much less mesh than the rendered mesh.

But obviously as you say it would be a matter of choice, depending on how accurate you collision should be. A trade-off between performance and accuracy.

Where I first got the idea of creating( in your modeling program ) Collision Mesh, was in Chapter 12 of the book "Game Art: Creation, Direction, and Careers" by Riccard Linde.

Sorry you got me wrong. I know what collision meshes are, I just didn't get your first question. But now I get it I think.
Current games like Fallout 3 or GTA 4 don't use alternate collision meshes anymore, at least that's what I feel. Which is good of course, but older computers might get problems with that sometimes. Older games, like GTA San Andreas or...uhm...Giantz: Citizen Kabuto do use them. In fact, in order to be a good player, you have to consider such things the most, as they can be a real pain in the bottom. In Super Smash Bros Melée you were only able to catch items when you hit the A button in the correct frame when the collision mesh of the item hits the one from the character. Getting the wrong frame resulted in not so good results ;)

//EDIT

Making a collision mesh in the 3D modeling program is an option I didn't think of, but it seems much easier than my way of creating collision boxes by code xD haha. Thanks for the hint.

Quote:

Original post by YoYoFreakCJ Sorry you got me wrong. I know what collision meshes are, I just didn't get your first question. But now I get it I think. Current games like Fallout 3 or GTA 4 don't use alternate collision meshes anymore, at least that's what I feel.

Yes you interpretated it correctly :)

So you would say that the current games do not use an alternate mesh( Collision Mesh ) but uses the actual mesh that is rendered?

Well, that would make sense, since today's hardware is much faster.

Yep, that's what I'm saying.

Do you know of the game Clonk? It's a more or less primitive game of building a village and digging for minerals. The graphics are pretty basic sprites and it's only a 2D world, but the collisions are calculated per pixel. It makes perfect sense, because the rain simulation and using explosives makes the game feel much more real.
But in games like GTA 4, you don't actually have to use the complete car models, at least not for crashs. But well..if you manage to run GTA 4 on your computer at all, you don't care about this anymore I guess ;)
If you take anime games on the other hand, eg DBZ Budokai Tenkaichi, every hit creates a particle effect, so you won't recognize if the punch actually hit as lon as you see the shiny effects. Who cares about detailed collision meshes there? ;) That's also the same way I'm creating my game, since it's also using an anime style.

But here is another thought: how many collision detections does it take to make the cpu really suffer? Once you know that, you can also decide which method you want to use. [if you know any numbers, let me know ;)]

Well, besides performance, there is another reason why I would want to use Collision Mesh to test collisions, for my specific implementation.

I use a ray that I shoot from my "player"(FPS) in 4 directions to test if he collides with anything, and if he does, he can't move in that direction where the object is, but if I have 'n stair railing and the ray shoots over or between 2 railings, then the test indicates that the player does not collide with anything and he just walks right through the railings and falls off the stairs.

So if I have a collision mesh for the railings, enclosing the railing, it will test that it does in fact collide against the railing and not fall off the stairs.

Hope that makes sense.

On the performance issue. I currently do implement the collision testing with the actual mesh and there seems to be no noticible drop in frame rate. But unfortunately I dont have precise numbers now. I also do implement Collision Culling before I do the Collision Detection with an object.

I don't think current games use the same mesh, they may use it at some level, but it just doesn't make sence to brute force test thousands of polygons, at the very least you'd want to separate sections into groups (torso,arms, legs) and save group data into your mesh.

What I would do is create the proxy using bounding boxes for each bone, if pixel perfect collision is required then test the collision point (from a ray, assuming we're dealing with bullets) against an off screen rendered silhouette of the full model mesh.

Quote:

Original post by G-Man9566 I use a ray that I shoot from my "player"(FPS) in 4 directions to test if he collides with anything, and if he does, he can't move in that direction where the object is, but if I have 'n stair railing and the ray shoots over or between 2 railings, then the test indicates that the player does not collide with anything and he just walks right through the railings and falls off the stairs. So if I have a collision mesh for the railings, enclosing the railing, it will test that it does in fact collide against the railing and not fall off the stairs.

For that level of collision detection, you'd want to use a bounding box for the character, be it axis aligned or object oriented, you would use bounding box collision detection methods as well rather than just ray projection.

Quote:

Original post by Kwizatz For that level of collision detection, you'd want to use a bounding box for the character, be it axis aligned or object oriented, you would use bounding box collision detection methods as well rather than just ray projection.

Well, that sounds like a good idea to me. There is just one more reason I have why I want to use collision meshes. The current way I stay above "ground" or on top of objects (such as the floor or terrain etc.) is to project a ray downward and test for an intersection with an object in that direction. I then offset the player with y units above the closest object that was intersected (mostly the floor or terrain), there by "staying on top of things" ( I got this idea and the ray projection idea, to avoid walking through things, from "3D Game Engine Design", Eberly ).

The problem is when I walk up stairs the movement is jagged since each time a new step is "hit" the player is elevated to the new step height + y offset and this process is jagged or jumpy.

And this is where again my solution with the collision mesh would come in. If I create a collision mesh for the stairs that is basically a ramp, the player would move smoothly up the stairs.

Well this sounds to me like a good solution, obviously it will be more work for the 3D artist to make the collision mesh, which I think is the only disadvantage, but I'm not sure if it is the best solution.

What do you think?

Quote:

Original post by G-Man9566 What do you think?

Its a good solution, but not the best one, since as you said, gives more work to the level creator.

I do what Quake 3 does, that is trace the BB slightly over the actual height (about a step) over the movement vector, then down, this results in smooth movement when on stairs. Can't remember of the top of my head how exactly it was done, though that's basically the idea, to "simulate" steps a biped takes when walking.

Edit:

Ok, now I remember, basically you do two traces, the first one is the usual one to see if you can move to the next position, if you can't, then you trace again but this time you offset the height of the bounding box by the amount that you would consider "climbable", IE: say between 30 to 50 cm, and trace again, if you get past the first result, you move to the second instead of the first one, this works very well for both stairs and slopes.

If you have no idea about what I mean by tracing, take a look at Devmaster's tutorial on Quake 3 collision detection it deals with BSPs, but the ideas should work with any system that uses convex geometry as a basis for collision.

[Edited by - Kwizatz on January 7, 2009 9:01:31 AM]

Quote:

Original post by Kwizatz ... trace the BB slightly over the actual height (about a step) over the movement vector, then down, ...

Hi, I'm not exactly sure what you mean by this?

Quote:

Original post by G-Man9566 Quote: Original post by Kwizatz ... trace the BB slightly over the actual height (about a step) over the movement vector, then down, ... Hi, I'm not exactly sure what you mean by this?

I just updated the post to explain that [smile], basically if your up vector is 0,0,1 and you are moving your character from 0,0,0 to 10,10,0, tracing is testing if the bounding box collides with something on that trajectory, if it does, you trace again, but this time you offset the height, so instead of 0,0,0 to 10,10,0, you test from 0,0,15 to 10,10,15, 15 here being an arbitrary value.

IIRC GTA3 based games used simple shapes for cars, mainly spheres and more complex meshes for the other models. Each primitive can have their own material which are predefined by the engine.
I think thats a pretty good way of doing things =)

Cool Kwizatz.

That sounds like a very good way of doing it. It does make a lot of sense. I like the idea. Will try that one.

I also have now come to realise that the ray projection method to test for collisions make life much more diffucult. Even though it works, you get a few issues that you have to work around, using collision mesh (which is unnessesary time and effort).

Thanks for the discussion.

[Edited by - G-Man9566 on January 29, 2009 1:59:12 AM]

Quote:

Original post by Kwizatz Edit: Ok, now I remember, basically you do two traces, the first one is the usual one to see if you can move to the next position, if you can't, then you trace again but this time you offset the height of the bounding box by the amount that you would consider "climbable", IE: say between 30 to 50 cm, and trace again, if you get past the first result, you move to the second instead of the first one, this works very well for both stairs and slopes.

It was a few weeks since I posted on this thread, but I got to a cul de sac and need some help or suggestions.

For my First Person Camera I am now using a AABB type test to determine if I can move in a certain direction and over all it works ok. I am now at the point were I want to implement the above quoted part of the Collision Detection. To be able to climb up stairs and slopes etc.

The problem I have with implementing it as is suggested in the quote is that:

Say we have a stair case 3D model (modelled it in Max, and exported it to the X file format and imported it into my engine into a ID3DXMesh object), the stair case would have a BB that encompasses the entire staircase, so if I( the camera) comes near it, the camera would collide with it it not be able to move forward, even if you do retrace the direction(movement) vector a few units higher it still collides, cause the BB encompasses the entire stair case.

The only way I can currently see myself bypass this is if every step has its own BB, but then I will have to model and export every step seperately( or at least every step will have to be a seperate ID3DXMesh object). And that again gives more work to the 3D Modeller.

What can you suggest?

For situations like that could you not just when you collide with the bounding box for the stairs then test against the actual mesh, or if your stairs are detailed, test against a secondary bounding box - a low poly count version of your stairs.

Not sure if it's the best way, but would seem to get around your problem.

Quote:

Original post by p0is0n For situations like that could you not just when you collide with the bounding box for the stairs then test against the actual mesh, or if your stairs are detailed, test against a secondary bounding box - a low poly count version of your stairs. Not sure if it's the best way, but would seem to get around your problem.

Hi p0is0n,

thanks for your response, its appreciated, as the topic of the thread originally ask is that: do the main stream game/physics engines use "collision mesh"( the low poly count version you refered to)? So yes, that would get me around that problem, but that gives the modeller more "boring" work. But if that is the way most engines do it, then that is probably the best way to go.

Hand-crafting collision meshes can be tedious indeed. Having them being generated from the visual mesh is much easier. Several, if not many, modern-day games do so (although an artist should still be able to manually create collision meshes, for special cases or those where the tools can't get it right).

That, of course, requires you to create a tool that can do that, so there's a certain time-investment involved. Only worth it if you have a lot of modeling to do, imho.


You could also mix the several methods, picking the best (or easiest) option for each model individually. In some cases, the visual mesh will do fine. In other cases, a bounding box does all you need. And sometimes none of those gives a desirable result, so you'll have to create a collision mesh. It may not be optimal, but at least you won't have to create collision meshes for each and every model...

EDIT: p0is0n's suggestion is a good one. Cheapest tests first, more expensive tests later. If the cheap test fails, it saves you some expensive tests already. That's the whole idea behind space partitioning optimizations, too.