Teaching OpenGL

Quote:

---

Originally Posted by Alfonse Reinheart

Then those people need to hire graphics professionals.

---

Maybe that will happen eventually.

Quote:

---

Either directly or by buying middleware written and supported by them.

---

There is some 'middleware' floating around. It gets very limited use at my company. It might be a growth area. Problem is it's hard to anticipate all the types of visualization problems that might pop up in engineering (a very broad field). The more general the 'middleware' is, the steeper the learning curve until you get to the point where it's almost as easy to learn GL (fixed pipeline).

Quote:

---

..you're not getting anything remotely like "accurate lighting" from fixed-function.

---

Yes. I realize that. Gouraud shading from a single light source is usually good enough for our purposes (i.e. engineering, not architectural). Basic shadow casting is useful too, which we can do using fixed pipeline GL.

Quote:

---

Originally Posted by Carmine

The more general the 'middleware' is, the steeper the learning curve until you get to the point where it's almost as easy to learn GL (fixed pipeline).

---

You seem to be saying that even the old school fixed function pipeline stuff was complicated and intimidating enough that real effort had to be put into dealing with it. So... modern OpenGL just cranks the dial up a few notches. :-) Is the problem all that greatly changed from a "gotta learn something" perspective?

To me the biggest stumbling block compared to writing software rasterizers from scratch, is nowadays the huge API spanning 8 recent revisions with uncertain extension support, and no ability to just use a C function, you've gotta indirect a pointer through the right rendering context, which jolly well have better have the right flags set, and redundant windows created and destroyed in the right order. I never had to deal with that mess when just blasting values into a dumb frame buffer. Once I had done the grungy OS-specific window and framebuffer setup, everything could be expressed in straight C++/ASM code with no API calls. Systemically it's a lot easier to conceptualize, even if you have to do various low level jobs yourself. We put up with 3D APIs because we want performance, not because they're easier to use. We can hope that someday the CPUs will be fast enough that we don't need GPUs anymore, although the concerns of parallelism might turn CPUs into something more horrible anyways, and then we'll be back to square one. We need some strong AI to save us from this guff.

Quote:

---

Originally Posted by tonyo_au

The actual OpenGL language is going to change radically over the next 10 years as hardware changes; so teaching them the nitty gritty is mostly wasted.

---

When I was teaching intro OpenGL at a university I grappled with "modernizing" too.
I expect the content has evolved since then, but I hope students are not struggling
with arrays and pointers and comp vs core vs ES - but I guess that's the landscape.

One option I'd like to point out for educators is an effort to emulate non-core
functionality (call it "deprecated" if you must!) such as immediate mode and
fixed-function lighting. It's an open-source library called Regal, available at
github, developed and tested on Windows, OSX, Linux, iOS, Android, and recently,
Google Native Client (NaCL).

https://github.com/p3/regal

- Nigel

Quote:

---

Originally Posted by Alfonse Reinheart

OpenGL is for graphics programmers. Engineers should be using tools graphics programmers make for them.

---

I disagree - as a Computer Science grad that has worked with a LOT of "real" engineers over the years - I've seen OpenGL put to various ingenious uses.
I think it would be a shame if OpenGL itself became inaccessible to non-professionals.

- Nigel