• Advertisement
Sign in to follow this  

HELP!!! Basic glOrtho problem!

This topic is 3892 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, can anyone explain to me why this code doesn't generate a visible red line from the left bottom to the top right corner of my window? void initGL() { glClearColor(0.0f, 0.0f, 0.0f, 1.0f); // Black background glMatrixMode(GL_PROJECTION); glLoadIdentity(); glOrtho(0.f, 1.f, 0.f, 1.f, 0.f, 1.f); glMatrixMode(GL_MODELVIEW); } void display() { glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); // Clear screen and depth buffer glColor4f(1.0f, 0.0f, 0.0f, 1.0f); glBegin(GL_LINES); glVertex3f(0.0f, 0.0f, 0.0f); glVertex3f(1.0f, 1.0f, 1.0f); glEnd(); glFlush(); } int main(int argc, char** argv) // Create main function for bringing it all together { glutInit(&argc, argv); glutInitDisplayMode(GLUT_RGB); // Display mode glutInitWindowSize(500, 500); glutCreateWindow("Aufgabe ?"); initGL(); glutDisplayFunc(display); glutReshapeFunc(reshape); glutKeyboardFunc(key); // callback for key input // glutIdleFunc(display); // If continuous animation is required glutMainLoop(); // Initialize the main loop } As you can see, I have specified the viewable volume as a cube of length one, one corner at (0, 0, 0), the other one at (1, 1, 1). I'm drawing the diagonal line through these two corners, so what I should expect on the 2D window surface is a diagonal line across the window. Why isn't this happening? My window remains BLACK. Please help. This is such a simple thing, and I'm stuck at this already. Cheers Marvin

Share this post


Link to post
Share on other sites
Advertisement
glOrtho(left, right, bottom, top, 0,1)

can't remember what the 0 and 1 were, think they were near and far planes for z-buffering or something.

left and top are usually 0, bottom equates to the height of the paint surface (SCREEN_HEIGHT, usually) and right equates to the width of the paint surface (SCREEN_WIDTH)


Used this for a sniper scope once, I also had a glLoadIdentity() after switching to modelview matrix.

I hope that helps. let me know if it doesnt.

Share this post


Link to post
Share on other sites
oh, yeah.

ok, here's what I had, or some of it


glMatrixMode(GL_PROJECTION);

glPushMatrix();

glLoadIdentity();


glOrtho( 0, SCREEN_WIDTH, SCREEN_HEIGHT, 0, 0, 1 );


glMatrixMode(GL_MODELVIEW);

glLoadIdentity();


//do drawing code here, My code disables the depth test here


glMatrixMode( GL_PROJECTION );

glPopMatrix();
glMatrixMode( GL_MODELVIEW );




Share this post


Link to post
Share on other sites
I'm confused with how that code fits into your first code. It says do drawing code here which implies it goes into the drawing function. But there's no trace of that in the code you initially posted. So how is it, is the first code REALLY the one you use?

Anyway, if that goes into the reshape function, you reset the projection matrix and replace it with another one. The new coordinate system ranges from 0 to screen width/height, but you're drawing the line from 0 to 1. Look closely and you will probably see a small red pixel in the upper right corner. That is your 1 pixel long line.

If this is not the reshape function, then please, post the real code.

Share this post


Link to post
Share on other sites
It looks like you line is being clipped.

Use
glOrtho(0.f, 1.f, 0.f, 1.f, -1.f, 1.f);
or change the display code to:
glBegin(GL_LINES);
glVertex3f(0.0f, 0.0f, 0.0f);
glVertex3f(1.0f, 1.0f, -1.0f);
glEnd();


Basically the view being rendered from the current modelview matrix is at position (0,0,0) looking towards -z. Your line is at 0,0,0 going towards +z. This means your line eventually gets clipped because it's behind the viewer. Read up on glOrtho() to see why this happens.

Some people set up a camera in the modelview matrix (ie. gluLookAt) so that the view is rendered looking towards the +z axis. Or they just set up a translation to neg-z(glTranslatef(0,0,-5).

If you're going to use double-buffer then you also need to call glutSwapBuffers() after the drawing code.

Good Luck.

[Edited by - Jack Sotac on June 26, 2007 5:57:22 PM]

Share this post


Link to post
Share on other sites
sorry bob, I think you have mistaken me for the thread starter, Merowingian.

I was trying to post a solution. (I didn't ever rally use GLUT, so I missed your point about the reshape method)

sorry Merowingian, hope I didn't also confuse you.

Share this post


Link to post
Share on other sites
Quote:
Original post by TheUmpteenth
sorry bob, I think you have mistaken me for the thread starter, Merowingian.

I was trying to post a solution. (I didn't ever rally use GLUT, so I missed your point about the reshape method)

sorry Merowingian, hope I didn't also confuse you.


Hah, you're so right. I mean, I asked for the reshape callback and I got something that looked like a callback along with an oh, yeah, sort of like an apology for forgetting to post it in the first place. Never mind my last post then, but my initial question to the real OP still stands...

Share this post


Link to post
Share on other sites
@Brother Bob

My reshape function doesn´t do anything other than calling the display function.



@Jack Sotac

Hey, I think some penny dropped now!!!

I really didn´t know the default GL_MODELVIEW looks to the negative z-Axis.

However, I then tried to "neutralize" the GL_MODELVIEW by applying a glLoadIdentity() to it, like you said some programmers would do.
But for some strange reason that didn´t change anything. Looks like OpenGL has it´s way of multiplying GL_MODELVIEW with some "hidden" matrix, making the z-Axis negative, whether you like it or not. GL_MODELVIEW by default seems to be looking to the correct direction (to the positive z-Axis, that is towards us), but is obviously secretly multiplied by that hidden matrix I just mentioned. So you could just multiply GL_MODELVIEW with the same z-flipping matrix again.

But anyway, I think there´s a good reason for leaving GL_MODELVIEW the way it is. Let a bigger z-value in glVertex() indicate that something is further away from us.

So at the current state of my program, I have considered the camera view of GL_MODELVIEW and changed that front value to 0, the back one to -1. It is not necessary to make it front 1 and back -1, since my line begins at 0.

And it works like a charm ;-)

Thanks everybody!!!

Share this post


Link to post
Share on other sites
There is no hidden multiplication or anything that turns the Z-axis into the direction you didn't expect. It's just the way it is by default.

You see, the Z-axis can point in two directions (assuming X and Y are left/right and up/down), that is into the screen and out of the screen. Which one is correct? OpenGL decided that it should point out of the screen.

The confusing part here is not that the Z-axis is pointing out from the screen. It is that the near and far planes doesn't define where along the Z-axis you want to place them, but they specifies a distance along the negative Z-axis. This has fooled me several times aswell, including this thread. You specified a Z-far distance of 1, which means 1 unit along the negative Z-axis, which places it at Z=-1.

So the depth range of your initial projection matrix was from 0 (near clip plane) to -1 (far clip plane). That is the confusing part here, not that the Z-axis is pointing out from the screen.

And realy, why are you calling the display function in the reshape callback? The display callback is called when needed. Don't do it manually.

Share this post


Link to post
Share on other sites
Ahh, good to know. I think the penny dropped again, but this time it's head, not tail ;-)

Well, looks like it's not THAT complicated then. I was trying to find some complicated and wrong explanation, but you have made it much clearer to me.


As for reshape(), I was still going to use it for changing the viewport to full window size always. And you need a display() call after that to draw everything afresh, don't you?

Share this post


Link to post
Share on other sites
Yes, the display callback needs to be called after a reshape. But GLUT, being a window handling API, already knows that you need to redraw the window and will call your display callback after the reshape callback.

Share this post


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

  • Advertisement