When I was using opengl 3.3, functions such as, glGenBuffers() and glBufferData() Worked Just fine, but now that I am using 4.3 I wish to use the more updated versions of those functions such as glCreateBuffers() and:
glNamedBufferStorage(), glVertexArrayVertexBuffer, glVertexArrayAttribFormat(), glVertexArrayAttribBinding(), glEnableVertexArrayAttrib().
When I implement them in the program I simply get Unhanded expression errors.
The book I am learning from (Superbible) no longer teaches the GenBuffer() Method so I need to make these work.
Thank You!
using 4.3
glCreateBuffers
glCreateBuffers is part of OpenGL 4.5 (and ARB_direct_state_access).
Related
I'm new to Qt and am trying to import some older C++ openGL code. I'm currently using Qt 6.4. I've subclassed my OpenGL-using class to QOpenGlFunctions.
Many of the glFoo calls "work" but the class also uses calls like glEnableClientState, glVertexPointer, glNormalPointer, glTexCoordPointer, glDisableClientState, glColor4fv, & glMaterialfv which come up with errors like undefined reference to __imp_glTextCoordPointer. Looking at the documentation these appear to no long be supported by "default" but it looks like they are supported using older versions of QOpenGlFunctions such as QOpenGlFunction_1_4 (https://doc-snapshots.qt.io/qt6-dev/qopenglfunctions-1-4.html).
Trying to change my subclass from QOpenGLFunctions to QOpenGLFunctions_1_4 complains that really only QOpenGLFunctions_1_4_CoreBackend and QOpenGLFunctions_1_4_DeprecatedBackend exist but there appears to be no documentation on those and if I subclass to one of them I start seeing complaints about my constructor...
How do I actually access the functions from these older versions of the class?
This question was answered by Chris Kawa over at the Qt Forums and it worked for me! Here is his answer:
OpenGL 3.1 introduced profiles. Core profile does not support these old functions and Compatibility profile does.
So first you have to make sure you have a context in version either lower than 3.1 (which does not support profiles) or 3.1 and up set up to use Compatibility profile. AFAIK Qt does not support OpenGL < 3.1 anymore, so you only have the latter option.
If you're not sure what context you have you can simply do qDebug() << your_context and it will print out all the parameters, or you can query individual fields of it e.g. your_conext->format()->profile(). If your context is not set correctly the simplest way is to set it up like this before any OpenGL is initialized in your app:
QSurfaceFormat fmt;
fmt.setVersion(3,1);
fmt.setProfile(QSurfaceFormat::CompatibilityProfile);
fmt.setOptions(QSurfaceFormat::DeprecatedFunctions);
QSurfaceFormat::setDefaultFormat(fmt);
When you have the correct context you can access the deprecated functions like this:
QOpenGLFunctions_1_4* funcs = QOpenGLVersionFunctionsFactory::get<QOpenGLFunctions_1_4>(context());
if(funcs)
{
//do OpenGL 1.4. stuff, for example
funcs->glEnableClientState(GL_VERTEX_ARRAY);
}
else
{
// Not a valid context?
}
And for anyone as amateur as I am, context() comes from QOpenGLWidget::context() which returns a QOpenGLContext*
C++ application, I define a temp context, make it current, and then try to use wglCreateContextAttribsARB, which is simply undefined. Most answers I have seen say to use PFNWGLCREATECONTEXTATTRIBSARBPROC. Which is also undefined. What am I missing?
I'm only using gl.h (provided by VS2015)
SetPixelFormat(g_hDc, chosenPixelFormat, &pfd);
HGLRC temporaryContext = wglCreateContext(g_hDc);
wglMakeCurrent(g_hDc, temporaryContext);
PFNWGLCREATECONTEXTATTRIBSARBPROC wglCreateContextAttribsARB...
Both, however, are just unidentified. I initially tried calling wglCreateContextAttribsARB by itself, to no avail, anywhere in my code.
At this stage, I have a context working, windowed, 480p, updating, stable 60FPS. So I know my side is working. I'm getting no GL errors either. Where do I need to instantiate these two? Am I using the wrong gl header?
I'm using an updated ASUS Radeon R9-285
All data types and constants related to wgl extensions are declared in wglext.h.
You need to query the function pointer of type PFNWGLCREATECONTEXTATTRIBSARBPROC using your current context via the GL extension mechansim (e.g. wglGetProcAddress()).
How to set sclar in new version VTK. How to convert new version VTK below code?
StructuredPoints->GetPointData()->SetScalars(scalars);
Without knowing what version you are referring too, I think both methods you are using are still available in VTK:
GetPointData
SetScalars
I’m trying to compile Tesselation’s example from http://www.kdab.com/opengl-in-qt-5-1-part-5/ (source included) with the Compatibility profile and it’s simply incapable to load this profile:
The minor (and only) modifications I’ve made:
#terraintessellationscene.h:
QOpenGLFunctions_4_3_Compatibility* m_funcs;
#terraintessellationscene.cpp:
m_funcs = m_context->versionFunctions<QOpenGLFunctions_4_3_Compatibility>();
if ( !m_funcs )
{
qFatal("Requires OpenGL >= 4.0");
exit( 1 );
}
m_funcs->initializeOpenGLFunctions();
It just crashes when I call versionFunctions(). And it should work. I can compile this source and several other different project of different complexity using any Core Profile desktop profile. I'm going to try to use GLEW later on to see if this problem is related to QT or my usage of QT or my opengl driver.
I’m using lasted AMD’s 14.4 WHQL. I’ve tried to using the pre-built 5.3 source and my self-compiled static version of 5.3. I’ve tried two old AMD drivers to see if this was a problem with the OpenGL package provided by AMD and yet it fails. I really want to use versionFunctions.
Update 2
It seems QOpenGLContext create(), after setting the QSurfaceFormat properly (QOpenGLContext::setFormat(format), is completely rejecting the compatibility settings (format.setProfile( QSurfaceFormat::CompatibilityProfile) and creating a Core Profile context instead, completely ignoring my request for a compatibility context and yet returning true as a successful operation that couldn't follow QSurfaceFormat format rules.
Update 3
Well, I just discovered the issue and it is not related to my modifications, it’s in the original code at kdab:
// Create an OpenGL context
m_context = new QOpenGLContext;
m_context->setFormat( format );
m_context->create();
by creating the context before setFormat, I was able to correctly initiate a proper Compatibility Context, as QT was simply setting part of my settings related to setProfile( QSurfaceFormat::CoreProfile)
Update 4: Final solution
"Creating the context before setFormat() is wrong and works by accident since what you are requesting then is a plain OpenGL 2.0 context and the driver most likely gives you 4.3 compatibility. On other drivers or platforms this may fail so be careful.
The behavior you are seeing is caused by the AMD driver: it refuses to create a proper compatibility profile context unless the forward compatibility set is not set. Qt sets the fwdcompat bit by default, it can be turned off by setting the DeprecatedFunctions option on the QSurfaceFormat. So requesting for Compatibility together with DeprecatedFunctions will give what you want. Other vendors’ drivers do not have this problem, there not setting DeprecatedFunctions (i.e. setting forward compatibility) is ignored for compatibility profiles, as it should be."
via agocs # qt devnet
you are getting the core profile (thanks to Qt) while you want the compatibility profile
you should request the compatibility profile on initializing by setting the format as follows
window.cpp line 24
format.setProfile( QSurfaceFormat::CompatibilityProfile);
and only call the versionFunctions after context has been created
I am using openGL and glew to check the extensions.
Say I wanted to check if I could use multitexture extension:
GLEW_ARB_multitexture will return true if I can use it.
BUT
arb_multitexture was deprecated in openGL 3.0.
Will it still return true?
What about in 3.1 where it was removed?
Thanks.
It'll return true if your context exports the extension, which it will if it's not "forward-compatible" or "core profile", or possibly if it supports the "GL_ARB_compatibility" extension.
The bottom line is, if GLEW_ARB_multitexture is true, you can use the functionality. Any higher-level logic (like only using shaders if they're available) is up to you.