[Solved] Simplest Vertex/Fragment Shaders using QGLWidget Derivation

Hornsj2

Thanks for the reply.

I might not have thought it through, but I think it might go deeper than changing the logic guarding the use of shaders. Again I realize I might be telling you something you already have thought of.

It would seem that, in addition to changing the method for checking extensions, maybe the function pointer declarations in Qt's OpenGL support need to be looked at. I do know there are some preprocessor guards that rely on that check in Qt. These guards encapsulate OpenGL function pointer definitions and defines. I ran into that with my tessellation work.

ZapB

Yes they do. As a starter for 10 I am looking at where to resolve the function pointer for glGetStringi() so that I can at least query the extensions ;-)

Also, the logic in QGLShaderProgram needs to be amended since shaders are part of the specification and not provided by extensions for newer OpenGL versions.

There is quite some work to do to properly support OpenGL 3.1 or newer.

Hornsj2

Great. It sounds like I should integrate my changes into your changes if you will be reworking that part of the code. I had to add tessellation support, in part, there.

ZapB

I have spoken to sroedal (Qt OpenGL dude) on irc this afternoon and he is committing a patch that is very similar to what I wrote yesterday afternoon. It allows for proper parsing of OpenGL extensions when using the Core profile. It should hopefully hit Qt master branch on gitorious within a day or so.

I'll try applying it locally tonight and see if QGLShader then starts working or if further changes are needed to make it realise that shaders are supported.

I also asked about having Qt resolve the Core profile entry points and the response was thet using GLEW is the current advice - which is what we had been doing anyway. I still think it would be nice that if we ask Qt for a OpenGL 3.2 Core profile context that it then resolves the function pointers for the Core profile entry points for us without having to use GLEW. But that is another problem I guess.

I'll keep you updated.

Hornsj2

Your posted example with fixed function works fine. I'll try using the entire shader pipeline.

It's normally slow going for me during the week. Weekends are my most productive time for these projects.

By "entire shader pipeline" I mean vert,geom, tess control, tess eval, frag.

ZapB

Cool. I'll look forward to seeing your example. I have not used the tesselation shaders yet so I would be keen to see a nice little example. I probably won't get back to this until the weekend either but I'll keep an eye out for that patch hitting Qt master.

Hornsj2

Promises promises... yeah I got caught today moving stuff. I WILL have the shaders tested by tomorrow night.

Hornsj2

By the way my tessellation tests will be posted in the proper thread.

ZapB

No worries, real life happens - especially when nice weather lands ;-)

I have just checked and the patch to Qt master that I mentioned earlier has no been applied. So now shaders should work even if you select the Core profile.

The main part of the patch is in src/opengl/qgl.cpp in the helper class QGLExtensionMatcher found "here":https://qt.gitorious.org/qt/qt/blobs/master/src/opengl/qgl.cpp#line5373.

The corresponding commit message was:

@
commit 2f59eaeee1fbe33d07b0e7d0747afd8658df95ac
Author: Samuel R<C3><B8>dal sroedal@trolltech.com
Date: Wed May 26 16:39:02 2010 +0200

Made extension resolving work with Core profile.

The Core profile was introduced in OpenGL 3.2 and if chosen removes
all deprecated functionality from the OpenGL API.

In the Core profile glGetString(GL_EXTENSIONS) is unsupported, so
instead we need to use glGetStringi(GL_EXTENSIONS, index) together with
glGetIntegerv(GL_NUM_EXTENSIONS). Also optimized the QGLExtensionMatcher
to not have to recompute the split positions all the time.

Preliminary support to prevent non-core-functions to be called in the GL
2 engine has also been added.

Reviewed-by: Kim

@

Hornsj2

removed.

Hornsj2

The fact that I can't just configure/nmake like I do with qt-everywhere-opensource is crushing my soul to the point where I'm going to call it for the night. I'll have to figure out this workflow.

Hornsj2

I'm just going to diff my changes with the repository and not worry about building from gitorious.

ZapB

If you are trying to build a checkout from gitorious you need to have perl installed. The reason is that the configure script calls a perl script called syncqt which is used to create the camelcase forwarding headers that allow you to do this:

@#include <QCoreApplication>@

These headers are generated to simply contain something like

@#include "../include/qtcore/qcoreapplication.h"@

I fell for this same problem too on windows. On linux it just works since perl is nearly always already available.

Edit: fixed typo.

Hornsj2

Great answer again, thank you. I posted the same question in the correct forum. I'm going to consider this thread closed and move my updates to my tessellation shader thread.

ZapB

No problem. You're welcome.

ZapB

Sorry to bump an old thread but I've just written a related "wiki article":http://developer.qt.nokia.com/wiki/How_to_use_OpenGL_Core_Profile_with_Qt on this topic that shows how to use the OpenGL Core profile with Qt using some very simple shaders and a single triangle.

number23

moved to new "thread":http://developer.qt.nokia.com/forums/viewthread/11031/