aybe's picture

Would like to contribute to OpenTK


For my personal needs, I adopted OpenGL (OpenTK) as my favorite API for drawing.
I come from the WPF world and after having spent years on it, I decided to go onto something else.
That API couldn't match the 60fps I am expecting for producing my visuals ...
Spent some time with XNA on Windows as well as WP7 but well, decided to look somewhere else, again.
Ok, this was just an introduction and why today I want to contribute to OpenTK.

While OpenTK is indeed very fast, there's simply nothing to get you started quickly.
I created a project that mimics GLOO but also mimics XNA.
There is still a lot to do but, now it's a matter of ~10 LOC to show something on the screen.
Of course, it is using the newer OpenGL with shaders, VertexAttribPointer, etc ...

Now, would you like to integrate these higher-level classes next to OpenTK ?

I am in the process of making a roadmap, but for now objectives are :
- to make it the easiest possible,
- provide basic drawing commands, like image, rectangle, polygon etc ...
- keep it extensible

These were my needs in fact, I needed to draw on a 2D surface simple things.

Here's an example :

            var vertices = new[]
                                   new VertexPositionColor(new Vector3(0.0f, 0.0f, 0), new Vector4(0.0f, 1.0f, 1.0f, 1.0f)),
                                   new VertexPositionColor(new Vector3(100.0f, 0.0f, 0), new Vector4(1.0f, 0.0f, 1.0f, 1.0f)),
                                   new VertexPositionColor(new Vector3(0.0f, 100.0f, 0), new Vector4(1.0f, 1.0f, 0.0f, 1.0f)),
                                   new VertexPositionColor(new Vector3(100.0f, 100.0f, 0), new Vector4(0.0f, 0.0f, 0.0f, 1.0f))
            var indices = new ushort[]
                                  0, 1, 2, 1, 2, 3
            var vertexBuffer = new VertexBuffer<VertexPositionColor>();
            vertexBuffer.SetData(vertices, BufferUsageHint.StaticDraw);
            var indexBuffer = new IndexBuffer16();
            indexBuffer.SetData(indices, BufferUsageHint.StaticDraw);
            var effect = new GeometryEffect();
            effect.Projection = _matrixProjection;
            effect.ModelView = _matrixModelView;
            var array = new VertexArray();
            array.SetVertexBuffers(new[] { vertexBuffer });
            array.ElementsToDraw = indices.Length;

But also higher-level features like :

            _rect = new Rect();
            _rect.X = 100;
            _rect.Y = 100;
            _rect.Width = 100;
            _rect.Height = 100;
            _rect.Color = Color.Red;

Now there's quite some stuff behind this, like a shared VBO, instancing etc ...
I really want to provide yet simple features but efficient from an OpenGL perspective.

Tell me if you're interested, you're welcome to contribute to the roadmap as well.

Thank you.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
migueltk's picture

I like the choice of classes. It would be interesting to have a sample code and to work on this code.

mOfl's picture

I think this could only work as a third-party library. For my own everyday engine, I also use a lot of wrappers for buffers, framebuffers etc., but they are tweaked for the very needs of my applications. For example, it is possible for some framebuffers to do no depth clear but just switch the depth test sign and adjust the depth range, which is faster than a depth clear but makes depth comparisons (e.g. for shadow maps) more difficult. Other framebuffers do not require a color clear because it is guaranteed that every pixel is overdrawn at runtime.
For some rectangles (e.g. fullscreen quads), you want to use just two triangles, for others (e.g. terrain) you want to generate 512x512x2 triangles which can be displaced. If position and size are saved with the rectangle, so should the transformations, e.g. translation, scaling, and rotation, thus the complete model matrix. But you would have to do this for 2D and 3D (or leave out the third dimension in 2D and have to deal with illegal 3D operations at runtime) or provide separate classes for 2D and 3D objects.

I could count endlessly, there are good reasons why OpenGL exists in the form it does today. It offers the core functionality to build your application on, without having to squeeze everthing in fixed classes. I am very happy the fixed function pipeline has gone, although it of course makes things more complicated. But it also is more efficient and much, much, much more flexible. It's the same with OpenTK - every generalization or wrapper makes the features easier to use, but makes special cases more difficult or inperformant to use.

I for myself would not use such classes because they are guaranteed to be slower or just as fast as my own implementation. It might be attractive for OpenGL beginners, but I'm not even sure if that's a good thing, as it hides the OpenGL calls and prohibits their proper understanding.

aybe's picture

migueltk :
I will sort out something within the next two weeks ...
Also, just had a look at Bixion2D, that's really great !

mOfl :
Of course not everything would be possible unless subclassing a lot, but I think you can do most basic/semi-advanced things using OO.
Can you explain me how you'd manage a large OpenGL project ? I guess there is some kind of object construction in the process.
Like Call Of Duty, it is made using OpenGL, obviously they are using some sort of OO, actually I can't tell you, I don't know ...
I haven't found much details on this topic on the web, beside using a scene graph.

Yes, static methods rock in themselves, you can do what you want at any time but it tends to be lengthy.
I've been using BASS.NET if you know it, it's an audio library, same syntax style as OpenGL, very powerful but lengthy in the end;
then I ended up creating a few classes like Channel, Stream, Effect ... otherwise that was impossible (I mean too long for 1 person).
That's quite handful even though I know it's not ideal but you know, work has to be done so ...

Here's how I see your last point :
- speed : questionable on a small project but definitely important for large projects though overhead might not be the biggest issue
- hiding : when writing the doc of my lib, every method tells what gl* func they use, therefore,
library is intended to people that knows it already or are willing to know GL, nothing in this planet happens without involvement.

All :
I need to create a webpage that presents the library, this is coming soon.
Are people who maintain OpenTK reading this now ?

Thank you.

flopoloco's picture

Hello aybe, welcome to the OpenTK community.

I would like also OpenTK to be more user-friendly and have higher level classes, I had this talk with theFiddler who is the father of OpenTK and his mission is very straight forward (The Open Toolkit is a free C# library that allows.Net/Mono programs to use OpenGL, OpenAL and OpenCL).

But that doesn't mean that there can't be a high level framework, there can be thousands of other projects based on OpenTK. So if there's a developer that wants to write games then he can jump straight to the appropriate game engine (not raw OpenGL).

Same is done with WebGL, there are some 3D engines based on it but WebGL is not high-level itself.

I had also made a proposal back then, to create a very easy game engine. I have not finished it yet due to lack of time, but I hope this year I will provide the first version. http://www.opentk.com/node/579

If you have something like this in mind, then we could talk so we can get somewhere. :)

aybe's picture

Hello flopoloco, thanks.

Yes why not, actually I'm in the process of finishing the "first" version, in fact I need it urgently.
Let's talk whether we can work on a common project...
Do you have a demo of your lib. ?


flopoloco's picture

Sorry, but I am not ready yet. Now I am working on Shaders, Textures and VBOs... When I plug these together I will proceed to cleanup and polishing.

I you want something fast look at this framework. I found it today...

aybe's picture

Yes I know it, thanks.
Actually the point was to not use XNA but OpenGL :-)
I know ANX can (will) also render to GL but heh lol ...

Just thinking that I'm locked in a loop :
You said such lib. (mine included) hides GL, that's true, but by coding mine I learnt and still learn GL ...
Therefore, the question of usefulness of your lib. for others becomes questionable itself,
since in the end we make pretty much the same objects : shader, texture, vertex buffer ...
Ironic, no ?

But doing so, we learn GL and it's probably a good thing :-)