OpenGL 3.3+ open source 3D engine?

I’m trying to locate open source 3D engines on Linux that use “modern” OpenGL 3.3+ with MIT / BSD / zlib licenses. Here’s what I’m aware of:

Ogre has a new 3.3 renderer that seems to be a work in progress. Forum entries seem to indicate that “modern” shader architecture stuff for both OpenGL and DX11 are unfinished. I haven’t tried to build the sources yet to know where things are really at today. MIT license.

G3D has OpenGL 3.3 but only for Windows and OS X. They used to have Linux support but discontinued it due to too many distros to deal with. A recent mailing list post says they want to reinstate the support. BSD license.

ClanLib seems to support 3.3…4.3 but may not build on Linux. Haven’t checked it out yet. Zlib license.

Irrlicht claims OpenGL 3.x on their features page but I couldn’t find concrete evidence of it poking at it further. Zlib license.

Cube 2 looks like OpenGL 2.x. Someone’s working on something called Tesseract which might have more “dynamic lighting” capabilities, but it’s unclear that this means 3.x+. Couldn’t pin it down. Zlib license.

Additions and corrections welcome.

To my experience there isn’t any open source 3D engine that uses “modern” OpenGL, but I’d be happy to be proven wrong.

Don’t forget that just by restricting your API use to core OpenGL functions only doesn’t mean that you do things in the “modern” or “proper” way. A naive port of a GL 1.x/2.x engine to 3.x/4.x would not mean they take any advantage of what the “modern” API provides.

I think the bare minimum do “modernize” an engine is to do the followings:

  1. Conditional rendering support (if the engine relies on occlusion queries, which many engines do, it should use conditional rendering as much as possible to avoid CPU-GPU sync points)
  2. GPU based skeletal animation (many engines still use CPU side skinning, despite the technology for GPU based animation is there for a decade now)
  3. Instancing support (especially for particles, vegetation and other similar stuff)
  4. Uniform buffer support (remove all glUniform* calls, despite they are still in core, allows also for batching)
  5. Texture array support (use them as much as possible, batch draw commands together)

The most important take away here is to batch. GL 3.x+ provides dozens of different tech to support this, unfortunately they go unused 99% of the time.

Sorry if I went a bit off-topic, but I wanted to note these, and I would be interested too if anybody knows more recent news about open source 3D engines that I’m aware of (seriously, I’m pretty out-of-date).

From reading the Ogre forums it’s clear to me that they want to do it. However, it’s equally clear to me that they’ve been dragging their feet on DX11 for years, with “work in progress” for an awfully long time. Strategically, I’m not thrilled about hitching my wagon to Ogre, because providing an API that paves over both DX11+ and OGL 3.3+ capabilities will be an ongoing source of complication. As in the past, I expect the development of the OpenGL and Linux side of things will languish fairly often. Unless the Linux commercial game market really takes off, now that Valve has deployed Steam there. Even then, Ogre being both strong and modern on Linux is something I wouldn’t expect for 1…2 years. Anyone “more up” on Ogre is welcome to jump in with a different point of view, but I’ve been watching that community for a long time.

ClanLib and G3D are OpenGL only engines / libraries, which strategically is a better position to work from. I don’t know yet if they’re making “good” use of 3.3+ as you point out. Nor if ClanLib is solid on Linux, nor if G3D is easy to get up and running on Linux once again.

Lacking other suggestions I’ll be running through evaluations of these 3 engines in short order. It’s a pity to be on the eve of some kind of Linux “commercial game awakening,” and to find that the open source projects simply aren’t ready for it.

Necessity is the mother of invention, and there hasn’t been much need for open-source game engines. And any “Linux ‘commercial game awakening,’” won’t change that. The number of people who have need of a game engine is simply not large enough to allow a large number of open source game engines to exist. Especially when there are cheap, functional alternative engines available.

Remember: most of the new sort of indie games can be built on Flash or something like Unity or Corona. Why bother with C++ when you can just throw some 2D thing together in a scripting language?

Alfonse, I somewhat disagree with you. If the only open source projects out there would be only the ones that there is need for, then we would have way less of them. A lot of people do open source projects just for fun and that’s the beauty of it.

Historically very true. For quite awhile, DX11 hardly existed on anyone’s deployed HW, and modern OpenGLs didn’t really exist in the wild. So yes, in that era I understood why the Ogre developers dragged their feet. I think the tide turned with DX11 some time ago though, so in that instance, it’s more the inertia of open source, their tendency to not get gruntwork done. The DX11 foot dragging compounds OpenGL foot dragging because they believe they want to make a grand unified API covering both, and judging by the forums they don’t seem to be ever getting it done.

Anyways of the 3 engines I named, the lesser known G3D and ClanLib didn’t build on my Linux box, so now I’ll be focusing on what Ogre is currently capable of. If all of them require gruntwork, I’d sooner do Ogre gruntwork unless that proves to be a bad call for other reasons. Ogre manages to sustain a critical mass of developer interest despite its foot dragging.

And any “Linux ‘commercial game awakening,’” won’t change that.

I think it will in time. But the critical mass of perceived need in open source may not arrive for 1…2 years yet.

The number of people who have need of a game engine is simply not large enough to allow a large number of open source game engines to exist. Especially when there are cheap, functional alternative engines available.

But what would you suggest as “cheap” and based on modern desktop OpenGL 3.3+ for a Linux developer? Assume “hardcore” 3d game development, not this wimpy “look at my smartphone” stuff.

Remember: most of the new sort of indie games can be built on Flash or something like Unity or Corona. Why bother with C++ when you can just throw some 2D thing together in a scripting language?

I agree that a lot of the gaming money grab has been driven by mobile devices of rather modest specs, especially on iOS, and possibly more recently on Android although I haven’t been paying attention. Personally I hate those devices. OpenGL ES 2.x is sufficient for such games, but not the kind of game development I personally want to do.

Open Scene Graph claims OGL 3.x and 4.x support, but has some kind of weird LGPL based hybrid license. It’s C++ based and they consider subclassing to be outside of the scope of the license, so that sounds usable if not my ideal MIT / BSD / zlib preference. They were an early CMake adopter and had a conscientious buildmaster back in the day. I’ll see what it can do.

EDIT: the CMake build system is solid, as expected. It appears to be one of those naive compatibility ports, or else just leaves the programmer to worry about 3.3+. You activate GL3 context support by providing your own GL3/gl3.h somewhere, then flipping a number of CMake variables that turn off fixed function pipelines and the like. No mention of GL4 or glcorearb.h. No modern shader files to exercise 3.3+. Since this is not a default capability of the build, and there’s only 1 GL3 code example, I doubt very much this is getting any exercise. Rather, there’s some structure in place to do GL3+ stuff if you intend to do it entirely yourself, and YMMV.

The hybrid LGPL-derived license has an exception which allows the shipment of statically linked binaries, so that eliminates one of the major objections to using the LGPL in commercial work.

But what would you suggest as “cheap” and based on modern desktop OpenGL 3.3+ for a Linux developer? Assume “hardcore” 3d game development, not this wimpy “look at my smartphone” stuff.

People who look for open source solutions, by and large, do so because they can’t afford something better. Beggars can’t be choosers, so they use what’s available to them. The ones who actually ship games (as opposed to the people who try to ship games, then get bored and move on to something else) will ship games that they can make, given their means.

Making a game that requires some actual GL 3.x functionality requires money. If you can’t afford a for-pay game engine, then you certainly can’t afford to actually do something with GL 3.x.

The people who have the money to do “‘hardcore’ 3d game development” are not going to base the success of their expensive game on open source engines. Not when they can buy something far more functional, with real, actual support behind it.

Not to mention the fact that if you have limited means, you won’t be making a game people have to pay a lot for. So you’re going to need people to be able to run it on more hardware. Limiting it to GL 3.3 means cutting out pretty much any pre-Ivy-Bridge Intel systems.

So Python, Eclipse, GCC, and Linux users are all beggars? You have half a point, but you’re ignoring a lot of the ideological direction of open source software to make it. How do you think this opengl.org forum software is licensed, that you use to post such sentiments?

Some followup.

Irrlicht does not have anything more than some fixed function emulation in OpenGL 3.x contexts. They do plan to do real 3.x stuff in the future.

I spent some time with the ClanLib developers for a bit, fixing up their 3.0 build system and correcting minor bugs so that it will build on Linux. They were very responsive about fixing anything trivial. Things were going ok until I became aware that they have a strictly hobbyist level of focus for ClanLib’s future. It might be appropriate for an enterprising indie who doesn’t need turnkey support or third party consulting, and who’s comfortable with treating the whole thing as “starter code” if one of their few core developers gets hit by a bus. I would not recommend it to any “heavyweight” commercial developer.

Ogre has the commercial infrastructure that ClanLib lacks. It is, however, strictly a 3D rendering component and not a game engine. Commercial projects get done with Ogre, but the open source ecology of Ogre add-ons and third party libraries leaves a lot to be desired. It was stronger a few years ago but now there are lots of inactive projects going without maintenance. I did a major housekeeping on their wiki pages to save anyone else the trouble of stumbling over the bitrotted stuff. What’s left in third party land is a pretty small working set. You’ll be rolling your own game engine with that one. Nevertheless, it’s the only open source project I’d consider contributing to, for forwards-looking commercial minded development right now. I don’t see that any of the other projects have the legs.

The NeoAxis commercial engine is based on Ogre. It’s a full game engine and integrates what Ogre itself did not. The company is basically 2 guys. They aren’t hugely profit minded and are talking about taking their work open source somehow. This is not very interesting to me right now because it’s a Windows engine. Adding Linux support in an open source project has been discussed, but at last count it didn’t sound high on many people’s TODO list, so I don’t think that helps my own cause personally. I may check on what they’re up to at some point.

[QUOTE=Brandon J. Van Every;1248579]I’m trying to locate open source 3D engines on Linux that use “modern” OpenGL 3.3+ with MIT / BSD / zlib licenses.
[/QUOTE]

Linderdaum Engine is OpenGL 3.3+ Core based and runs pretty nice on Windows (as on Windows, MacOS, Android and BlackBerry 10). OpenGL ES 2 is also there.

Unfortunately Linderdaum doesn’t have the licensing I was interested in. It’s free for non-commercial use, and available for commercial use at an unspecified price.

Lol :smiley: Have you tried to reach them via mail?

“Them?” You are listed as a core developer; perhaps you don’t handle the pricing. I will say, when developers list their price as “unspecified,” it comes across as a “business to business” proposition. That implies a big contract negotiation, and that it’s going to be expensive. As a small indie developer, contacting someone about such an arrangement is not interesting. I’d either be interested in off the shelf, “here’s what it is” product terms, or open source as I originally posted.

I find it odd that you are having trouble with building ClanLib on Linux. ClanLib started off being Linux only. In its beginnings it was mostly a 2d library though.

Most of the open source engines have a linux target. Besides the ones already mentioned there is also Crystal Space which is one of the oldest engines available on Linux, but is still actively developed. It looks like it is being included in the 2013 Google Summer of Code. Not sure which OpenGL spec they are up to, but they are OpenGL exclusive so its the focus of what they do.

Was, past tense.

  1. I debugged, submitted patches, or otherwise precipitated them fixing things.
  2. I found out they are a strictly hobbyist project, and thus are not of use to me.

ClanLib started off being Linux only.

This is what happens, I think, when people have a hobbyist mentality to development. They don’t realize how little labor they have at their disposal. Years go by and the project drifts in such and such direction, depending on who’s actually working on it. Without an effort to attract a critical mass of developers, some things fall by the wayside.

In its beginnings it was mostly a 2d library though.

I noticed the bones of that in their demo code. I’m not sure how far beyond 2D they’ve moved.

Crystal Space which is one of the oldest engines available on Linux, but is still actively developed.

LGPL

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.