Jump to content
  • Advertisement
Sign in to follow this  
Myth000

3d Visualisation (3d to 2d)

This topic is 4816 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

Hey, I want to calculate the 2d location in let's say a graph, from 3d coordinates. I'm new to this subject and I have no idea how to do it. I found a few tutorials, but when they started talking about matrixes I get confused :S. I do ahve experience with OpenGL, but yea, I want to make some non-realtime render engine for fun :). Not sure if I can call it engine, my first objective is drawing a few pixels... then a line, then a cube, then triangles. Thanks, - Myth

Share this post


Link to post
Share on other sites
Advertisement
Say you want 2d coordinates on a x-y plane, and your 3d coordinates are (x, y, z). It's actually as simple as z=0. (x, y) are your 2d coordinates! To teach you a fancy term, this is called the projection of a vector on a plane. [smile]

Share this post


Link to post
Share on other sites
z = 0*(x, y)?
I don't quite get it..
If you have x,y,z respectivicly {10,10,10}
You'd have: 10 = 0*(10,10) ...?
There won't be much left to solve + it won't equel 10, erm..
I don't mean your equetion is incorrect, it proberly is good, I just don't get it.
I lost my train of though :P

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
It sounds like you want to write your own graphics pipeline.

First it helps to understand how what you're doing in openGL works. In OpenGL you're working with matrices all the time, you just might not realize it since there are functions that do everything you need with them. glTranslate, glRotate, and glScale actually build matrices that represent translation, rotation, and scaling and then multiply the current matrix by them.

They use a 4 by 4 matrix because such a matrix can represent all the geometric transformations you usually need to move geometry around in 3d space. Multiplying a vertex by a matrix results in transforming the vertex by the matrix. If your vertex is [x y z 1] then multiplying it by a matrix that represents a translation on the x axis up 5 units will result in the vertex [x+5 y z 1]. So all this matrix stuff is really fundamental to how the geometry of your objects is interpreted. OpenGL takes your vertices and multiplies them by the current matrix, which was formed by multiplying all the matrices for your transformations together (it does this as you tell it each transformation).

The way it usually works is all these transformations end up placing the geometry so that things that are straight ahead of the camera are on the positive z axis. Then to get perspective, the place a vertex is drawn on the screen is (x/z),(y/z) (assuming the center of the screen is (0,0), if it's not you just do a little more math to line things up). This is because what you see through a window is not everything in a rectangular box in front of you, but rather everything in a trapezoidal shaped box. For the clip planes, you don't want to see any geometry behind the camera, so any geometry with a value less than some small z value is not drawn. Usually graphics systems have a far clip plane too.

The camera matrix does some math with the z coordinate before the object is drawn to the screen which sets up this division to result in the appropriate projection. If you look at the matrices created by the openGL functions that create the camera matrix you can see what they do.

Getting vertices to the screen is the first thing. After you know where to draw vertices on the screen, you can draw lines on the screen connecting them, and you can fill in triangles. Then there is the problem of depth ordering, so that's where z buffering comes in. The older 3d games before hardware acceleration had to use more clever methods for drawing the geometry from back to front to ensure that objects further away are obscured by closer objects. I think they used things like quadtrees and bsp trees to do this. And that's a whole different issue...

Also there is backface clipping, where you don't draw triangles that are facing away from the camera. For drawing a convex polyhedron, like a cube, that's enough to ensure that things further away aren't drawn closer than things near the camera.

Share this post


Link to post
Share on other sites
No, no, that '.' was just a full stop! (x, y) are your coordinates! Talk about knowing more math than you should ... which is ofcourse a good thing ;)

Share this post


Link to post
Share on other sites
Thanks, I indeed want to write my own graphics pipeline.
I still don't understand what matrices actually do.
They contain values for a formula?

EDIT: Lol didn't look at it that way.

Share this post


Link to post
Share on other sites
For some reason my draw3dline function isn't working.
The getTargetAngle, GetDist, and Put3dPixel functions do work.
Someone helped me making this for another thing once I based it on it.
But I don't quite remember what everything excatly does.
The problem is proberly, does:

(facing * (1.0f + 1.0f)) + _p1 ?= (_p1.x+facing.x*2,_p1.y+facing.y*2,_p1.z+facing.z*2).

I'm not sure if it's correct.


void _ART::draw3dline(vector3df p1, vector3df p2)
{
Put3DPixel(p1.x,p1.y,p1.z);
Put3DPixel(p2.x,p2.y,p2.z);
vector3df _p1 = vector3df(p1);
int count = (int)Math->GetDist(p1,p2);
for(int i=0;i<count;i++)
{
// What direction do we have to 'move' to go to the other point?
// Returns rotation.
vector3df rot = Math->getTargetAngle(p1,p2);

// So we must face that way...
vector3df facing = vector3df(
sin( (rot.y+90) * PI/180.0f),
0,
cos( (rot.y+90) * PI/180.0f)
);

// Eventualy, we move the way we are facing.
// We move pixel per pixel :)
// This is: (facing * (1.0f + 1.0f)) + _p1;
// But for some reason that isn't allowed.
_p1 = vector3df(_p1.x+facing.x*2,_p1.y+facing.y*2,_p1.z+facing.z*2);
Put3DPixel(_p1.x,_p1.y,_p1.z);
}
}



Share this post


Link to post
Share on other sites
Quote:
Thanks, I indeed want to write my own graphics pipeline.
I still don't understand what matrices actually do.
They contain values for a formula?
You could conceivably write a software pipeline without matrices, but I doubt you'd want to. It's possible you might be better off backing up a little and getting comfortable with matrix and vector math before tackling such a project.

Matrices are a convenient way to express and combine linear transformations. Let's say you have a vector (x,y), and you want to transform it as follows:

x' = ax+by
y' = cx+dy

This can be written in matrix form as:
[a b][x]
[c d][y]
Or:
[x y][a c]
[b d]
Most of the operations we want to perform in a graphics pipeline involve mapping a vector from one coordinate system to another (e.g. geometric transformations), or a vector component from one range of values to another (e.g. projection). Such operations can be concisely and conveniently expressed using matrices.

I'd think the bare minimum you'd need to know to get started would be:

1. How to multiply a matrix and a matrix
2. How to multiply a matrix and a vector (a special case of the above)
3. The difference between row and column vectors

[Edited by - jyk on September 11, 2005 3:04:00 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The easiest way to draw a 3d line defined by its end points to a 2d display is to determine the coordinates of the endpoints on the 2d display and then draw a 2d line between those coordinates.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!