Delayed implementation

Well, yesterday my day was full so I had precisely zero opportunity to do any coding.

Get up, go to work, go tutor, go home, watch this week's Walking Dead, go to sleep.

Today, I got up and came to work and, when I leave, I have an appointment in Worcester so I can't code. Hopefully it won't last too long and I'll be able to get home with at least a couple hours devoted to coding.

I know that I haven't yet fixed the object adding / manipulation, but that hasn't stopped my head from musing on the implementation of collision detecting whilst making my 45 minute commute to and from work. I think I have a fairly stable / easy idea, but it's really only applicable to the types of models that will be employed in-game.

I'm going to be using strictly primitive shapes - rectangles, spheres and cylinders (note that cubes are just special rectangles and cones are cylinders with one end tapered). This allows me to save a lot of time, energy, cycles and sanity when writing the detection methods.

In modern collision detection, every edge of every polygon is tested for whether it passes through a polygon of another model (or sometimes the same). To do this, the following typically needs to take place:

1. Establish vectors based on the three vertices of a polygon (P1,P2 and P3)
2. Establish a plane based on the cross products of these vectors
3. Establish a line based on two vertices from another polygon (P4 and P5)
4. Test whether there exists a point of intersection exists between the line and the plane and, if yes,
5. Find the point of intersection (P6)
6. Test whether the point exists on the line between the two vertices P4 and P5
7. Test whether the point exists on the plane within the triangle formed by the three vertices P1, P2 and P3

That's a lot more than I want to do currently. I'll admit, I'm a bit embarassed to say I don't feel like doing the math for it (and I don't want to look up someone else's work; I can't help but feel like that's cheating). So I have a different plan in mind.

What I intend to do is sort through the objects and, for each one, test it against all other objects (there's obviously a need for redundancy checks so we don't test the same relationship more than once and waste cycles). To do this, I'm going to apply a rotational transform to the objects being tested based on the position and orientation of the object against which they're being tested. From there, it's as simple as testing whether any of the vertices lie inside the space defined by the first object.

For a rectangle, it's extremely easy; I just have to test whether a colliding vertex exists within the bounds formed by the rectangle's height, width and depth. For a sphere, it's even easier; test whether a colliding vertex is within a certain radius of the sphere's center.  For a cylinder, test whether a colliding vertex is within a certain radius of the longitudinal axis of the cylinder. Easy!

"But Mike," you may cry. "What if just an edge intersects the object and not a vertex? Your plan is foiled! Buahahahaha!"

First I would reply that you should probably stop heckling a blog. Second, I have a plan for that too. I will test for not only the vertices, but points along the edge (as defined by a line established by two vertices) at regular intervals. The interval in question represents a degree of accuracy of the collision detection, and that will be adjustable based on system performance.

So you see, I am quite clever and adept at thwarting your would-be thwarting.

Now all I need to do is actually get around to coding this. Unfortunately, I need to finish fixing the problem with my object adjustability and movement. Once that's worked out, I can test swinging one object into another with just a mouse gesture.

After collisions are repeatedly successfully detected, I can move on to dictating how they should move after the collision is detected.

For now, feel free to comment about my dazzling MS Paint skills.