OpenGL function need to be called twice to take effect - c++

I have a QWindow which lives in one thread and then I have another class that renders on that QWindow surface from another thread.
I did call XInitThreads() in main function before anything else. I created the QOpenGLContext in that QWindow class and then moved it (moveToThread) to the render thread where I made it current. Now I'm trying to just clean the screen and set the colour, but when I call the glClear and glClearColor it gets totally ignored for the first time (no error, no crash, no nothing), I need to call it second time for that functions to take effect. Also after I call it two times it clear the screen and set the colour, but if I want to set the colour to a different one I need to do it twice again in order to take effect.
I'm swapping the buffer correctly, and I know that the first time I call the glclear* that it gets ignored, because after I swap the buffer for the first time there is a random noise on the screen window (which shouldn't be there after glclear).
Here is the initialization in the QWindow subclass:
void OpenGLWindow::initialize()
{
if (!m_context) {
m_context = new QOpenGLContext();
m_context->setFormat(requestedFormat());
m_context->create();
}
thread = new ThreadHelper(m_context, this);
m_context->moveToThread(thread);
thread->start();
}
And here is the rendering class:
ThreadHelper::ThreadHelper(QOpenGLContext *context, OpenGLWindow *window) :
m_context(context),
m_window(window)
{
}
void ThreadHelper::run()
{
m_context->makeCurrent(m_window);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);
glClearColor(1.0, 0.0, 0.0, 0.5);
// in order to take effect this have to be called for the second time
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);
glClearColor(1.0, 0.0, 0.0, 0.5);
swapOpenGLBuffers();
}
void ThreadHelper::swapOpenGLBuffers()
{
m_context->swapBuffers(m_window);
}
Does anybody know how to solve this? I'm using qt5.2.1, tried this on intel and nvidia graphics and the result was the same.
Thanks for any help.

glClear will use the currently set clear color for clearing the color buffer (which is set via glClearColor). So your first clear call will just use the old/default clear color, the second one will have the effect you intend it to have and the additional glClearColor is just redundant. Just swap the order of the first two lines and remove your duplicated code.

Related

C++ opengl intersecting glScissor

A Project I am working on involves me using glScissor, in some cases i need to perform a scissor on an area twice (or more), with the goal of only rendering what is within both scissor boxes.
The issue im running into is that the second scissor box just overrides the previous one, meaning only the last box set is used instead of both.
I have tried existing solutions such as setting scissor1, push matrix, enable scissor_test, set scissor2, disable scissor_test, popmatrix, disable scissor_test. As proposed here: glScissor() call inside another glScissor()
I could not get these to produce any difference, I had also tried glPushAttrib instead of matrix but still no difference.
Here is an example program I wrote for scissor testing, its compiled by g++ and uses freeglut, the scissoring takes place in display():
/*
Compile: g++ .\scissor.cpp -lglu32 -lfreeglut -lopengl32
*/
#include <GL/gl.h>//standard from mingw, already in glut.h - header library
#include <GL/glu.h>//standard from mingw, already in glut.h - utility library
#include <GL/glut.h>//glut/freeglut - more utilities, utility tool kit
void display();
void reshape(int, int);
void timer(int);
void init(){
glClearColor(0, 0, 0, 1);
}
int main(int argc, char **argv){
glutInit(&argc, argv);//init glut
glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE);//init display mode, add double buffer mode
//init window
glutInitWindowPosition(200, 100);//if not specified, it will display in a random spot
glutInitWindowSize(500, 500);//size
//create window
glutCreateWindow("Window 1");
//give glut a function pointer so it can call that function later
glutDisplayFunc(display);
glutReshapeFunc(reshape);
glutTimerFunc(0, timer, 0);//call certain function after a specified amount of time
init();
glutMainLoop();//once this loop runs your program has started running, when the loop ends the program terminates
}
float xPos = -10;
int state = 1;//1 = right, -1 = left
//our rendering happens here
void display(){
//clear previous frame
glClear(GL_COLOR_BUFFER_BIT);//pass in flag of frame buffer
//draw next frame below
glLoadIdentity();//reset rotations, transformations, ect. (resets coordinate system)
//we are using a model view matrix by default
//TEST
glEnable(GL_SCISSOR_TEST);
glScissor(0, 0, 100, 1000);
glPushMatrix();
glEnable(GL_SCISSOR_TEST);
glScissor(50, 0, 1000, 1000);
//assuming both scissors intersect, we should only see the square between 50 and 100 pixels
//draw
glBegin(GL_QUADS);//every set of 3 verticies is a triangle
//GL_TRIANGLES = 3 points
//GL_QUADS = 4 points
//GL_POLYGON = any amount of points
glVertex2f(xPos, 1);//the 2 is the amount of args we pass in, the f means theyr floats
glVertex2f(xPos, -1);
glVertex2f(xPos+2, -1);
glVertex2f(xPos+2, 1);
glEnd();//tell opengl your done drawing verticies
glDisable(GL_SCISSOR_TEST);
glPopMatrix();
glDisable(GL_SCISSOR_TEST);
//display frame buffer on screen
//glFlush();
glutSwapBuffers();//if double buffering, call swap buffers instead of flush
}
//gets called when window is reshaped
void reshape(int width, int hight){
//set viewport and projection
//viewport is a rectangle where everything is drawn, like its the window
glViewport(0, 0, width, hight);
//matrix modes: there is model view and projection, projection has depth
glMatrixMode(GL_PROJECTION);
glLoadIdentity();//reset current matrix after changing matrix mode
gluOrtho2D(-10, 10, -10, 10);//specify 2d projection, set opengl's coordinate system
glMatrixMode(GL_MODELVIEW);//change back to model view
}
//this like makes a loop
void timer(int a){
glutPostRedisplay();//opengl will call the display function the next time it gets the chance
glutTimerFunc(1000/60, timer, 0);
//update positions and stuff
//this can be done here or in the display function
switch(state){
case 1:
if(xPos < 8)
xPos += 0.15;
else
state = -1;
break;
case -1:
if(xPos > -10)
xPos -= 0.15;
else
state = 1;
break;
}
}
I tried following example solutions, such as push/pop matrix/attrib, but couldnt get anything to work
There is no first or second scissor box. There is just the scissor box. You can change the scissor box and that change will affect subsequent rendering. But at any one time, there is only one.
What you want is to use the stencil buffer to discard fragments outside of an area defined by rendering certain values into the stencil buffer.

libQGLViewer how to draw withouth clearing buffer

I'm using libQGLViewer in my project to draw the trajectory of a robot. To this end, I started from the code of the simpleViewer provided in the examples.
To do my stuff, I put these lines of code in the draw function:
void Viewer::draw()
{
glPushMatrix();
for (auto pose : poses)
{
std::vector<float> m;
poseToVector(pose, m);
glPushMatrix();
multMatrix(m);
drawReferenceSystem();
glPopMatrix();
}
glPopMatrix();
}
where the poseToVector, multMatrix and drawReferenceSystem functions are OpenGL wrappers to implement the desired functionalities.
Now, my problem is that the poses vector is filled at each iteration of my code with a new pose. Thus, what I'm doing now is that at iteration 1 I'm drawing pose 1, at iteration 2 I'm drawing pose 1 and 2, at iteration 3 I'm drawing pose 1,2 and 3, and so on.
For this reason, I was wondering if there was a more efficient way to perform this operation. However, if I just get the back of the vector I will see at each time instant only the last pose. I guess that this is because every time the draw function is called the frame buffer is cleared.
Therefore, my question is: is it possible to avoid clearing the buffer or I'm just saying bullshit?
preDraw clears the screen and resets matrices.
You could subclass QGLViewer and override it to drop the clearing behavior.
The default implementation is:
void QGLViewer::preDraw() {
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); // this line should be removed here or in a sublass.
// GL_PROJECTION matrix
camera()->loadProjectionMatrix();
// GL_MODELVIEW matrix
camera()->loadModelViewMatrix();
Q_EMIT drawNeeded();
}

Initialise a QGLWidget with a glClearColor

I have a QMainWindow with a QGLWidget in it. I want the widget to display a 'clear' colour of my own choice, instead of the default black screen.
void MyQGLWidget::initializeGL(void) {
glClearColor(0.7f, 0.7f, 0.7f, 1.0f);
}
void MyQGLWidget::paintGL(void) {
qDebug("Painting grey-ness");
glClear(GL_COLOR_BUFFER_BIT);
// ... Do more stuff, but only after a certain event has happened ...
}
This works, and I noticed that the method is called 4 times during the start-up. However, I only want to paint it blank once in the paintGL() method, because this method is being called very often after the start-up, and there actually is small but significant performance loss if the buffers are cleared at every call.
So I changed the code to this:
void MyQGLWidget::paintGL(void) {
static bool screenOnBlank = false;
if (!screenOnBlank) {
qDebug("Painting grey-ness");
glClear(GL_COLOR_BUFFER_BIT);
screenOnBlank = true;
}
// ... Do more stuff, but only after a certain event has happened ...
}
Now the clearing is only done once, but I am left with a black screen, rather that with the grey screen of glClearColor. Why is this? Why does QGLWidget paint my screen black again? And more importantly, how can I make sure the screen is my own default colour, without repainting it blank at every time step?
Short answer:
In most platforms, the state of your backbuffer is undefined after performing a buffer swap. You can find more details here. Hence, you cannot rely on the behaviour that your buffer remains as you left it before the swap operations. Then, to ensure your program is cross-platform, you have no other choice than calling glClear() at each drawing.
In practice:
It is possible that your platform/configuration do guarantee that your buffer is unchanged, or don't guarantee it but it is still the case in practice. If you know you are in those cases after experimenting (see below), but still have your screen turned black, it means that somehow in your code, you did something "wrong" that makes Qt explicitly call glClear() with its own glClearColor().
You can use this code to see if the buffer remains unchanged after swapBuffers(). It is actually the case in my configuration: Qt 4.8 on Linux 64bits:
// -------- main.cpp --------
#include <QApplication>
#include "GLWidget.h"
int main(int argc, char ** argv)
{
QApplication app(argc, argv);
GLWidget * w = new GLWidget();
w->show();
return app.exec();
}
// -------- GLWidget.h --------
#include <QGLWidget>
#include <QTimer>
class GLWidget: public QGLWidget
{
Q_OBJECT
public:
GLWidget() : i(0), N(60)
{
timer.setInterval(16);
connect(&timer, SIGNAL(timeout()),
this, SLOT(animationLoop()));
timer.start();
}
protected:
void initializeGL()
{
glClearColor(1.0, 0.0, 0.0, 1.0);
}
void resizeGL(int w, int h)
{
glViewport(0, 0, (GLint)w, (GLint)h);
}
void paintGL()
{
bool test = false;
if(i<N)
{
if(test)
glClearColor(1.0, 0.0, 0.0, 1.0);
glClear(GL_COLOR_BUFFER_BIT);
}
else
{
if(test)
{
glClearColor(0.0, 1.0, 0.0, 1.0);
glClear(GL_COLOR_BUFFER_BIT);
}
}
}
private slots:
void animationLoop()
{
i++;
if(i>2*N) i=0;
updateGL();
}
private:
int i, N;
QTimer timer;
};
if test == true, then I always call glClearColor() followed by glClear(), but alternating between a red color and a green color every second. I indeed see the color switching back and forth between red and green.
if test == false, then I only call glClearColor() once and for all in initializeGL(). Then in paintGL, I alternate between calling glClear() or not calling it. The screen stays red, i.e. never turns black (or display a unicorn) even when glClear() is not called.
Hence, regarding your problem:
Either your configuration is different than mine (the implementation of swapBuffers is provided by Qt and differs according to the underlying window system)
Or your code is broken.
Simple way to check: compile my code, and see if it still reproduces the issue. If it does, then you are in case 1., and there is nothing you can do about it (can be considered a bug of Qt, of rather an inconsistency, since the correct behaviour is not specified anywhere in the documentation). Otherwise, you are in case 2., and then you should provide more of your code so we could determine where is the issue.

opengl glutWireTorus artifact

I am working on a small animation of a sinewave being generated by a moving circle similar to this gif.
However I'm having a weird issue with using glutWireTorus for the circle. Even when I comment out all the other drawing code and leave the torus moving along the z axis alone, I get flashing lines on the inside of it:
This is the display function where everything is drawn. I use the display function as my idle function, also, I checked if that was the issue by creating an idle function and putting my update code there but it still persisted.
void display(void)
{
glClearColor(0.f,0.f,0.f,0.f);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); // clear the color buffer
and the depth buffer
glLoadIdentity();
glTranslatef(0.0f,0.0f,-5.0f); //Push everything back 5 units into the scene,
otherwise we won't see the primitive
camera();
//yPrev = myCircle.y;
glPushMatrix();
glTranslatef(0.0f,0.0f,t);
glutWireTorus(0.02,1,100,100);
glPopMatrix();
DrawAxes();
glutSwapBuffers(); //swap the buffers
glFlush();//Flush the OpenGL buffers to the window
t-=0.002;
if (t < -T)
{
t = 0;
}
}
Uh, interesting, I run into the same problem.
Here is the picture using parameter
glutWireTorus(/*innerRadius*/0.3, /*outerRadius*/0.5, /*nsides*/32, /*rings*/32);
another picture using parameter
glutWireTorus(/*innerRadius*/0.3, /*outerRadius*/0.5, /*nsides*/64, /*rings*/128);
We don't know why without glutWireTorus function implementation, but we can implements our own torus, or maybe someone can explain it?

Windows OpenGL implementation bug?

I am having a very tough time sorting out this strange clipping bug in my app.
Basically, for some reason, OpenGL is clipping (using the scissor test) my call to glClear(), but not the rendering I do afterwards.
The real problem, however, is that the problem goes away when I resize my window. I can guarantee that resizing the window doesn't change anything in my app or run any code. It is very stange. Worse still, simply putting
glDisable(GL_SCISSOR_TEST);
glDisable(GL_SCISSOR_TEST);
where I need to disable the scissor test, instead of having just one call to glDisable() solves the problem. So does removing the code all together (the scissor test is already disabled in this test case, but the code is there for when it wasn't left to disabled in previous code). It even solves the problem to put:
glEnable(GL_SCISSOR_TEST);
glDisable(GL_SCISSOR_TEST);
There are only two explanations I can think of. Either I am somehow calling UB (which I doubt, because opengl doesn't have UB AFAIK), or there is an implementation bug, because calling glDisable() twice with the same parameter consecutively SHOULD be the same as calling it once... if I'm not mistaken.
JUST incase it is of interest, here is the function for which the problem is happening:
void gle::Renderer::setup3DCamera(gle::CameraNode& cam, gle::Colour bkcol,
int clrmask, int skymode, gle::Texture* skytex, bool uselight) {
// Viewport
Rectangle wr(cam.getViewport()?*cam.getViewport():Rectangle(0,0,1,1));
if (cam.isRatioViewport()||(!cam.getViewport())) {
if (i_frameBind==NULL)
wr.scale(selectedWindow->getWidth(),selectedWindow->getHeight());
else wr.scale(i_frameBind->getWidth(),i_frameBind->getHeight());
}
gle::Rectangle_t<int> iport; iport.set(wr);
int winHei;
if (i_frameBind==NULL)
winHei = selectedWindow->getHeight();
else
winHei = i_frameBind->getHeight();
glViewport(iport.x1(),winHei-iport.y2(),iport.wid(),iport.hei());
// Viewport Clipping
if (cam.isClipping()) {
/* This is never executed in the test case */
glEnable(GL_SCISSOR_TEST);
glScissor(iport.x1(),winHei-iport.y2(),iport.wid(),iport.hei());
} else {
/* This is where I disable the scissor test */
glDisable(GL_SCISSOR_TEST);
glDisable(GL_SCISSOR_TEST);
}
float w=wr.wid()/2, h=wr.hei()/2;
// Projection
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
Projection proj = cam.getProjection();
gluPerspective(proj.fov,proj.aspect*(w/h),proj.cnear,proj.cfar);
// Camera
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
float m[] = { 1,0,0,0, 0,0,-1,0, 0,1,0,0, 0,0,0,1 };
glMultMatrixf(m);
static gle::Mesh *skyBox = NULL;
// Screen Clearing
switch (clrmask&GLE_CLR_COLOUR&0x00F?skymode:GLE_SKYNONE) {
case GLE_SKYNONE:
clear(clrmask&(~GLE_CLR_COLOUR)); break;
case GLE_SKYCOLOUR:
clearColour(clrmask,bkcol); break;
case GLE_SKYBOX:
glDisable(GL_DEPTH_TEST);
if (!(clrmask&GLE_CLR_DEPTH&0x00F)) glDepthMask(0);
float m = (cam.getProjection().cnear+cam.getProjection().cfar)/2.0f;
if (skyBox==NULL) skyBox = gle::createStockMesh(GLE_MESHSKYBOX,GLE_WHITE,0,m);
glEnable(GL_TEXTURE_2D);
glDisable(GL_CULL_FACE);
skytex->flush();
glBindTexture(GL_TEXTURE_2D,skytex->getID());
glDisable(GL_LIGHTING);
glPushMatrix();
float m3[16];
Orientation::matrixSet(m3,cam.pos().getMatrix(GLE_ROTMATRIX));
Orientation::matrixTranspose(m3);
glMultMatrixf(m3);
if (i_reflectionOn) glMultMatrixf(Orientation::matrixGet3x3(i_reflectionTransform));
renderMesh(*skyBox,NULL,1);
glPopMatrix();
glDisable(GL_TEXTURE_2D);
if (clrmask&GLE_CLR_DEPTH) glClear(GL_DEPTH_BUFFER_BIT);
else glDepthMask(1);
glAble(GL_DEPTH_TEST,depthmode!=GLE_ALWAYS);
break;
}
// Camera
glMultMatrixf(cam.getAbsInverseMatrix());
if (i_reflectionOn) glMultMatrixf(i_reflectionTransform);
// Lighting
i_lightOn = uselight;
glAble(GL_LIGHTING,i_lightOn);
}
This looks like a driver bug to me. However, there are two cases where this may actually be a bug in your code.
First, you might be in the middle of the glBegin() / glEnd() block when calling that glDisable(), causing some error and also ending the block, effectively making the second call to glDisable() legit and effective. Note that this is a dumb example with glBegin() / glEnd(), it could be pretty much any case of OpenGL error being caught. Insert glGetError() calls throughout your code to be sure. My guess is the first call to glDisable() generates GL_INVALID_OPERATION.
Second, you are not scissor testing, but you are still calling glViewport() with the same values. This would have the opposite effect (not clip glClear() and clip drawing) on NVIDIA, but it might very well be it does the opposite on some other driver / GL implementation.