I call ResizeScene initially in setting up. I call it when the user resizes the window. Everything is fine after the first call, but after a second call to ResizeScene, my nice rotating triangle is no longer visible. Could someone look at the relevant code below and maybe spot why that happens? I had this working right before, but I lost my source code and started over from scratch. This time around it doesn’t work right.
Public Sub Triangle()
Gl.glColor3f(1, 0, 0) : Gl.glVertex3f(0, 1, 0)
Gl.glColor3f(0, 1, 0) : Gl.glVertex3f(0.87, -0.5, 0)
Gl.glColor3f(0, 0, 1) : Gl.glVertex3f(-0.87, -0.5, 0)
Private Sub DrawScene()
Gl.glRotatef(ElapsedTime * 0.1, 0, 0, 1)
Public Sub ResizeScene(ByVal w As Integer, ByVal h As Integer)
If h = 0 Then h = 1
Gl.glViewport(0, 0, w, h)
Glu.gluPerspective(45.0, w / h, 1.0, 100.0)
>Just before window resizing do you see the triangle rotating?
Yes, until I grab the corner of the window and stretch it, the triangle rotates at a nice constant speed, about the z-axis, facing the viewer.
>have you enabled the depth test?
No, I hadn’t. Now I have, and use GL_LEQUAL as my dpeth func. No change.
>So why don’t you put 1.0 for the aspect ration instead of w/h ??
In the general case, I make the viewport match the client area of the window. It so happens, in this app, I force a square window client area, so w=h, therefore the aspect ratio is always 1.
>Just to be sure, I suppoze you have already done this, have you
>the same problem with 1.0 for aspect ratio?
Yes I did, and Yes, the problem remained.
>How do you create your window? using glut, win api, …?
Ultimately win api, via .Net
>It looks like that after resizing the window is not redrawn by
>opengl, are you sure that the ogl draw function is called? You
>can put a printf or cout in the draw function (hardcore but
I have tested this, and yes, the OpenGL drawing is still called.
Maybe you can try removing the glFlush call. I remember that some implementations swap buffers on a glFlush call. This would mean you are swapping the buffer twice. I know it’s far fetched, but it’s strange that something this simple doesn’t work…
Aha! Are you sure your ResizeScene function is getting called at startup? Going by the coordinates of your triangle vertices, I doubt that your triangle will be inside the view frustum of your gluPerspective call…
>you sure your ResizeScene function is getting called at startup
Yes, I confirmed that.
>I doubt that your triangle will be inside the view frustum of >your gluPerspective call…
I think you are on to something, there. Though the call to ResizeScene is definitely made at startup, it appears that Glu.gluPerspective(45.0, w / h, 1.0, 100.0) has no effect. If it worked, the near plane is at 1 and the far plane is at 100 on the z-axis, so only something inside that region would be visible. My triangle is drawn at z=0, so it should not be visible Ever!
I ran a test. Every second, the FPS is calcuated and shown in the window caption. I added code to translate the triangle along the z-axis by 0.1 each second. The triangle remains visible from -1.0 to +1.0, but if it goes to + or - 1.1 it vanishes.
It appears I have a default glOrtho, though I never call glOrtho, and I DO call gluPerspective (which I believe calls glFrustrum behind the scenes). Resizing, ever so slightly, messes something up with that uncalled and unwanted glOrtho.
The default ortho setup corresponds to an identity matrix for the projection. So my guess is that the resize function is called at startup, but that you don’t have a vaild OpenGL context at that time. Therefore the GL commands issued at startup will have no effect, resulting in the default ortho setup.
>but that you don’t have a vaild OpenGL context at that time
You nailed it! The resize was being called at an unexpected time before I had done my gl setup. I have set some flags and re-ordered some code to prevent the first call from happening before my context is ready. Now it works fine. Thanks for your help!