Maybe I'm the most computer illiterate person in the world, despite the computer things I am good at, but I really struggle to grasp the principles of computer programming.
I've made attempts, every now and then, to try and learn about things such as Java, C++, PHP, etc, but I've always come away feeling that I haven't really learned anything, and not understanding what the fuck is so crucial about learning how to create a button graphic that creates a popup when clicked. This is stuff computers do anyway, it's not anything "new", nor have I learned anything about computer programming from it.
Perhaps I'm in the wrong media, the stuff that fascinates me is how one would program a 3D model (as an example) to make specific actions, such as movement, palette swaps, those kinds of things. Hell, I actually struggle to understand how a 3D image is programmed into a computer in the first place. Sure, I can reason it with intuition, graphic frames, textures and colour, but how exactly is this translated into code? Surely a computer doesn't just "magic up" things like video games and the Internet, based upon long strands of numbers?
It's really frustrating stuff, I'm determined to try and learn it (for the sake of having it as a useful skill), but I'm failing to do so on my own.
I think that you're coming at this from the wrong direction if you're picking a language first and then trying to figure out how to use it to make models of objects. Assuming you're not looking to
use Blender or Sketchup or Wings3D, but rather to figure out how to write a similar program, you should first attempt to study the math and the
algorithms -- as Lindley mentions -- behind such a subject.
For example, consider a simple, two-dimensional box. It has four sides, but more importantly, it has four
corners, and most algorithms concern themselves with tracking the motion of those corners through space using something like the Cartesian coordinate system.
Get out a piece of graph paper and try to follow along using pencil and paper. In high school, you were probably taught that most graphs put their origin -- the starting point where the x and y values are zero -- at the lower left corner, and increasing positive values of x go to the right and increasing positive values of y go up. This is good enough for our purposes, but you should remember that on a computer screen, one usually maps the origin to the upper left corner and increasing positive values of y go
down.
So the box is defined as having four corners at the following locations (for example): (0,0), (0,5), (5,5), and (5,0). This is your data defining a square box having a length of five units on each side. Your algorithm assumes that you draw a line from the first coordinate to the second, second to third, third to fourth, and fourth to first. Try this with pencil and graph paper and you've just essentially emulated the way a computer would draw a box on the screen.
An offset can then be applied to the box (transforming or moving it in space) by adding the offset to each corner's coordinates. Give your box an offset of (6,8) ... that is, add six to each x value of the box's corners and eight to each y value; like this (x+6,y+8). If you've used the same sheet of graph paper, you should now have a second box, identical in shape to the first, above and to the right of the first.
Now one thing a computer is good at is doing the same thing over and over, very quickly. Put aside the pencil for a moment and just imagine the computer counting from one to one hundred very quickly. Each time it increments, lets imagine it uses the current count as the x value of the offset. That is, let's assume the box's corners are offset by (count,0) every time the counter goes up by one. So the coordinates for each corner will look something like (x+count,y+0). If you also assume the computer erases the previous box before it draws a new one, you can probably imagine the result you'll get ... a box sliding quickly across the screen to the right until it gets to the end of the count. And then it stops.
Yet another transformation you can apply to each coordinate is a rotation. The math here gets a little more thick, and it's been over thirty years since I've done this stuff, so forgive me if there are some trig errors. Let's assume you want to rotate your box through a complete, 360 degree circle. This time, you'll want to count from 0 to 359 and you'll want to transform each corner's x and y values by x*sine(count*0.01745329) and y*cosine(count*0.01745329). For fun, don't forget to keep an offset to relocate your box, so the actual value for each corner would be (x*sin(count*0.01745329)+offsetx,y*cos(count*0.01745329)+offsety). Animate the offsetx and offsety values by having them change by some value each time the box is redrawn and you'll have a spinning box sliding across the screen.
Now implementing the above on a computer and disposing of the graph paper is what you'll use a computer language for. I used BASIC and Z80 assembly language the first few times I tried to tackle these subjects. The results were impressive only for the time. But they are
fundamental to understanding what is going on whenever your see a box on your screen ... like a "Submit Reply" button on an HTML page. Somewhere deep down, buried in a library no programmer has probably touched in years, is a call that adds an offset to that box so that it's positioned correctly on your screen.
I highly recommend getting hold of old, old issues of
Byte Magazine or
Creative Computing just to see how this stuff used to be done.
Here's a PDF version of the February, 1982 issue of Byte (careful, it's a long download) that goes into a simple introduction of computer graphics. Specifically, I draw your attention to "A Graphics Primer" on page 448 and "Interactive 3-D Graphics for the Apple II". The computer systems described and languages used may be long dead, but the principles described are still an active part of graphics today.
