Whats new in opengl since 2003

Hello forum dwellers,

I am returning to opengl code after 7-8 years of not touching it.

‘Back in the day’ I knew the whole API back to front and a good load of the extensions. I am looking for an overview of what’s new in OpenGL since 2003.

Also a few questions concerning the state of graphics programming…
1)Is there a common language for shaders yet?
2)Is there a new (non-painful) work flow for getting models loaded. What about skinning and bones?
3)Shadows, are they still roll your own algorithm?
4)Is there a standard scene graph, or is it still use an open source project or make your own.
5)Collision detection, general volumetric geometry functionality, physics. Is their a good standard turnkey solution, or is it still a case of writing your own?
6)Fonts, again is still make your own image atlas of all letters, or similar trick; or does some standard library let me println…
7)Is there any really cool improvements to the graphics programming work flow I should be aware of.

Thanks,

-dm

  1. GLSL
    2), 3), 4), 5), 6) these are nothing to do with OpenGL. OpenGL is a low level API that you can use to access the underlying hardware’s rendering capabilities, not something that should include things like scene graph, automatic shadows ro collision detection (which in fact has nothing to do with a graphics rendering API).

cheers for 1

Sorry if the rest are too of topic, I did qualify them as “questions concerning the state of graphics programming”

Just found an article
http://en.wikipedia.org/wiki/OpenGL#OpenGL_2.0
that brought me up to speed on recent developments in a chronological fashion.

It seams that that a lot of new things have come along and it all looks good.

I saw something in the 3.1 update that caught my attention “Signed normalised textures”… I just cant imagine a use for this of the top of my head, is it something more related to processing non graphics data on GPU’s?

Anyway just made a quick OpenGL app to shake of the cobwebs. The whole API seems to act like it did in the old days which is good. Will spend a weeks going through some of the new stuff (since 1.3) and see what’s what.

If I were you I would focus on modern OpenGL (3.2+). Lots of the old stuff has been deprecated.

I saw something in the 3.1 update that caught my attention “Signed normalised textures”… I just cant imagine a use for this of the top of my head, is it something more related to processing non graphics data on GPU’s?

Not really. They’re useful for normal maps, as well as many kinds of textures that contain non-image data.

Depends what hardware you want to focus on. Personally I think around Opengl 2.1 is a good standard to aim for, as that gives shaders etc, and covers a wide range of hardware. Last I checked there was a whole range of ATI harwdare that technically claimed opengl 2.0 support, then lacked the non power of two extension which officially was part of the standard :s

Then theres the Intel problem. Do intel cards even support GLSL shaders? It’s almost enough to make a developer abandon Opengl. Intel used to have 40% of the graphics card market …

Yes, Intel cards support GLSL shaders. Intel Sandy Bridge supports OpenGL 3.0.

Yes, Intel cards support GLSL shaders. Intel Sandy Bridge supports OpenGL 3.0.

Admittedly, the question was not properly framed, so let’s revise it. Does Intel provide reasonably functional OpenGL drivers that support GLSL? What Intel claims is irrelevant; what Intel does is what matters.

Then theres the Intel problem. Do intel cards even support GLSL shaders? It’s almost enough to make a developer abandon Opengl

The reason is merely technical and silicon related :wink:

Embedded graphics chips are designed to fit in little space without causing overheating to its neighbors or even itself. Can you imagine the complexity of circuits to handle GLSL or anything beyond GL 1.4?

glfreak get yourself to a shop and look at an iphone4 or android.

So you telling me the excuse I made for them is just B.S :smiley:

I almost forgot about the capabilities of these “little devices.”

Now, what’s the excuse for Intel, which is IMHO the God of silicon? You telling me the GL specification is too complex for them to implement it? But it’s simple for smaller companies?

I’m now super confused.

Yeah, Intel supports GLSL. Not as well as HLSL, but it’s supported. You’ll need at least a 965 or thereabouts (which is a pretty old part right now so no big deal) and you should be a little careful about trying anything fancy, but otherwise it works.

Embedded graphics chips are designed to fit in little space without causing overheating to its neighbors or even itself. Can you imagine the complexity of circuits to handle GLSL or anything beyond GL 1.4?

What? I frequently code on an embedded GPU just fine. With GLSL and everything. An ATI HD3300. It’s low power consuming, embedded into the motherboard, and provides GL 3.x level functionality just fine.

Sandy Bridge puts GL 3.x functionality on the CPU. AMD’s fusion puts GL 4.x on the CPU. So don’t act like this is complicated or something. Intel’s OpenGL problems are purely software, not hardware.

Now, what’s the excuse for Intel, which is IMHO the God of silicon? You telling me the GL specification is too complex for them to implement it? But it’s simple for smaller companies?

Have you actually read the OpenGL specification? The whole thing? Writing a GL implementation is not a small undertaking.

Remember: Microsoft writes a good chunk of all D3D implementations. You don’t get that with Windows OpenGL.

Intel’s hardware acumen has always been better than their software skills (outside of writing compilers for their hardware).

Microsoft writes the runtime, the vendor writes the HAL. When you write D3D code you make calls to the runtime which in turn makes calls to the HAL. The obvious advantage is that by decoupling them you ensure that the HAL must conform to the spec, but the disadvantage is that there is no scope for vendor-specific optimisation in the runtime.

It’s also one reason why OpenGL implementations are more complex; the driver effectively has to contain both layers. Another reason is that D3D frequently drops backwards compatibility whereas OpenGL doesn’t; an OpenGL driver must continue to support the full spec going back through all GL_VERSIONs and must have software emulation for features that aren’t present in hardware. D3D on the other hand tends to just not provide support for anything that’s not present in hardware.

Welcome back, duckman! You’ve gotten answers to the rest but I’ll just add that, for this one, there’s no:

glEnable( GL_SHADOWS );

:wink: , but modern OpenGL makes implementing a number of shadow techniques “tons” simpler and more flexible than it used to be. But you have to decide on a shadowing technique (or techniques) first. Then go for it.

BTW, re the glEnable humor, one of the reasons this isn’t built-in behavior is of course most shadow techniques involve resubmission of the geometry to the GPU pipeline, and this is below the level of abstraction of OpenGL. You (or the scene graph/engine you use) does that.

If you have any other questions as you go getting your “GL legs” back, don’t hesitate to ask!

Cheers Randal,

Those “modern opengl samples” seem to fill in some of the “missing years” for me as far as the OpenGL API are concerned.

I will have to poke around a bit and see what’s cooking with graphics programming in general.

-dm

Thanks for the warm welcome Dark Photon,

Had a good lol at glEnable(GL_SHADOWS); no explanation was required :slight_smile:

I know many (if not all) of the questions I asked have nothing to do with a hardware API.

I just remember the huge amount of time I invested in all those areas, and I am sure my solutions were not significantly different to anyone else’s. Being a bit older now I don’t feel like “recoding the wheel” and was curious what solutions/libraries worked well with OpenGL to these ends.

As nobody has mentioned anything, I assume It’s a case of spending the time all over again?