I construct / build an OpenGL object as part of state machine code in “display” .
Had a small issue maximizing the object in window until I found an error in my “reshape” callback function.
I have not ventured into manipulation of viewports , not yet, but that is all the real code in “reshape” - changing the viewport size - does.
Does that means that my object is not being rebuild to fit the new window size, just viewport size is being changed?
It is not that easy to track when the entire screen gets overwritten, and if that is the case it will simplify my code considerably.
Anything that’s rendered is scaled to the viewport. If the viewport’s aspect ratio changes and you don’t change any of the other transformations (model-view and projection matrices), the aspect ratio of rendered objects will change. That’s why you typically take the viewport dimensions into account when constructing the projection matrix.
The first time that a context is bound to a window, the viewport is set to the bounds of the window. Thereafter, it won’t change unless you call glViewport. Typically you either call glViewport in the reshape callback or store the parameters to the reshape callback and call glViewport in the display callback. The reshape callback will always be called at some point between window creation and the first call to the display callback.
Vertex coordinates passed in via glVertex or glVertexPointer are in object space. These are transformed by the model-view matrix to eye space, then by the projection matrix to clip space. Projective division (division of the x, y and z components by w) yields normalised device coordinates (NDC). For vertices which survive (or are generated by) clipping, these coordinates will always be between -1 and +1. Finally, the x and y coordinates are transformed by the viewport transformation to obtain window coordinates (in pixels, with the origin in the lower-left corner).
Thanks , but this all is little to hard to envision.
(I still like to know little more about relation between OpenGL window status bar menu and OpenGL.)
Maybe because I really do not deal with vertex coordinates .
In an essence - base of my application has only ONE vertex - describing a point in X / Y coordinates .
By changing the coordinates such vertex builds a primitive - circle or polygon.
By modifying other pipe parameters - color , scale , translation I build a set of circles .
Farther modification results is several sets of these circles.
More modifications - rotation and translation and I get two more sets…
Still missing some.
So I go from single vertex to basic Smith chart…
So for me the concept of "from vertex to display / viewport " is still there , but gets covered under all these "functions, translations and subroutines " C language concepts.
But knowing that the object (context) does not have to be rebuild each time different part of the chart needs to be highlighted will make the code much easier
Here is a proof that I still do not understand the “reshape” callback process.
The attached code draws required sets of circles just fine.
However, the “window” “maximize” draws miniature something around NDC 1,0.
I suspect the function leaves the OpenGL matrix view in last “half scale” processed.
How do I restore whatever (vieport ?) back to full scale?
Non of the code does any push / pop operations.
I have no issues maximizing a single vertex loop, so I assume my “reshape” code is correct.
// start process
{ // draw real axis of max scale
for (scale = 0; scale != MAX_SCALE; scale++) {
{ // single scale
printf("\n scale %i ", scale);
OpenGL_Draw_10_Circles(
1, // point size
3, // selection highlight
0, // apply to circle
0, // future option
1, // stadard red
0, // green,
0 //float blue )
);
}
// next scale
glScalef(.5, .5, .5);
// translate
glTranslatef(1, 0, 0);
// next scale
}
}
glFlush();
// this does not restore to fulls scale
glPushMatrix();
glLoadIdentity();
glScalef(1,1,1);
glPopMatrix();
// end process
glPushMatrix();
glLoadIdentity();
glScalef(1,1,1);
glPopMatrix();
This sequence of commands does:
- save the current matrix to the top of the matrix stack (
glPushMatrix)
- reset the current matrix (which starts out as a copy of the previous one) to the identity matrix (
glLoadIdentity)
- multiply the current matrix with a matrix that applies a scale factor of 1 along each axis (which of course is also an identity matrix) and make the result the new current matrix (still an identity). (
glScalef)
- restore the current matrix to the value of the topmost one on the stack (i.e. whatever matrix you saved with
glPushMatrix) and remove the topmost matrix from the stack (glPopMatrix).
In other words the sequence is a no-op.
1 Like
OK, so do I have to enclose the previous operations in push / pop matrix and then reset the last scale back to normal?
It seems there should be a way to restore to full scale after the vertexes are rendered / flushed.
The window maximize does not work when either scale or translate is applied in “outer” loop.
If you push the matrix before your for loop and pop it after it will be back to the state it had before you pushed it. If it was an identity matrix or some other matrix that does not apply any scaling you will be back in a state where the current matrix applies no scaling
Calling glScalef(1.0f, 1.0f, 1.0f) does not reset the scaling factors of the current matrix to (1,1,1), it multiples the current matrix with a scaling matrix and makes the product the new current matrix. If you apply this sequence of commands:
glLoadIdentity();
glScalef(2.0f, 2.0f, 2.0f);
glScalef(1.0f, 1.0f, 1.0f);
The current matrix will still scale everything by a factor of 2 along each axis. The product of a matrix that scales by 2 along each axis with a matrix that scales by 1 along each axis is still a matrix that scales by 2 along each axis.
OK, the solution is to do the “loop” in its own matrix , where scale and translation is applied.
I actually see an analogy with C - applying local (matrix) variables inside push / pop enclosure.
I may put these loops back into functions back where they came from before my code broke.