开发者

OpenGL Wrapper in .Net

开发者 https://www.devze.com 2022-12-28 12:55 出处:网络
This question is similar to the one here. But I feel that the answers recommended ( such as Tao and OpenTK) are not good enough because they are just a开发者_如何学Go direct port from OpenGL, with no

This question is similar to the one here. But I feel that the answers recommended ( such as Tao and OpenTK) are not good enough because they are just a开发者_如何学Go direct port from OpenGL, with no OOP design, and hard to use.

What I'm looking for is a .Net OpenGL wrapper that is written in clear OOP principles, easy to use ( easy to apply textual and lighting, easy to debug etc), able to rotate the 3D diagram with mouse ( a feature that is critically missing from OpenGL and TAO), and the ability to export to other file formats ( such as dwg or dxf or Google Map file format).

Any suggestion? Both Open source or commercial components would do.


While you are correct that an OOP wrapper would be possible, the truth is that you need to understand how OpenGL works first (this is true of any wrapper API, and doubly so for OpenGL). Since you find the OpenGL API hard to use, you probably don't understand rendering well enough to use any wrapper API either.

Most wrappers avoid heavy class frameworks because storing state with each object and sending it to the GPU for each object is very inefficient and can kill your frame rate. You, the programmer, need to be aware of these pain points, not try to hide them behind an abstract wrapper layer. A library designer can't solve them for you.


Take a look at

  • MOGRE
  • osgDotNet


The big issue is that OpenGL isn't a OOP framework, it's a state machine (http://en.wikipedia.org/wiki/Finite-state_machine) as such any translation to a OOP library is going to add allot of complexity that will slow down your program. So either use it as a state machine, or look at a OOP library like OGRE. But for many things OGRE will be too restrictive.

When it comes down to it, why do you need OOP with OpenGL? There's a reason the library was written the way it was, and that is because it maps very cleanly to the hardware below it. A graphics card doesn't think in OOP, it's a state machine, and the library used to program it reflects that.


Maybe too arrogant, but I'm writing my own abstraction. It works most of the times, but it is in a planning state, but gives you an idea how to implements an "OpenGL" OOP abstraction.

Look at the SVN: http://sourceforge.net/projects/genomalib/develop

Surely it is not a solution for production code, but it's opensource and easy to extents once you get the design. Recntly I've added "deprecated" API, since it was initially written for rendering with shaders only (indeed it still miss support for "older" hardware); but surely I has the fundation for rendering...

0

精彩评论

暂无评论...
验证码 换一张
取 消