   Basic 3D math tutorials?
  Can anyone point me towards a tutorial that covers the basic maths involved in 3D graphics? Everything I''ve seen so far is too advanced for my needs, as all I really need to know are the basic formulae for displaying simple geometric objects in a 3D world on a 2D screen.All I really need to know at this point is how to work out what size to draw the objects at any given distance and where to place them in relation to the horizon and/or vanishing point. 
  Assuming that you have a camera fixed at the origin, looking down the z-axis in a positive direction, all you have to do for perspective is divide the x and y co-ordinates of each point on each object by z, and scale / centre the result so it fits on the screen.However, except in the most trivial examples, you want to be familiar with _matrices_ so that you can implement object and camera movement and rotation in a vaguely sane manner.  Google for matrix tutorials, or have a look around this site for an introduction until you find one you get along with. ;  You might try looking at some of the feature articles here at gamedev.net. Some of them attempt to make the math of 3D graphics more intuitive. You also might try the OpenGL red book, for which the OpenGL 1.0 edition is available online:OpenGL Red Book, version 1.0 Graham RhodesSenior ScientistApplied Research Associates, Inc. ;A good one for 3D graphics maths. ;quote:Original post by llyod  A good one for 3D graphics maths.   That is a pretty good tutorial. I added it to the Forum FAQ under question 11.   Graham RhodesSenior ScientistApplied Research Associates, Inc. ;  Those tutorials seem to skip over the parts I need to know and go way beyond the complexity I''m aiming for. I guess I should explain a little more about what I''m trying to do.Basically, I''d like to create a 2D view that looks like a first person 3D view, but is in fact made up from predrawn image "slices".This is a method used by early DOS RPG games, such as Eye of the Beholder and the Unlimited Adventures construction kit. A more recent version of the latter can be found at http://uaf.sourceforge.net/ if seeing screenshots would help understand what I mean.What I''d like to know, is how to work out where to place each corner of the wall images depending on how far away they are, so that I can draw them accurately in a 2D image program, such as Fireworks. ;  Do you mean like Wolfenstein or Doom, or like really early games where you could only face north / south / east / west? ;  The old 90 degree rotation, single step movement, turn based combat type. ;  Let sz be the size of a ''step'', in pixels, close up (perhaps equal to the vertical size of your viewing area, or a little smaller).  Let (cen_x, cen_y) be the centre of your viewing area.Then a monster z steps infront of you and x steps to the right could plotted with the middle of his feet at:x'' = (x * sz / z) + cen_xy'' = (0.5 * sz / z) + cen_yand divide his size by zDo not attempt to calculate this for z <= 0, you''ll get a division by zero error - simply don''t display the monster when it''s not infront of you.You''ll have to work out how to find z and x from the positions of the monster and player and the way the player is facing.Drawing order is an issue, and drawing walls is more tricky than monsters - have you got a strategy worked out?  The corners of the walls are not on grid squares but inbetween them, so use half ''steps'' to find where to draw these points. ;  Thanks. That''s a lot closer to the type of info I''m looking for. I saw something similar in a tutorial a few weeks back, but it based the scale calculations on a focal length without giving any clues as to what a sensible figure would be.I believe they said "150", but gave no unit of measurement for that and did not mention if it should directly relate to the x,y and z scale (i.e. if it was in cm then so were the z units).The equation was something like:-scale = focal length / (focal length + z)As for drawing the walls, I was going to experiment with drawing them all starting with the ones furthest away and then see if it was any quicker to check if they were visible first.I wouldn''t think there would be much of a problem with speed either way though - even on a Pentium I or 486 - as they would only be static bitmap images (with transparent areas).This type of game was available for 8086 and 286 machines after all. 