The State of OpenGL

CowboyRobot writes "No longer vapor, but a true 3D-embedded engine, OpenGL is on the move. Pixar and others would love to be able to render their movies in realtime, and that desire has prompted the intended release of OpenGL 2.0, due in a few months. Khronos is now in charge of further extending OpenGL to cellphones and handheld gaming devices."

Pixlet

[BWJones]

Pixar and others would love to be able to render their movies in realtime,

Ummmm......Pixlet [apple.com].

Re:Pixlet

[PurdueGraphicsMan]

Pixlet is for playback (a codec), not for rendering films. Unless I'm missing something in your post.

Re:OpenGL is Dead

[Xeo 024]

DirectX has won the war, with better features, performance, and availability.

I don't know about availability, OpenGL is cross-platform (works on OS X, Linux, Windows, etc.) while DirectX is Windows only. OpenGL is also included with many if not all graphic cards. So it's just as widely available, if not more, than DirectX.

Re:OpenGL ES with hardware support?

[LousyPhreak]

exactly thats the point of opengl es.

as it is only a subset of the opengl standard trimmed for low power/low speed devices it is (or will be) also fast in software. afaik there are also hardware renderers for opengl es in the works.

and remember:
we hat 3d games long before the gigahertz pcs with 3d accelerators were out and they were a tiny bit faster than 1 frame/second.

my interest fwiw

[rokzy]

I'm going to learn opengl in a few months during the holidays before I start my PhD. I work with simulations of the Sun and use IDL to visualise the results. but I think it would be cool to have more "realistic" pictures, plus having the hardware acceleration has benefits when dealing with a lot of data (IDL gets real slow for 2D simulations at resolutions above a few hundred squared)

these simulations are done on beowulf clusters (imagine that!) so I think opengl is the best (the only other API I know of being directx)

OpenGL 2

[woodhouse]

OpenGL 2.0 is not as exciting as the new major version number might indicate. Probably the most important new feature of OpenGL 2.0 was going to be the GLSL high level shader language. However, in order to speed up its support by hardware companies, this was instead put into OpenGL 1.5 spec when it was announced last year; GLSL already has implementations by 3DLabs, ATi and nVidia. OpenGL 2.0 will still add some useful new features, but it won't be the world-shattering event that 3DLabs promised in their original proposals.

Re:OGL alone is not enough for gaming

[System.out.println()]

My friend is working on a multipurpose game engine, with the ability to "plug in" different graphics managers - so you can have the beauty of DirectX 9 on your Windows version, and seamlessly switch to OpenGL when you port it to Mac OS.

Or should I say, when I port it to Mac OS, since that's my job. I wish I had the slightest idea how his engine worked... He has all sorts of complicated code that compiles fine on his x86, but is gcc-unfriendly. :-(

Re:Pixlet

[Anonymous Coward]

There is a bit of lunacy afoot; start looking at the troll postings, then at these people's journals, and you discover that there are "troll rings".

Their evil (no, actually boring and stupid) plan:

* come up with cheap and easy ways to get modded up (karma whoring).

Ways to karma whore include: These posting the article text early on, stealing people's posts far down in the discussion and reposting on an earlier thread, and reposting comments from other people on other threads with similar topics.

* a bunch of trolls simultaneously get moderator points

* in a coordinated fashion, they label on-topic posts as offtopic and attempt to steer the whole discussion in absurd directions, usually by recycling troll and flamebait posts that have worked in the past.

These people are sad and lonely. I feel sorry for them. Maybe someday they'll feel the joy of accomplishing something that most would appreciate and call constructive. Otherwise, I fear that they'll eventually discover the wonders of heroin.

Re:Pixlet

[Anonymous Coward]

omfg.

so if something uses the word "rendering" in it, it's on topic.

3d rendering is one thing.

video rendering is something completely different.

they are as different as me "rendering" something in charcoal on a napkin.

but hey..if yelling at moderators gets you points...don't let me stand in your way.

Re:Pixlet

[Anonymous Coward]

-1 Factually incorrect.
You may want to look up the definition of "rendering" ("The process of creating an image (on the screen or some other medium) of a model".
Pixlet has nothing to do with rendering except as a working format for the already rendered images. The article is talking about OpenGL, a 3D API, which is suitable for rendering, not about what happens with the rendered pictures (which could be compression [google.com] with pixlet).

On a related note..

[rkaa]

Jan 16th 2002: SGI transfers 3D graphics patents to MS [theregister.co.uk]
Jul 09th 2002: Microsoft Claims IP Rights on Portions of OpenGL [slashdot.org]
Jul 11th 2002: 3D graphics world shaken by patent claims [zdnet.co.uk]
Jul 13th 2002: Microsoft patent claims may affect OpenGL [macworld.com]
Mar 3rd 2003: Microsoft quits OpenGL board [theregister.co.uk]

Re: OpenGL 1.5

[TypoNAM]

I am a licensed indie Torque owner and I have to say it is a very impressive game engine when it comes to cross platform game development. Not only does it run pretty smooth just like games such as Wolfenstein: ET and Tribes 2 (T2 was actually not really good on Linux compared to it on Windows) its source code is actually gcc friendly.

About Tribes 2, its Linux port wasn't very good and it choked from time to time for no real reason and Torque engine doesn't have this problem. The real history of Torque is that it came about right after Tribes 2 was released and GarageGames company was formed which are several former Dynamix Employees (even the founder is the founder of the company) working at GG. Torque Game Engine I have to say is far better than the old Tribes 2 engine (if you worked with Tribes 2 and then Torque you would know exactly what I mean by it).

Anyway the engine is pretty good in my opinion and as a note to those Quake lovers Torque doesn't do BSP structures for the whole map. It has a true terrain system that goes on forever and no it doesn't loop all the way around (but I've seen mods pull this off :). It uses BSP structures for what is called Interiors which are basically buildings and the GG community has been making great advances in the game engine for several years so it isn't something that will sit there and idle for months, it's always being worked on by several groups of people. So the whole game engine development is mainly driven by community resource submissions.

I guess I've talked my head off long enough and put several readers to sleep, sorry. Check out the site for yourself and maybe consider getting a license (please read the license agreement before forking over cash for it since I've seen many people ask questions about the license AFTER they bought it!)

gl pipeline not for raytracing

[nuttyprofessor]

Most frames in Pixar movies are rendered using some form of ray-tracing. While it is possible to use vertex and fragment shaders in uncoventional ways to do ray tracing, this is *not* what the OpenGL pipeline is designed for. Great for games, but ray-tracing will still be done using render farms (and not in real time).

Re:Damn them

[HeghmoH]

Two points:

First, they still sell black and white portable computers today, they've just shrunk; before they were 5-pound portables, now they're quarter-pound Palms.

Second, battery life, both for portable phones and portable computers, has been on the increase, not the decrease. My portable computer from the mid-90s (black and white, even) was lucky to get two hours. My giant, power-sucking G4 with a full-color 3D-accelerated screen is unlucky to get three hours; I can get five hours on light use. My girlfriend's full-color-screen, MIDI-playing, Java-gamed cell phone lasts for four days between charges. I see no reason for this trend to reverse; indeed, people tend to value battery life extremely highly, and so manufacturers value it accordingly highly.

OpenGL | ES is not OpenGL

[Performer Guy]

The original article post seems to confuse different forms of OpenGL. OpenGL|ES is the embeded stripped down OpenGL for mobile & embeded systems. OpenGL 2.0 is just a proposal from 3DLabs and may never get off the drawing board. Most of the significant changes that OpenGL 2.0 introduced have been implemented and released either as extensions or as part of OpenGL 1.5, so it's just not clear if or when OpenGL 2.0 will actually arrive, there's a lot of resistance because 2.0 intended to throw some stuff out and many developing, selling & using OpenGL implementations think that it's a REALLY bad idea to do that. With OpenGL|ES there is already a version 1.0 and you can actually get this in several forms from implementations that run on phones to wrappers around OpenGL that you can use on the desktop to emulate OpenGL|ES. OpenGL|ES is in the process of developing version 1.1 right now.

Re:OpenGL 2

[woodhouse]

You're splitting hairs. The entire of OpenGL 1.5 is ARB extensions. There are no new "core" features in OpenGL 1.5, however cards can only be said to support OpenGL 1.5 if they support the ARB extensions.

BTW, have you actually programmed for ATi's GLSL implementation lately? It's improved a lot over the last few months, and it's very usable at this point. I can't give details due to an NDA, but expect ATi's implementation to be at 1.0 very soon.

Re:gl pipeline not for raytracing

[One Louder]

Uh, no. Pixar movies typically use the REYES micropolygon algorithm, with some assists from raytracing for certain effects as necessary, implemented within their Photorealistic Renderman (PRMan) product.

The notion that Pixar would use OpenGL for final rendering if only it were fast enough comes up every time a new video card or GL enhancement comes along just indicates how little people understand how Pixar actually makes their films. Oddly, Pixar really doesn't make this information much of a secret, and they'll even sell you the same software they use.

Re:To my understanding...

[omicronish]

From coding experience the integration is pretty much non-existent or not very strong. APIs such as Direct3D and DirectSound have consistent API styles, but they don't share much API. It is possible to write an OpenGL application that uses DirectSound and DirectInput, like GLQuake.

Re:gl pipeline not for raytracing

[kmo]

Most frames in Pixar movies are rendered using some form of ray-tracing.

Technically, no. Renderman (the Pixar renderer) does not perform ray tracing. It uses a scanline renderer that is much faster than any ray tracer I've ever seen. They've been at this for literally decades, and are very good at it. Still, the most complex images in their movies can take many hours -- sometimes more than a day -- to render. The time-to-render doesn't seem to improve much from picture to picture because as computers get faster, they just add complexity to the scene.

Re:OpenGL ES with hardware support?

[Mithrandir]

The simplistic reason for this is that the full OGL spec, or even the "miniGL" drivers are still waaay to complex for what is needed on these devices. Things like multitexturing, and anything that requires readback from the state is especially costly. The point was that on these devices they dont want full OGL support. If they did, they wouldn't have even bothered starting this spec. It is to provide a spec that has a greatly reduced footprint (memory, API coverage, etc) that allowed first class 3D graphics on smaller devices. If you want full OGL support, you do full OGL, not a partial implementation. There is no point "working upwards to full OGL" because they are never going to get there with this spec. Once a device wants to head towards desktop OGL support, then they bite the bullet and implement the complete API.

It was also determined that most of that sort of functionality was not needed. Other things like 1D and 3D textures, attribute stacks, display list etc are just non existant. On the other end, there are things that never existed in OpenGL, such as the fixed point maths support, along with defined accuracy measures etc.

In the beginning, OGL-ES had two primary targets - small footprint mobile devices, and safety critical markets (ie avionics displays etc). In the former, they needed basic functionality, but enough to do things like overlays and texturing. In the latter, they needed a very small API footprint that can be verified IAW with various authorising bodies (eg FAA for avionics, NIH for medical devices etc). In both cases, a miniGL driver was just not good enough because miniGL still assumes the full OpenGL spec and only for one particular application. Both groups required a formalised spec that they can point to and claim "this is what we support", complete with some logo branding. miniGL still assumed a desktop based system, neither of the target groups for OGL-ES could make a lot of those assumptions (for example floating point abilities at all)

FWIW, I was a member of the ES spec development group until about 3 months ago and still am on the spec mailing lists.

Re:Java on top of OpenGL is happening...

[Mithrandir]

You may want to have a look at JSR-231 then, which is the official bindings of OGL in Java. If you need something more immediate, the JOGL project, which is the baseline for the JSR, should be checked out. It can be found on the java.net site.

Re:my interest fwiw

[wass]

I've used IDL before, and I'd avoid doing any very intensive calculation on it (unless it was 'linkimage'd to an external C routine). Some of the specific IDL calculation routines are optimized (FFT for one), and i've FFT'd 64k arrays of floats, but that's about the limit.

Anyway, since you use IDL on a Beowulf I'm assuming they finally added multithreading. That's good, when I used it before my PhD (I'm doing condensed matter physics now, but used IDL at my research job prior to this) there was no multithreading in IDL, which was kind of annoying at the time.

IDL is good at visualization, and the interactive mode is really nice, but I would avoid using it directly for actual intensive calculations. But if you have alot of code written already, check out the external development guide, it's not that hard to link to external C programs. I did that to call low-level hardware IO routines, and run the high-level data-acquisition code from IDL w/ GUI and the niceness of IDL's display routines.

Re:OpenGL 2

[jra101]

The OpenGL Shading Language extensions (ARB_shader_objects, ARB_vertex_shader, ARB_fragment_shader, ARB_shading_language_100) are NOT part of OpenGL 1.5. An implementation can advertise OpenGL 1.5 support without any of these extensions.

They will be added to OpenGL 2.0.

Re:OGL alone is not enough for gaming

[System.out.println()]

Well it's designed to run any sort of game, and a number of different "plugins" (a C++ class inheriting from an abstract plugin class) allow specialization as the given genre demands. So far using this engine a lot of 2D games have been developed - a working DDR clone (albeit only with keyboard support and crummy graphics), a decent version of Asteroids (vector graphics, scrolling, camera zoom, camera rotation, minimap/radar, running at 60fps or better - Asteroids is the testbed for most of the engine's new toys), a Commander Keen-like platformer (bitmap-based graphics with camera rotation and hundreds of enemies on screen with virtually no slowdown), an ASCII shoot-em-up and a few others I can't think of off the top of my head. There's also a primitive vector-3D game (6-player Pong with 5 computers :)....) using the engine.

The core engine itself mainly contains only a few pieces that are common to most genres: graphics management (which is then passed off to a renderer of your choice), UI element handling, collision detection, and the like.

The engine also has built-in scripting and a console mode (where the game pauses and you can enter commands as if part of a script, which is very cool, and very useful for debugging - stuff like SET_X PLAYER 120... and yes the console can be disabled)

Re:gl pipeline not for raytracing

[Anonymous Coward]

Tradtitionally, Pixar moves has absolutely no raytracing in them. Most of the movies have no need for them, as raytracing is mainly useful for non diffuse surfaces, which there are very few of in Pixar movies. They have however been struggling with adding some raytracing features into their renderer, and I believe there was some in Finding Nemo. Mostly likely there was some raytracing in the lighting calculation, in combination with the traditional REYES renderer.

Re:gl pipeline not for raytracing

[Viking Coder]

Peercy and Olano [psu.edu] (Click on "PDF" in the upper right)

Presentation [ibiblio.org]

ASHLI [ati.com]

GPGPU [gpgpu.org]

More than Moore's Law [geek.com]

Moore's law : still for wimps [extremetech.com]

Using programmable graphics hardware (possibly through OpenGL) for final rendering is not that far off. (Definitely not in real-time, but as a more cost-effective way to do it, anyway.) Especially with the massive parallelism of rendering, and the fact that GPUs are far outpacing CPUs in terms of their speed and transistor counts.

OpenGL is much more similar to micropolygon rendering (REYES) than it is to raytracing in the first place. The shaders are where you spend all of your time, anyway.

Heck, do you think nVIDIA bought ExLuna (Larry Gritz, author of BMRT, and former Pixar employee) just for the fun of it?

Software for translating from RenderMan Shading Language to Cg?

And what about RenderMonkey supporting RenderMan?

Do you even remember PixelFlow [unc.edu] from Pixar? Do you see the name Marc Olano on that paper? The same Marc Olano who talks about rendering on consumer-level graphics hardware? These things have far more in common than you seem to realize.

Re:To my understanding...

[hawkstone]

> SDL is a reasonable answer to portability while still accomplishing the integration that MS has achieved, but SDL isn't really as mainstream as OpenGL is.

SDL and OpenGL are not mutually exclusive. I have very successfully used SDL to handle joystick input, window creation, and sound output, with OpenGL for 3D. SDL in fact is designed to work this way, since SDL will create OpenGL rendering contexts for you when you create windows, and it handles the fullscreen video modes far easier than any other method of creating OpenGL contexts that I have used.

And just for comparison: I ported a DirectX/3D game from windows to SDL/OpenGL on Linux, and cut out about 1000 lines of code in the process because the DirectX API is so ugly. (I realize that might imply DirectX is more powerful, and I also realize my abhorrence of the MS DX API may be simply personal preference, and to boot, this was a DX5 program, so the API may be simpler now. I'm just relating the facts as I found them.)

Oh, and wasn't SDL used by Loki quite often for porting games to Linux?

Re:Direct-compile model looks dangerous

[Screaming Lunatic]

FUD. Offtopic. Flamebait. Why does every discussion remotely related to graphics have to deteriorate into closed versus open source drivers zeolotry.

Drivers are closed source now. Drivers will continue to be closed source in the future in spite of where the compiler lies. Having the compiler in the driver is the right decision.

Don't like it. 3DLabs released the front end to their compiler. There is work being done in Mesa to support GLSL.

From now on, all bitching about open versus closed drivers will be modded as offtopic. Everyone knows the pros/cons and reasons for either decision. No need to drive it into the ground.

Re:gl pipeline not for raytracing

[One Louder]

Yes - that image [landscapemodeling.org] was used as an example in the original paper [acm.org] describing the REYES algorithm.

Re:my interest fwiw

[Anonymous Coward]

Using OpenGL to visualise scientific results is, in some ways, "wrong". For visualising scientific results and such, I would recommend VTK (Visualisation Toolkit). OpenGL is just a graphics library, and visualising any results with it would usually mean transforming everything into geometric primitives before rendering - a lot of work, in other words. VTK uses OpenGL for rendering, but also contains many functions for extracting, transforming and doing calculations on the data.

The functionality of VTK is closer to IDL, and uses OpenGL as the rendering subsystem. Very interesting, and widely used...

Re:To my understanding...

[Tough Love]

if i recall correctly, SDL was originally developed by a guy who worked at Loki.

Actually, Loki hired the guy who developed SDL.