Is there a middleground between writing raw OpenGL versus using a full-blown game engine? - opengl

I'm playing around with OpenGL and I'm finding myself writing code that I feel like I shouldn't have to write.
GLU and GLUT are nice but not really what I'm thinking of.
Code to load .obj models (vertex and normal vectors) from Blender and render them.
Code for collision detection.
Code for navigation/camera stuff.
Code for simple terrain generation.
But at the same time I feel like a full-blown game engine is more than I need.
Are there any good libraries built on top of OpenGL that I could take advantage of, perhaps to create relatively simple games? I don't necessarily need all of the items listed above. Those are just examples of what I'm thinking of.

Yes.
I can't be more specific as I don't write my own game engines but I do have a list of libraries online at this location, most of which sit below being a full engine.

Ogre
Irrlicht
openscenegraph (replaces performer)

Depending on how much you need, one of these toolkits / libraries might suit your purpose.
GLUT - OpenGL Utility Toolkit
Ogre3D - OGRE Object Oriented Graphics Library
Open Inventor - OpenGL toolkit for scene management created by SGI
Performer - OpenGL toolkit for real-time rendering created by SGI

I learnt my opengl stuff from GameTutorials and Gamedev. Unfortunately gametutorials are no longer a free selection of tutorial (there's some examples) but they were good. Coupled with SDL, you would have code to do everything you wanted - and you'd be able to understand what is going on under the covers, something I find is very useful later on (if, for example you wanted to write HTML5/WebGL code later).
A lot of the game engines aren't as well documented as I'd like (well, weren't a few years back when I was looking), but they might still do what you need. Sourceforge has many, including Ogre3d, Irrlicht, and CrystalSpace.

In general I agree with your sentiment. There is a school of thought that says that programming should consist of pluggable modules. Once youve written an OpenGL app, you should be able to grab a model loader, and/or a skeletal animation engine and plug them in.
The depressing thing is, most of the game engines on that list (that Ive looked at) are all or nothing propositions. They provide an entire framework and do not really take into account the more common real case scenario.
That said, all is not lost. A lot of those engines package up a number of other 'utility' libraries into their distribution. With a bit of patience it is possible to piece together the component libraries yourself: OpenAL for the sound, Freetype for font rendering, libpng, libjpeg etc for image codecs

Related

Learning modern OpenGL

I am aware that there were similar questions in past few years, but after doing some researches I still can't decide where from and what should I learn.
I would also like to see your current, actual view on modern OpenGL programming with more C++ OOP and shader approach. And get sure that my actual understanding on some things is valid.
So... currently we have OpenGL 4.2 out, which as I read somewhere requires dx11 hardware
(what does it mean?) and set of 'side' libraries, to for example create window.
There is the most common GLUT, which I extremely hate. One of main reason are function calls, which doesn't allow freedom in the way how we create main loop. As some people were telling, it was not meant for games.
There is also GLFW, which actually is quite nice and straight-forward to me. For some reason people use it with GLUT. ( which provides not only window initialisation, but also other utilities? )
And there is also SFML and SDL ( SDL < SFML imo ), whereas both of them sometimes need strange approach to work with OGL and in some cases are not really fast.
And we have also GLEW, which is extension loading utility... wait... isn't GLUT/GLFW already an extension? Is there any reason to use it, like are there any really important extensions to get interested with?
Untill now we have window creation (and some utilities), but... OGL doesn't take care of loading textures, neither 3D models. How many other libs do I need?
Let's mention education part now. There is (in)famous NeHe tutorial. Written in C with use of WinApi, with extremely unclear code and outdated solutions, yet still the most popular one. Some stuff like Red Book can be found, which are related to versions like 2.x or 3.x, however there are just few (and unfinished) tutorials mentioning 4.x.
What to go with?
So... currently we have OpenGL 4.2 out, which as I read somewhere requires dx11 hardware (what does it mean?) and set of 'side' libraries, to for example create window.
DX11 hardware is... hardware that has "supports DirectX 11" written on the side of the box. I'm not sure what it is you're asking here; are you unclear on what Direct3D is, what D3D 11 is, or what separates D3D 11 from prior versions?
FYI: D3D is a Windows-only alternative to using OpenGL to access rendering hardware. Version 11 is just the most recent version of the API. And D3D11 adds a few new things compared to D3D10, but nothing much that a beginner would need.
OpenGL is a specification that describes a certain interface for graphics operations. How this interface is created is not part of OpenGL. Therefore, every platform has its own way for creating an OpenGL context. Windows uses the Win32 API with WGL. X-Windows uses the X-Windows API with GLX functions. And so forth.
Libraries like GLUT, GLFW, etc are libraries that abstract all of these differences. They create and manage an OpenGL window for you, so that you don't have to dirty your code with platform-specific details. You do not have to use any of them.
Granted, if you're interested in learning OpenGL, it's best to avoid dealing with platform-specific minutae like how to take care of a HWND and such.
And we have also GLEW, which is extension loading utility... wait... isn't GLUT/GLFW already an extension? Is there any reason to use it, like are there any really important extensions to get interested with?
This is another misunderstanding. GLUT is a library, not an extension. An OpenGL extension is part of OpenGL. See, OpenGL is just a specification, a document. The implementation of OpenGL that you're currently using implements the OpenGL graphics system, but it may also implement a number of extensions to that graphics system.
GLUT is not part of OpenGL; it's just a library. The job of GLUT is to create and manage an OpenGL window. GLEW is also a library, which is used for loading OpenGL functions. It's not the only alternative, but it is a popular one.
Untill now we have window creation (and some utilities), but... OGL doesn't take care of loading textures, neither 3D models. How many other libs do I need?
OpenGL is not a game engine. It is a graphics system, designed for interfacing with dedicated graphics hardware. This job has nothing to do with things like loading anything from any kind of file. Yes, making a game requires this, but as previously stated, OpenGL is not a game engine.
If you need to load a file format to do something you wish to do, then you will need to either write code to do the loading (and format adjustment needed to interface with GL) or download a library that does it for you. The OpenGL Wiki maintains a pretty good list of tools for different tasks.
There is (in)famous NeHe tutorial. Written in C with use of WinApi, with extremely unclear code and outdated solutions, yet still the most popular one. Some stuff like Red Book can be found, which are related to versions like 2.x or 3.x, however there are just few (and unfinished) tutorials mentioning 4.x.
What to go with?
The OpenGL Wiki maintains a list of online materials for learning OpenGL stuff, both old-school and more modern.
WARNING: Shameless Self-Promotion Follows!
My tutorials on learning graphics are pretty good, with many sections and is still actively being worked on. It doesn't teach any OpenGL 4.x-specific functionality, but OpenGL 3.3 is completely compatible with 4.2. All of those programs will run just fine on 4.x hardware.
If you are writing a game, I would avoid things like GLUT, and write your own wrappers that will make the most sense for your game rendering architecture.
I would also avoid OpenGL 4.2 at this point, unless you only want to target specific hardware on specific platforms, because support is minimal. i.e., the latest version of Mac OSX Lion just added support for OpenGL 3.2.
For the most comprehensive coverage of machines made in the last few years, build your framework around OpenGL 2.1 and add additional support for newer OpenGL features where they make sense. The overall design should be the same. If you're only interested in targeting "current" machines, i.e. machines from late 2011 and forward, build your framework around OpenGL 3. Only the newest hardware supports 4.2, and only on Windows and some Linux. If you're interested in targeting mobile devices and consoles, use OpenGL ES 2.0.
GLEW loads and manages OpenGL Extensions, which are hardware extensions from different vendors, as opposed to GLUT which is a toolkit for building OpenGL applications, completely different things. I would highly recommend using GLEW, as it will provide a clean mechanism for determining which features are available on the hardware it is being run on, and will free you from the task of having to manually assign function pointers to the appropriate functions.
OpenGL SuperBible is a pretty good book, also check OpenGL Shading Language. Everything you do with modern OpenGL is going to involve the use of shaders - no more fixed functionality - so your biggest challenge is going to be understanding GLSL and how the shader pipelines work.
I'm currently learning modern OpenGL as well. I've also had hard time finding good resources, but here's what I've discovered so far.
I searched for a good book and ended up with OpenGL ES 2.0 Programming Guide, which I think is the best choice for learning modern OpenGL right now. Yes, the book is about OpenGL ES, but don't let that scare you. The good thing about OpenGL ES 2.0 is that all the slow parts of the API have been removed so you don't get any bad habits from learning it while it's still very close to desktop OpenGL otherwise, with only a few features missing, which I think you can learn rather easily after you've mastered OpenGL ES 2.0.
On the other hand, you don't have the mess with windowing libraries etc. that you have with desktop OpenGL and so the book on OpenGL ES won't help you there. I think it's very subjective which libraries to use, but so far I've managed fine with SDL, ImageMagick and Open Asset Import Library.
Now, the book has been a good help, but apart from that, there's also a nice collection of tutorials teaching modern OpenGL from ground up at OpenGL development on Linux. (I think it's valid on other OSes the name nevertheless.) The book, the tutorials and a glance or two every now and then to the Orange Book have been enough in getting me understand the basics of modern OpenGL. Note that I'm still not a master in the area, but it's definitely got me started.
I agree that it's king of hard to get in to OpenGL these days when all the tutorials and examples use outdated project files, boken links etc, and if you ask for help you are just directed to those same old tutorials.
I was really confused with the NeHe tutorials at first, but when I got a little better understanding of C, compiling libraries on UNIX and other basic stuff, it all fell into place.
As far as texture loading, I can recommend SOIL:
http://www.lonesock.net/soil.html
I'm not sure but I recall I had trouble compiling it correctly, but that may have been my low experience at the time. Give me a shout if you run into trouble!
Another usefull tip is to get a Linux VM running and then you can download the NeHe Linux example code and compile it out of the box. I think you just need GLUT for it to work.
I also prefer GLFW before GLUT, mainly because GLUT isn't maintained actively.
Good luck!
The major point of modern OpenGL is tesselation and new type of shader programs so i would like to recommend to start from a standalone tutorial on OpenGL 4 tesselation, i.e: http://prideout.net/blog/?p=48
After manuals and tutorials a good follow-up is to take a look at the open-source engines out there that are based on top of "new" OpenGL 3/4. As one of the developers, I would point at Linderdaum Engine.
"Modern OpenGL programming with more C++ OOP and shader approach" makes me mention Qt. It hasn't been mentioned yet but Qt is a library that is worth learning and is the easiest way to write cross platform C++ apps. I also found it the easiest way to learn OpenGL in general since it easily handles the initialization and hardware specific code for you. Qt has it's own math libraries as well so all you need to get started with OpenGL is Qt. VPlay is a library that uses Qt to help people make games easily so there are obviously some people using Qt to make games as well.
For a short introduction to Qt and OpenGL see my post here.
I will mention that since Qt abstracts some OpenGL code, if you are trying to use the Qt wrappers, the API is slightly different than just OpenGL (although arguably simpler).
As for my vote for good tutorials or book check out Anton's OpenGL tutorials and Swiftless tutorials. Anton's ebook on Amazon is also rated higher than any other OpenGL published resource I have seen so far (and far cheaper).

C++ Game Programming Resources

Where can i get some advanced game programming resources for c++?
At http://gamedev.stackexchange.com ?
More specifically, this question and lots of others tagged with c++
Start with writing some simple 2D games, e.g. Snake, TicTacToe, etc. Write these using any GUI builder you're already familiar with.
Then try to rewrite these games using a serious graphic engine, e.g. SDL, OpenGL, or DirectX.
Then try to write a more complex 2D games, e.g. side-scroller. Write these games with the graphic engine of your choice.
Then add some simple 3D effect to your 2D game, e.g. parallax scrolling.
Then rewrite this effect with true 3D, use 3D models/sprites, 3D environment, etc, while maintaining a 2D look and feel.
Then add some simple 3D look and feel, e.g. allowing characters to move in the Z-direction (to/from the camera), doing camera rotation, etc.
If you just got out of the command prompt and simple GUI, you'll probably want to start simple.
I'd very much recommend OpenGL as your API of choice. Since you've done some simple GUI programming, you'd know what an API is.
OpenGL has the following advantages (compared to SDL and DirectX previously mentioned):
-Its hardware accelerated (SDL is not as far as I know)
-Its 3D (SDL is 2D)
-Its cross-platform (DirectX is Windows only)
By far the best place to start with OpenGL is the Nehe tutorials.
http://nehe.gamedev.net/
Game programming becomes evident once you become a bit more familiar with the API.
Also, I'd heartily recommend GLUT (OpenGL Utilities Toolkit). It simplifies window creation and user input handling, among other things. Its great for learning OpenGL. It also happens to be cross platform.
Here's freeglut, a free GLUT implementation:
http://freeglut.sourceforge.net/
OpenGL is also a relatively simple and easy API to learn. You'll be going into 3D in no time.
What libraries are you using? You can try GP wiki. It can be a bit hit and miss depending on what you want to use.
By "resources," do you mean tools? Libraries? Tutorials? I have a bunch of useful game developer links in the sidebar of my own site. I also think "Mathematics for Game Developers" was very helpful. It has a second edition as well.

Creating effects in 3D game from scratch, using c++ and DirectX

So the title says it. I couldn't find any info on how actualy build effects into 3D game. I'll maybe stick to some engine later, but for understanding of this whole thing I would need to try it on my own for this time. I found a few about particle systems which may be the right way but any other connection between DirectX and particle systems on google gave results as 3DSmax and etc.
So I would be thankful if you would point me on some tutorials for this, or explaining it...
Last possibilitie would be pointing me on some simple engine focused on this thing (I don't really want to fight through tons of code and understanding how this engine works, I just need to see how they implement this FX stuff).
Thanks
PS: the other possibilitie would be if you know about good book discusing this. It can be more complex but apart from tutorial, books are usually wrote more basicly so this would be also nice way to go
First of all: particle effects are just one kind of effects, it's better you specify the word particle engine :p.
Secondly: search int he articles of Gamedev, it's really the best resource if you want things like this. You can find lots of articles and even better, tons of links, and useful information on the discussion boards. Two articles I can link to is the NeHe lesson about particles in OpenGL, it's not directx but NeHe tutorials for OpenGL are very good. I also found one for directx8 and VB (so a little bit older).
Keep in mind though that a particle engine is often a huge performance hit if you can't optimize it yourself, so try to look at open source game engines (e.g. OGRE) on how they implement it or even better, specific particle engines.
So I would be thankful if you would point me on some tutorials for this
You need to download microsoft DirectX SDK.
In addition to it, you should try NVidia SDK.
You may also try ATI SDK. Study them all.
In addition to them... there are couple of books on OpenGL: "Red Book", "Blue Book", Orange Book . "Computer graphics using OpenGL" by Francis Hill is also a very good one.
Get this info, and start reading.
how actualy build effects into 3D game
This question is too broad. There are lighting effects, particle systems, post-processing effects, physics (which are also effects), and even character animation is an effect. It is unclear what kind of effects you are talking about.
What do you think is better DirectX or OpenGL.
They are more or less equal. You can do same things in both of them. Try both and pick one you liked more. OpenGL is better for playing around and experimenting (because you can easily draw triangle without messing with hardware buffers), available on larger selection of platforms, plus GLSL is better than HLSL (because it doesn't "compile into assembly"). DirectX is geared towards performance from the beginning, available on XBox360, and 9th version was actually good. openGL is more "abstract" and DirectX is closer to hardware.
If you could use the factors as simplicity, area of usage, performance, number of examples and resources etc
If you want simplicity, you should forget about making game engine. You'll have to learn quite a lot of things if you want to deal with 3D.
Both DirectX and OpenGL are used for making 3d-related products.
You can get good performance with both DirectX and OpenGL, and get poor performance if you don't know what you're doing.
Both DirectX and OpenGL have insane amount of examples and books - just search for it. They weren't made yesterday, so enough information is already available.
You need to select goal, select platform, select your API, research available technologies, and start writing code. Wondering "which one is better" is a waste of time. 3D knowledge and algorithm are equally applicable to both APIs.
OpenGL is the best bet to learn I feel. Glut is available free of cost and has all the functions you need to implement a particle engine. Plus theres loads of sample code online. I like the way functions are . Easy to remember and use logically
The best books for learning D3D9.0c/D3D10 are by Frank Luna. Just put him in to amazon or google and you'll get results. He teaches how to build a fully-fledged game engine from scratch.

What environment should I use for 3d programming on Linux?

One thing I always shy away from is 3d graphics programming, so I've decided to take on a project working with 3d graphics for a learning experience. I would like to do this project in Linux.
I want to write a simple 3d CAD type program. Something that will allow the user to manipulate objects in 3d space. What is the best environment for doing this type of development? I'm assuming C++ is the way to go, but what tools? Will I want to use Eclipse? What tools will I want?
OpenGL/SDL, and the IDE is kind-of irrelevant.
My personal IDE preference is gedit/VIM + Command windows. There are tons of IDE's, all of which will allow you to program with OpenGL/SDL and other utility libraries.
I am presuming you are programming in C, but the bindings exist for Python, Perl, PHP or whatever else, so no worries there.
Have a look online for open-source CAD packages, they may offer inspiration!
Another approach might be a C#/Mono implementations ... these apps are gaining ground ... and you might be able to make it a bit portable.
It depends on what exactly you want to learn.
At the heart of the 3d stuff is openGL, there is really no competitor for 3d apps, especially on non-windows platforms.
On top of this you might want a scenegraph (osg, openscengraph, coin) - this handles the list of objects you want to draw, their relationship to each other in space the ability to move one relative to the others, selecting objects etc. It calls opengGL to do the actual rendering.
Then on top of this you need a gui library. Qt, Fltk, wxWigets or one built into the scene library or written directly in openGL. This handles the menus, dialogs frames etc of your app. It provides an openGL canvas to draw into.
Personal choices are openscenegraph and Qt
For the 3D part, I strongly recommend the SDL Library with the OpenGL library
You can get some tutorials here
Qt has a pretty decent OpenGL-based graphics module.
Maybe you should consider using a graphics rendering engine such as OGRE. Coding a CAD program from scratch using OpenGL will take lots of time.
On Linux you have no competition to OpenGL.
It's one of the big players in the 3D field, so it's definitely worth learning.
This site has some excellent guides and code examples (on various languages).
You can use OpenGL with many languages, naturally on C and C++ but also for example with JAVA using LWJGL or other API's.
If you want to program at "a higher level" than opengl, use vtk. It is quite easy to get started and has bindings to many languages.
See www.vtk.org
you may use OpenSceneGraph for rendering.. it is an OpenGL based library..
and you may use OpenCascade.. it is good for 3D modelling...
we are implementing such an IDE at work and we use these things.. using pure OpenGL may be hard for you... anyway you may try...
for interface it is good to use Qt..
and i suggest you to use Eclipse if it is Linux..
(if it was Windows, suggestion would be Visual Studio)
For a C/C++ IDE, you have the following options:
KDevelop - KDE-based
Anjuta - GTK-based
Netbeans
Eclipse
Of course, you could also use a language like C# or Java:
Best OpenGL Wrappers for Mono and .Net
JOGL
There's really no reason why a simple CAD application would have to be written in C++.

3D scene file format & viewer

I am looking for a cross-platform solution for saving and viewing 3D scenes (visualizations of engineering simulation models and results) but there (still) doesn't seem to be much out there.
I looked into this almost 10 years ago and settled on VRML then (and started the project that eventually turned in OpenVRML). Unfortunately, VRML/X3D has not become anywhere near ubiquitous in the past decade.
Ideally a solution would offer a C++ library that could be plugged in to a 3D rendering pipeline at some level to capture the 3D scene to a file; and a freely redistributable viewer that allowed view manipulation, part hiding, annotation, dimensioning, etc. At least linux, mac, and windows should be supported.
3D PDFs would seem to meet most of the viewer requirements, but the Adobe sdk is apparently only available on Windows.
Any suggestions ?
The closest thing that I'm aware of is Collada.
Many 3D engines can read it, and most 3D design tools can read and write it.
I believe the Ogre engine has pretty good support.
If you are using OpenGL, GLIntercept will save all OpenGL calls (with the data they were called with) to a XML file. It's only half the solution, though, but it shouldn't be hard to parse it and recreate the scene yourself.
Take a look at Ogre3d.org. Its just an engine, you must program with it. But OGRE is probably the better (free/open) platform to develop 3D right now.