Wire Whizz - 3D Maths
Mathematical Short-Comings
Okay, so I should confess that my grasp of 3D maths isn’t quite as strong as it once was. I was quite a whizz (if you’ll excise the pun) when I was younger, but I pursued an alternative career back in my youth (Acting, bizarrely as it happens!) and so my maths and 3D knowledge slipped into corners of my memory I cannot now reach. Additionally I never studied higher maths, so many concepts in 3D are a little beyond me, but I am hoping to address this soon so that I can do much more mathematically intense stuff, probably with the GPU on the 3G S and iPhone 4.
That said, I will explain a little of the maths behind Wire Whizz, but no math detail (you can find ray -> plane intersection tests from more reliable sources!).
In an ideal world I would have a spline defined by control points and render a tube around that spline, based on those control points. This would be fab, it would be quite easy to make levels and to make parts of levels and make the level data smaller.
I don’t do this however 
I could never get a decent mathematical representation of spline to match one in any 3D package I tried, principally because I was never entirely sure I was using the same algorithm. What I am able to do, is to create a spline in a 3D editor and to create geometry in the editor based on this spline and then export both pieces of information.
The exported spline is the resultant geometric line as opposed to the control points etc that will define the spline and any point along it. This has some advantages for me, because each spline is defined by series of straight lines, I have no geometry to generate on load, and the maths associated with colliding a hoop with a line are somewhat simpler - at least on this side of the mathematical gulf from which I am currently standing.
Collision Detection?
Initially the concept of colliding a hope with a spline is pretty complex. There are probably easier and more accurate ways to describe the hoop and detect collisions with the wire, but this was my approach and it functions pretty well, as you will see if you patronise the product (when it finally comes out).
If you consider the hoop to be a plane, then colliding a spline that is made up from line segments with it begins with a ray plane intersection. If you know the centre of your hoop, its radius, the radius of your wire, then any intersection that occurs at a distance greater than the radius of the hoop plus the radius of the wire, has entirely missed the hoop.
Detecting whether the wire is entirely within the hoop is similar: if the intersection occurs at a distance less than the inner radius of the hoop, minus the radius of the wire.
As the game allows the player to rotate by 90 degrees around Z, I am also testing for intersections with the edge of hoop and comparing that intersection with the width of the hoop’s edge and the radius of the wire. This is particularly necessary for when the player is within an intersection, as the section of the wire may not pierce the plane of the hoop.
Okay, that all sounds a bit complex and I appreciate that a diagram would help but I think it would take me too long to do that right now. Blogging the progress and history is therapy, drawing a complex maths diagram is not
The key thing to take from the above, is that ray plane intersections make up the majority of the tests done. The game has a concept of the player being on a particular section of the spline or being within a junction (areas defined for the player to leave the spline). And so it is necessary to check for collisions only among nearby segments, greatly reducing the overhead.
Camera Shake
Just a brief note to say that camera shake is a pretty straight-forward thing of adjusting the centre for the projection matrix in the Y direction by a random amount.