Thursday, November 18, 2010

/facepalm

So I changed some things around. I wound up doing the matrix inversion (a process I previously debunked as frivolous and unnecessarily complex) as a direct result of my inability to manage my modelview matrix pushing and popping. My code is cleaner as a result (always a huge plus) and I have more stability with all my on-screen objects.

I talked recently about how the rendering slowed to a painful rate with more than three objects on the screen; I don't know why that happened. I didn't change a library's worth of code, but it has no problem with things as they are now. I can seemingly add as many objects as I wish with no detriment to system performance (within reason, naturally).

Actually, come to think of it, it may have been the 20k + polygons that I had in one sphere alone that could have slowed things.

Maybe.

Regardless, I seem to be getting a solid handle on the collision detection. I'm still only detecting vertices (I haven't yet implemented my user-customizable accuracy setting) and it still often yields unexpected results. I have witnessed two objects generate a collision despite a very clear 20-pixel gap between them. It seems I have more work ahead of me in this vein.

Joy.

The object type with which I am having the most difficulty is, unsurprisingly, also the most recently implemented. Cylinders (here just as much a misnomer as "rectangle" in the capacity of this game) are giving me much cause for self-inflicted forehead bruises.

The first test for collision with a cylinder with a top and bottom of potentially differing radii is to see whether a would-be colliding vertex's y-coordinate is between the top and bottom of the cylinder (i.e., - L / 2 ≤ y ≤ L / 2 ). Assuming the test passes, we then test for whether the vertex exists within a specific radius of the cylinder's longitudinal axis. This radius is defined by the slope of the edge, which is a function of the length of the cylinder and its two radii.


In the diagram above, 'x' represents that test radius. So all we have to do after that is see if the distance of the vertex from the y-axis is less than that radius (i.e. x 2 + z 2 ≤ r ). Simple, right? Yeah, I thought so too. Apparently my compiler disagrees. Bastard. Moving on....


Above is a sample shot of multiple objects of random proportions and colors on a separate heightmap (which is there for no other reason than that of variety). The purpose of this image is just to show the different kinds of shapes that can exist within the game. Unfortunately, there are no convex shapes as they would prove an overly difficult addition to the collision detection.

I do think I'll allow for custom "paints" within the game, granting the user whatever palette they should so desire for their machinations. After all, everyone loves putting their own little stamp on the world. And that is, to some extent, my mantra with this game.

Well, tomorrow is another day and I'll see how I fare with fixing the aforementioned collision issues (as well as testing for collisions with the ground).

1 comment:

  1. Well I just noticed a fairly significant error in the line equations in the diagram above. In the first equation, the denominator on the right side should be (r1-r2), not (r2-r1). That changes things drastically and could very well explain the collision generated with a visible gap between objects.

    ReplyDelete