I'm trying to *really* understand homogeneous coords and affine transformations .. using the computer graphics book by F. S. Hill.  As a start, I'm playing with the camera.

I'm a bit confused by the up vector used by the camera .. it seems to be backwards!

Here's a tiny experiment:
http://www.backspaces.net/files/testcam0/applet/

Its a rectangle in the x-y plane with x,y,z axes, and a center sphere which can be turned on/off.

I can change the up vector by hitting the x,y,z keys, and reverse the sign of the vector by hitting the - key.

The vectors seem reversed: [0,0,1] has the z axis pointing down.  But [0,0,-1] does what I want, aligning the camera with the positive Z axis.

Is this the correct behavior?  If so, can anybody explain why?

Owen

The code:
float upX, upY, upZ;
boolean drawSphere = true;

void setup() {
 size(500, 500, P3D);
 textFont(loadFont("AmericanTypewriter-Bold-24.vlw"));
 frameRate(5);
 setCamera(0,0,1);
}
void draw() {
 background(200);

 if(drawSphere) {
   noStroke();
   fill(200,0,0);
   sphere(50);//box(100, 100, 100);
 }
 stroke(0);
 fill(255, 255, 255, 200);
 rect(-200,-200,400,400);

 float len = width/2;
 line(0,0,0,len,0,0);
 line(0,0,0,0,len,0);
 line(0,0,0,0,0,len);
 fill(color(255,0,0));
 text("X",len,0,0);
 text("Y",0,len,0);
 text("Z",0,0,len);
}
void setCamera(float upX, float upY, float upZ) {
 this.upX = upX; this.upY = upY; this.upZ = upZ;
 camera(width,width,width,  0,0,0,  upX,upY,upZ);
 println("Up vector: ["+upX+" "+upY+" "+upZ+"]  drawSphere="+drawSphere);
 printCamera();
}
void keyPressed() {
 switch(key) {
 case 'x':
   setCamera(1,0,0);
   break;
 case 'y':
   setCamera(0,1,0);
   break;
 case 'z':
   setCamera(0,0,1);
   break;
 case 's':
   drawSphere = !drawSphere;
   break;
 case '-':
   setCamera(neg(upX),neg(upY),neg(upZ));
   break;
 }
}
float neg(float f) { // avoid odd -0.0 float.
 return f==0f? f:-f;
}

Thanks for the reply!

Yes, I'm aware of the screen orientation of Processing.

But from my reading of how the camera transform works, "up" is *relative* to the Processing axes, no matter what is up/down for them in the world coordinates.

Thus an up = [0,0,1] means to place the camera's up axis in the +z direction, i.e. the up vector is parallel to the Z axis in the world coordinates.

This would create a view with the +z axis being upwards on the screen, because both the camera's up vector and the world's z axis are parallel and in the same direction.

Owen

Just to clarify, or at least be complete, here's the reasoning I've been using:

I'm using the Computer Graphics using OpenGL book by F.S. Hill, using the eye,look,up -> U,V,N transform where eye and look are points (1 as 4th coord) while up is a vector (0 as 4th coord) relative to the world coordinates.  (And no, I don't expect anyone to have the book, I just want to clarify the issue as precisely as possible!).

The camera transform is then (ch 7, page 364):
N = eye - look (point subtraction yields a vector)
U = up cross N
V = N cross U
.. then normalize for n, u, v.

The drawings in the book are clear that up is a vector relative to the world coordinates.

The transform matrix from world to camera coords is then:
ux uy uz dx
vx vy vz dy
nx ny nz dz
0  0  0  1
.. where dx,dy,dz = -eye.u, -eye.v, -eye.n, where "." == "dot"
[Fine point: eye above is treating the eye point as a vector, really we're using the vector built by subtracting the point (0,0,0,1) from the eye point (eyex,eyey,eyez,1)]

Anyway, in all this, Prof Hill is VERY clear that up is indeed a vector relative to the world coords, thus [0 0 1] is parallel to and aligned with the z axis, thus should show a "z is up" image on the screen.

I'm going through this absurd level of detail because I want to get the homogeneous coords and affine transformations right so that the *rest* of my work will be right!  Screwing up the basics, as I apparently am, makes the rest futile, alas.

Whew!

Owen

Well, that's reassuring, I thought I was loosing it!

I guess I'll just give up on trying to the camera in the opengl way .. and see if I can figure out the processing way.

Thanks!

Owen

Having had a quick look around the PGraphicsOpenGL source, I think there is a nice quick fix:

Code:

import javax.media.opengl.*;

void setup()
{
  size(....,OPENGL);
  ((PGraphicsOpenGL)g).gl.glScalef(1,1,1);
  // rest of normal code..
} 

Quote:


Thanks for the pointer!  I hadn't thought of looking at the opengl code.  Although, for now, I'm using P3D primarily.

I've downloaded the code source too, and am reading it to try to understand the system better.  What a great tool, sure glad its available.

Owen