I am writing a plugin on Maya/MacOS which is compiling a vertex shader for OpenGL:
const char* vscode =
{
"#version 150\n"
...
}
However executing the code in Maya gives me
ERROR: 0:1: '' : version '150' is not supported
The OpenGL version returned is 2.1 ATI-1.42.6. I tried to change the OpenGL via glut
glutInitDisplayMode(GLUT_3_2_CORE_PROFILE);
But it does not seem to change the OpenGL Core Profile. How can I change the core profile from within a Maya plugin, or how can I know which "xxx" version would be supported in the shader ?
The OpenGL version returned is 2.1 ATI-1.42.6. I tried to change the OpenGL via glut
Does Maya use GLUT? No! So how so you expect this to work then?
GLUT is a independent library that does window and OpenGL context creation. GLUT is not part of OpenGL and GLUT can not influence OpenGL context management of programs not using GLUT.
Maya does its OpenGL context management internally and when your plugin is called a OpenGL context is already created and the version profile of that particular context set into stone.
But what you can do is you can create a very own OpenGL context, just for your plugin and connect it with the OpenGL context that Maya created (OpenGL context sharing). Doing this is advisable anyway, since this separates OpenGL your plugin uses from OpenGL state Maya uses.
You will have to use the system level OpenGL context management APIs for that. So no GLUT, no GLFW, no SMFL or other helper libraries. Don't worry, it's not too difficult to do. Regarding connecting with the OpenGL context of Maya, every OpenGL context management API has functions to query the currently active OpenGL context and the drawable it's active on. Use those to store which context+drawable pair was active before your plugin got called, then before returning to Maya reset the OpenGL context activation to that pair.
Related
I am attempting to create an OpenGL context with osmesa (off-screen mesa). I wish to use the software implementation of mesa without a window and save the rendered output to a png file.
http://www.mesa3d.org/osmesa.html
I create a GL context with the following:
OSMesaContext context = OSMesaCreateContext(GL_RGBA, NULL);
OSMesaMakeCurrent(context, buffer, GL_UNSIGNED_BYTE, width, height);
However, when I invoke glGetString(GL_VERSION) the version is 2.1 Mesa 10.1.1. As expected, none of my GLSL ES shaders compile. When using SDL I can supply a version hint and create a GLES 2.0 context.
How do I specify the version of the GL context being created by osmesa?
If you look at src/mesa/drivers/osmesa/osmesa.c, around line 745, you can see that it explicitly asks for an OpenGL compatibility profile, which Mesa limits to OpenGL 2.1 and GLSL 130 (see src/mesa/main/version.c line . Replacing API_OPENGL_COMPAT with API_OPENGL_CORE results with the OpenGL version being 0.0 in Mesa 10.6.2, so unfortunately, the simple fix doesn't work. But, setting the MESA_GL_VERSION_OVERRIDE environment variable to "3.3" appears to work. Haven't tested beyond seeing what glGetString(GL_VERSION) returns. Good luck!
I'm going to start implementing OpenGL 3 into my application. I currently am using OpenGL 1.1 but I wanted to keep some of it due to problems if I attempt to change the code but I wanted to change some of my drawing code to a faster version of OpenGL. If I do things like bind textures in OpenGL 1.1 can I draw the texture in OpenGL 3?
Mixing OpenGL versions isn't as easy as it used to be. In OpenGL 3.0, a lot of the old features were marked as "deprecated" and were removed in 3.1. However, since OpenGL 3.2, there are two profiles defined: Core and Compatibility. The OpenGL context is created with respect to such a profile. In compatibility profile,
all the deprecated (and in core profiles removed) stuff is still availbale, and it can be mixed as well. You can even mix a custom vertex shader with the fixed-function fragment processing or vice versa.
The problem here is that it is not grequired that implementors actually provide support for the compatibility profile. On MacOS X, OpenGL 3.x and 4.x are supported in core profile only.
In you specific example, binding textures will work in all cases, since that funtctionality exists unmodified in all versions from 1.1 to 4.3 (and is likely to do so in the near future). However, most of your drawing calls are likely to be not available in the newer core profiles.
Omg.. opengl 1.1 is from 1997! Do yourself a favor and get rid of the fixed-function pipeline stuff and adapt to OpenGL 4.x. However, you can try
#version 420 core
in your shader.
I 'd like to render a CALayer into my openGL Context in openGL 3.2 Core.
I'm using CARenderer to render the layer but when I try to render I get the following error.
CoreAnimation: unsupported graphics hardware; need two or more texture units; need ARB_texture_rectangle extension; need EXT_framebuffer_object extension; need ARB shader extensions.
The problem doesn't occur when I ask for the legacy version of openGL. Is there a constant to pass to CARenderer in the rendererWithCGLContext:options: ?
I've been trying to work with OpenGL ES 2 in Android for some time now, but I'm finding the lack of experience with OpenGL itself to be an issue, since I barely understand what all the GLES20 methods actually do. I've decided to try to learn actual OpenGL, but a little bit of reading has informed me that each version of OpenGL is drastically different from its predecessor. Wikipedia isn't very clear on which version that OpenGL ES2 most closely resembles.
So, my question is, which version of OpenGL should I learn for the purpose of better understanding OpenGL ES2?
According to the book OpenGL ES 2.0 Programming Guide:
The OpenGL ES 1.0 and 1.1 specifications implement a fixed function
pipeline and are derived from the OpenGL 1.3 and 1.5 specifications,
respectively. The OpenGL ES 2.0 specification implements a
programmable graphics pipeline and is derived from the OpenGL 2.0
specification.
OpenGL ES 2.0’s closest relative is OpenGL 2.0. Khronos provides a difference specification, which enumerates what desktop OpenGL functionality was removed to create OpenGL 2.0. The shading language for OpenGL ES 2.0 (GLSL ES 1.0) is derived from GLSL 1.20.
OpenGL ES2.0 is almost one-to-one copy of WebGL.
The differences are practically only in the setup of the environment, which in Android happens with EGL and which happens in WebGL with calls to DOM methods. (setting canvas)
The comparison to "open gl" is next to impossible, as Open GL means almost fixed and hidden rendering pipeline, which is controlled by stack of matrices and attributes. This is now obsoleted in ES. Instead one has the "opportunity" to control almost every aspect of the rendering pipeline.
Apple's OpenGL Shader Builder let's you drop in your vertex (or fragment) shader and it will link and validate it then tell you which GL_RENDERER is used for that shader. For me it either shows: Apple Software Renderer (in red because it means the shader will be dog slow) or AMD Radeon HD 6970M OpenGL Engine (i.e. my gpu's renderer which I usually want to run the shader).
How can I also determine this at runtime in my own software?
Edit:
Querying GL_RENDERER in my CPU code always seems to return AMD Radeon HD 6970M OpenGL Engine regardless of where I place it in the draw loop even though I'm using a shader that OpenGL Shader Builder says is running on Apple Software Renderer (and I believe it because it's very slow). Is it a matter of querying GL_RENDERER at just the right time? If so, when?
The renderer used is tied to the OpenGL context and a proper OpenGL implementation should not switch the renderer inbetween. Of course a OpenGL implementation may be built on some infrastructure that dynamically switches between backend renderers, but this must then reflect to the frontend context in renderer string that identifies this.
So what you do is indeed the correct method.