Hacker News Reader

I am glad they don't give thoughts to beginners.

Low Level Graphics APIs are about perf and giving as much access as possible to the hardware in as much as possible a cross platform way.

It's called layering. Let OpenGL focus on the lowest level. Use other libraries for higher levels.

People learning should choose what the right level for them is. Whether it's starting with Unity3D or Unreal and not worrying about the low level details, or going slightly lower level with some other library.

Adding more high-level beginner friendly features to OpenGL is the worst possible thing you could do. It clutters the API and needlessly brings all kinds of baggage with it.

For those who do want to learn though I'd suggest starting with WebGL. It's way way easier. You don't have to deal with all the system specific setup. You don't have deal with figuring out how to get some image loading library to compile and link. If you want to get started instantly use [three.js](http://threejs.org) or if you want to understand how it works try [WebGL Fundamentals](http://greggman.github.io/webgl-fundamentals/)

BTW: Those fundamentals, could easily be adapted to C/C++ and current GL.

I'm glad, when I started to learn OpenGL I used web tutorials and most of them were written in immediate mode.

It was nice to be able to quickly get some stuff going and then realize "Oh wow, my program is slow." Then I learned how to use VBOs and shaders and eventually got a pretty good handle on how to work it all.

There's a big difference between Unity which is "Here's a model, display it at this position and this scale" and writing your own .OBJ loader and arranging vertices and outputting the data to the screen, even if you're doing it inefficiently.

Sure when you use immediate mode it's terrible performance wise and very restrictive, but once upon a time, immediate mode was the only thing. Many people who are skilled started with it, and made use of new features as they became available. Sure jumping in and doing it the right way is better, but it's also really hard.

For a parallel example for C, we have printf to write to a console. In most applications you're not actually using printf to print to an 80x25 console, you're rendering your text to a window or some other output stream. But we leave print in the stdio library, because it's handy for testing things quickly, for learning, for getting quick and dirty output when performance is less important.

Immediate mode is easy. Begin, add vertices, end. You can do a lot with it. You don't want to write a graphics engine in it, but that's no reason to discard it. You don't want to write a client app with console output but that doesn't mean it's irrelevant.

I do agree you shouldn't hold the language back to support these way of doing things, but there's no point in now letting them exist.

WebGL is pretty cool but in my experience still has some compatibility issues with browsers rendering it, and then there's the reliance on js.

>It was nice to be able to quickly get some stuff going and then realize "Oh wow, my program is slow." Then I learned how to use VBOs and shaders and eventually got a pretty good handle on how to work it all.

Unfortunately this doesn't always work. For some programs (typically small ones, not really representative of common usage) the deprecated functionality will beat out the modern functionality in performance, until you scale up. I've seen this several times with display lists in particular.

Which will typically leave newbies with the feeling that the new functionality is crappy and slow.

> once upon a time

That's the important point. That one upon a time was invented 23 years ago. It was the wrong model but it took ~15 years to figure out that.

The problem with "beginner mode" is who decides what goes in it? You want what you had 10-15 years ago. Why is that the right level? Maybe it should support 1000 lights instead of 4? But that would require using deferred rendering under the hood. Maybe it should support shadows, oh but which kind as their are 10-15 techniques for shadows each with their own tradeoffs. Maybe you want it to support normal maps, or opacity maps, or specular maps, or glow maps. Maybe it should use physics based lighting because that's far easier for artists.

That's the reason all of that cruft was pulled out. OpenGL is no longer a 3D library. It's a 3D rasterization library. You build a 3D library on top of it. You choose the features you think your beginners need.

If you want your old style immediate mode GL then go use regal (https://github.com/p3/regal). Hopefully people will come out with better ways to start. (like three.js) That old school way is not the best. It was just one of the first. They figured out it was the wrong thing at the OpenGL level and moved on.

I'm happy you're nostalgic about your beginning experiences. People starting out today should start agruably somewhere else though.

> WebGL is pretty cool but in my experience still has some compatibility issues with browsers rendering it

not nearly as many issues as OpenGL because unlike OpenGL, WebGL has conformance tests

http://www.khronos.org/registry/webgl/sdk/tests/webgl-confor...

The thing is, OpenGL shouldn't be a learning API, especially considering on many platforms (Mac, Android, iOS, Linux) its the lowest level way to get access to all vendor's graphics hardware. The primary customers of the API should be developers of large frameworks, engines and applications and it should be the lowest level abstraction that maximizes performance and compatibility. As GPU hardware becomes less fixed function and more complex the API will naturally become less beginner friendly.

Beginners today should be starting with a game engine or a creative coding framework. There is an abundance of high or mid level options (processing, three.js, Unity 3D, Unreal 4, openframeworks, ShaderToy, etc.) that allow people to play with and learn about different parts of the graphics pipeline while getting immediate and cool results.

Processing, for example, lets people do the equivalent of glVertex\glColor immediate mode calls with far less boiler plate than GLUT, SDL or GLFW, and it's easy for them to add and learn about the transform state, fixed function lighting, shaders, etc.

I like your idea. When starting with Unity/UDK/etc they would get some basic understanding of how it 3D rendering works. Then, if they want, they could go deeper and learn low level api like DX, OGL

> 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?

> 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.

>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.

> 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)

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.

This! The layer you build can be super small, about 100 lines of code or so, and people can be taught to replace the whole thing rather quickly, and we can stop getting junior programmers that thing it's ok to use OpenGL in immediate mode.

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."

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.

> 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.

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.

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?

> But will using the immediate API help them grasp some of the concepts of OpenGL?

No, not a single one.

immediate mode had gl_Vertex, gl_Normal, gl_Color. Those are all gone. immediate mode had lighting, that's now hiding the fact that modern GL has no lighting, you have to write it yourself. Old GL has no normal maps, no opacity maps, no specular maps. Old GL had a matrix library. That's gone to.

You learn almost nothing from immediate mode GL that is relevant to modern GL.

You could argue you learn about some common 3D concepts like a projection matrix and a model matrix but since you don't actually work with the math in old GL you aren't really learning anything more than you could learn from any other 3D library built on top of GL.

Beginners can always use something like Unity3D, or any of the other gazillion libraries that are available. IMO beginner-friendly stuff has no place in the spec.

It seems to me that many people these days aren't willing to invest time to learn certain technologies anymore. They just want to be able to slap a bunch of components together quickly, and don't want to invest time in actually learning anything. Well, good luck doing that with 3D. Even if you manage to find an API that is simple enough, you probably still don't understand the 3D math behind it, or why your renderer is dog slow even though you only draw a handful of triangles

> I wish the people in charge of the standard would give some thought to beginners and the increasingly awful learning curve.

Why would they?

I don't mean to be antagonistic, instead I want us to look at the incentives of standards developers. What they're trying to do is make an old API perform new tricks and perform faster. In doing so, they will implicitly be answering the requests of people at the height of their field, as those are the people who need the standard to evolve for their needs.

Beginners aren't even considered. That's a shame in the long run.

You're right; that seems to be the way these people think.

But still, I have an answer for them:

> Why would they [give some thought to beginners]?

Because they want there to be a next generation of OpenGL experts.

Once upon a time there was OpenGL and there was DirectX, and an awful lot of people chose DirectX. Today every week brings a new API/framework/language. Most of these quickly die a well deserved death, but some don't. The competition for developer mindshare is fierce. Why not target beginners?

The answer seems to be that they wanted the API to be cleaner and easier to implement. Starting with GL 3.0 they've been tossing out the old cruft to get a more focused, streamlined API.

That sounds good, but I think it's idiotic. Everyone still implements glBegin anyway. The ARB's approach has made the maintenance of API implementations more complicated, not less.

I agree that it's annoying how complex 'simple' examples are but am not sure the OpenGL standard is the right place to inject a beginner friendly interface. A lot of the complexity like managing buffers and graphics memory are a result of the more capable 3D hardware we have today. A better thing to do would be to have a nice beginning library built on top of OpenGL and which abstracts away a lot of the gory hardware details to expose a simpler immediate mode style or scene graph interface.

I agree that simple 'hello triangle' is not that simple any more.

When I taught OpenGL I also used good old fixed functionality - just to show how the basics works. Then (in the next lesson) I usually tried to move to modern style.

Another thing is that Rendering Techniques are moving so fast that it is hard to keep up with the pace.

Honestly the thing I found most helpful when learning how opengl works is to write a rasterizer from scratch. Then all of the buffers and shaders and everything made a lot more sense after that.

I frequently hear WebGL recommended instead as a good place to start; that way you get 'modern' OpenGL without much of the hassle.