OpenGL 1.5

Yogijalla writes "SGI and OpenGL ARB just announced the OpenGL 1.5 specification, introducing support for a new OGL Shading Language. Also, check out the new Java bindings to OpenGL. OGL 1.5 is a step towards the OGL 2.0, already suggested 2.0 by 3DLabs." Also worth pointing out that OpenML SDK has been released as well.

Comments

Somewhat old, it's been there since Monday...

[ericvids]

But I'm happy to see that they're finally putting a high-level alternative to the ARB_vertex_program and ARB_fragment_program extensions. I've been dabbling in these extensions and it's been a huge pain. Also just in time for the class I'm teaching next semester.

I wonder when these will become standard (not just as an ARB extension but as an ARB required feature). Hopefully in 2.0? It will save a lot of calls, at the very least--just check the version number of the GL implementation, no more searching extension strings... :)

Woohoo

[Duncan3]

"Non power-of-two Textures"

That's _thee_ key feature Apple needed to do the fully OpenGL desktop, along with a pile of more eligant error handling of course. Glad to see it's now standard.

It also makes the modeling and artist guys much happier. Do you have any idea how hard it is to make everything out of squares?

2.0 should put the last of what we need for the next 5 years into OpenGL, then maybe people can start writing more portable games again.

Re:Woohoo

[zenyu]

"Non power-of-two Textures"

That's _thee_ key feature Apple needed to do the fully OpenGL desktop, along with a pile of more eligant error handling of course. Glad to see it's now standard.


I suspect it's for bind to texture, not anything that can already be done by just using part of the texture. Supposedly nVidia has been waiting for 1.5 before doing bind to texture in UNIX environments (currently only a WGL extension.) For me, on the FX, copy has actually turned out faster than bind, but that is hopefully just a driver limitation. Rectangular textures also have nice coordinates for using them in multi-layer programmable pipeline settings. (I haven't read the specs yet, just extrapolating from the nVidia extension.)

Doom 3

[DeathPenguin]

The shipping date is coming up in a few months for Doom 3. Any ideas on whether it will be using OpenGL 1.5, or is Carmack still intent on pushing the industry forward by implementing draft standards?

So:

[Anonymous Coward]

- What still remains before we can say OpenGL is back toward its original goal (you write for one standard instead of having to write for every single little card driver, something kind of ruined by the fact that many things these days, every card uses a different opengl "extention" to do the exact same goal.)

- What still remains that DirectX excels at that OpenGL is lagging behind at

- What of the things in the above two lists will be fixed by OpenGL 2.0, when/if it is adopted.

Re:Would like to try the OpenML SDK

[i_am_nitrogen]

OpenML and SDL are hardly the same thing... Check out the Jahshaka home page for an idea of the kind of application OpenML will benefit. OpenML is really an awesome thing. It finally brings together 2D and 3D raster graphics (OpenGL) with video processing and synchronization capabilites, providing a standard platform for applications to perform accelerated compositing, editing, effects, and other operations on various media. Hopefully we'll see an Open Source implementation of the SDK in the future.

SDL is simply a low-level hardware abstraction layer. It doesn't even have geometric drawing code.

OGL 1.5 - Legal Issues

[BigFootApe]

IFAICR, nobody has been able to do work on programmable hardware shader support for DRI (because of IP issues on some GL_ARB_Vertex* extensions). Is the new shader language similarily problematic?

What I always wondered

[Anonymous Coward]

I've heard the comments before that Direct3D/Quickdraw3D are "high-level" standards, and OpenGL is a "low level" standard-- i.e., OpenGL is largely primitive things, meaning developers must implement a bit more engine on their own; Direct3D tries to bring in the programmer at the higher level but limits them if their needs don't exactly fit that of Direct3D. Is that an accurate portrayal?

What I always wondered is why the OpenGL people don't promote a two-level standard; the low-level is OpenGL as it exists now, the second level of the standard would be optional. and consist of the kinds of things that Direct3D/Quickdraw3D would have offered, higher level things. The second-level standard would be implemented on *top* of the first level standard, meaning it would be as portable as the base is and not provide a roadblock to changes in creating new opengl versions. Something like Mesa.

Is this an attractive idea, or do the present existence of third-party libraries that sit on top of opengl make such an idea irrelivant? Even if so, it seems a "standard" higher-level library for opengl could take out one of the big complaints of Direct3D programmers ("OpenGL is too much work!")

Let me know if anything i've said here is wrong; I've followed the Direct3D/OpenGL argument but have personally done nothing more complex than some simple GLUT applications. (And I didn't even get enough into GLUT to see to what extent it functions as a higher-level 'cover' API for OpenGL..)

How will this affect Doom 3?

[Muhammed Absol]

ID is already doing amazing shit with OpenGL, will this be something that helps a game like D3 do more or do the same thing faster?

development speed is critical

[rexguo]

I'd much prefer to see Sun/SGI base their work on GL4Java (www.jausoft.com/gl4java) than starting from scratch all over again. The industry needs this now and needs it fast. Microsoft has already got DX9 bindings for .NET months ago, but Sun/SGI has only announced it -now-? GL4Java, which is open-source, has been around for a long time and is pretty mature. It has survived the competition from commercial offerings like Magician (which is now dead). In fact, last year, SGI (or was it Sun?) used a customized version of GL4Java to show off the new NIO features of Java, rendering a 300MB+ terrain dataset in real-time. The speed at which Sun/JCP develops Java, and the speed at which SGI/ARB develops OpenGL, is a shame, let's hope they change this tradition this time!

Re:What about the postscript desktop?

[IamTheRealMike]

Yes, all that is absolutely correct. I'd just like to point out that you don't really need to use OpenGL to do those things though, at the end of the day the 2D/3D primitives all boil down to a sequence of instructions to the card. For instance X pixmaps (on XFree) are already stored in video RAM.

The main problem with XFrees responsiveness is not whether it uses OpenGL or not (which ultimately makes little difference) but how it interacts with applications and how it pokes the video card. For instance very few drivers fully accelerate RENDER (which is 2D hardware acceleration for alpha channel blending and some other things). That means you end up doing very slow framebuffer reads, compositing in software then upload. I guess part of the reason for using OpenGL was to work around the reluctance of driver manufacturers to write specialist fully optimized drivers for their hardware.

Not to mention that most apps are very slow at processing Expose events. There has been talk of doing what MacOS does here and having apps directly render client-side into a compressed backing store.

What happened to Fahrenheit?

[gakguk]

All I remember about it is that cool poster of flames on the water or something.

OpenAL

[Wuukie]

Now we have OpenGL and OpenML. It seems nobody picked up OpenAL when Loki left the building.

Do Linux game developers (or anyone at all) use OpenAL nowadays for environmental sound effects? Is it any good in its present state? It seems the website www.openal.org hasn't been updated since 2002. Well, most of the stuff seems to be from 2001...

Tremendously slow progress

[Junks Jerzey]

Microsoft rushed ahead with Direct3D in the mid 1990s, made lots of well-publicized mistakes early on because of a general lack of 3D knowledge, then nailed it starting with the graphics side of DirectX 8. The next version, DirectX 9 is a dead-on match for what's generally considered the state of the art in PC video cards. Microsoft isn't even planning DirectX 10, because DX9 is still way beyond what most people need or use (well, that, and the overall decline of the the PC video market). And, believe it or not, DX9 is a breeze to use and has a well-designed API (once you get over the usual COM nonsense that comes with DX in general). Meanwhile, OpenGL, which I'll admit was much better designed from day 1, is going to reach the DX9 level in about five years, if things keep going as they are.

The article confuses me.

[Randolpho]

In it, it makes no mention of Java3d, which is a scene graph API with bindings to OpenGL or Direct3d. Is this announcement going to be a thin binding, or a new version of Java3d? Or will it replace Java3d?

Inquiring minds want to know! :)

Re:The article confuses me.

[deanj]

Yeah, I know...I know... technically (offical Sun party line), it's not dead, but for all practical purposes, you're right, it is dead. I was just relating what one of the developers said at JavaOne. I did a lot of work with it, so it's hard to see it go.

It'll be interesting what happens with the patents, particularly the .compile() part of the API, since I believe that's one of the things Henry Swizworal (I never could spell that) and the hardware guy (who's name escapes me at the moment...John Deering maybe?) got a patent on.
At one time I believe they were going to implement that in hardware, but the PC hardware vendors overtook the industry and basically made that irrelevent.

The real shame of Java3D's history is they never did put the proper number of resources on this project. I don't think there were more than three or four people working on it at any one time at Sun. I think they did one more release after Henry left for that networking company in Seattle, and that was basically it. They were working with Hanrahan's group on a shading extension, but I think that basically went away because of OpenGL's new stuff, and NVIDIA's stuff.

And actually, they do declare things dead. They put them into "end of life cycle" or something like that. HotJava is one of them. They have a page of the others, but I don't have that link handy. As you say, this rarely happens though.

You gonna start a JOGL FAQ site? :-)