Sorry your browser is not supported!

Well, here is my 46th post! Either way, i was wondering, what kind of math is used for converting an object's vertex coordinates to 2d coordinates on the screen? For example, how would a program that uses math to make a movable, rotatable, cube out of lines work? I know trig is involved, and i did about an hour of research, but nothing makes very much sense. I know a vanishing point may also be used, but how is this turned to 2d? Thanks!

Please answer, if i ponder about this too long my brain will over heat and explode

Hmm, well it's a little hard to explain all in one go, but a while ago I read this. In the "The Geometry Pipeline" section, it gives a pretty good explanation of the processes that need to happen in order to transform the vertices from the objects all the way into 2D coordinates on the screen, but it doesn't really explain the math. To learn about the math, you should brush up on your matrix algebra. The only part of the whole transformation process that requires trig is during rotations. Here's the wiki article on Transformation Matrices. It's pretty advanced, but in the "Examples in 2D graphics" section it gives a basic idea of how to make different kinds of transformation matrices for different purposes. Granted, the examples they give are for 2D coordinates, but if you expand the matrix, it can easily be (and very frequently is) used for 3 dimensions.

Thanks man! Yah, kinda confuzzling, but i bet ill figure it out. Thanks!

Back in the day i wrote a program that shows a perspective view on a 3d wire mesh in qbasic. Basically what happens is a software render judges the perspective distances by the z distance from the origin. Basically you modify the coords on the 2d plane to make it look like its getting farther closer away.... this is a general brief unhelpful description but the basic concept of it. Now... im not 100 percent but the best way to figure out how dx does it would probably be to take a look at how there software rendering system works... i belive the hardware version uses... well.. hardware to create the 3d on 2d plane effect... If you would like i could later write aout a brief description as to what i did and post it when i have time. for rotation there are some trig formulas that would be required in order to get a rotating object/ verts. I cant actaully produce any usable code because really qbasic was a dos progamming language and wouldnt be usable in windows anyway except for in maybe dosbox.... (Hey theres a thought maybe ill grab qb for fun...) Anyway hope that helps a little??

@PrimalBeans That does help! If youd be willing to tell me what you did that would be great! Thanks

K its been a while but heres what i did in qbasic:

first things first:

to set up a simple view port with an origin you need do create the following variables

X_origin = screen resolution x / 2
y_origin = screen resolution y / 2

The reason you do this is because your 2d display surface has the x and y "0" as the upper most left most pixel on your screen (top left is 0,0) for a perspective 3d view the focus point or the origin needs to be the center of the view.

now for the perspective math (Its really easy.)

screenx = (x/z) + X_origin
screeny = (y/z) + Y_origin

thats the bare bones essential of how a 3 coord vertex is transformed to a 2d view port... mind boggling huh?

now you could make that more interesting by adding variables to control camera location:

well add in
vx vy vz
to locate viewer location

screenx = (x - vx)/(z - vz) + X_origin
screeny = (y - vy)/(z - vz) + Y_origin

basically all you are doing is teaching the computer how to "draw" 3d images on a 2d surface. Thats all any system does because that all that can be accomplished with a flat surface is a 2d image made to look 3d.

were the math gets tricky is rotation... basically you have to have a formula that can rotate vertexes in a manner that they dont get deformed and mangled... trust me it took me a while to get it right since math isnt one of my strongest points... especially now.

to traslate (move) verts one direction or another is simple... add the translate value to the vert data then update the vert

x = x + translate_x to move on the x axis
z = z + translate_z to move on the z axis
y = y + translate_y to move on the y axis...

simple....

heres rotation:
save the original coords to a different vairable. because youll need them as you rotate on each axis
old x,y,z

set the rotation values "how much to rotate for x/y/z"
rotx, rotz, roty (in degrees)

oldx = z
oldy = y
oldz = z

to rotate on x axis


y = (sin(rotx) * oldz) + (cos(rotx) * oldy)
z = (cos(rotx) * oldz) - (sin(rotx) * oldy)

to rotate on the y axis:

x = (cos(roty) * oldx) - (sin(roty) * oldz)
z = (sin(roty) * oldx) + (cos(roty) * oldz)

and the z axis:

x = (cos(rotz) * oldx) + (sin(rotz) * oldy)
y = (cos(rotz) * oldy) - (sin(rotz) * oldx)

not so simple... Im not really sure of the breakdown of them myself... if your better at math then me then youll have an easier time with it.

When i wrote my 3d drawing program way back when i found the formulas and basically plugged them in... im in no way a math wiz nor an expert at any of the above math...

anyway hopefully that gives you something to ponder or playwith...

Wooow, thanks for the long reply! That must have taken some time! That is very useful, you should have seen me trying to figure what formulas to use a couple days ago I will incorporate this into some code when i have time Thanks man!

For more modern windows work this kind of stuff can still be useful in a 2d game for 2d effects.... Remember chrono trigger?? LOL glad i could help.

Cool!