Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.


Outlined 3d cube, but in 2d!

This topic is 5487 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was just thinking of doing a 3d cube but just drawing with lines in 2d. But then i realized i really had no idea how to do it. So i would appriciate to see some example codes just for fun

Share this post

Link to post
Share on other sites
All 3d renderers are just projecting the 3d geometry to a 2d plane (the render area)

So let''s say the position on the 2d surface along the x and y axis ok?
We''ll label these x'' and y'' (I think these are usually spoken of as "x prime" and "y prime")

Because of perspective, the apparent size of an object is proportional to it''s distance.

x'' = x/z
y'' = y/z

where x,y, and z are in 3d, and are relative to your current position (like your camera''s position in the 3d world)

So, to find the x,y,and z for any given point, the math would be
x = geometry.x - camera.x
y = geometry.y - camera.y
z = geometry.z - camera.z

so, x runs left to right, y runs bottom to top, and z runs from the screens surface back into the screen.

btw, if you have camera rotation (say along the y radial axis)
you''ll have to rotate by the inverse of that also
(this process, the geo-camera stuff, positions and rotations are called an inverse transformation)

you''d actually recalculate the x and z values based upon their previous angle, and (subtracting) the camera''s angle of rotation relative to "straight ahead"

Now, if you''re under 18 you''re probably pretty confused. Go figure out the stuff w/o the rotation and code it up.

(This info is not guarenteed to be 100% correct, if anyone finds something wrong with it, please correct me.)


Share this post

Link to post
Share on other sites
I''ve got a program that basically does this. It''s written using GLUT, you can download the source from my website:


It''s in the University Work section, called glutLines (The oldest one, the newer one doesn''t do 3D lines)

I''m affraid if you''re looking for an explanation as to exactly what''s going on, then this probably won''t be too helpful. I suggest learning these things:

1. Vectors
2. Homogeneous (spelling?) vectors
3. Matrices (4x4)
4. Projection Matrix (Projecting 3D points onto the screen)
5. View Matrix (Transforming 3D points to give perspective)

Let''''s struggle for our dream of Game!

Share this post

Link to post
Share on other sites
Hehe your program was quite hard to understand

I know vectors but i don''t understand anything about matrices, what they do and whats the point of using them. Where can i read about this (related to 3D programming)?

Share this post

Link to post
Share on other sites
Yeah, i didn''t really comment it too well.

Theres a link on the right hand side of my site that says "Matrix Stuff", it''s got some ueful info on it.


Let''''s struggle for our dream of Game!


Share this post

Link to post
Share on other sites
The new Andre LaMothe book is quite good for that:
"Tricks of the 3D Game Programming Gurus-Advanced 3D Graphics and Rasterization "

It''s very in-depth and should provide you with a pretty good understanding.

Hope this helps.

Share this post

Link to post
Share on other sites
the easiest way to do a simple 3D projection like this is as follows...

To do the projection, you don''t need any complex maths. All you need is to understand what the camera is, and how perspective projection works.

Your camera is basically a plane, and a point. To start with, we can ignore the possibility of moving these around for now, and pick a simple case.

Lets say the plane in the x,y plane... and your point lies on the z axis.

To convert a 3D coordinate in your world into a point on the plane, you simply project a line from your camera point, to the coordinate you chose, and where it intersects the plane... that is your 2D coodinate.

As you can imagine, the plane is infinite. since a screen is only finite, we must choose a certain region of that plane to represent the screen.

For simplicity, you might choose this region to be a rectangle, centred at the origin, whose height and width correspond to the number of pixels on the screen.

Now we come to the point. For a fixed region of the plane, the distance of the point from the plane determines how much of the world is visible. This hence determines the FoV (Field of View) of your camera. The actual field of view in degrees can be worked out with simple trig.

Now you know how the camera works... what can you draw... Well, hard code the coordinates for the corners of a cube, and simply plot them usign the scheme I detailed. Remember that the plane lies at the origin, so the scene must be shifted away from the camera (just add some set value to your coods for now).

Once you have this up and running, you can go onto rotation. To start with, you can just rotate around one axis, using the standard 2D rotation formula... then rotate around another, then another (just do them sequentially). You can then rotate your object freely.

Now you have this foundation, you have to build on it. Remember, in your 3D world, moving your camera, makes all the coordinates of objects you draw move. You might want to mess about with trying to figure out how the world will move, and making your display, resolution independant (normalised coordinates).

After building an engine this way (hard coding all the transformation) you will come to appreciate the simplicity that Matricies can provide you. Once you''ve switched to a matrix based transformation system, you will be well on the way to making a software 3d engine .

Simply things to add are, backface culling, depth sorting (for painters algorithm)... and lambertian flat shaded lighting. Once you get on with this, you may well be bored, and sayin "OpenGL all is forgiven"... but if you are not... have a go at gouraud shading, then texture mapping... and phong mapping, blending, perspective correct textures, bumpmapping (using clever phong map offset method ), depth buffers etc.

Writing a software only 3D engine can be a lot of fun, and give you real insight into how the 3D maths actually work... rather than using all the helper functions and the black box API generated matricies.

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!