You should not call GUI function from a different thread. Signal and slots is the way to go.

Yup, looks like you've spotted it -- in particular, the specular term is materialSpecularColor * lightStrength * pow(cosAlpha, 10) That's the part that will contribute to the shininess of the material. And, materialSpecularColor comes from highp vec3 materialSpecularColor = lightColor.rgb; which is to say that the materialSpecularColor in that shader is not really a property of the material since the value is just from the lighting. Not really the clearest name if you are trying to pick it apart. This type of look is traditionally used for a plastic type material which has white highlights for white lights regardless of the color of the material. If you want something a bit more metallic looking, you can multiply the lightcolor.rgb by some actual material color. This lighting model is a bit of an old school aphysical hack, so you may want to look into to more modern physically based lighting models if you are looking for more realism. But the classic specular + diffuse model is way simpler to understand even if it isn't super accurate to the real world.

@sierdzio Ok, i see, I'm using open source. Maybe I need to change a deviece or try to use qwidget. Thanks for your patience.

@Julius-Aetherwing Sorry, I'm not familiar with OpenGL, too. But you can find some example code in Qt install dir, something like "C:\Qt\Examples\Qt-5.12.6\opengl" The docs of the examples can be found in All Qt Examples

@fcarney said in Poor quality colored emojis, how to fix that?: font.hintingPreference: Font.PreferNoHinting Wow excellent! This resolved my issue. Thank you very much

That's becoming even more weird: GLFunctions::gl30()->glGenTextures(1, &texHandle); returns 2 in texHandle. but for using it in the shader it works for a value of 1 in the bindTexture GLFunctions::gl30()->glBindTexture(GL_TEXTURE_2D, texHandle-1); This is driving me nuts.

What processing are you doing with OpenCV ?

For those who end up looking here : It seems that this is a Qt 5.6 bug, it works fine in Qt 5.14 Edit : The bug itself may be related to the use of QSurfaceFormat::setDefaultFormat after application startup : Qt 5.14 warned me about a piece of code I was not aware saying that it could cause context sharing issues. Having it removed seems to have solved the bug when i got back to Qt 5.6

@Chris-Kawa ah ok that worked and learned something new thanks

Thanks, so that is what "OpenGL-based composing" does under the hood! Is there any way to synchronize/batch my QGraphicsView updates, so that there is less of a performance impact? Or would it be preferable to switch the QGraphicsView-based widgets over to render their scene via OpenGL?

@Patterson sure, I will get more details on this and post here

@yijia Maybe with different QLabel and QPixmap or QPicture https://doc.qt.io/qt-5/qlabel.html#pixmap-prop https://doc.qt.io/qt-5/qlabel.html#setPicture

Alright after developing spine problems from leaning into my screen for a week and losing more hair than my GPU has cores, I sort of fixed the issue. So for some reason when I was reading data into my textures without setting the active texture back to the GL_TEXTURE0 default, things were going sideways. So basically I had something like: glActiveTexture(GL_TEXTURE0 + inputTextureUnit[vid]); glBindTexture(GL_TEXTURE_2D, inputTextureID[vid]); glTexImage2D(GL_TEXTURE_2D, 0, GL_internalFormat[vid], videoSpecs[vid].videoWidth, videoSpecs[vid].videoHeight, 0, GL_format[vid], GL_UNSIGNED_BYTE, (const void*)(frame)); But this was missing at the end: glBindTexture(GL_TEXTURE_2D, 0); glActiveTexture(GL_TEXTURE0); But I'm not 100% convinced that this is the cause because if I read still images, there is no issue. Its only when I read videos that I see the flickering and black texture issue. It seems like when other widgets start rendering and there is a texture active, they somehow corrupt it but I would certainly appreciate it if anyone has input on what actually might be happening.

I did in fact have to call glDrawBuffers myself. I assumed this was handled by the FBO binding, but apparently not. QOpenGLExtraFunctions* f = QOpenGLContext::currentContext()->extraFunctions(); GLenum bufs[2] = { GL_COLOR_ATTACHMENT0, GL_COLOR_ATTACHMENT1 }; f->glDrawBuffers(2, bufs); This seems strange to me that the FBO abstraction supports color attachments, but requires extra functions to use them.

'Client vertex and index arrays - all vertex array attribute and element array index pointers must refer to buffer objects. The default vertex array object (the name zero) is also deprecated. Calling VertexAttribPointer when no buffer object or no vertex array object is bound will generate an INVALID_- OPERATION error, as will calling any array drawing command when no vertex array object is bound.' source: https://www.khronos.org/registry/OpenGL/specs/gl/glspec33.core.pdf page 344

@BoboFuego said in How to use anti-aliasing on QGLWidget?: how can I add MyWidget.h as promoted class for it in the MainWindow constructor? Promoted class won't allow you to pass parameters to a constructor. Just don't add it in the designer at all. Lets say you've got this designer_widget as a central widget of the mian window in the designer. Just delete it entirely and add it in code: MainWindow::Mainwindow(QWidget* parent) : QMainWindow(parent) { ui->setupUi(this); MyWidget* gl_widget = new MyWidget(); setCentralWidget(gl_widget); }

@feistykittykat Don't know if I'm allowed to bump this bad boy up. Been struggling to use PVRVFrame or something similar to get openGL found on my machine, but I have no idea how to set it up for QT. Still not even sure if that's the source of my problem.

An update on this. It works perfectly and its a very low-cost solution. My processing time remains almost the same (~10mS) using this method since the painter does the scaling for you when it draws. Thanks for your help guys.

@kent-dorfman Thanks and will try out those methods also.

Just to sum up this thread for anyone else having this issue, this would be the correct way to do it: QImage img; unsigned char* data; data = new unsigned char[4*width*height*sizeof(unsigned char)]; img = QImage((uchar*)(data),width,height,QImage::Format_RGBA8888); Make sure you allocate the appropriate space needed. E.g. if image format is RGB, size of the data array will be 3 * width * height * sizeof(unsigned char) and the QImage format will be QImage::Format_RGB888. Thanks all for your help.

@julianm You will have to set setSyncData(true); on the attribute-buffers and also synch the index buffers to get the right vertices.

Hi and welcome to devnet, From the looks of it you are using both glu and the fixed pipeline. Since you are starting a new project, may a suggest taking a look at the Qt OpenGL examples and their use of current technologies like shaders ?

Hi Hmm, nope. it looks very much like the sample with some code from TriangleWindow::initialize() in the render() function.

@SGaist My solution is heavily inspired by: this old ogre wiki post (should have linked it as well, forgot about it until now). I mostly slimmed it down to what I posted as my solution, but I agree if I have time I'll try to make an example/entry. There are some things that need to be updated from the linked post to fit Ogre 2.1 since the post is old.

@HW-Developer OK, I don't want to discourage you, maybe you just want to play with it, I've said I have no knowledge. But maybe if that sort of thing was freely available from 2005 there are some more recent ones which might be better?

@kenchan I want to draw it on QOpenGLWidget and i want to relate it to an audio file so i can position it wherever i want

https://drive.google.com/file/d/1SHw3k6gY9pz8cL7skhDUPUf2NrwF4xeE/view

@HW-Developer Start here http://doc.qt.io/qt-5/qtxml-index.html

Off the top of my head, I am not sure if fbo::save() is valid while the FBO is still bound as the target for drawing. Try releasing it first and then calling save. An FBO can only be used as a texture when it is not bound as a target -- I think that applies to all readback operations. Also, you have a glClearColor, but you never glClear(). If there is garbage in the depth buffer of the FBO, maybe your stuff is never getting drawn. glClear() the depth buffer and the image buffer before you draw. At very least you should be able to see the clear color in the FBO when you save it, so you know the binding is working at that point.

Alright, with much time and an extensive amout of google search I managed to cobble a working QOpenGLWidget program together. I used this official Qt-Example as a basline: http://doc.qt.io/qt-5/qtopengl-cube-example.html here is the combination with my Tesseract code https://github.com/DeiVadder/Tesseract-Challenge-OpenGL It's working, yeah me!!, but I have the feeling that it's far from ideal. I'm just glad I managed to draw something in 3d. Anyway, closed and solved.