Book recommendations?

First of all, thanks to everyone who has been so helpful and responsive in the past week or so in getting me up and running.

I think I have enough of JOGL/OPENGL in place that I am ready for more comprehensive study. However, like the online tutorials, actual books on learning OpenGL are all over the place - publications spanning more than ten years, and more recent, supposedly up-to-date, offerings criticized for a poor blending of old and new programming models. How is a newb to filter all of this? Since I am starting from zero, I'd like to not be confused by deprecated approaches. There is a new RedBook coming out in July that might address the criticisms of the current version (confounding programming models), but I have a project on which I need to start much sooner.

==> Any suggestions as to the best available book to begin to learn current opengl programming?

Here is what I looked at so far:

OpenGL Programming Guide: The Official Guide to Learning OpenGL, Versions 4.1 (8th Edition) (okay, July, but I want to get started now).

Interactive computer graphics: a top-down approach with shader-based OpenGL. 2011. by Edward Angel, Dave Shreiner (earlier editions well received, but limited feedback on the latest. Is this shader-based stuff what I need to learn?)

OpenGL SuperBible: Comprehensive Tutorial and Reference (5th Edition). 2010.
Richard S. Wright (Author), Nicholas Haemel (Author), Graham Sellers (Author), Benjamin Lipchak (Author) (a popular past choice, but criticism of it being focused on the authors' on toolkit rather than openGL, itself. Gets some recommendations here in the past year).

With respect to learning, I am worried about this statement in one of the threads: "Please note: by using the GL core profile you won't be backwards compatible with the so called fixed function pipeline and it won't be able to run on drivers implementing the old spec (GL 2.x) like those shipped with latest Mac OS systems." I develop on a mac and distribute my software free to researchers around the world with highly varying resources. So, I would like whatever I learn/do to be current, but not unduly restrictive when incorporated into my apps.

Hi

I learned more things about OpenGL thanks to Internet than in books and I'm accustomed to convert OpenGL C code to JOGL which is not that hard.

I understand your position, especially the last aspect. Actually, if you want your application to be largely supported, you will have to be comfortable both with the fixed function pipeline and the programmable pipeline. In my case, I'm more comfortable with fixed function pipeline, I rarely use shaders. The main problems will be the real drop of the fixed function pipeline, i.e the abandon of support for the backward compatible profile in future drivers. We are at an important time in the history of computer graphics. There are currently no scenegraph supporting both the backward compatible profile and the forward compatible profile. Best regards.

LordSmoke wrote

Interactive computer graphics: a top-down approach with shader-based OpenGL. 2011. by Edward Angel, Dave Shreiner

I haven't used this one yet, but I know Dave S. a little from work, so if you buy it and have feedback I can send it to him

LordSmoke wrote

OpenGL SuperBible: Comprehensive Tutorial and Reference (5th Edition). 2010.
Richard S. Wright (Author), Nicholas Haemel (Author), Graham Sellers (Author), Benjamin Lipchak (Author) (a popular past choice, but criticism of it being focused on the authors' on toolkit rather than openGL, itself. Gets some recommendations here in the past year).

This book contains a lot of useful info, but I noticed the same thing -- the author builds up a set of wrapper objects that make it hard to see the OpenGL clearly. I think this is part of why it's hard to teach shader-based OpenGL effectively; in the process of building up a program, it's very hard not to factor stuff out into new wrapper objects, and once you do, it's hard to teach with those.

I've recently written a few basic demos using shader-based OpenGL and JOGL, where I deliberately tried to program it "raw" without using the JOGL ShaderUtils or any other toolkit, for pedagogical reasons. It probably takes 250 lines of code to put a single triangle on screen . I'm going to try a different approach of factoring repeated code out into functions instead of objects, to see if that makes the OpenGL parts clearer.

Thanks once again for the helpful feedback.

Looking into it today, I think I really don't care at all about shaders. My needs are rather simple. I want to plot multivariate data with different symbols, axes, titles, legend, with user rotate, translate, and zoom. I also want to plot texture-mapped surfaces of, say, brains, lungs, faces, and animate those a bit - respiring lungs, growing brains. I am picky about such things, but more lifelike, fog-shrouded, chrome teapots are not on my todo list. But, hey, I might go wild and let the user pick a point and see ancillary information about it. =8o

I am confident I can understand:

    public void render( GL2 gl2, int width, int height ) {
        gl2.glClear( GL.GL_COLOR_BUFFER_BIT );
        // draw a triangle filling the window
        gl2.glLoadIdentity();
        gl2.glBegin( GL.GL_TRIANGLES );
        gl2.glColor3f( 1, 0, 0 );
        gl2.glVertex2f( width/2+c1*width/2, height/2+s1*height/2 );
        gl2.glColor3f( 0, 1, 0 );
        gl2.glVertex2f(  width, 0 );
        gl2.glColor3f( 0, 0, 1 );
        gl2.glVertex2f( width / 2, height );
        gl2.glEnd();
    }

What I don't know is if the above has anything to do with the new programmable pipeline and I should learn a different way to do things. Of course, I abstract my stuff so the data plotting layer calls isolated, underlying procedures (plotSymbol(symbolType, location)) that handle the details. I should only have to rewrite those, if necessary, but I would rather get off on the right foot.

Then again, java3d seemed to serve my purposes just fine. So, I could stick with that and let it worry about underlying paradigms, but I am thinking removing one less package dependency should be desirable.

Yes, once I have my footing and start to write my own routines, I seldom refer to a book - google is my friend. But I'm a bit old school and think a hefty processed paper product is better to curl up with to assimilate the big picture. :)

Again, thanks.

Lol we will worry about the paradigms for you if you use Java3D. However, you should have a look at Jzy3D if you want to draw plots.