text: ).
  Meanwhile I have some questions regarding GL 4.1
  Re: OpenGL 4.1 support
  Thank you for your answer.
  OK, I see it's low priority task for you, but not for me. So I'll be glad to do it by myself, but there is still no answers for my questions 'bout OpenGL 4.1 bindings generation. Although It is interesting for me to get a post from the_fiddler, especially on the OpenTK development and support.
  Re: OpenGL 4.1 support
  Yeah sorry, I dodged that because there is no simple answer to it and every time we did update to a new GL version, we found gremlins or desireable features that needed to be addressed at the generator source code, and that is why it's a non-trivial task adding GL 4.1 (also 4.0 and 3.3). No offense, but it will cost considerably more time teaching you how to make all the modifications than simply doing them.
  While waiting for Fiddler's input, feel free to comment on my questions or explain what makes GL 4.1 a priority for you.
  Edit: Nvidia just released slides from the GPU technology conference 2010 and indirectly answered all questions. Thanks ;)
  Re: OpenGL 4.1 support
  4.1 support is coming. I tested the generator as soon as 4.1 was announced and it consumed the new specs quite well. However, the released spec files were incomplete at that point so it didn't make any sense to devote any more time on that.
  I've spent the last month working on less visible stuff (tests for faster extension loading, better debugging, a new build server and build process) and we should start getting results by next week or so. I've also working on a few features to make new specs easier to support.
  What we are missing now is a cleanup of the new 4.1 functionality in the essence of the 3.3/4.0 enums that are in the bug tracker.
  Re: OpenGL 4.1 support
  I have a slightly off-topic question about post-3.3 support: How will you handle Core- and Compatibility-profiles in the Toolkit?
  I for one would like to be able to separate these, on a programmatic level. Perhaps a namespace for Core and an additional namespace, Compatibility, with only the now deprecated functionality. Preferable in separate assemblies.
  Re: OpenGL 4.1 support
  GL 4.1 cleanup should be complete by the end of the week(end), I need to cross-check some enums with the GL 4.0 cleanup to ensure we are not creating unnecessary duplicates.
  Rawn, there are several lengthy discussions in the forum regarding this, but in short we agreed not to take any actions regarding core and compatibility. In practice, applications will encapsulate the low level GL calls into a class, and after that it's not transparent anymore whether you're using comp. or core anyways. OpenTK 2 will go that road (look for keyword "GLOO", and/or CLOO and ALOO) which will be a lighter API with core features only. (lowlevel access is not going to disappear, we provide both)
  What we have atm is automatic error checking when doing Debug builds. This helps alot to find any invalid functions/tokens, when using a core profile. IIRC this is the only action we are taking regarding deprecation.
  Note: In the presentation linked 3 posts above, Nvidia does recommend to use compatibility - NOT core - profile in your applications! It's a misbelief that core profile will be any faster, in contrary: the additional "is this allowed?"-checks can cause the core profile to be slower. I have no written proof for it, but it's very likely true for Ati's drivers, too.
  Re: OpenGL 4.1 support
  Thanks for the fast and lengthy reply. I look forward to OpenTK 2.0 then. I will take a look at GLOO for now and see what it is about. Again thanks.
  Note: I have never held any beliefs about performance differences between the profiles, nor have i particularly cared. If i cared about every little percentage of performance, i would never have looked at OpenTk to begin with. I do think however, that using the core profile will make your code look a lot cleaner, something i care a great deal about.
  Why would the core profile be slower however? Why would you need to make those checks at all? From an engineering standpoint it seems... unnecessary. Isn't it something that should be decided on header/library level and discarded by the compiler if it differs? I.e if i was using C++ and added the coreGL header file, that would be enough to make sure i couldn't call anything deprecated. No extra run-time check would be necessary. The same should apply to OpenTK. Namespaces are resolved at compile-time.
  Re: OpenGL 4.1 support
  Gloo is not ready yet but it is coming together. I'll make an announcement once it becomes ready for testing.
  I'm actually adding the facilities to make a split between OpenGL profiles possible. I don't know how far I should take this, but at the very least you should be able to compile a custom OpenTK version that contains only the profiles you need. I'm still weighting our options.
  Re: OpenGL 4.1 support
  Thanks for good news, I'm glad to hear that OpenTK is alive!
  While waiting for Fiddler's input, feel free to comment on my questions or explain what makes GL 4.1 a priority for you.
  OpenGL is interesting for me in general, cause I have a hobby - graphical engines, and I rewrite my one with each major change in OpenGL. Last one I wrote uses OpenTK and OpenGL 3.2 and is written on C#4.0.
  In OpenGL 4.1 I especially wait for debug output extension and 64bit vertex attributes which allows me for example to render star system and galaxies using one global coordinate system.
  Now I was about to choose what to do - go back to C++/SDL or dig into OpenTK Generator code, but if you are going to done with OpenGL 4 in a week, I have no doubts :)
  Also I'm surprised that this task have no priority for you - recent versions of OpenGL is popular, there is a lot of news, rumors and noise in WWW about them. All this can draw a bit of public attention to OpenTK if you declare latest OpenGL support, cann't it?
  Edit: Nvidia just released slides from the GPU technology conference 2010 and indirectly answered all questions. Thanks ;)
  Nvidia does recommend to use compatibility - NOT core - profile in your applications!
  Too few new nice renderings in comparison with last presentation :(
  And indeed, as in last presentation NVIDIA again declare that core profile as slow profile..
  IMHO NVIDIA actually says: we done no clean and new core profile for now, but make a wrapper on the top of old profile. So current core implementation is temporary and it cann't be faster then compatibility profile even in theory. But I belive potentially it may be optimized mach better. And will be, in other case there is no reason for it to be. I hope in future code of different profiles would be separated.
  Also note all this relates to NVIDIA drivers.
  I'm actually adding the facilities to make a split between OpenGL profiles possible.
  It would be great! Waiting with impatience :).
  Add my voice to those requesting OpenGL 4.0 support at least - and 4.1 support wouldn't go amiss.
  Any displacement-mapped model can be used for tessellation, so ZBrush, etc. are perfect for it. However, I find the tessellation support is much more interesting with respect to terrains and environments...