-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- INTRODUCTION TO 3D SERIES #1 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Writer: Matthew River Knight

Have you ever played Quake and wished you could make a similar game in Qbasic? Have you ever tried to learn how to code a 3d program in Qbasic, only to find that there are no good tutorials out there? Yep? Well then this tutorial is just for you! ^_^

I remember when I wanted to learn how to do 3d, it was a total nightmare. I went to every shop I knew of in search of a book - they had books on the subject, but they were all aimed at C programmers...there was nothing for Qbasic coders such as myself. Next I decided to search around the internet for a decent tutorial. I found several tutorials, but to my alarm, they were all so complicated! I'm sure that some of you have, at some stage, downloaded a certain 3d tutorial by Matt Bross. What a mistake that was eh?! It is a pathetic excuse for a tutorial. It consists only of extremely complicated and difficult to read code, then followed by a very brief explanation of what it does, and an even briefer explanation of how it goes about achieving this.

In order to fill the obvious void in the QB world for a decent 3d programming tutorial, I have decided to do a series about it right here in QBCM! We are going to take things step-by-step, progressing from the very simplest aspects of 3d programming, right up to the more complicated, but extremely fun stuff! ^_^

Don't worry if you aren't good at maths, or aren't a programming guru. I am going to explain things in such a way that they are going to be very easy to understand, regardless of your ability! I do however recommend that you have at least an intermediate knowledge of Qbasic. As far as the maths is concerned, there is a large misconception amongst the programming circles that in order to do 3d, you have to be a genius with mathematics. Not so. You will need to have a good knowledge of Algebra, Geometry, and Analytical Algebra. That's it. It does help to know Trigonometry, but it is not a necessity.

Okay, I have rambled on long enough! Let's start learning how to program in 3d!!! To begin with, we need to know how to define a point in a 3d world. You already know how to define a point in 2d - it's simple...you have your X coordinate to describe the point/pixel's location across the screen, and you have your Y coordinate to describe the point/pixel's location down the screen. In 3d it works exactly the same way, however, we have to add another coordinate: Z. The Z coordinate describes the depth, or in other words, how far the point/pixel is away from the viewer. In a 3d world, the exact center of the world is X,Y,Z = (0,0,0). So, a point that is 100 pixels to the left of the center of the 3d world would be at (-100,0,0). A point that is 50 pixels to the right of the center of the 3d world, 100 pixels higher than the center of the 3d world, and 10 pixels closer to the viewer than the center of the 3d world, would be at (-50,-100,10). All of the points in your 3d world are collectively called the world coordinates.

Using the above method, it is easy to create a 3d world. If, for example, you wanted a quadrilateral (such as a cube) in your 3d world, you would compose it by defining points which are the vertices of the object. Later on, when actually drawing the object on the screen, we connect all of the points/pixels together by using the LINE statement. This gives us what is called a wireframe representation of the object. But, before we can draw our 3d objects on the screen there's some stuff you have to know - we'll cover that at a later stage.

Once we have defined all of our world coordinates, we have to place the camera in the 3d world. The camera (also called the eye or the viewer) is what actually looks at the world. If you place it high above the 3d world, then you see the world in much the same way that it would be seen from a high tree, or a building. If you place the camera much lower down, then you will see the 3d world from an ants point of view! The camera's position is defined in exactly the same way as the world coordinates: you describe the camera's position in the 3d world with X, Y, and Z coordinates. It is important to note that the camera will ALWAYS 'look' to the center of the 3d world (0,0,0).

Now that we have defined our world coordinates, and have defined our camera position, we have to find a way to plot the 3d world on the screen, relative to the camera's point of view. Now the most obvious question is "how on Earth do I plot a 3d object on a 2d surface like the screen??!!" Well, let's take this one step at a time.

Okay, let's say we have defined a single point in a 3d world where:

x_world = 100 y_world = 20 z_world = 10

The first step in getting our 3d world onto the screen is changing these world coordinates into what is called the camera coordinates. The camera coordinates describe the world coordinates as they are seen from the camera's point of view.

Now, in order to change the world coordinates into camera coordinates, we have to use a set of mathematical formulae. "Nooooo!" I hear you say. Heheh, don't worry, it isn't difficult at all...and I am going to explain how it works. ^_^

Now let's think about this logically. Suppose we are in a 3d car racing game. Our camera (which is basically the same as the person inside our car in the game) is at (100,10,10) and is looking at the center of the 3d world (0,0,0) (you will recall that the camera in a 3d world will always look to the center of this world). With the camera at this position, the center of the world is at (-100,-10,-10). From this information, it seems that:

x_camera = x_world - camerapos_x y_camera = y_world - camerapos_y z_camera = z_world - camerapos_z

where:

x_camera = x coordinate of a point (camera coordinate system). Ditto with y_camera, and z_camera. x_world = x coordinate of a point (world coordinate system). Ditto with y_world, and z_world. camerapos_x = x coordinate, describing the position of the camera in the 3d world. Ditto with camerapos_y, and camerapos_z.

And guess what...those equations are actually the equations we use to convert world coordinates into camera coordinates!!! ^_^

It is important to note that you can place the camera anywhere in the 3d world, except for one place - you CANNOT place the camera in the center of the 3d world (0,0,0). You can put it anywhere but there. Why? Well, since the camera will always look to the center of the world, if the camera was in the center of the world it would be looking at itself. Can you look at your eyes??!! Nope, of course not (not without a mirror anyway.) So you can't put the camera at (0,0,0). If you do put the camera in the center of the world, then some of the mathematical formulae which we are about to describe will not work, and the program will crash.

Okay, so now we have converted our world coordinates into camera coordinates. But we still can't draw our 3d world/object(s) on the screen yet. We still have points which are described by X, Y, and Z, but the PSET and LINE statements can only draw with points defined by X and Y (which is 2d) - this is logical really...the screen is, after all, a 2d surface.

In order to draw in 3d on the screen using PSET or LINE, we have to convert our camera coordinates (which describe the 3d world coordinates relative to the camera's point of view) into 2d screen coordinates. How? Simple. We use a set of mathematical formulae!!! (Do I hear groaning?! ^_^)

Once again, we have to think about the problem at hand with a bit of logic and common sense. In real life, objects that are further away from us look smaller than they do when you are right next to them. The principle is the same with 3d computer graphics. For example, imagine that in our 3d world we have two points/pixels that are 10 pixels length apart. If their Z coordinates are both decreased by 1, then the two points are each going to move one pixel length closer to the other. This information demonstrates the golden wisdom of every 3d programmer: "The screen coordinates could be calculated by dividing the X and Y position through the depth (z coord- inate)."

This shown as a formula is:

x_screen = x_camera / z_camera y_screen = y_camera / z_camera

where:

x_screen = x coordinate of the pixel on the screen. y_screen = y coordinate of the pixel on the screen. x_camera, y_camera, z_camera = (see above).

However, we have several different screen modes at our disposal, and (0,0) on the screen is actually the top left hand side of the screen, so we have to change the formulae a little if we want the 3d object to be centered on the screen and if we want the program to work in all screen modes. The final set of formulae for conversion of camera coordinates to screen coordinates is as follows:

x_screen = (x_camera / z_camera) * srx + srx / 2 y_screen = (y_camera / z_camera) * sry + sry / 2

where:

srx and sry describe the screen resolution. In SCREEN 13, srx would be equal to 320, and sry would be equal to 200.

Another very important thing that I must mention is that if any of our points in the 3d world go behind the camera, or in line with the camera, then the math for projection of the camera coordinates onto the screen goes all haywire. This is logical really. In real life, if an object is behind you, or in line with your eyes on the side, then you cannot see it. This is the same with 3d computer graphics, but the problem is that the computer doesn't yet know that we must not be able to see these points, so it attempts to use the math on them anyway, and it goes nuts!!! ;)

We'll say that points in our world coordinates that are in line with or behind the camera are "out of range". In order to fix this problem, it is necessary that we do a test on all of the points in our 3d world (the world coordinates) to see if they are "out of range" and if they are, then we have to temporarily eliminate them. When they are back in range again, then we can put them back and have them plotted on the screen. Let's explain this another way: if the value of the world Z coordinate of a point is equal to camerapos_z or greater than camerapos_z then it is "out of range" and we must eliminate it (ie. we don't draw it!) Simple eh?! Here's some code for this:

IF x_world >= camerapos_z THEN 'Don't PSET this point!

Please note that when you are doing a 3d engine you should NEVER use PSET do draw everything in the world. That would be terribly slow. LINE is a much faster alternative, however, I used PSET here in order to make the explanation easier to understand.

Well, this concludes the first entry into the INTRODUCTION TO 3D SERIES. I hope you enjoyed it! Next issue we'll be covering 3d rotation, how to code a 3d program in which you can 'walk' about the world, and hidden surface removal. We'll also add some source code to help ya out! ^_^

Cya next month!