Indoor 3D Collision Detection Help

Started by
5 comments, last by Hawkblood 7 years, 4 months ago

Hello reader,

I'm implementing a collision system and I'm lacking knowledge on how collisions are done with indoor levels that may have many platforms, pillars and walls. I'm not talking about actually detecting collisions with bounding volumes but more on how are bounding volumes setup. For example in this image of a level in doom I highlighted some of the different things that you would have to detected collisions against. Is the level (by level I do not mean props like that barrel) one mesh or is it broken down into big chunks that each have there own bounding volumes. Are walls just planes or AABB's, Is the ground just a large plane. Are all the platforms the player can walk on planes at different heights? I know there's lots of ways of doing it but what is a pretty generic (by that I mean common solution. not general purpose) way that most games like this would solve this problem. I have ideas on how to do it but maybe there's a better solution to just lots of planes and AABB's. So how are indoor level bounding volumes setup? How is the level broken down into 3D shapes that collision can be tested against.

Thanks.

[attachment=34124:doomhigh.png]

Advertisement

Bounding volumes are often generated alongside the graphical 3D model of the individual elements. If you're using a modern modeling app you should be able to find some functionality for it.

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

Often the collision shapes for a complex level like that are just a polygon soup -- a massive list of triangles.

To speed up collision checks against that list of triangles, you can organize them into a BVH or another hierarchical structure.

We used some kind of Quadtree like mechanisms for polygon based collision detection using a collision tree a few years ago. Maybe such systems like PhysiX use some other kind of polygon checks. But for performance and simplicity one should use as simple collision checks as possible so it dosent make sence for a box to be polygon collided rather than box collided or a barell uses a collision cone or sphere as same as some enmies could do

(Modern computers don't need to do this because of their speed unless the area is extremely large or the number of objects is huge) If the level is extremely large or there is a huge amount of collisions, you can break it up into evenly spaced 3D cells that you would only need to test objects within that cell. These cells could be any size, but would typically be small enough that you wouldn't have a large number of objects to test against. Start with bounding boxes or spheres for each object and only test poly collision if within/going through those bounds.

I think you just realized something. I know what you are thinking about. Don't you think their levels look blocky? Almost like a minecraft, but a fancy minecraft. I bet you got half of it. My theory is that this is just an artifact of level design with premade lego-like meshes.

Yes. That's correct. The only issue you will have is keeping track of what objects are in each box. This includes static objects and dynamic ones like physics objects and characters. Remember, some objects could be inside two or three or even more boxes if they are large enough. This wouldn't be a problem because you are still culling most objects in the level already.

This topic is closed to new replies.

Advertisement