[Solved] Simplest Vertex/Fragment Shaders using QGLWidget Derivation

ZapB

[quote author="Hornsj2" date="1301913471"]I suspect it will work. I'll try it after I get home from work tonight.

The "problem" is that, as you know, the core profile removes deprecated functionality. In the case of the code above the following will have been removed ( my goal was to keep my code "pure" and not have any deprecated functions and simply turning on compatibility seems to not work with QGLShaderProgram):
[/quote]

Yes I know, but as I said I wanted to start off from a starting point that I know works with Qt and QGLShaderProgram. I was then going to remove the old fixed functionality calls and modify the shaders to use the Core Profile when I found this bug in Qt's extension mangling support so I did not go any further yet.

[quote author="Hornsj2" date="1301913471"]
The fact that the above works and my code doesn't, even though I turn on the compatibility profile, leads me to believe QGLShaderProgram can't be used in my project.
[/quote]

Not yet, because of the problem reported above, namely that QGLShaderProgram believes that it cannot use shaders when you are using the Core Profile due to this bug.

[quote author="Hornsj2" date="1301913471"]
For completeness I'll test my tessellation shader additions with your harness and make a merge request.
[/quote]

It should work if you use the compatibility mode - except if there is a bug in your shaders of course ;-)

[quote author="Hornsj2" date="1301913471"]
I've never used Gitorious but I signed up and it wants a public key. If I understand the directions I can generate a public key with Putty. Is that right? Also, once that's done where do I store the key? Is it to be placed in a certificate store?
[/quote]

Sounds about right for generating the key. It's been ages since I used PuTTY to generate a key. Have a google for it, should be easy to find instructions.

[quote author="Hornsj2" date="1301913471"]
Also, are there rules as far as comments or will Nokia clean that up?
[/quote]

You need to follow Qt's "coding style guidelines":https://qt.gitorious.org/qt/pages/QtCodingStyle. There is more info "here ":https://qt.gitorious.org/qt/pages/Home.

Good luck.

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/