Learn OpenGL? Now??

Started by
31 comments, last by Escarab 15 years, 6 months ago
Well, some time ago I was learning OpenGl, I was learning from "Opengl superbible", that book was teaching me OpenGL 2.1, and I was madding some cubes when I stopped. Why did I stop?? OpenGl 3.0 spec was about to be released (It has been about to be released for 2 years, but it was released 3 months after I've stopped)!!! OpenGL 3.0 would change everything, rendering my learnings practically useless, so I decided to wait. I waited, opengl 3.0 has been released, but nothing changed that much... Now Khronos says: "Wait some more, opengl "3.1" will change everything, a completely new and clean API, we were just preparing the terrain for it." And now, what do I do?? This are some options I've been considering: 1) Grab my opengl 2.1 book and restart from were I stopped. Nothing will change that much. 2) Find something about opengl 3.0 and study it, using the GL 3 clean context. But there is a problem, there is no such something(I can't find nothing about opengl 3.0), and there is no implementation of the spec yet. 3)Wait some more *_*. This are dark times to learn opengl, try again latter. 4)Forget about Opengl, It's dead. thanx
Advertisement
Yes GL3 is basically just GL2.2, so option (1) is a decent choice.

NVidia and ATI both have beta implementations of GL3 (you can download these beta drivers from their sites), so option (2) is open as well.

I don't think (3) really makes much sense - GL3 has already specified which parts of the API are going to be deprecated, so you already know which bits you should not bother learning about. And (4) is rubbish.
GL 3 doesn't mean anything. It just adds a few features. The depracation model can be ignored. nVidia has already announced that they will continue to support everything and I'm sure ATI beleives in that as well. Feedback mode, select mode, glBitmap and color index mode and other bizarre stuff will all be supported until GL dies in 50 years.
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
You forgot this one:

5) Now is a good time to pick up DirectX if you haven't yet.

OpenGL isn't going to run away while you do that. At worst, you'll suddenly know two graphics APIs instead of one.

Personally, I'd say that unless you are suddenly gonna program to next-gen hardware at the expense of a large chunk of your userbase, OpenGL 2.1 is still a good target to program to for now. Not that I have much of a choice, if I want to stick with Java (which I do).
Basing your OpenGL coding on the GL3.0 spec, and not using deprecated features will make anything you write more efficient, closer to the metal, and tighter and faster. You'll also understand what's going on under the hood a lot more...

Using deprecated features for prototyping is also a good way to go, so learning the deprecated stuff is worthwhile. I will certainly continue to use it for a lot of initial development, simply re-coding it to comply with GL3.0 and beyond once I have ironed out the kinks.

So get to it.. Learn the lot. :)
Feel free to 'rate me down', especially when I prove you wrong, because it will make you feel better for a second....
6) forget about building your own 3D engine and use a 3rd party 3D engine.

this is not an option as bad as it may look... the big problem about this option is choosing the right engine that fits your needs, and I agree its not an easy task, given the availiable options.

But if you expend about the same time reviewing several 3D engines, than you would expend building your own, you can find one that fits your needs, and then you will be able to do everything you need, without having to worry about the future of OpenGl or DirectX
Well...

I think your worry towards the version of graphic programming interface can be real. However, is there any programming interface can live forever?? I don't think so (even C++ have some major changes over all this years). As long as the interface is relatively stable, it should be just fine.

And, in case of OpenGL, the programing interface is relatively stable which worth some investment.

Take a look at Direct3D, the interface kept changing every two to three months. And, as the other products from Microsoft, most of those changes are not backward compatible. (What a dirty marketing strategy!) The works you spent in Direct3D will be obsoleted in less than half a year and become alien manuscript in a year. If you think OpenGL is bad, Direct3D will be far worse than a nightmare.
Quote:Original post by ma_hty
Take a look at Direct3D, the interface kept changing every two to three months. And, as the other products from Microsoft, most of those changes are not backward compatible. (What a dirty marketing strategy!) The works you spent in Direct3D will be obsoleted in less than half a year and become alien manuscript in a year. If you think OpenGL is bad, Direct3D will be far worse than a nightmare.


That's not necessarily true. D3D8, D3D8.1, D3D9a, D3D9b, D3D9c have been very similar and have been around 6 or more years. D3D10 and 11 will be very similar. It is an indication that the API has matured.

Perhaps you were not around during those days.
1. GL didn't have shaders in the beginning. You had NV register combiners on nVidia and on ATI, you had fragment combiners or whatever they called it, and on everything else you had nothing.
Then suddenly, the ARB texture combiners came along but these were very limited.
2. Then there was the NV way of allocating AGP or video memory and storing vertices and at the same time the ATI extension. Finally, the ARB created VBO.
3. render to texture. You need 2 extensions to get this working. It was painful and required its own context. What a bad idea! It took a few years to get FBO.

Since there are all these multiple ways of doing things 6 years ago, even today, newbs get bad advice. I've seen a few times people recommend p-buffers even though FBO has been out for a few years.
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
Thank you all for the feedback. Some of you deserve some kind of feedback to.

lightbringer(Lucifer???): I considered DirectX to, but I want to learn D3D10, and my pc doesn't supports it(no vista).

vicviper: I don't plan to build my own engine in the near future. I've started to learn Ogre3D, but it feels like plastic knowledge if I don't get how OpenGL or directX works. So I decided to go the hard way (and the best), learn the hard thing first, and then go to a simplifier, like Ogre3D.

And some last questions:
Where do can I get something didactic about GL 3? NeHe seems old stuff. Not a raw spec where I must swim trough 300 pages to find something I can't even understand yet, but a tutorial or a book.

And where can I find something good abouti geometrc shaders in opengl?

And also, it seems like the fixed function pipeline will be dead soon, so I don't wanna lose my time with it. But I cant't find nothing like "Begining opengl programming through shaders", all tutorials I find start with fixed function stuff, and use this as a base ground to teach you shaders. There is such "Begining opengl programming through shaders" or something?
Quote:Original post by V-man
That's not necessarily true. D3D8, D3D8.1, D3D9a, D3D9b, D3D9c have been very similar and have been around 6 or more years. D3D10 and 11 will be very similar. It is an indication that the API has matured.
...


The phenomena that the products from Microsoft usually not backward compatible have nothing to do with technical stuff. Instead, it is a dirty marketing strategy. ( Who will buy new stuff if the old one works perfectly? ) As long as the people in Microsoft keep doing that, this situation is not going to change.

This topic is closed to new replies.

Advertisement