So I have been wanting to venture into the world of Graphics programming lately. After hours of learning how to use the OpenGL Unofficial SDK elements, I was finally able to figure out what I needed to do.
Small problem though: My Intel Graphics Card ("HD") can not support OpenGL beyond 2.1.
The book I am reading teaches through OpenGL 3.3 and after from what I can tell. I have heard this book is really good and I want to keep using it, but it seems like my hardware has destroyed my chances, and any other books that I can find are very recent, or were made in the 90s and are very outdated. I am very frustrated, so my question is is there any way I can create modern OpenGL applications on my current setup?
I may be able to get a new Graphics Card, but I am not sure, so any advice would be wonderful.
Intel HD Graphics has always been behind supporting new OpenGL extensions.
Your best bet is to get a graphics card from one of the major vendors (Nvidia or AMD).
Well if your hardware supports only OpenGL 2.1, just use OpenGL 2.1, whats the problem with that? Of course you can use OpenGL.
Related
I'm a relative beginner with OpenGL (I'm not counting the ver. 1.1 NeHe tutorials I've done, because I'm trying to learn to do it the modern way with custom shaders), and I don't quite grasp how the different versions work, which ones require hardware changes, and which ones only require updates to the driver. Also, I've tried to find more details about how GLEW works (without diving into the code - yet), and it's still not clicking. While learning, I'm trying to find a balance between forward and backward compatibility in my code, especially since I'm working with older hardware, and it could become the basis of a game down the road. I'm trying to decide which version of GL and GLSL to code for.
My specific question is this: Why, when I use the GLEW (2.7) library (also using GLFW), does GLEW_VERSION_3_2 evaluate to true, even though the advertising for my GPU says it's only 2.0 compliant? Is it emulating higher-version functionality in software? Is it exposing hardware extensions in a way that makes it behave transparently like 3.2? Is it just a bug in GLEW?
It is an integrated Radeon HD 4250.
Then whatever advertisement you were looking at was wrong. All HD-4xxx class GPUs (whether integrated, mobile, or discrete cards) are perfectly capable of OpenGL 3.3. That ad was either extremely old, simply incorrect, or you read it wrong.
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).
I am going to buy a book on OpenGL, but I have a few questions as to what I should be learning.
I am torn between dedicating myself to learn OpenGL 1.x or OpenGL 2.0, because OpenGL ES 2.0 only exists on 3G and beyond, and if I were to develop an app and place it on the app store, I would want everyone with an iphone capable of utilizing the app.
Also, I want to experiment with desktop OpenGL.
So, my question is as follows:
simply put, what should I be learning? If I learn Desktop OpenGL, would this be easily transferable to OpenGL ES? Like if I knew OpenGL in c/c++, would I also know OpenGL ES, what major differences are there?
Also, would you recommend I learn both 1.x and 2.0, for the specific reason I stated previously, that I would want all iphone owners capable of utilizing my app, not just 3G and beyond?
Lastly, are there any books you would recommend? I really enjoy the style of this tutorial. It's very easy to follow, shows a lot of code, and explains every line of code carefully.
I faced the same question myself, and my decision was to go with OpenGL ES 2.0. Firstly because the great majority of iOS devices in use today can run it (iPhone 3GS or better). Secondly because the future of OpenGL is shaders because they offer so much more flexibility than the fixed pipeline of ES 1.
That said, I will add that using shaders is NOT easy. It takes a lot more effort to set everything up in ES 2 than it does in ES 1. Many more things can go wrong, with many more times that you'll be looking at your program creating nothing but a blank screen leaving you scratching your head and wondering why.
Once you get the basics, though, ES 2 isn't really all that bad. It's just a pretty steep learning curve.
As for the desktop vs ES question, I would recommend learning ES. It's a very nice & functional subset of OpenGL, and will allow you to write programs that run on many more platforms. Using full OpenGL might get you into trouble if you want to port your code to ES, since there are aspects of it that don't translate.
To get you started with OpenGL ES 2, I highly recommend this tutorial and this book.
OpenGL ES 1.1 uses much of the old deprecated functionality, whereas OpenGL ES 2.0 uses the modern shader-only vertex array/buffer approach, being more future ready. If you learn desktop GL, you won't have too much difficulties using OpenGL ES, as they are quite similar.
If you really want to use the old-style OpenGL ES 1.1, then I suggest you to learn desktop OpenGL 2.0 (best done with the "OpenGL Programming Guide"/"Red Book") which will teach you the old immediate API along with the modern vertex array/buffer functionality and (in conjunction with the book "OpenGL Shading Language"/"Orange Book") also the use of programmable shaders. So this way you will be ready to use old-style (1/(2)) and modern ((2)/3/4) desktop GL along with OpenGL ES 1.1 and 2.0.
But if you want to start directly with the new and modern way of programming OpenGL (which might be advisable, although the old-style is a valuable experience), then I would rather suggest to use the newest edition of the "OpenGL SuperBible", which will teach you modern-style ((2)/3/4) desktop OpenGL without the old deprecated functionality. But then much OpenGL ES 1.1 code won't be of much use to you (although you will surely understand its principles). Although I really appreciate my knowledge of the fixed-function old-style OpenGL, I would rather suggest beginners to start with modern OpenGL right-away, even if it might be a bit harder to learn for a beginner, as this is the way to do hardware-accelerated real-time graphics today (and tomorrow).
But what really matters is, that in contrast to learning the API by mind you should understand the underlying principles and the principles of 3d graphics in general. Then you won't have much difficulty switching to other APIs, like Direct3D, anyway.
I have to start a 3D-Project for mobile platforms. First of all I would like to outline the main aim - skeletal animation. As for the solution I was thinking of OpenGL ES and C++. So the questions are:
Is OpenGL ES robust enough to handle skeletal animation (including those skinning shaders)
Is OpenGL ES supported widely across mobile platforms, and what are the most famous ones? (for instance, is iPad supported?)
Is this possible anyway, I mean will I have enough computation power?
Is it worth using XNA math library, because of its SIMD optimization (though I'm really unsure that SIMD is supported on mobile platforms, but who knows...).
Is it good to use C++ for this? If yes, then which compiler should I choose for development and testing? Moreover, I have no clue what compilers are used for mobile platforms?
As you might have got it - I've never programmed for mobile platforms yet. Therefore, some general recommendations are welcome.
Yes, OpenGL ES 2.0 can handle vertex skinning for skeletal animations quite well. OpenGL ES 1.1 used a fixed function pipeline, without shaders, so it's harder in the older API to do this, but 2.0 adds support for shaders. OpenGL ES 2.0 is present on all shipping iOS devices (the iPhone 3G S and newer supports it, including both iPads), as well as almost all Android devices (I could only find a couple of very low end handsets that didn't). Windows Phone 7 doesn't appear to support OpenGL ES, but I believe BlackBerry does.
If you're interested in this, I highly recommend reading Philip Rideout's book "iPhone 3D Programming". While it has "iPhone" in the title, he uses generic C++ for almost all of the code in the book, so it should translate to other platforms well and should be easy for you to understand. He even has a section in the "Optimizing" chapter with code for performing vertex skinning on OpenGL ES 2.0 and even 1.1. You can grab the sample code for the book here, including a demonstration of this skinning.
C++ is supported on iOS through Objective-C++, where you could set up the platform-specific UI elements in Objective-C and then do all your backend and rendering logic in C++. Again, Philip does this in his book, and you can see in his source code example applications how he structures this. The people at Imagination Technologies have also set up some platform-agnostic scaffolding in their PowerVR SDK, which some people have used for quickly getting their 3-D rendering up and running on mobile devices. Also in that SDK are some great documents about moving from OpenGL to OpenGL ES, as well as performing various effects on these GPUs.
I have heard of some people getting slightly better performance for small vertex sets by performing transformations on-CPU (on iOS this can be done using the Accelerate framework), but I'd imagine that vertex shaders would be much faster for larger geometry. The PowerVR GPUs that I've worked with in mobile devices are much more powerful than you'd think, particularly the new one that ships in the iPad 2.
You'll need to use the Xcode IDE, with either its GCC or LLVM compiler to target iOS devices, but I believe Android has a few more options in that regard.
In short:
Yes, of course. Why not?
Yes, I suppose. What else? DirectX definitely not.
Yes, I suppose. But depends on what else you want to do.
No, at least not just because of SIMD, as I suppose it is not much supported on mobile platforms, at least the SIMD instructions XNA is optimized for.
Yes, why not? I think the i...s mostly use Objective-C, but there should be compilers for C++, too. Just ask google, as I also don't have any mobile experience.
Can I expect users to be able to run software that uses OpenGL 3.x?
Can Linux users who have open-source graphics drviers run OpenGL 3.x? I know that Mesa3D 7.8 only supports OpenGL 2.1.
I also know that OS X Snow Leopard supports some but not all OpenGL 3.0 features. I don't know the situation on Leopard.
I don't know the situation on XP, Vista, and Windows 7.
I'd like to start learning OpenGL, and my interest lies more in scientific and engineering applications than games. I know I'll be reading code that uses OpenGL 1.x, but I'd like to write code using the newest specification I can expect user's systems to support. I'm wondering whether I should start learning 2.1 or 3.3. I was thinking of getting either the 4th edition of the OpenGL Superbible to learn 2.1 or the 5th edition which is coming out July 30 to learn 3.3. (I have a bachelor's in physics, so my math background is pretty good.)
Edit: I found this related question with answers that are relevant to my question.
As Martin Beckett already pointed out, the situation is really rather bad as far as support for OpenGL 3.x is concerned. Many "modern" graphic chipsets widely used in notebooks (yes, Intel, I'm looking at you) do not even fully support OpenGL 2.x; some even lack features as old as multisampling.
The only way to make your software run on as many systems as possible is to use things like GLEW to decide which features to use at runtime (i.e. no need for conditional compiling).
As far as learning OpenGL is concerned, 2.1 is definitely a good choice, because it enables you to understand both older code using the fixed-function pipeline and more modern code relying on shaders. Afterwards, getting to grips with the most important 3.x features (e.g. frame buffer objects, vertex array objects) will be rather easy.
I can happily inform you that the open source drivers now officially fully support OpenGL 3.0, and Intel will be supporting OpenGL 3.1 as of the next release of Mesa, now renamed to Mesa 9.0. They added official support for OpenGL3.0 as of Mesa 8.0.
The Intel OpenGL support for Windows is currently at 4.0, so that shouldn't be a problem for you.
Regarding AMD and NVidia support, there is full OpenGL4.3 support for both closed source drivers, on both Windows and GNU/Linux. Regarding Open Source drivers, Radeon will officially be bumped to OpenGL3.0 support as of Mesa 9.0, combined with the 3.6.0 kernel release.
It is probably worth mentioning that the drivers supports subsets of OpenGL3.2/3.3/4.0/4.1/4.2/4.3, but the "supported version" can't be bumped until ALL features are implemented. Please see the official document for more detailed information.
These are exciting times for OpenGL!
The Windows XP drivers for Intel's GMA 950 only support OpenGL 1.4, sans GL_EXT_framebuffer_object. Oddly enough on the same exact hardware (a Mac mini) both Linux and OSX manage to support GL_EXT_framebuffer_object.
I don't know the situation on XP,
Vista, and Windows 7.
Bad - most cards claim to support openGl 2.0 or 2.1 but unless they are Nvidia don't expect any features beyond 1.1 to work
IIRC windows vista/7 supports opengl 1.1 in software or 1.4 with a directX wrapper. The graphics driver is free to support whatever it wants but except for Nvidia the quality is poor.
As long as you do only Scientific and Engineering applications, I would suggest you to use Modern OpenGL. Normally an Engineer can afford to buy a Modern Computer with a nice Graphics Card, if he needs it. For Science the application does often only need to run on one Computer, so compatibility with old computers shouldn't be your biggest concern, but being forward compatible with new hardware is never a wrong decision.
Writing a game is very different. Here is it very important to maximize the audience so that you can sell the maximum amount of copies. Requireing too much resources would reduce the target audience very much.