ortho function is broken

[processing-bugs]

Original author: bearmoun...@gmail.com (September 12, 2012 17:01:00)

1. ortho() works fine
2. ortho(0, width, 0, height) seem to be be misaligned
3. ortho(0, width, 0, height, -10, 10) don't seem to show anything

For any practical use of ortho(...) function you must now be followed up with a call to translate(...) with specific coordinates which depend on the left, right, top, and bottom parameters for the ortho call as well as width and height of your window. This is unpractical.

Reproduce:
void setup() {
size(800, 600, OPENGL);
}

void draw() {
float x0 = 124213;
float x1 = x0 + 512;
float y0 = 2342;
float y1 = y0 + 384;
float tx = width/2 + x0;
float ty = height/2 - y1;

ortho(x0, x1, y0, y1);

translate(tx, ty);

background(0x234567);
rect(0, 0, 10, 10);
line(0, 0, width, height);
rect(x1-x0, y1-y0, -10, -10);

}

Version 2.0b3 Mac OSX Mountain Lion 10.8.1

note: I have yet to figure out how to get ortho(left,right,bottom,top,far,near) to display anything.

Original issue: http://code.google.com/p/processing/issues/detail?id=1240

[processing-bugs]

From bearmoun...@gmail.com on September 12, 2012 17:55:03
Above contains error for tx and ty, please use following:

void setup() {
size(800, 600, OPENGL);
}

void draw() {
float x0 = 124213;
float x1 = x0 + 512;
float y0 = 2342;
float y1 = y0 + 384;
float tx = width/2;
float ty = height/2 - y1 - y0;

ortho(x0, x1, y0, y1);

translate(tx, ty);

background(0x234567);
rect(x0, y0, 10, 10);
rect(x1, y1, -10, -10);
line(x0,y0,x1,y1);

}

[processing-bugs]

From andres.c...@gmail.com on September 13, 2012 18:46:18
Hello, what happens is that the left, right, bottom, top arguments in ortho() refer to the center of the screen, with the y-axis inverted with respect to the default orientation in Processing: e.g: botton-to-top instead of top-to-bottom. The reason for this is to follow the convention of the original OpenGL function glOrtho(), in the same way that frustum() follows glFrustum().

For instance, if you need to set the an orthographic projection exactly covering the rectangle starting at the origin and having the same dimensions as the screen size, then you would call ortho(-width/2, +width/2, -height/2, +height/2) (not ortho(0, width, 0, height)).

In general, if you want to set an orthographic projection covering the rectangle determined by the top-left corner (x0, y0) and bottom-right corner (x1, y1), you would need to pass to ortho() the following parameters:
left = x0 - width/2
right = x1 - width/2
bottom = -(y1 - height/2)
top = -(y0 - height/2)
that correspond to the change of coordinates between the system located at the screen center with the Y-axis bottom-to-top, and Processing's system.

So the following code in your example should work:

void setup() {
size(800, 600, P3D);
}

void draw() {
float x0 = 124213;
float x1 = x0 + 512;
float y0 = 2342;
float y1 = y0 + 384;

ortho(x0-width/2, x1-width/2, -(y1-height/2), -(y0-height/2));

background(0x234567);
rect(x0, y0, 10, 10);
rect(x1, y1, -10, -10);
line(x0,y0,x1,y1);
}

[processing-bugs]

From bearmoun...@gmail.com on September 15, 2012 09:12:28
I've looked into the source code and I've figured out what was wrong and this is how it can be solved

Overview

• small change to ortho()
• small change ortho(float,float,float,float)
• revert comment for ortho
• swap and invert bottom and top variables in both main frustum function and main ortho function (the ones that do all the calc)
• add information to reference documentation of ortho() and frustum() about calling resetMatrix()

Discussion
The problems we have previously experienced derive from Processing creates a default camera which is centered at width/2 and height/2. Each frame the camera matrix is added to the modelview matrix in beginDraw. I believe this is desired for most users and sketches. However, we can avoid future misunderstandings regarding this if we add information in the ortho(), frustum() as well as the camera() documentation.

I've looked hard and tested many things for any side effects this change would have, but I've found nothing yet. Doing the suggested changes will make Processing OpenGL work as all others OpenGL implementations. The parameter "bottom" in frustum and ortho really means 'top' since processing y-coordinates is reversed in comparison to cartesian coordinates. The perspective()-function will continue to work as expected.

Details of changes:

In PGraphicsOpenGL.java fix the following:

1. line 4451 frustum(float, float, float, floaf, float, float) function, right after "flush();"
   add
   float temp = -bottom;
   bottom = -top;
   top = temp;
2. line 4380 ortho(float, float, float, floaf, float, float) function, right after "flush();"
   add
   float temp = -bottom;
   bottom = -top;
   top = temp;
3. line 4346:
   change
   ortho(left, right, bottom, top, cameraNear, cameraFar);
   to
   ortho(left, right, bottom, top, -10, 10);
4. line 4335:
   change
   ortho(-width/2, +width/2, -height/2, +height/2, cameraNear, cameraFar);
   to the default as it says in the help text for ortho
   ortho(0, width, 0, height, -10, 10);

Changes to reference documentation

1. in camera() add something along the lines of:
   "camera() is called once automatically when creating 3d context"
2. in ortho() and..
3. in frustum() add something like:
   "camera() is called once automatically when creating 3d context with default values. If this is undesirable you can reset the camera matrix with resetMatrix()".

[processing-bugs]

From andres.c...@gmail.com on September 18, 2012 15:07:36
Thanks a lot for your suggestions. I will pass them along the other member of the team in order to discuss the final form of the ortho() function.

[processing-bugs]

From bearmoun...@gmail.com on October 25, 2012 04:48:57
Is there any update on this issue?

[processing-bugs]

From f...@processing.org on November 25, 2012 02:15:15
Is this actually a problem where ortho() is not behaving like glOrtho/gluOrtho? (and is broken)
http://www.khronos.org/opengles/documentation/opengles1_0/html/glOrtho.html

Or is it just that the method is not as convenient as it could be?

[processing-bugs]

From bearmoun...@gmail.com on November 25, 2012 18:32:46
Short answer: Yes ortho is broken.

Long answer: My suggested changes mentioned above will solve the issue, but I'm not sure it's the most proper way to go at it.

1. One part of the problem is caused by Processing use left handed coordinates compared to OpenGL's right handed coordinate system. I mean, what is "bottom" in processing (as parameters are called in ortho/glOrtho and frustum/glFrustum). Bottom in opengl's right-handed system is both low-y and down compared to "top" parameter when viewed from person eye, but what should it be Processing? It's unclear, and it affects both frustum(), perspective(), ortho() calls. Therefore I cannot say if the most proper way to use ortho is
   ortho(lowX, highX, lowY, highY, nearZ, farZ) or
   ortho(lowX, highX, highY, lowY, nearZ, farZ).
   Though as it is now, neither of them work.

The inverted y axis also affects the camera() function (which is also broken). It's supposed to mimic gluLookAt which you call with eye and lookat positions together with the up direction. But in Processing you call it with eye and lookat pos but with the DOWN direction.

1. The other part is the deafult camera wich you set it to look at center which works for perspective projection but if you want to use ortho you need to reset the camera by resetMatrix. That should be mentioned in the documentation some place.

[processing-bugs]

From caseyr...@gmail.com on December 04, 2012 23:09:32
In regard to the ortho() example in the reference:

size(100, 100, P3D);
noFill();
ortho(0, width, 0, height, -10, 10);
translate(100, 100, 0);
rotateX(-PI/6);
rotateY(PI/3);
box(45);

The current code 2b6 behaves differently. To get the equivalent images in 2b6, the following changes need to be made:

ortho(0, width, 0, height);
translate(width/2, height/2, 0);

[processing-bugs]

From bearmoun...@gmail.com on December 14, 2012 16:25:19
I just tried it with 2.0b7 and I the changes to ortho has once again confused me. This is my workaround that gives "correct" (read below) results:

void simpleOrtho(float xLo, float xHi, float yLo, float yHi, float near, float far) {
resetMatrix(); // get rid of default model view

// calculations according to glOrtho spec
float tx = - (xHi+xLo) / (xHi-xLo);
float ty = - (yHi+yLo) / (yHi-yLo);
float tz = - (far+near) / (far-near);
float a = 2.0/(xHi-xLo);
float b = 2.0/(yHi-yLo);
float c = -2.0/(far-near);

// invert y axis (this is done to account for Processing's different coordinate system than OpenGL)
b = -b;
ty = -ty;

PMatrix3D mat = new PMatrix3D(); 
mat.set(  a, 0.0, 0.0, tx, 
0.0, b, 0.0, ty, 
0.0, 0.0, c, tz, 
0.0, 0.0, 0.0, 1.0);

PGraphicsOpenGL gl = (PGraphicsOpenGL)g;
gl.setProjection(mat);

}

Notice that I've gotten changed the parameter names of "left, right, top, bottom" to avoid confusion. As you can see in the image (from OpenGL red book), the parameter "bottom" is the one that usually corresponds to the plane that is aligned to the lower part of the screen/window, and it makes sense in OpenGL as positive y axis goes upwards. If you want to stay true to the function name and correct order of parameters, ortho would be default as ortho(0,width,height,0,-1,1), but I think it makes more sense to use as I have.

Anyway, hope this can be to some help, and I'm happy to answer any questions.

---

Also, you can check the example sketch I've attached which demonstrates that it works.

[processing-bugs]

From ericthe...@gmail.com on January 09, 2013 18:39:05
I'm running 2.0b7 on a Mac. The example code on the website doesn't produce any visible results, nor does the code in Comment 3. The change in Comment 9 does work.

Is this issue stabilizing & if so could someone update the example?

[codeanticode]

I think that many of the arguments in this discussion boil down to a matter of preference, and also to the idea of following the original gl functions (gluOrtho(), glFustrum, etc). About the latter, it should be noted that GLES 2.0+, GL 3.0+ and WebGL deprecated all those functions, so their value as a model is not very significant at this point.

About perspective() and frustum(): I think they shouldn't be changed. The main reason for this is that many camera libraries that are around use the current "up" convention.

Regarding ortho(), one thing I should note to @alignedleft is that the example in the reference page:

http://trunk.processing.org/reference/ortho_.html

is indeed broken and does not work with the latest revision from the repo.

The following modified example code does work:

size(100, 100, P3D);
noFill();
ortho(0, width, 0, height); // same as ortho()
translate(width/2, height/2, 0);
rotateX(-PI/6);
rotateY(PI/3);
box(45);

Regarding the near and far arguments in ortho(), they now have exactly the same meaning as in perspective(), i.e.: near and far are the distances from the eye of the camera to the near and far planes, respectively (while before they didn't, notice the -10, 10 values used in the example). The following code makes the equivalence more clear:

boolean persp = true;

void setup() {
  size(100, 100, P3D);
  noFill();
}

void draw() {
  background(150);
  float far = map(mouseX, 0, width, 10, 150);
  if (persp) perspective(PI/3.0, float(width)/float(height), 10, far);  
  else ortho(0, width, 0, height, 10, far);
  translate(width/2, height/2, 0);
  rotateX(-PI/6);
  rotateY(PI/3);
  box(45);
}

void keyPressed() {
  persp = !persp;  
}

@benfry, @REAS: let me know if you have any comments about this.

[REAS]

@codeanticode If you think it's the way to do it, it's OK with me. I've just changed the reference entry to include the modified example.

[codeanticode]

great, thank you Casey.

I was thinking that it could be useful to add the last example I mentioned above to the Basic|Camera section. Do you guys agree?

[REAS]

Yes, I'll add it. I will make it 600 x 360 and format it like the rest of the examples. Thanks for making it and sorting this out.