CollisionPolygon or CollisionBox?

Scripting Issues
1

Hello all,

I have not been able to find much about whether to use CollisionBox or CollisionPolygon for static (unmoving) terrain models like floors, ramps, walls, etc.

I’ve read that CollisionBox has some issues which have still not been fixed, but is that still true?

CollisionPolygon is supposed to be slow, but is there a real alternative for custom collision models? Like would CollisionBox be better to use for square-shaped collisions over CollisionPolygon because of the speed, or would the problems with the CollisionBox make it not worth it?

Which is more likely to result in “holes” in the collision geometry, like being able to clip through walls / fall through the floor where you shouldn’t?

Thank you very much for your time! Let me know if there is any more information I can provide.

2

Hmm… A lot depends on just what you intend to make, I think, both in terms of level-structure and gameplay mechanics.

If your levels can be reasonably represented by cubes–without doing so resulting in a ridiculous number of them–then using cubes might be a good idea.

On the other hand, if your levels are more complex than that; if you intend to have curves, or corners for which cubes would be troublesome, or suchlike, then polygons might be better.

As to their relative advantages and disadvantages:

Cubes are simple. They also have volume, making them more reliable than infinitely-thin polygons, especially for faster-moving objects. And finally, they’re likely to be a little less slow than polygons.

On the other hand, polygons are general: you can more-easily make varied shapes with them.

As to that slowness, however, unless you have a vast or hugely-complex level, I doubt that you’ll see all that much difference in the performance of polygons and cubes. Cubes are likely a little faster–but not so much that it’s likely worth worrying about unless you have reason to believe that it’ll be an issue in your specific circumstances.

As to “holes”, I would imagine that polygons will be more prone to that–but it’s possible to design a character-controller that accounts for this to a large degree, I think.

1 Like
3

Thanks again Thaumaturge, that’s some useful information. I’m glad that performance isn’t really that big of an issue. I suppose I’m overthinking.

As for the character controller designed to account for holes, what kinds of things would you do to ensure that the player doesn’t slip through the cracks as it were?

4

It’s my pleasure. :slight_smile:

That depends somewhat on what you intend to do, I think: a rapidly-moving first-person-shooter controller might be handled in a manner different to a slow-moving flying controller, for example.

So for example, if the player walks on a floor-surface, and there will never be any case in which there is one floor above another–no overhangs, bridges, rooms-above-rooms, etc.–then, if our floor-detection finds no surface, we can assume that we’ve encountered such an error–and simply re-use the floor-height from the last successful floor-detection.

On the other hand, if there might be floors above other floors, then you might instead check for sudden changes in the floor-height, and then use a secondary foot-collider to check for nearby floor-geometry, using the old floor-height if such nearby geometry is found.

But on the other hand, if the player is simply flying around at a fairly low speed, then you might be able to just represent them as a reasonably-sized sphere: since it has volume, and presuming that you don’t make it too small, it shouldn’t slip through gaps between polygons.

And if you have objects that move very quickly, you might consider representing small objects (e.g. projectiles) simply as line-segments, and for larger ones using the technique described on this page.

So in the end, I suppose that the question becomes: what sort of character-controller are you making?

5

Ah, of course – I’m making a first-person game (not really an FPS, more of an action-adventure / RPG the likes of King’s Field or Elder Scrolls). You generally start off moving pretty slowly, but there may be some very fast characters in the end-game. I will try to limit that since high speeds can be game-breaking in a game which is balanced around a certain character speed, but I do want the player to be rewarded in satisfying ways, one of which should be movement speed. But, I digress.

The character controller’s collision type was also of concern to me. I thought that I’d use a collisionCapsule sort of like Unity tends to use, but I read in the documentation that the capsule is not very good to use as a “from” object like the player. But I decided I will probably use two or more spheres to represent the player – at least one for the head, and one for the torso. Then I use a raycast to check for floor collisions at the player’s feet. So far it seems to be working, anyway, but I’m not sure if this is a good solution especially for collisions with walls and other terrain.

For the actual collision geometry I figured I would create one model for the visual representation, and another simplified model that could serve at the collision geometry, which would be created after the visual model. So like a corridor with an archway and little decorative pieces coming out of the walls would be simplified to just four polygons for the walls, floor and ceiling, and maybe a collisionBox for the archway. So with the way I’m designing my models, the geometry will be perfectly flush together, like there won’t be any natural gaps in the geometry – I’m not sure if that matters for the avoidance of holes.

There will be floors above floors. But I’m afraid I’m not quite sure what you mean by the following:

you might instead check for sudden changes in the floor-height, and then use a secondary foot-collider to check for nearby floor-geometry, using the old floor-height if such nearby geometry is found.

Wouldn’t this interfere with falling off ledges when intended by the player? Or even accidentally falling over the edge on a precarious cliffside? Or am I misunderstanding?

About the fluid methods – I’m already using the FluidPos method on the character controller just in case, although I don’t think they will ever need it. When I used Unity I turned on a similar feature for the character controller by default so it’s a habit. But for fast moving projectiles that would be definitely something to remember to do, for sure.

Thanks again! :slight_smile: you are very helpful.

6

Ah, fair enough–that’s useful information, I think. :slight_smile:

That’s a pretty good approach, I think, and probably a not-uncommon one. (My own character controllers tend to be much like that, in fact.)

Also a good idea, and indeed, I believe that it’s the the usual approach to building collision geometry.

Indeed, it looks to me like you have things largely sorted out! :slight_smile: Have you had any issues with the character falling through the floor or tunneling through walls?

To some degree–but remember that a player viewing a game from a first-person perspective will tend to have far less awareness of their foot-placement than in the physical world, or even in a third-person game. Thus it makes sense, I find, to provide a bit of a grace-buffer against falling being too easy.

Basically, it means that going off the edge of the cliff when done intentionally calls for a decisive action, and when done unintentionally feels a bit more fair, I think.

1 Like
7

player viewing a game from a first-person perspective will tend to have far less awareness of their foot-placement than in the physical world, or even in a third-person game. Thus it makes sense, I find, to provide a bit of a grace-buffer against falling being too easy.

Ah, I see what you mean. Actually, I think my character controller should be able to deal with this just by the fact of the ray checking for floor collisions while the main body collisionSphere is floating above that. So I imagine a player falling off a ledge would be feasibly able to turn around rapidly and “catch” themselves by the sphere colliding with the side of the platform and the momentum carrying them upward. I will do some tests to verify.

Have you had any issues with the character falling through the floor or tunneling through walls?

No, I am just thinking ahead :smiley: when I heard that the polygons were inefficient and could cause players to slip through collision geometry I just figured I’d try to see if there was a better way. But, I think you’ve given me enough information to make a good decision and/or from which to continue my research, so thanks yet again!

Indeed, it looks to me like you have things largely sorted out! :slight_smile:

Well, that’s good to hear, because I’m just doing what makes sense to me, and really have no idea what I’m doing. I’ve never even really made a serious 3d game before, though I’ve dabbled. So it’s just all very new to me. Thanks for being so prompt and helpful, not just to me, but to all the newcomers here.

Edit: out of curiosity, what kind of “secondary foot checker” would you use for checking for floor collisions? Like would you use another sphere? There’s no cylinder collider, huh?

8

It’s important to note that polygons are infinitely thin. Boxes are not: they have a volume. If an object slips through a polygon somehow, it’s on the other side. If it slips into a box on the other hand, Panda will continue to be able to detect that it’s inside, and push it out.

If your level geometry can always trivially be represented by boxes, they are always the better choice. If your level geometry is arbitrary, go with polygons.

1 Like
9

Hmm… That might work, but it might also feel a little off-putting to players to have to catch themselves due to a minor slip like that. (While still allowing poor footing beyond the scope of that grace-buffer to fairly catch out the unwary player.)

But do test it, indeed–if you find that it works, and your players like it, then fair enough!

If you’re using Panda’s collision system, then a sphere might be a good choice, indeed. In my own main project, I’m using Bullet and have a cylindrical foot-detector, if I recall correctly.

It’s very much my pleasure! I’m glad if I’ve been of service. :slight_smile:

1 Like