OpenGL coordinates

Hi.

I got two questions about OpenGL which I cant find good enough explained in my book or on net-tutorials.

1.How do the OpenGL coordinate-system work?
How do i know where for example glVertex3f(1.0,1.0,1.0); is?
From what I have read, I think you set up the coordinatesystem your self with the mix of
-glFrustum()
-glViewPort()

Can someone try to explain how I can set up a coordinatesystem which is logical,detailed and easy to use? and try to explain how to simply set up the coordinatesystem to anything you want?


2. Also, from what I've read, the "Eye" or the "Camera" is actually allways at the origin(0.0,0.0,0.0), EVEN when using glTranslate3f() and gluLookat(). WHY? Wouldent it be easier and better to simply move the camera, rather than moving the whole world?

Quote:

---

1.How do the OpenGL coordinate-system work?
How do i know where for example glVertex3f(1.0,1.0,1.0); is?
From what I have read, I think you set up the coordinatesystem your self with the mix of
-glFrustum()
-glViewPort()

---

I use glViewPort, but instead of glFrustum I use gluPerspective. It's a tad bit easier (does more of the work for you). Look both of these up on msdn.com. Note that gluPerspective takes the YField of view angle, NOT the x field of view angle

Quote:

---

Can someone try to explain how I can set up a coordinatesystem which is logical,detailed and easy to use? and try to explain how to simply set up the coordinatesystem to anything you want?

---

I dont' even know what this means really. The x axis is off to your right, the y axis is up, and the negative z axis is forward into the screen.

Quote:

---

2. Also, from what I've read, the "Eye" or the "Camera" is actually allways at the origin(0.0,0.0,0.0), EVEN when using glTranslate3f() and gluLookat(). WHY? Wouldent it be easier and better to simply move the camera, rather than moving the whole world?

---

I don't think you realize that the only way to do this is to move the whole world. Even when you use gluLookAt, all it does is build the rotationmatrix so that it can rotate the world around the camera.

Think about it: how, from an implementation point of view, can you just 'move the eyepoint' ? What you are suggesting is that you move the eyepoint without altering the vertices of the world or something like that? Can't be done.

Basically when you move the world you are moving the camera to the origin of the world. Say for instance when you are driving a car down the road. The world is brought to you based on your velocity, etc. Now in a physical sense you are moving through a stationary world and it is that motion that brings the world to you. However if you look at the world using the car as your frame of reference...everything is moving relative to the car. In essence the world is moving, not the car. When you are in the car, the dashboard, steering wheel, passengers, cargo, etc., all move with the car. Regardless of what the windows display...all of this stays stationary as it relates to the car.

So in a game you must move the world the exact opposite of the object in order to give the illusion of movement. You can't just move the object because we are not talking about a real world...it is one simulated by numbers and mathematics. So in order to simulate what happens in the real world you must move the whole world in relation to the object.

This is a very poor explanation of what really happens in 3D but it does give you a starting point. I would recommend reading some books concerning 3D mathematics and principles.

Let's look at the car example from a top down view.

Code:

---

*Car                                * Tree
0  1  2  3  4  5  6  7  8  9

---

The car is the origin of the world in this example. The tree is about 9 units from the car. Now move the car 3 units toward the tree and make the car the origin of the world.

Code:

---

        *Car                    *Tree
-2  -1  0  1  2  3  4  5  6  7  8  9

---

Because the car has moved 3 units towards the tree, the tree is now only 6 units from the car. This is the concept of translation.
We have translated the car 3 units, but we are still assuming that the origin of our world, or number line in this case, is always where the car is. This makes our calculations much easier.

TranslatedTree=OriginalTree-CarMovement

Since our Car moved 3 units CarMovement is +3. The original tree position as it relates to the car was 9. So the new position of the tree is 6 or TranslatedTree=(9)-(3)=(6). Note that we don't have to worry about the position of the car in any of these equations if we assume the world origin is always where the car is. This is, in essence, what we do a lot of in 3D graphics. We always translate the camera to the origin of the world. Note that even though the car moved forward, the tree actually moved closer to the car - so the world ALWAYS moves the EXACT opposite of the camera movement.

World=World-CameraPos.

Another way to code this is as follows. I'm going to create some code here for a simple 2D starfield. I will leave out all of the graphics code because that is more about graphics programming than the concept of translation.

Ok in our space scene we want the spaceship to be in the center of the screen AT ALL TIMES. But we want to make it look like the ship is flying through space. How do we do this?

Code:

---

struct point2D
{
  int x;
  int y;
  point2D(void)
  {
      x=0;
      y=0;
  }
  point2D(int _ix,int _iy)
  {
    x=_ix;
    y=_iy;
  }
};

struct SpaceShip
{
  float Speed;

  SpaceShip(float _fSpeed) {Speed=_fSpeed;};
  SpaceShip(void) {Speed=0.0f;};
};

#define NUMSTARS 100
#define MAXX 1024
#define MAXY 768

point2D *Starfield;
SpaceShip PlayerShip;


void MoveStars(void);
void Render(void);
void Setup(float _fShipSpeed);
void Shutdown(void);

int main(void)
{
  Setup(); 
  do
  {
   
    MoveStars();
    Render();
   
    //Code for this not listed here
    Present();
  } while (!kbhit());
  Shutdown();

  return(0);
}

void Setup(float _fShipSpeed)
{
  //Create starfield
  Starfield=new point2D[NUMSTARS];
 
  //Set ship speed
  PlayerShip.Speed=_fShipSpeed;

  //Populate starfield
  int starx=0,stary=0;
  for (int i=0;i<NUMSTARS;i++)
  {
      starx=rand() % MAXX;
      stary=rand() % MAXY;
      Starfield[i].x=starx;
      Starfield[i].y=stary;
  }
}

void MoveStars(void)
{
  int x=0,y=0;
  for (int i=0;i<NUMSTARS;i++)
  {
      x=Starfield[i].x;
      x-=PlayerShip.Speed;
      if (x<0) x+=MAXX;
      if (x>MAXX) x-=MAXX;
      Starfield[i].x=x;
  }
}

void Render(void)
{
  RenderSpaceShip();
 
  for (int i=0;i<NUMSTARS;i++)
  {
      PlotPixel(Starfield[i].x,Starfield[i].y,15);
    }
}

void Shutdown(void)
{
  delete [] Starfield;
  Starfield=NULL;
}

---

Okay if I didn't make any errors and you implement this and use your favorite graphics API to do the drawing, you will have a virtual starfield wizzing by on the screen.

Notice that because the spaceship is always in the middle of the screen you must move the stars to make it look like the ship is moving. This clearly illustrates the camera concept. Imagine the ship as being the camera. Everything in the world is relative to the camera position. So the world flies by the camera - thus we must move every star in the world by the negative camera speed. When the ship speed is positive, the stars will move to the left and when it is negative the stars will move to the right. I'm assuming that the ship nose is always pointed towards the right side of the screen.

Incidentally you can alter this code to account for any angle of movement for the ship. Pick an angle for the ship and move the stars based on the sin and cos of the angle multiplied by the speed of the ship. You must now also check for when stars wrap on the y extent so they don't all disappear on you, but that's trivial.

I hope this lengthy explanation helps you understand the concept of translation.



EDIT: Very cool. I edited this post and the spacing within my code block was preserved. Thanks to the board admins for fixing this extremely annoying bug.

Okay, I got how translation and cameras works now... Thanks! :)

But about the coordinate-system, what I wonder about there, is like "How can i know how long it is between coordinate 1.0 and 2.0?

How many pixels are there? How will it look like?
As I said, I think it got something to do with the
-glFrustum()
-glViewPort()

, I know how to use them(atleast a little), but I dont understand how I can use them to get exactly the length between cordinates as I want...(I am used to the easy coordinate system in Win32API, where 1 coordinate equals to 1 pixel :D

you define what one unit looks like

Quote:

---

Originally Posted by Da-Nuka

As I said, I think it got something to do with the
-glFrustum()
-glViewPort()

---

your not wrong but your making things hard on yourself... have a look at gluPerspective()

and for future reference check here http://pyopengl.sourceforge.net/documentation/manual/