I suppose I could put a cap on the quality settings :P I hadn't even thought of lowering the quality that much! XD

Yes I know. http://local.wasp.uwa.edu.au/~pbourke/geometry/planeline/ Simpler than you might think, and requires stunningly less math than a sphere, and even less to transform the image coordinates.

There is more than one way to find whether or not a point lies inside a triangle. The way you said works, as does computing the normals of the sides, then finding the dot product of the point against the normal. The dot product returns a positive number if the point is inside, and a negative if outside. Calculating the normal is trivial given the coordinates of the vertexes of the triangle, and the dot product is merely multiplication and addition. Do this for all 3 sides and your good :/ I do this in my rigid body physics simulator to detect collisions, and let me assure you, it is quite fast.

The slowdowns you talk about are always pressent, even in this scenario. Finding whether or not a point is inside a polygon is trivial using normals and dot products. The multiplication is Trivial compared to the trig needed for rotation, and the slowdowns that come from reading and writing from greenfootimages. I think I may have discovered a way to make at least the graphics faster though. Converting an image to 3 arrays of color bytes could speed up reading from images, and writing directly to the writable raster of an image drasticaly decreases writing times, and gives more control over color manipulation.

@Zerg: A polygon could just be an equation for a plane with some bounds on it. For example, if you wanted to map a triangle, you would first find the plan that it lies on, and find the point at which the ray collides with the plane. If the point is inside the triangle, go to linear interpolation for the mapping. And yeah, my code is a bit messy and hard to read right now, i hope to clean that up in the future. And normal shading might not be out of the question, after all it only takes a bit of multiplication. @Mjrb I am aware of that, i am just experimenting with Graphics and Graphics2D to see how I can maximize speed.

It could be done. The egning would have to be changed a bit, but it wouldn't be that hard. :) Unfortunately, GreenfootImage is a bit slow, and i need to figure out how to write to the awt image directly XD

Hi Mjrb, and Sorry BlackholeGF, I don't check my email that often so i didn't get to your question in time. Mjrb gave the right advice! :) As for the Overload message, it was something I programmed in to output under special circumstances of the simulation. It occurs when there is an error calculating the Surface Normals, and they become much larger than suposed to, so until I figure out how to fix it, I outpul Overload!!! And reset the normal to zero, hence the weird movement. It seems to happen when corners colide.