Talk:OpenGL Programming
From Wikibooks, the open-content textbooks collection
[edit] How about more modern OpenGL?
Whilst this is a reasonable start, it's teaching a curiously 'old school' style of OpenGL.
Nobody much uses glRect anymore - teaching it first is a curious choice. If starting a new book on this subject, I'd recommend starting with vertex arrays and shaders rather than with glVertex/glColor/glNormal and all of the fiddly OpenGL lighting, materials and junk. Modern programs are moving away from that old style and a new manual should start off with 'best practices' rather than retro-programming. SteveBaker 04:05, 7 March 2006 (UTC)
I'm not so sure that it's a good idea to start with a subject so complicated as vertex arrays and shaders. I think it's better to work up to these subjects. glVertex is the basis of vertex arrays anyway, and shaders are an enormous enough topic to deserve it's own book. (Hint hint!) This book was meant to follow in some regard the Red Book [edit: it's the first citation], cited in the Further Reading Section. This is how most books approach OpenGL, and I think it's wise to continue this way. 67.100.43.114 21:03, 7 March 2006 (UTC)
You see, that's how I used to feel - being an 'old school' OpenGL person. But vertex arrays really AREN'T complicated - and if you ONLY teach shaders, they are a lot simpler than all of those old-fashioned OpenGL calls. You set up a simple linear array of data, you set up a pair of shaders and you say 'Draw it' with a single call. It takes less words to describe this than to tell all about the 23 different versions of glVertex, glColor, gl..whatever. The original RedBook descriptions were simple because there was only one colour, only one texcoord and no weird auxiliary data possibilities. Once you accept multitexture and shaders, vertex arrays are really a lot simpler to explain. Furthermore, there are HUNDREDS of OpenGL calls to describe lighting, materials, light source, etc - you can describe the interface to the shader language much more simply. Well, perhaps the way forward is to allow this book to continue to become a red-book equivelent - and inparallel, write a new book about 'new-school' OpenGL as likely to come about with the embedded flavors of OpenGL (and OpenGL 2.0 'Pure') that leave all of that historical stuff behind. I'll consider how to start writing that. SteveBaker 17:07, 8 March 2006 (UTC)
Then is this discussion closed? C is not the only language that is used to program OpenGL, and thinking that All programs are going to be written in GLSL is taking a step back to low level coding.
- I'm an attendee at FullSail, I have already been student to both methods of teaching. The first exposed to me was using complex vertex objects and buffers with direct X. I managed to understand them but I warn you greatly, do not teach this method first. When our OpenGL class came around we learned glNormal/glVertex/etc.. first and then worked our way to vertex buffer objects. This method came across leaps and bounds better. The concept of plotting points makes sense in more peoples minds than massive vertex and index arrays. While vertex arrays are a simple concept in truth, it is hard for the new graphics programmer to understand the concept. It takes some time to set in what is happening behind the scenes. Also, any graphics programmer needs to know how to use the standard glVertex calls. It would be rather embarrassing if I met someone who couldnt plot a point on the screen inside a glBegin() and glEnd() but knew how to program hardcore shaders. These calls allow for quick prototyping as well. A good analogy would be: Sure, chainsaws are an easy concept to understand, but you might want to start them off on a hand-saw or maybe just an axe first or they might end up making a mess of things. If my pupils are a demonstration as well, it is necessary to teach the glVertex related calls first to gain a proper understanding. I assume you used to think 'that way' back in the day because you were an inexperienced programmer, not out of nostalgia for 'old-school' OpenGL programming. Continueing, your comment shaders being easier than the opengl lighting system, you seem to be inexperienced yourself. For one, openGL barely has 'hundreds' of function calls itself. While powerful seems misguided. The function calls require the programmer to know what he wants his light to do, not how to do the math behind his light, unlike shaders. Also, the GLSL language is much more simplified when one uses it in conjunction with the hardware lights. The hardware can manage a lot of math that won't bloat your shader systems, making them easier to read and, most importantly, faster. The openGL language is as popular as it is today for a reason. Most users would agree that its functionality and interface is simple and powerful. Frankly, the 'new-school' openGL adds efficiency, but not necessarily simplicity. Finally, It would be a shame to strip the new graphics programmer from any corner of the OpenGL API, mostly to something so integral. - BTW, How is GLSL low level coding? By far, I would consider GLSL a higher level of OpenGL functionality (even though your kind of dealing with low-level, per-pixel, functionality).
"Once you accept multitexture and shaders, vertex arrays are really a lot simpler to explain." ==> By the time you understand multitexturing and shaders, vertex arrays are already a trivial concept. It's the learning part that the front of the book should address, and more sophisticated concepts (multitex and shaders) should be addressed in the back. Though I have to agree, glRect() is an odd choice - would recommend doing the convention glBegin(GL_QUADS)/glVertex*()/glEnd(). That could also be used to segue into vertex arrays. (Actually, I didn't even know there was such a function as glRect().) Is anyone still working on this? Lyngvi 01:49, 29 March 2007 (UTC)
[edit] merge is not a good idea
The tutorial that has been proposed to be merged with this book is OS specific. Worse yet, it is specific to an IDE which is only available for one family of OS'. OpenGL on the other hand has been implemented on a wide range of operating systems and is a virtually universal drawing API. Maybe an IDE and OS neutral tutorial would be better.
If whoever proposed the merge does not explain the reason for the proposal, I suggest it be removed.
