the Fiddler.'s picture

Planning for OpenTK 0.3.14

To help prioritize tasks, please check the list below and choose the two most important features for you:

  1. Documentation (NDoc function reference, user manual, improved tutorials)
  2. Bug and stability fixes.
  3. Joystick support.
  4. Improved mode setting (fullscreen modes, FSAA, stencil, stereo)
  5. Glu bindings (tesselation, quadrics)
  6. Mac OS X support
  7. OpenAL bindings
  8. Fonts and Text (multiple font sheets, text layout)

This will help focus resources on items that will be more useful for your projects. You don't need to create an account before posting.

Thanks!

Edit: Added item 8


Comments

Comment viewing options

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

The most important two features for me and my project are:
8. Fonts and Text (multiple font sheets, text layout)
4. Improved mode setting (fullscreen modes, FSAA, stencil, stereo)

GOoOGle's picture

The 2 importants things
first one - 9. Multiplatform Widget if possible (GTK could be the easier choice).
second - 4 Improved mode setting
in fact, the first, it's a little personal, but it's essential i mean if we want to try to have a crossplatform-mono-openg-application which work fine, developing with a GUI. I agree it's depends of the goal of the applications, but for integrate with Linux, it's the best think you can do !
For the second, i think you will get more users if you have full fonctionnalities to allow user of the lib to be able to do same things than a C-opengl-program.
For the rest, i think the doc is really important to begin, but proposing only a "already-prepared project" in monodevelop and sharpdevelop (= visual studio) is enough. After, the use of the lib need more a known of opengl than the library itself.

the Fiddler.'s picture

first one - 9. Multiplatform Widget if possible (GTK could be the easier choice).
GTK#-OpenTK is almost ready but I haven't found the time to integrate and test yet. For the time being, Windows.Forms work fine on Mono/Linux - we just lack a decent GUI designer.

For the second, i think you will get more users if you have full fonctionnalities to allow user of the lib to be able to do same things than a C-opengl-program.
Good point. Ideally the user will be able to do more with C#/OpenGL than C/OpenGL with less effort (otherwise, why change?), so each of these tasks is important. Thing is, time is limited (and it's getting worse), so it's important to prioritize items that matter most. (Oh, and contributions are always welcome! :) )

george's picture

FSAA and stencil would be very nice.
Function level documentation isn't a huge issue imo because there's so much OpenGL documentation around which can be used directly, docs for the non-opengl stuff like maths and widgets and so on might be useful (maths is mostly done of course). More useful I think would be more small examples showing best practice of how to setup a modern OpenGL pipeline with VBOs, FBOs, shaders etc.

GOoOGle's picture

More useful I think would be more small examples showing best practice of how to setup a modern OpenGL pipeline with VBOs, FBOs, shaders etc.
I'im not agree with you about this point, because i think it's not the responsability of opentk to explain this, except if the opentk-way differs from the usual-way in classic opengl ( i mean if somes wrap for some functions are really slow, in comparaison with the original function). But for the rest, it's more useful to learn opengl with classic example, like the nehe tutorials or some other good book (http://nehe.gamedev.net/)

the Fiddler.'s picture

You are right that tutorials bundled with OpenTK will never be able to replace a good OpenGL book. On the other hand it would be nice to have some code available to fall back when something doesn't work as you expect (imagine for example you wrote some VBO code that crashed or produced incorrect results, it would be nice to have a working implementation to check your code against). It's also a good idea to document slow paths (like Vertex Arrays in .Net), to avoid nasty pitfalls.

I'm making changes on the Example Launcher right now, expect some updates and screenshots soon, which I think will cover the tutorial part quite nicely (about 50% of the documentation issue). I'm also working on a more general user manual (which covers issues like installation, good practices, distribution, etc), but this will take some time.

Thanks for your suggestions everyone, it's now more clear were OpenTK should head first. Cheers!

Anonymous's picture

A "performance manual" or something, detailing things like you mentioned (VA is slow in OpenTK?) would be worth it's weight in gold .. especially explaining those things that differs from how you would do it in C/OpenGL. :)

nythrix's picture

It's also a good idea to document slow paths (like Vertex Arrays in .Net), to avoid nasty pitfalls.
Hang on! What??

the Fiddler.'s picture

Yeah, it's true. Any OpenGL function with client-side storage will suffer under .Net - VA's are by far the worst offenders here.

Reason is, with client-side storage you are responsible for managing the memory. Since .Net uses a compacting garbage collector (which is free to move memory around), you have two choices:

  1. Either pin the vertex array in memory for as long as you need it, which fragments the heap and undermines GC efficiency (there is extensive performance analysis on MSDN blogs), or
  2. Allocate this memory in the unmanaged heap, which means you cannot easily modify it from the managed side.

Mind you, this only affects VA's; VBO's are server-side objects and are completely unaffected. Moreover, OpenGL 3 does away with client-side storage, so this won't be an issue in the future.

    Rules of thumb:

  1. Minimize OpenGL function calls. They have slightly bigger call overhead than plain C# function calls.
  2. Play nicely with the Garbage Collector. Avoid unecessary allocations and global 'pins'.

This boils down to: use Display Lists, use VBO's, use GLSL, don't use Immediate Mode, don't use VA's.

Efficiency will improve in the future (I have a plan that should drop function overhead close to native levels, more information soon), but if you have any performance questions feel free to ask! I'll also direct you to Rico Mariani's Performance Tidbits - he is an expert on .Net performance, and this blog is an information gold-mine.

nythrix's picture

This boils down to: use Display Lists, use VBO's, use GLSL, don't use Immediate Mode, don't use VA's.
Display lists will be gone as well. So I'm left with VBO's. I feel like dropping any further programming efforts till GL3. So depressing...
Common ARB, we need some fresh GL air here!

Thanks for the blog. Looks good!