Guys, I need a way to detect simple collision with walls. My map is pretty basic. All the floor is on the same height and I have very simple walls that I need to collide with.

Two ways come to mind and I'm wondering what's better.

1st - Put one camera watching my hero from above. Use this camera to render the depth values in front of the hero in another framebuffer. If the depth values in front of the hero are less than the depth value of some fragment from the hero, then there is a wall in front of him.

OR

2nd. Make AABBs for every wall. The problem with this is that every time there is a turn, I need to divide the wall into separate meshes and find the AABB for that mesh, because if the wall is like this:

(top view)

____

| |

___ | |

|_______ |

And I count these two rectangles as one mesh and find the min and max x,y,z of the two figures, the AABB is going to be this:

(top view)

________

| |

| |

|______ _|

And this is very inaccurate. That's why I have to make a new mesh every time the wall turns left or right.

What to choose?

I hope someone understood something from this very bad explanation. :lol:

Can you not just test collision between a box (your player) and triangles (your wall meshes).

I tend to use the fast triangle-box overlap test from Tomas Moller for things like this.

http://fileadmin.cs.lth.se/cs/Personal/Tomas_Akenine-Moller/code/tribox3.txt

There are other fast intersect tests here too such as tri-tri and ray-triangle.

http://fileadmin.cs.lth.se/cs/Personal/Tomas_Akenine-Moller/code/

If the reason you can't use an AABB for your walls is that the walls have corners in them - i.e. they are concave objects - you could split those walls into 2 convex walls, each with its own AABB.

And what do you think about the first option?

Sounds wrong to use the camera and the depth buffer to query for information that is surely already in the game engine.

Depending on your game design, you might be able to use a navigation mesh:

https://en.wikipedia.org/wiki/Navigation_mesh

This can greatly simplify and accelerate your collision detection, and allow path finding too.

Is this only for the character, or also for projectiles, etc? Are your walls always perpendicular to the ground? If so then you can do circle-vs-edge, since your problem would effectively be 2D. If your geometry is static then you can tessellate it into regions beforehand and skip the broad phase entirely, since each region will know exactly what walls are within reach.

Check out http://www.metanetsoftware.com/technique/tutorialA.html and http://www.metanetsoftware.com/technique/tutorialB.html to get some of the basics and gather a bit of vocabulary.

Guys, thanks a lot for getting me started. Will post later if there is some progress.

do you have an underlying map that tells you where to draw walls? or is it just a list of triangles / quads/ renderables?

almost every game i've done used an internal map (usually a 2d array) to represent the game world. it said where to draw the graphics and was also used for collision checks.

in my current project, not everything is a map. many of the maps are implemented as sparse matrices (IE a list), not 2d arrays. terrain chunks are just ordered lists of renderables. what i do is generate a 2d collision map at some desired resolution, and use that for collision checks.

it often turns out one data structure (such as 2d arrays) is best for fast collision checks, but some other type of data structure (such as renderables list - oct-tree, etc) is better for fast graphics.

so you keep two copies of the info, one in each type of data structure, and use the best data structure for the job at hand. data oriented design. how the data is used determines the best data structure for each task that uses the data. odds are different tasks (like rendering and collision checks) may have different "best" data structures (such as an ordered list of renderables for terrain chunks, and 2d collision maps).

while it may be less efficient from a memory use point of view, its WAY more efficient from a clock cycle use point of view.

Yes, I was about to say that if it's axis aligned and regular in shape an array would probably work.