OpenGL is not for TEACHING, it's for LEARNING, so never TEACH OpenGL in computer graphics courses. Computer graphics should be introduced to students as an abstracted mathematical model instead. THEN you give students assignments to do on their own using OpenGL or whatever API. Implementing things in software is the way to go for better learning.
Well first of, this thread is about teching OpenGL and not about teaching computer graphics in general, so your remark is quite off topic.Originally Posted by Janika
Second: even if discussing teaching 3D graphics I think we can agree on the fact that doing some practical work, implementing 3D algorithms etc. in any 3D API will help understanding the theoretical background. Sadly, from my experiance in teaching you have to force some students to do some practical stuff on there own, otherwise they will fail the tests (and have not learned anything). This means mandatory homework even for programming assignments. To be able to correct these in a finite time for lots of students (and to be able to give best support), the class has to agree on one API to work with. As there is only one modern API available that works on all major operating systems, we chose OpenGL.
On a side note: teaching the students practical stuff that lets them produce 'nice colorful images' is a very good motivation tool, a pure theoretical computer graphics course wouldn't by far motivate as much people to learn about this topic.
To conclude: I beleave evyone discussing there wants to discuss teaching OpenGL and everyone has there own motivation to do so, so a meta discussion about the usefullness of doing so will not help here (you might want to open a new thread if you want to discuss the question whether teaching OpenGL is a good idea in general).
I have to disagree with everything here. OpenGL is for neither teaching nor learning; it's for getting stuff on your screen. The abstracted mathematical model has it's place in linear algebra and other mathematics courses; a graphics course is for - among other things - showing students one practical - and quite cool - application of the theoretical stuff. Actually writing graphics code and seeing the results creates a positive feedback loop for students, both in terms of the graphics course and in terms of seeing the immediate and practical use for the more abstract material they've learned elsewhere.
Maybe...I'm not sure how teachers structure their computer graphics courses these days...but don't get me wrong if I say a course called "OpenGL Programming" or so should have no place in academia.
Back in the day at Cornell U., computer classes were split into a 3-credit theory course and a 2-credit practicum/lab course. Taking the practicum was optional. Although theory courses sometimes did have non-trivial projects in them, practicum courses were, by design, focused on huge amounts of programming. Personally I feel this removes any pedagogical objections about how/where to teach OpenGL in academica. I think the idea of sending B.S. grads out into industry without any practical skills is completely silly, and grads who can't get jobs are bad for a department's reputation and funding. To wit, CS majors were required to take at least 3 practicum courses IIRC. I did that and I wasn't even a CS major, got my B.A. in Sociocultural Anthropology. :-) In my experience the practicum courses were way harder than the theory courses, although this may have partly been due to being a non-major. Nevertheless I had enough theory and practicum courses for a major. I was just a few math classes and GPAs shy of their reqs. So I don't think I'm totally off-base to say, those practicum courses were hard.
It has been quipped that academics think everyone should have exactly the same background as they themselves had. So, get your pith helmets out!
I agree with you here. I'll be teaching co-workers a class in OpenGL in a few weeks.You are right! I need to do something other to keep them motivated.
FS should exist all the time. It would be very simple, but still has to support coloring and texturing. Lighting and texturing would be per vertex as long as FS becomes an active topic.
This would be a course on master studies. They already have enough knowledge about CG, transformations, lighting, texturing and legacy OpenGL.
The students will be engineers who want to get things up on the screen quickly.
It will be a hands on course with simple, in-class assignments, and home works requiring programming.
I will be teaching fixed pipeline GL. Shaders would be far too complex for this type of audience.
My feeling about shaders is that they are for people who want to be professional OpenGL developers.
They are not for the rest of the world who want to learn how to do simple, 3D, graphics.
I get the feeling from reading the forums, that GLSL has actually discouraged novices from
trying to learn GL programming.
I dunno, when I got started PCs didn't have any 3d APIs. You had to code your own software renderers. How is shader programming greatly different than that? Sure it's hairy, but building 3d pipelines has always been hairy.
Then why are you teaching them OpenGL? Why would people who just want to draw lines and stuff be using a low-level rendering API? They shouldn't be using OpenGL directly, ever.The students will be engineers who want to get things up on the screen quickly.
OpenGL is for graphics programmers. Engineers should be using tools graphics programmers make for them.
For the most part, you are right. 99% of the 'graphics' done by engineers can, and is, done using Excel, Mathematica, or plotting software with some 3D capability. But there is a limited demand for custom, 3D simulation development to handle unique situations. At my company of ~3,000, there are 5 or 6 engineers who spend some time (not full time) developing 3D, OpenGL, applications. These apps don't have to be as visually sophisticated as a computer game. Fixed pipeline GL addresses our needs nicely.
True for GLSL. But I think the people who developed original OpenGL did not think this way. Seems like they tried to design a library that anyone with some technical bent could pick up if they were interested. I think they succeeded.OpenGL is for graphics programmers.
Engineers can't be pidgeon-holed so easily. Some just go to meetings, never doing any technical work. Some do technical work running in-house or commercial software. Others spend most of their time developing software. Slowly, but surely, 3D engineering visualization is becoming an expected ingredient in engineering analyses. I'm not just talking about CAD. I'm talking about 3D representations of complex scenes with many moving objects and accurate lighting.Engineers should be using tools graphics programmers make for them.
There is a need for either commercial or custom 3D engineering visualization capability. I think it would be a shame if GL went in a direction that discouraged learning and use by anyone except those who intended to be professional, full time, graphics programmers.
Then those people need to hire graphics professionals. Either directly or by buying middleware written and supported by them.I'm talking about 3D representations of complex scenes with many moving objects and accurate lighting.
Oh, and you're not getting anything remotely like "accurate lighting" from fixed-function.
