objarni's picture

Hooray for OpenTK!

Just wanted to share with you my love for OpenTK! It is really getting better and better every week :)

Anybody wanna join in the celebration, add a comment below!


Comments

Comment viewing options

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

OpenGL is a great cross platform low level API, but it takes a lot of work to make an efficient game or application with it.

There are some rendering engines out there that are either C# or have C# bindings.

Ogre3D seems to be a well thought out rendering engine written in C++.
MORGE is a C# wrapper for Ogre3D. It seems pretty nice but I do not know it it would work under LINUX since I think they put special code in the C++ MOgre libraries.

AxiomEngine is a cross platform C# engine that is a port of the Ogre3D engine. I do not know how mature it is though.

The nice thing about these engines is that they optimize the loading of models and handle materials and shaders for you. There are a lot of tricks to fast rendering, from using the proper hardware buffers to sorting the rendering of objects by state and texture. They also support advanced materials, shaders, shadows, and scene culling. These engines do it for you.

I have been wondering of late if a pure C# rendering engine such as the axiom engine which has to call an unmanaged API like OpenGL or a managed wrapper like MOgre that calls the unmanaged orge3D API which can directly access the OpenGL API would be more efficient. Since calling from managed to unmanaged code requires a pInvoke which does have overhead, a question is which one would have fewer pInvokes?

My initial gut feeling is that the MOgre wrapper may be faster, but there are tricks both APIs could make.

djk's picture

I experimented with Ogre3d at my last job, at the time the C# wrapper was not available, I was trying to take a game engine and pound it into an engineering application. We successfully demonstrated a prototype that was abandond by management.

My son has followed the Axiom crowd and development around for several years, my impression is that there was a loss of focus awhile back and the new team is intent on taking Axiom to XBox. If I remember right my son did have a version of Axiom running on his Gentoo laptop using Mono, but it was a very difficult process.

the Fiddler's picture

There's no doubt that using a game engine is easier than using OpenGL directly (if it isn't, there's something terribly wrong with the engine). On the other hand, engines tend to restrict you to a specific set of features; move outside that set, and things start to get more difficult, ugly and/or hackish. From my experience, .Net bindings on top of a C++ application tend to be less usable than a fully managed solution (problems inheriting from objects, C++ conventions leaking into managed code etc).

OpenTK does not aim to be a 3d engine. It's not a game-development library either (how many gamedev libraries can handle multiple monitors and multiple contexts cleanly?) It could be classified as a low-level multimedia library with a focus on usability, which makes it suitable for a wide range of applications: from games to engines and 3d modelling/visualisation software. It does try to simplify OpenGL development in the managed world, to the extent that this is possible (OpenGL is a complex beast) - OpenGL 3 will hopefully take this a step further.

I have been wondering of late if a pure C# rendering engine such as the axiom engine which has to call an unmanaged API like OpenGL or a managed wrapper like MOgre that calls the unmanaged orge3D API which can directly access the OpenGL API would be more efficient. Since calling from managed to unmanaged code requires a pInvoke which does have overhead, a question is which one would have fewer pInvokes?
On my machine (Core 2 @2.66GHz), a straight function call consumes about 1.5ns. A simple pinvoke costs about 8.5ns on Mono/Linux x64. For non-trivial applications like MOgre and Axiom, the p/invoke overhead will be insignificant compared to memory management, state batching and other high-level optimizations.

The one place where pinvoke overhead *does* matter are math functions - depending on how complex the function is, it might make sense to pinvoke hand-optimized native code, rather than perform the calculations in managed code. For simpler functions however, pure managed code will be faster than a pinvoke, so even this is not a clear-cut case. A relatively recent benchmark:

Machine: Core 2 Duo E6600 clocked at 3.0GHz
Managed XNA - Matrix.Multiply(ref,ref,out): 557ms
Managed w/ P/Invoke to SSE2 function:       341ms
Native C++ - Full Compiler Optimizations:   300ms
Native C++ - hand-optimized SSE2:           138ms
Inertia's picture

I'm quite sure that for 2D applications the overhead is absolutely neglectible.

Regarding 3D: according to Microsoft's keynote the performance of Marble Blast's XNA version is "in striking distance" to it's C++ counterpart, and they built the whole engine in 3 weeks. (!) (<- Don't overlook the !)
Tom Miller's book "Beginning 3D Game Programming" claims the difference to be 7%, according to MSDN forums.

Imo it's also important to consider what sacrifices you're willing to make for performance. Without doubt, developing with .Net is by far more fun and productive than working with C. Importing optimized unmanaged functions to a managed environment is only a half-hearted solution, if you're a speed-junkie then you'll have to eat the sour apple and stick with C/Assembler, or use a stock engine.

It's also much about the level of programming you like to do. If you want quick results and scripting is most you want to do, take a look at a commercial engine (like Unreal 3, which runs on more platforms than you have fingers) which are usually very highly optimized and mature. None of the homebrew engines can compete with commercial solutions for game creation, and those packages usually also include alot of tools that help speeding up the development process aswell.
You can start developing your game as a Mod ontop of those engines, and acquire a license if you intend to go commercial with it at some point. Or use the previous iteration of their engines, which come with full source code and are - by far - cheaper.

Just trying to give an objective analysis of the Wrapper vs. Engine problem. (as objective as I can possibly be, with my choices made)

Edit: Forgot to comment on the 'benchmark'. C compilers have been under development for over 3 decades now and obviously had alot of smart people doing optimizations. Net is rather young and the mentioned 7% will more likely move towards 5% than 10% in the coming years. The overhead differences between Mono and Net already show that there's room for improvement.

Datriot's picture

OpenTK has been very useful for me. I've allways like the way .Net works and OpenTK does exactly what I need. The fact that this is still a growing community and there are still active updates on it makes me feel like I made a good choice with this.
Kudos to Fiddler, Inertia and any other people who helped make this happen. :)
I'll also be posting my game in the Personal Projects section quite soon, it's coming along nicely.

Inertia's picture

The discussions OpenGL vs. DirectX, unmanaged vs. managed and Wrapper vs. Engine are all obsolete now. Everyone was wrong.