Quote:Original post by GMano

The way it is usually done in a game engine is that you do a broadphase collision tests first using bounding volumes of some sort, and only test tri/tri collisions when necessary, and when you do the tests you have (hopefully) narrowed it down to a manageable number of tris or convex polygons. Once it is known the bounding volumes collide, if more precise collision information is needed you do a narrowphase collision test using entire tris/polygons rather than vertices using various methods (separating axes, GJK, etc.) depending on the engines requirements.

What's a manageable number though? Any rule of thumb?

Quote:Original post by jyk
Even then, I imagine the narrow-phase tests are often performed using simplified geometry, such as a simplified version of the mesh or a proxy object composed of simpler primitives such as spheres, boxes, and capsules.

Okay, but do I have to experiment with a "target polycount" (whether original geometry or collision geometry) or can I assume that with a given algorithm I should aim at x polygon intersection test per narrow phase at most? Like 50 tris per colliding object?

A good rule of thumb for the latter would simplify things for me a good deal for me, of course.

Alex

Quote:Original post by ak-73
What's a manageable number though? Any rule of thumb?

This really is dependent on your engine, application, target hardware, etc. What is often done pre-process is that some sort of bounding tree structure is generated (quad/oct tree, k-d,bsp, etc.) and you can specify how many polys to allow in the leaf nodes of the tree, then empirically determine how many polys per leaf gives you the best performance.

In a usable engine, you will often find that you have to use several different techniques to do what you want. You may use raycasts for things like bullets, simple bounding proxies for objects like crates, barrells, rocks, etc., hierarchies of bounding proxies for characters, and some sort of space partitioning tree with sets of tris as leaves for the terrain. The right tool for the job to be done. It is up to you to determine what kind of accuracy you need for your collisions, and how much time/memory/cpu/gpu/etc. budget you have to do it.

Quote:Original post by GMano

Quote:Original post by ak-73
What's a manageable number though? Any rule of thumb?

This really is dependent on your engine, application, target hardware, etc. What is often done pre-process is that some sort of bounding tree structure is generated (quad/oct tree, k-d,bsp, etc.) and you can specify how many polys to allow in the leaf nodes of the tree, then empirically determine how many polys per leaf gives you the best performance.

In a usable engine, you will often find that you have to use several different techniques to do what you want. You may use raycasts for things like bullets, simple bounding proxies for objects like crates, barrells, rocks, etc., hierarchies of bounding proxies for characters, and some sort of space partitioning tree with sets of tris as leaves for the terrain. The right tool for the job to be done. It is up to you to determine what kind of accuracy you need for your collisions, and how much time/memory/cpu/gpu/etc. budget you have to do it.

Preprocess seems a bit overkill. I am writing a simple 3D space-shooter and I'd just like to implement basic but efficiently enough working collision detection to pick up some basic understanding of that issue at hand. After all I have yet to implement an enemy ai which I'd like to pour more time and energy into.

Right now I am planning to divide spaceship geometry into different vehicle parts first (these will be individually damageable, leading to a natural first division layer) and then, for the sake of simplicity to divide meshes with a too high polycount into submeshes by hand.

Any thoughts on that? Sensible approach, given the game I am trying to code?

Alex