OpenGL core profile support

[Adam Griffiths]

I've gotten OpenGL 3.2 core profile rendering on OS-X.

It required some changes to the Cocoa config which are available here:

https://github.com/adamlwgriffiths/Pyglet

I also monkey patch the window at run time:

https://github.com/adamlwgriffiths/PyGLy/blob/master/pygly/gl/core/__init__.py

And disable the shadow window as suggested by another user who created the original cocoa patch:

https://github.com/adamlwgriffiths/PyGLy/blob/master/examples/core/window_creation/main.py

But I am unable to use any of the pyglet wrappers such as vertex_list or Label due to the use of Legacy profile code.

I'm happy to begin modifying these to patch out the legacy code.

But I want some feedback on how this should be done.

I don't want to maintain a branch of pyglet. I'd rather any changes could eventually be integrated.

Now that core works, I'm at the point where I either write my own simple wrappers (very tempting as I don't want anything heavy weight), or I help fix pyglet up.

My question is this:

Does anyone have any thoughts on how this should be done?

My thoughts at the moment are to make the legacy calls optional. By detecting if we're running in Core profile with no compatibility, we can 'if' most of these statements out.

Is there any simple way to do this? Is there a boolean somewhere?

I can add one if there isn't. It would basically be:

if core profile AND not compatibility:

  core_only = True

Does this sound reasonable?

Cheers,

Adam

[Nathan]

On Sat, Sep 22, 2012 at 9:43 PM, Adam Griffiths <adam.lw....@gmail.com> wrote:

I've gotten OpenGL 3.2 core profile rendering on OS-X.

It required some changes to the Cocoa config which are available here:

https://github.com/adamlwgriffiths/Pyglet

I was able to read through those changes in your pyglet fork over the weekend.  Unfortunately, I'm still weak in my understanding of both OpenGL and Cocoa (and especially where they deal with eachother).  Would you expect these changes to fix the a-window-never-appears problem with system python on 10.8.x?  I'll try to get around to testing your code on my setup later today.

 

I also monkey patch the window at run time:

https://github.com/adamlwgriffiths/PyGLy/blob/master/pygly/gl/core/__init__.py

And disable the shadow window as suggested by another user who created the original cocoa patch:

https://github.com/adamlwgriffiths/PyGLy/blob/master/examples/core/window_creation/main.py

But I am unable to use any of the pyglet wrappers such as vertex_list or Label due to the use of Legacy profile code.

I'm happy to begin modifying these to patch out the legacy code.

But I want some feedback on how this should be done.

I don't want to maintain a branch of pyglet. I'd rather any changes could eventually be integrated.

Perhaps someone with commit rights could comment here.

 

Now that core works, I'm at the point where I either write my own simple wrappers (very tempting as I don't want anything heavy weight), or I help fix pyglet up.

 

Help fix pyglet up!

 

My question is this:

Does anyone have any thoughts on how this should be done?

My thoughts at the moment are to make the legacy calls optional. By detecting if we're running in Core profile with no compatibility, we can 'if' most of these statements out.

Is there any simple way to do this? Is there a boolean somewhere?

I wish I fully understood what "Core profile" really means, and how that translates to Linux and Windows.  Does it simply mean a different version of OpenGL?  If it does, then some global approach to addressing how to support multiple versions of OpenGL across all the platforms should probably be discussed - right?  Along with some new facility for listing & choosing your OpenGL version...

What does pyglet do now?  Try to use the same version of OpenGL across platforms, with the helper objects hard-coded to use that version of OpenGL?

Am I on the right track, or have I missed some fundamental point, here?

~ Nathan 

[Tristam MacDonald]

I wish I fully understood what "Core profile" really means, and how that translates to Linux and Windows.  Does it simply mean a different version of OpenGL?  If it does, then some global approach to addressing how to support multiple versions of OpenGL across all the platforms should probably be discussed - right?  Along with some new facility for listing & choosing your OpenGL version...

What does pyglet do now?  Try to use the same version of OpenGL across platforms, with the helper objects hard-coded to use that version of OpenGL?

Am I on the right track, or have I missed some fundamental point, here?

~ Nathan 

The 'core profile' is part of the post-gl3 deprecation model. Basically, the core profile is the subset of OpenGL commands that are supported for the future (i.e. not deprecated).

There are core profiles for each version of OpenGL since 3.0. If you request a Core profile (when you create the context), it will remove all deprecated functionality (immediate mode, managed matrices, anything without shaders), and you can only use 'new world order' features.

The core profile doesn't add any features, and there is always a matching legacy profile, if you need access to deprecated features. The core profile just enforces that you write 'modern' (idiomatic) OpenGL code.

--

Tristam MacDonald

Software Development Engineer, Amazon.com

http://swiftcoder.wordpress.com/

[Adam Griffiths]

I was able to read through those changes in your pyglet fork over the weekend.  Unfortunately, I'm still weak in my understanding of both OpenGL and Cocoa (and especially where they deal with eachother).  Would you expect these changes to fix the a-window-never-appears problem with system python on 10.8.x?  I'll try to get around to testing your code on my setup later today.

These code changes are simply to get the OpenGL Core profile working on OS-X.

I believe it works on Windows / Linux (I just ran my core examples with no changes on Ubuntu).

I don't experience the problem with the window not showing, and these changes aren't aimed at that problem so I highly doubt these changes will help.

I don't expect them to be pulled verbatim into pyglet. But they work, so someone with more knowledge of the code base should be able to look into why they work and how to integrate it cleanly =)

 

 

I also monkey patch the window at run time:

https://github.com/adamlwgriffiths/PyGLy/blob/master/pygly/gl/core/__init__.py

And disable the shadow window as suggested by another user who created the original cocoa patch:

https://github.com/adamlwgriffiths/PyGLy/blob/master/examples/core/window_creation/main.py

But I am unable to use any of the pyglet wrappers such as vertex_list or Label due to the use of Legacy profile code.

I'm happy to begin modifying these to patch out the legacy code.

But I want some feedback on how this should be done.

I don't want to maintain a branch of pyglet. I'd rather any changes could eventually be integrated.

Perhaps someone with commit rights could comment here.

 

Now that core works, I'm at the point where I either write my own simple wrappers (very tempting as I don't want anything heavy weight), or I help fix pyglet up.

 

Help fix pyglet up!

 

My question is this:

Does anyone have any thoughts on how this should be done?

My thoughts at the moment are to make the legacy calls optional. By detecting if we're running in Core profile with no compatibility, we can 'if' most of these statements out.

Is there any simple way to do this? Is there a boolean somewhere?

I wish I fully understood what "Core profile" really means, and how that translates to Linux and Windows.  Does it simply mean a different version of OpenGL?  If it does, then some global approach to addressing how to support multiple versions of OpenGL across all the platforms should probably be discussed - right?  Along with some new facility for listing & choosing your OpenGL version...

What does pyglet do now?  Try to use the same version of OpenGL across platforms, with the helper objects hard-coded to use that version of OpenGL?

Am I on the right track, or have I missed some fundamental point, here?

OpenGL 2.1 and below are considered legacy and use the fixed function pipeline.

This was pre-shaders being core to opengl.

To get fancy effects you had to set a lot of state and do some tricky things with stencil buffers, etc to get opengl to do what you want.

Shaders changed that.

 

OpenGL 3 broke away from the fixed function by replacing almost _everything_ with shaders.

There is no matrix stack, no push / pop functionality. And you _need_ shaders to render _anything_.

It's a big change, and it breaks a lot of existing functionality.

So they implemented a compatibility mode... well... the vendors did.

So you can run fixed function logic along side core logic.

But OS-X doesn't seem to support this. At least from the way pyglet is running. I may be wrong.

OS-X also only supports either, 2.1 legacy, or 3.2 (OpenGL is up to 4 now).

So it's very.... strict.... for lack of a better word.

Pyglet already lets you select the opengl version you want in the gl config class that you pass to Window.

You use the major_version and minor_version (3,2 for core 3.2).

But on OS-X, this value is ignored. At least in vanilla pyglet. Hence the patch to read and process these.

The problem I have is that classes like Label and vertex_list use fixed function calls such as glPushClientAttrib, glPushAttrib.

These are (unfortunately) gone in the core profile.

The best way I can think of getting around it, is to either monkey patch the code, or add a tonne of 'if core_profile and pure' statements to avoid these calls. But that's pretty messy =/

I can get things rendering in the core profile, but only using pure opengl calls. The pyglet wrappers will cause gl exceptions due to unsupported functionality being used.

It's not a trivial job. Even in my project, trying to provide a single code path for legacy and core.... I just can't see one without scattering global variables all over the place to store matrix stacks and what not.

And that really defeats the purpose of the core profile.

Then there's also backward compatibility to think about. I don't think people would like it if they had to update existing code to keep it working.

It's pretty confusing =/

Cheers,

Adam

[Nathan]

On Mon, Sep 24, 2012 at 11:37 AM, Adam Griffiths <adam.lw....@gmail.com> wrote:

OpenGL 2.1 and below are considered legacy and use the fixed function pipeline.

This was pre-shaders being core to opengl.

To get fancy effects you had to set a lot of state and do some tricky things with stencil buffers, etc to get opengl to do what you want.

Shaders changed that.

 

OpenGL 3 broke away from the fixed function by replacing almost _everything_ with shaders.

There is no matrix stack, no push / pop functionality. And you _need_ shaders to render _anything_.

It's a big change, and it breaks a lot of existing functionality.

Ah, man.  That means that the old OpenGL 2 tutorial I've been working through is already obsolete. :-(  And here I thought I was making progress...

Thanks for the explanations!

~ Nathan

[Adam Griffiths]

Legacy can still do what Core does, just using shaders.

If you're using vertex buffers objects, vertex array objects and shaders with uniforms and vertex attributes then you're basically using core.

It's just a little bit of tweaking. Core doesn't have a special attribute for vertex colour or texture coordinates, nor even vertex normals. All of these are custom attributes that you bind to your shader. Etc etc etc. Small things, but the essence is the same. Essentially core is stripped to the bone.

The reason I'm trying to get Core working, is Legacy only seems to support GLSL up to version 1.20.

With Core, I can get up to 1.50 (there are far higher versions than that) on both Linux and OS-X.

There are a number of new functions in 1.30+ that I really want. But you can't use >1.20 in legacy it seems.

Hence, my crusade for core =P

Cheers,

Adam

--
You received this message because you are subscribed to the Google Groups "pyglet-users" group.
To post to this group, send email to pyglet...@googlegroups.com.
To unsubscribe from this group, send email to pyglet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.

[infinite8s]

For those of you still stuck in the legacy mode of thinking, this is a really good tutorial on 'modern' OpenGL:

http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Table-of-Contents.html

Naveen

[Nathan]

On Thu, Oct 4, 2012 at 9:34 AM, infinite8s <naveen.mic...@gmail.com> wrote:

For those of you still stuck in the legacy mode of thinking, this is a really good tutorial on 'modern' OpenGL:

http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Table-of-Contents.html

Naveen

That's me, thanks!

~ Nathan