5 ms·

> So I'm a rebel. I still teach immediate mode. I'm well aware that this is The Wrong Way (tm), but my goodness, you can't throw profiles and buffer objects at

> So I'm a rebel. I still teach immediate mode. I'm well aware that this is The Wrong Way (tm), but my goodness, you can't throw profiles and buffer objects at people before they've even successfully animated a polygon. OpenGL is a fairly low-level API. If your students just want to get something animating on screen without having to dive too deep then surely there are many libraries/engines built on top of OpenGL that will allow that. On the other hand, if your students are learning OpenGL to write such libraries/engines on their own then what is the point of leading them into a dead end?

ggchappell 12y ago
> If your students just want to get something animating on screen without having to dive too deep then surely there are many libraries/engines built on top of OpenGL that will allow that. The reason my students are learning graphics programming vary with the student. Some just like making pretty pictures. Some are thinking of themselves as future game-engine writers. And of course, this being a university degree program, many of them just want to pick up some elective credit so that they can graduate. So I take a more short-term view. I teach low-ish level graphics programming so that my students will know low-ish level graphics programming. What they do with it after that is up to them. > ... what is the point of leading them into a dead end? That's a good question -- one I've had to give substantial thought to. There are really three aspects to VBOs/EBOs. (1) Capabilities of the graphics system and the data it needs. We are dealing with a system that can render (for example) triangles arranged in strips, specified via 3-D vertex positions and other attributes. (2) Data format. Arrays of attribute values. (3) Storage management. Buffer objects. If I do VBOs from day one, then I am introducing these three aspects all at once. It's tough to catch that they really are separate ideas; the concepts get all jumbled up, and understanding suffers. OTOH, if I start with immediate mode, then I can focus on the capabilities of the graphics system. What can it do, what information does it need from us, and how do we figure out that information. This is important stuff; it's good to learn issue (1) well without having to worry about the others. Students also get some quick success. They can write code to do interactive 3-D animation without having to worry about issues (2) and (3). So then I move to vertex/element arrays, focusing on issue (2). Lastly, buffer objects, and issue (3) is done. Yes, some people would call it a waste of time to talk about immediate mode. But even ignoring the above arguments, I can cover immediate mode in an hour, complete with a functioning demo written nearly from scratch. If that's wasted time, then it isn't very much wasted time.
- dualogy 12y ago
  VBOs are really pretty easy to explain though, no? "Look your GPU probably has 1 or 2 GB of its own VRAM, so there's no way we would upload many polygon meshes every frame via 10000s of individual glVertex calls, so just assume something as silly and useless as glVertex doesn't exist to begin with."
- Impossible 12y ago
  >Some just like making pretty pictures. Some are thinking of themselves as future game-engine writers. Both of these students will learn more using a framework or game engine than immediate mode OpenGL. > I teach low-ish level graphics programming so that my students will know low-ish level graphics programming. What you're teaching isn't the real graphics pipeline anymore or even an abstraction of it. It's limited high level graphics programming that both doesn't teach how modern high level graphics work is done and doesn't teach fundamentals either. You're really just teaching how to write code for 90s fixed function APIs. I agree that it is a valid stepping stone (many of us started there), but I think there are much better options now than there were 15 years ago. Anyway, OpenGL is not an educational library and making the lives of educators easier should not be a concern of Khronos (or anyone). As an educator you can always build your own framework that has the appropriate level of "low-ish" levelness but holds the students hands enough to not confuse them, if you don't feel that current options are sufficient.
  - twelvechairs 12y ago
    > I think there are much better options now than there were 15 years ago. What are these? (Honest question. I am aelf-taught, first in immediate mode so tend to agree with parent comment that this is a sensible approach. If there's a better way of understanding the pipeline than starting this way - I don't know it)
- loup-vaillant 12y ago
  May I suggest a different approach? (No? I will anyway :-) First, scrap immediate mode. Do as if it doesn't exist. Second, since modern OpenGL is impossible to teach, write a higher-level layer over modern OpenGL. Tailor that layer to teach what you want to teach. My guess is, you can do even better than the immediate mode —for teaching purposes, I mean. Third, teach your student how you have implemented the magic, bit by bit. Or teach them some new low-level stuff, and then ask them to implement one of your high level functions. And so on, until they get the whole thing. (Be careful with that approach, though: you probably don't want your students to just plug holes in a program.) That way, you keep the tight reward loop, and you don't teach obsolete tech. As approachable as it is, you don't want to even suggest immediate mode can be used for serious development.
kbenson 12y ago
On the other hand, if your students are learning OpenGL to write such libraries/engines on their own then what is the point of leading them into a dead end? Because it lets them get feedback along the way while exposing them to some of the concepts they will be using later? Taken to the extreme, that statement is the same as saying 'If your students aren't ever going to print "Hello World!", why ever use that string? They should be finding something more relevant to their eventual goal.' That is, as stated, extreme, but you can extrapolate my point from that.
- vinkelhake 12y ago
  > Taken to the extreme, that statement is the same as saying 'If your students aren't ever going to print "Hello World!", why ever use that string? They should be finding something more relevant to their eventual goal.' That is, as stated, extreme, but you can extrapolate my point from that. I don't think I can extrapolate your point. It all boils down to what the student wants: quick results or to actually learn OpenGL? All I'm saying is that if you want to learn OpenGL, there's little point in spending time on de facto deprecated functionality.
- jjoonathan 12y ago
  Students will use the "print" function and printf-style debugging frequently in production coding environments. Students will never use the OpenGL immediate API in a production coding environment. One of these is a much better didactic stepping-stone than the other.
  - kbenson 12y ago
    But will using the immediate API hepl them grasp some of the concepts of OpenGL? Is there truly nothing that's learned that applies to other tasks in OpenGL? I find that unlikely. In C, the canonical hello world example can help teach about the program starting point, return codes, argument passing, and IO. This extremely simple program can help the student learn these core concepts, even if in practive their program may ignore all of that for main except what the instruction starting point is. Was the exercise pointless, or did it help cement core concepts which may help later?

ggchappell 12y ago

> If your students just want to get something animating on screen without having to dive too deep then surely there are many libraries/engines built on top of OpenGL that will allow that. The reason my students are learning graphics programming vary with the student. Some just like making pretty pictures. Some are thinking of themselves as future game-engine writers. And of course, this being a university degree program, many of them just want to pick up some elective credit so that they can graduate. So I take a more short-term view. I teach low-ish level graphics programming so that my students will know low-ish level graphics programming. What they do with it after that is up to them. > ... what is the point of leading them into a dead end? That's a good question -- one I've had to give substantial thought to. There are really three aspects to VBOs/EBOs. (1) Capabilities of the graphics system and the data it needs. We are dealing with a system that can render (for example) triangles arranged in strips, specified via 3-D vertex positions and other attributes. (2) Data format. Arrays of attribute values. (3) Storage management. Buffer objects. If I do VBOs from day one, then I am introducing these three aspects all at once. It's tough to catch that they really are separate ideas; the concepts get all jumbled up, and understanding suffers. OTOH, if I start with immediate mode, then I can focus on the capabilities of the graphics system. What can it do, what information does it need from us, and how do we figure out that information. This is important stuff; it's good to learn issue (1) well without having to worry about the others. Students also get some quick success. They can write code to do interactive 3-D animation without having to worry about issues (2) and (3). So then I move to vertex/element arrays, focusing on issue (2). Lastly, buffer objects, and issue (3) is done. Yes, some people would call it a waste of time to talk about immediate mode. But even ignoring the above arguments, I can cover immediate mode in an hour, complete with a functioning demo written nearly from scratch. If that's wasted time, then it isn't very much wasted time.

dualogy 12y ago
VBOs are really pretty easy to explain though, no? "Look your GPU probably has 1 or 2 GB of its own VRAM, so there's no way we would upload many polygon meshes every frame via 10000s of individual glVertex calls, so just assume something as silly and useless as glVertex doesn't exist to begin with."
Impossible 12y ago
>Some just like making pretty pictures. Some are thinking of themselves as future game-engine writers. Both of these students will learn more using a framework or game engine than immediate mode OpenGL. > I teach low-ish level graphics programming so that my students will know low-ish level graphics programming. What you're teaching isn't the real graphics pipeline anymore or even an abstraction of it. It's limited high level graphics programming that both doesn't teach how modern high level graphics work is done and doesn't teach fundamentals either. You're really just teaching how to write code for 90s fixed function APIs. I agree that it is a valid stepping stone (many of us started there), but I think there are much better options now than there were 15 years ago. Anyway, OpenGL is not an educational library and making the lives of educators easier should not be a concern of Khronos (or anyone). As an educator you can always build your own framework that has the appropriate level of "low-ish" levelness but holds the students hands enough to not confuse them, if you don't feel that current options are sufficient.
- twelvechairs 12y ago
  > I think there are much better options now than there were 15 years ago. What are these? (Honest question. I am aelf-taught, first in immediate mode so tend to agree with parent comment that this is a sensible approach. If there's a better way of understanding the pipeline than starting this way - I don't know it)
loup-vaillant 12y ago
May I suggest a different approach? (No? I will anyway :-) First, scrap immediate mode. Do as if it doesn't exist. Second, since modern OpenGL is impossible to teach, write a higher-level layer over modern OpenGL. Tailor that layer to teach what you want to teach. My guess is, you can do even better than the immediate mode —for teaching purposes, I mean. Third, teach your student how you have implemented the magic, bit by bit. Or teach them some new low-level stuff, and then ask them to implement one of your high level functions. And so on, until they get the whole thing. (Be careful with that approach, though: you probably don't want your students to just plug holes in a program.) That way, you keep the tight reward loop, and you don't teach obsolete tech. As approachable as it is, you don't want to even suggest immediate mode can be used for serious development.

kbenson 12y ago

On the other hand, if your students are learning OpenGL to write such libraries/engines on their own then what is the point of leading them into a dead end? Because it lets them get feedback along the way while exposing them to some of the concepts they will be using later? Taken to the extreme, that statement is the same as saying 'If your students aren't ever going to print "Hello World!", why ever use that string? They should be finding something more relevant to their eventual goal.' That is, as stated, extreme, but you can extrapolate my point from that.

vinkelhake 12y ago
> Taken to the extreme, that statement is the same as saying 'If your students aren't ever going to print "Hello World!", why ever use that string? They should be finding something more relevant to their eventual goal.' That is, as stated, extreme, but you can extrapolate my point from that. I don't think I can extrapolate your point. It all boils down to what the student wants: quick results or to actually learn OpenGL? All I'm saying is that if you want to learn OpenGL, there's little point in spending time on de facto deprecated functionality.
jjoonathan 12y ago
Students will use the "print" function and printf-style debugging frequently in production coding environments. Students will never use the OpenGL immediate API in a production coding environment. One of these is a much better didactic stepping-stone than the other.
- kbenson 12y ago
  But will using the immediate API hepl them grasp some of the concepts of OpenGL? Is there truly nothing that's learned that applies to other tasks in OpenGL? I find that unlikely. In C, the canonical hello world example can help teach about the program starting point, return codes, argument passing, and IO. This extremely simple program can help the student learn these core concepts, even if in practive their program may ignore all of that for main except what the instruction starting point is. Was the exercise pointless, or did it help cement core concepts which may help later?