Collision Detection

[RustyNail]

How would go about implementing it?
I don't need to be told about the different algorithms and stuff, just how one would go implementing it.
This question came to me when my screen was capable of showing a skybox and Sydney in all her 198-frame glory (199?), inside a bounding box.
Voila!
Pwetty. Very. but it's getting boring.
I have an XML file to hold my scene. but I have no way of editing it other than by hand... 1. How hard would it be to write an exporting script for irrEdit, and 2. Is there any other program like irrEdit that works on Linux?

And back to the main question:
My teacher gave me several choices on how to procede:
1. Go after the way Cube did it, but in a simpler way, aka - larger cubes, having all angles be 90degress and stuff. and use a 2D grid for collisions... or 3D if i am going to have stairs and stuff.
2. have a quasi-2D world, like Wolfenstein... of course, i'd have make a sausage-like test for each wall... and then when I collide with 2.. or even 3 walls... o.0 My math skills fail me.
3. And then i could do it like In Descent -> a pwetty world, and right-angle clipping boxes, against which collisions are done...
4. the good old collide against everything... but then I still have the problem of colliding against multiple things....
Any suggestions?

[JP]

You do realise that irrlicht can do collision detection for you right....?

Although it's not perfect and is fairly buggy in some cases it may be enough for your project, if not then you can just use a physics engine and it'll handle it all nicely for you.

Or are you required to do the collision detection yourself rather than relying on a library? If so then you could look at how Irrlicht implements it to get ideas on how to do your own.

[rogerborg]

I don't need to be told about the different algorithms and stuff, just how one would go implementing it.

You implement it with "algorithms and stuff".

I kind of zoned out after reading that. Perhaps you could read the fine tutorials.

[RustyNail]

I would have been using Irrlicht's collision detection...IF i was using Irrlicht.
Oh, and rogerborg, what I meant was "How should one react when colliding with more than one triangle at once." It's easy to see if one is colliding with triangle X, but what if one is colliding with triangle Y and tri Z at the same time? If one does a check against each triangle one at a time, then we might end up (if the collision response is to move away from collision) going through the previous triangle...

[arras]

Collision detection is mostly time consuming process so you wont to divide it in to several passes:

starting with rough test (fast but unprecise) if collision is detected then do more exact test (more precise but slower) on that object.

Good candidate for first pass are cube, sphere and bounding box collision, with first one be fastest but less precise.

If your application allow, you may consider to limit your collision test in to zones. Of course this require your objects to by sorted by zones. This might be tricky since one object can have one end in one zone and second end in another.

Response to collision is another thing. Simplest reaction is to move object back to last position where no collision was detected. This can be done by storing old position before moving object. In this case it doesn't matter if you are colliding with several objects. Once you detect first you can stop detecting and move object back to old location which you know was free of collision.

If you however want to get some king of sliding effect you need something more complex, with several rounds of collision detection.

[Dorth]

actually, a cube has nothing on a aabb ...

[Halifax]

Yeah I agree with arras.

You will probably want to create an OctTree of your aabb/obb, and then query the objects that are in the specific node that your collision testing object is in.

If objects are found, then you will want to do a broad phase pass, and test the bounding boxes, whether they be aabb/obb. After that, you can do a narrow phase test on any of the intersections present, which is basically using the complex physical representations of the objects.

If you need to know more about this subject, then Google is your friend.

[arras]

Or quadtree which is simpler and thus bit cheaper (you need only 2 coordinates to do calculations). In most cases quadtree would be sufficient.

If your scene is simple enough (dozens to hundred nodes) you will probably do fine even without it.

[Systemerror]

I don't need to be told about the different algorithms and stuff, just how one would go implementing it.

You implement it with "algorithms and stuff".

I kind of zoned out after reading that. Perhaps you could read the fine tutorials.

I have to agree with this, you can't really do any realistic collision detection without maths and Physics formulas, algortithims and good program code.

For simple collision detection (and I mean really basic) you should look into Elastic collision, that is, Both kinetic energy (due to motion) and momentum (the product of mass and velocity) and conserved in the colliding objects.

I'm not even going to into Non-elastic collisions as it's rarely used in games anyway.

I can't be bothered to explain the hypothesis even around simple collision detection, but it's enough for you to know that you need reasonable math, Physics (not to the cosmological level) and algebra skills to perform good collision detection within your game, as, unfortunately, it's a very complex subject.

But I'll give you a basic ficticiouse example of a ball bouncing accross a screen, then revercing the object (via velocity) to change it's direction.

Code: Select all

//obj at x, y with velocity of xv, yv
if(x > E.edge || x < W.edge)
      xv=-xv;  //rev vel
if(y > S.edge || y < N.edge)
yv=-yv;

But I suggest you use the Built in functions until you've studied the subject a little.

[david_at_bass]

you may use irrlicht with newton physic engine

http://www.irrlicht3d.org/wiki/index.ph ... nDetection

theres a great tutorial