Thought Towards Concave Collision Detection

[Alpha Omega]

So I tried to write some Irrlicht code to detect collisions using triangles using the triangle selectors and such to detect collision for world geometries but for some reason it didn't really work because they way I implemented it only worked on concave objects I believe.

Anyway I trashed that code mainly because it was extremely inefficient and am now writing some code based on AABB and OBB boxes to test collision between world geometry. My thoughts are...

A) This will increase speed compared to using triangle selectors.
B) Will allow for easy development of 3d levels mainly CSS/Quake/FPS style
C) An editor to create maps can easily be made for this if needed.

The idea is mainly that each piece of the level is put into the mesh as an indepent mesh in the mesh buffer. When the map loads each piece of the map is either fit with an OBB or an AABB depending on what is needed. Then intersection tests using these methods can be used instead of using triangle based methods.

This should also eliminate the need to raycast as I believe currently that would have been needed for the triangle based method to determine height values of each plane.

Anyone have any suggestions on efficiency or robustness for this kind of method? Am I deceiving myself somehow?

[shadowslair]

May have misunderstood you somehow, but I`ve never heard of collision method that works for concave collisions only and not working for convex ones.

A) Maybe, but triangles give you the exact result (1:1 with the level mesh) where aabb/obb are very inaccurate. If you shoot towards a cylindrical column you can get your bullethole really far from the surface, floating in the air. Note that an OBB test/check alone will be always slower or in best case equally fast than with a triangle. The only benefit is that you may save some checks testing one obb, and not 12 trigs(worst case) for example.

B) True, editing will be easier, but will be efficient for simple box or slightly deformed box based worlds, which will be like the games from 1998, which I personally like, but not everybody likes.

C) An editor to create such maps may be created, but it won`t be that easy and not worth the effort.

Sorry for somehow discouraging you, but it`s only a friendly opinion and advice. If you wanna create something, it`s a good idea not to throw the selectors, but build your system to use and work with them, or you`ll lose a lot of time and effort to create something similar to your own .bsp (in best case) format.

[Alpha Omega]

Sorry I meant to say convex and I know that triangles can do the concave things like levels and such but when I implemented it it was just so slow using the irrlicht methods and didnt work that well so I scraped it for now. I want to understand how to do things with AABB's and then move to triangles for harder things.

I was thinking like the hammer editor. Levels will ONLY be made of AABB's or OBB's if only absolutely necessary. I just want to learn how to do stuff so thats why I am doing this. When I understand the simple things then I can move on to harder things.

[Mel]

Compose your levels using sets of planes which define closed spaces. That's exactly the way Hammer (and other Quake-style engines) work. Using bounding boxes would lead to a Tomb Raider like Engine

A "brush" (the hammer entities which build the levels) is really a set of intersecting planes. A box is a set of 6 planes, really. The intersections of the planes define the edges and the vertices of the meshes you want to render. They are convex meshes, but they can be more complex than simple boxes, and the intersection tests can be done faster than with triangles.

There is a bit of more maths involved, but that's how it is really done.

[Alpha Omega]

That is a very good idea Mel. Think about this much I will.