Jump to content
  • Advertisement
Sign in to follow this  

Choosing a graphic library

This topic is 1516 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Me and my team are looking for a graphic library for C++. Unfortunately, until now we were not able to find a suitable libary.
What is our situation?
We programmed a game in Java using the JMonkey Engine 3.
Due to some technological reasons we decided to re-write the game in C++.
What are our skills?
We have already wirtten a small engine on top of OpenGL and worked with other graphic libraries. Still, we don't want to mess around with programming a 3D engine. Also, we don't have enough experience (and time/people) to programm a library that can keep up with modern graphic engines.
What do we need?
Simple answer - a modern graphic library. Features like physically based shading, tessellation, deferred shading, etc.. would be nice to have. We want to build the game engine by ourself - so we are combining several modules to our own engine that fits our needs. Some of them (like graphics and physics) should be handled by 3rd party libraries and others (like networking) are programmed by ourself. This is very important to us, since we can modify the engine later and change the graphics library in the future, for example. So we don't need a complete game engine - we need a seperare graphics library. Or an engine that lets you use only the 3D library of the whole package.
We don't want to set a maximum limit for the pricing - the cheaper the better. OpenSource would be best.
What do we have looked at already?
We have seen that the CryEngine and the UnrealEngine 4 offer fair licencing prices for indie-developers (from 10-20 € / month). Now, I don't know how these engines work. My fear is that they require you to use the shipped SDK to build your games with the engine. What we want is to develop our game in-code only, and write our own SDK/Editor for the game. Also, I doubt that you can only use the 3D part of the Cry/Unreal engine sepperately from the rest.
Libraries like Ogre3D and Irrlicht would have the structure that we are looking for (simply including the 3D library and using it), but I don't think it can keep up with modern graphic engines.
We also looked at Torque3D, Panda3D, Leadwerks and PixelLight (which seems quite promising but the last github commit is 2 years ago and no stable version was released so far).
Searching through the web I got really confused about todays game developing. I couldn't find a graphics library that could reach the rendering standards of engines like the Cry- or UnrealEngine. (I know the showcases of these engines have top-assets and so on, but there are some features like physically based rendering that would be so nice to have in a pure graphics library). Is this just the modern way of game developing? Choosing an engine and building the game on top of an SDK? I would feel deprived of my freedom, when I have to decide on an engine and content myself with its features. We want to build the engine ourself - and provide a useful interface that fits the needs of the game. These SDKs seem so straight forward - building a game out of the box. Doing a few clicks to create an FPS game. No freedom, no uniqueness. Might be that I'm wrong, this is just how these engines appear to me (no doubt that it still needs a lot of talent, training and work to actually create a good game with these SDKs).
So, what are my questions (finally)?
*Is there any graphics library out there that provides a C++ API that is not bound to an SDK (except to convert files into the right format, etc..) and is at the state-of-the-art (or at least, almost)?
*Is is possible to use the Cry- and/or UnrealEngine in-code only, so that we can abstract all functionalities into our own engine that isn't dependent of an SDK?
*Is our way of thinking really that outdated? Would it be better to just go with a complete engine?

Share this post

Link to post
Share on other sites

Your needs seem odd. Let me see if I've got this straight.


You are going to write:

  • math libraries
  • memory managers, pools, and related systems
  • file packing/unpacking, caching, and more
  • input managers, mouse and gamepad and joystick systems
  • Utilities, logging, scripting
  • Networking, streaming, lobbies, connections, topologies with partial meshes, host migration, fault tolerance, 
  • UI frameworks with widgets, windows, and more
  • controller systems that let you run scripts and handle messgaes locally and remotely
  • Animation systems, which usually tie into audio, streaming, physics, and more
  • Audio systems, that need to be synced up with multiple other systems
  • physics systems, which usually tie into AI, world management, data systems, and more
  • world editors, script editors, animation editors, resource packagers, fonts, and much more.
  • ...
  • and then you need to build a game out of it.


But you're fine doing that, instead you're just looking for a graphical rendering component?


If you have the capacity to do all the other things involved with building a modern game engine, hooking up D3D or OpenGL should be a relatively minor exercise.

Share this post

Link to post
Share on other sites
If you just want to drop in a graphics engine, Ogre3D is one of the few options you have. It's not the best graphics engine, nor the easiest middleware to integrate, nor so on... but it works, shipped games have used it, and it meets your stated needs. There's not really many alternatives; the guys doing cutting-edge graphics work are doing it with bigger game engines (Unreal, CryTek, etc.) and not stand-alone middleware libraries.

And that makes sense - graphics spans _far_ more areas of game development than just the rendering and file conversion. Your entire content pipeline is built around it. The animation system integrates with physics and game logic. The choice of scene graph depeneds very heavily on the game, how content is created for the game, and how you want to support in-game modification (think of a 3D-tile engine like NWN versus something like Battlefield - totally different beasts). Fundamental portions of rendering, audio, etc. are far more game specific than most people think.

Graphics middleware is generally best off supporting one small aspect of rendering (Umbra, Enlighten, PopcornFX, Granny, etc.) rather than being a complete drop-in renderer.

I think your evaluation of Unreal is way off, though. You can write custom game code in it just fine. You get full source code access and modify it to your heart's content. There's some very good reasons for games to not choose Unreal but the reasons you listed aren't one of those.

Share this post

Link to post
Share on other sites

http://urho3d.github.io/ is another possibility. It integrates a lot of the different parts together (sound, physics, networking, 3d, etc), but you could certainly take the graphics capabilities and glue your own systems together with it. That would of course re-invent what is already there in this package, but it does meet your requirements, I believe.

Share this post

Link to post
Share on other sites

Thanks for your answers!




But you're fine doing that, instead you're just looking for a graphical rendering component?


Yes. We are using libraries for rendering, physics and audio that take away the low level work from us. We are hooking this parts together by ourself in our engine - and only the parts that we really want to be included in the engine. Some points that you listed simply aren't needed in our project. We are only looking for a library that takes care of the rendering.


Urho3D is worth a try. I didn't have time to take a look at it but I will do so as soon as I can.


Yesterday, I read that Ogre 2.0 is currently WIP but there will be a first stable version soon. From what you can read in the forums it sounds very promising. If there are no other alternatives, I think we will go with Ogre.


Here are some links for those interested in Ogre 2.0.



Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!