C# OpenGL bindings

Hi to all!

I’m developing a C# application for my sake. I’ve used untill some weeks ago OpenGL bindings like Tao Framework. Since I noticed how specification are used to generate C# bindings, I tried to generate OpenGL C# bindings myself. Generated bindings are generated following the Tao Framework bindings…

Actually I have not tested my generated bindings, they are so far to be declared as usable, but I think this way is right.

I come here to ask you, OpenGL experts, some questions… but first I would like to present my ideas.

• Define a OpenGL Forward Profile only interface (!)
• I’d like an interface near as much as possible to the OpenGL specification writing, including extensions. i.e. : this require the definition of function overloads such as Gl.Get for glGetIntegerv, glGetFloatv, etc. routine.
• Routine scoping into a main class (Gl, Wgl, Xgl…), in a way to remove the typical gl routine prefix and GL_ enum prefix.
• Remotion of f, v, fv, i, iv, b, bv, N, etc… suffixes from OpenGL routines names.
• Remotion of every ARB, EXT, etc… routine which already has a counterpart in the core specification (!)
• Renaming of every ARB routine not yet removed in a way to remove the ARB suffix.

My question are the following:

• What about the OpenGL specification in XML format?
• Imposing a forward compatible context (and all derived consequences) is deprecable?
• What about licencing this specification with an open licence, specifically the GPL3?
• Any opinion or advice about my OpenGL bindings? (code, concepts…)
• What about binding function overloads?
• Probably too many questions…

Thank you all for your time.

P.S.: the code is available at

svn co https://genomalib.svn.sourceforge.net/svnroot/genomalib genomalib

SVN on Web @ Sourceforge

Have a look at OpenTK.

Patrick

Yes, already checked. It seems that the Tao Framework and OpenTK has the same contributors (infact the source it is very similar).

I’d like to develop this piece of code in my own.

- I'd like an interface near as much as possible to the OpenGL specification writing, including extensions. i.e. : this require the definition of function overloads such as Gl.Get for glGetIntegerv, glGetFloatv, etc. routine.
- Routine scoping into a main class (Gl, Wgl, Xgl...), in a way to remove the typical gl routine prefix and GL_ enum prefix.
- Remotion of f, v, fv, i, iv, b, bv, N, etc... suffixes from OpenGL routines names.
- Remotion of every ARB, EXT, etc... routine which already has a counterpart in the core specification (!)
- Renaming of every ARB routine not yet removed in a way to remove the ARB suffix.

OpenTK does all that. I had my own wrapper once, but now I use OpenTK for prototyping. (Otherwise I use C++)

What do you mean by “Forward Profile”?

Again, yes, I know. I don’t want to discuss whether use the OpenTK! Since my work actually does the same OpenTK thing, why I should refer to that library?

The important thing is to have a good interface to OpenGL. And I like GPL licences. Actually I have both, while OpenTK not. And consider to have yout own controllable OpenGL binding generator. Too fashinating.

I asked community feedback to know flavors about ideal OpenGL bindings in a OO language (in this case C#).

I mean Forward Compatible Profile: OpenGL 3.2 core profile with non deprecated extension.

Hi!

JOGL 2 allows to choose the forward compatible profile:

GLProfile profile = GLProfile.get(GLProfile.GL3);

Maybe you could port this mechanism into the Tao Framework or into OpenTK.

I want to impose forward compatible profile, not to give an option, when creating OpenGL context.

P.S.: currently I’m not using those frameworks.

Why can’t you prepare C++ OpenGL DLL in which you draw your graphics and prepare your own bindings to C#? You can set and get context using wgl library, you can also prapare a bitmap in memory and get it fro C# to render on forms. Beware that using wpf can make you struggle into troubles, see: http://msdn.microsoft.com/en-us/library/aa970688.aspx . Once you want to render it in WPF you havfe to provide bitmapped wpf brush in the manner I’ve yet told and than prepare special class derived from HwndHost. Sot it’s better to Draw on winForms context nad get it anywhere you want.
Cheers!
Greg

you can also prapare a bitmap in memory and get it fro C# to render on forms.

Because I’m pretty sure that creating a GL context that renders to a bitmap will only get you the Microsoft reference GL implementation. Which is either version 1.1 or 1.4.

OpenTK supports OpenGL 3.2 and forward-compatible contexts just fine. The public API is very different from Tao and actually covers every single item in your list - and then some. Moreover, it provides a binding generator that can read both XML files and .spec files. Finally it is MIT/X11 licensed, which means it can be incorporated into GPL projects if necessary.

Anyway, good luck with your project. For bonus points, consider using enums instead of plain const ints for tokens. Don’t hesitate to ask or PM me if you hit any snags - there’s a lot of tricky stuff involved in removing the [fduisv] suffices and generating overloads.

Regarding WPF, the only 100% reliable way I’ve found is to render to a FBO and read back the results to a WPF bitmap. Relatively slow, but it produces correct results.

The second best approach is to use a WindowsFormsHost and instantiate an OpenGL context on that (OpenTK supports this through GLControl). This works correctly, but you won’t be able to host WPF controls directly on top of the WinForms control. To do that, you will have create a transparent WPF control that covers the WinForms one and use that for hosting other WPF elements.

Edit: you can use the XML documentation for OpenGL to generate inline docs for the bindings. Needs some XSLT to clean up MathML but the result is very useful.

Edit 2: you can use generics (with struct constraints) instead of ‘object’ parameters to improve type safety.

Edit 3: I’d recommend against removing the ‘ARB’, ‘EXT’ suffices completely, because that will cause trouble when these functions are promoted to core with modified parameters. This happens from time to time, check for example the ARB GLSL functions versus the core ones.

In OpenTK, I’ve opted to use nested classes to handle this:

GL.Foo() // Core function
GL.Arb.Foo() // ARB function
GL.Ati.Foo() // vendor-specific function

This handles the issue nicely and also gives you get a handy grouping of functions per extension category.