Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: