Upcoming Events
Gen Con UK
8/28 - 8/31  

Penny Arcade Expo
8/29 - 8/31 @ Seattle, WA

Virtual Worlds Conference and Expo
9/3 - 9/4 @ Los Angeles, CA

Women In Games
9/10 - 9/12 @ Coventry, United Kingdom

More events...


Quick Stats
3655 people currently visiting GDNet.
2208 articles in the reference section.

Help us fight cancer!
Join SETI Team GDNet!



Link to us

  search:   

I had wanted to attend SIGGRAPH for years, but for various reasons (two years ago, I'd just started a new job, a year ago, it fell at the end of crunch time) I wasn't able to go. But this year, with the conference being held in San Diego (where I live) and many of the sessions being directly related to my current job, I was finally able to go.

For the uninitiated, SIGGRAPH is the annual conference put on by the ACM's special interest group on computer graphics. Every year, thousands of people involved in computer graphics from around the world gather to hear researchers present their latest work, attend courses covering important evolving topics, see the best of the best CG animation shorts and movies, and to check out cutting edge products. The scope of SIGGRAPH is obviously much larger that the game industry, but there's no question that the majority of the material covered in the papers and the courses will benefit game developers.

In this report, I'm going to provide a summary of the sessions I attended, both to pass along the information that I picked up, as well as to give those who haven't attended the conference before a glipse of what it's like.

Day One: Real-Time Shading
There's no question that real-time shaders have been one of the biggest revolutions in graphics. Of course, programmable shaders have been available on various platforms since the 80s, so they aren't exactly new, but their (relatively) recent appearance on consumer-level hardware at interactive speeds has opened the doors for their use in a wide range of applications, games being but one of them.

This full-day session focused on the current state of real-time shading, covering some of the more interesting uses of shaders, as well as looking at current and future support from hardware vendors.


Procedural solid texturing using a texture atlas
Some of the highlights of the course included an overview of the OpenGL Shading Language (more on that later), samples of several areas shaders are being used, such as in computing more accurate BRDFs and procedural textures, a look at coming up with level-of-detail mechanisms for shaders (so that less expensive shaders are used for distant objects), and an overview at some of the work that has been done in producing compilers to allow high level shading languages to ignore the limitations of the underlying hardware by breaking shader programs down into multiple passes.

Early on in the course, it was pointed out that GPUs are becoming increasingly general purpose, and that other than operating on vectors rather than scalers, they really aren't much different from a CPU. This is allowing for some unconventional uses of the GPU, some of which have very little to do with graphics. One of the more interesting of these unconventional uses (which of course *is* graphics-related) is ray tracing. The approach described involves sending each triangle down the pipe encoded in the vertex data of a quad covering the entire screen (so that the triangle's information is available at every fragment in the fragment shader), encoding the rays in texture maps, and then doing all of the ray-triangle intersection tests in the fragment shader. Several different groups are doing research in this area, with variations on where the line is drawn between what's done on the GPU and what's drawn on the CPU. The results have been ray tracers that are able to do many times the number of intersection tests done by the best CPU-only ray tracers. It would seem that real-time ray tracers on consumer hardware aren't far off.

During their portion of the course, NVIDIA discussed Cg, and it appears that their official line is that they are recommending that you use HLSL for DirectX and Cg for OpenGL. At the same time, they are supporting the OpenGL Shading Language. They said that they'll be modifying the Cg compiler to add OGLSL as a profile to compile to. It'll be interesting to see how well this works out.

In the evening, there was an IGDA-sponsored session which featured the creators of Neverwinter Nights, Splinter Cell, and Sly Cooper and the Thievius Racoonus doing kind of a live postmortem. I was unfortunately only able to stay for a few minutes, but from what I saw and heard from others, the discussion was interesting but a bit too high-level.

Day Two: The OpenGL Shading Language

Inspired by Pixar's toy ball, this was colored using OGLSL. No textures here!
This half-day course, conducted by Randi Rost of 3D Labs and Bill Licea-Kane of ATI, covered the new OpenGL Shading Language. The language (which had been called GLSlang previously, but which everyone was referring to as OGLSL - we'll have to see which one sticks) was officially approved by the ARB on June 10th, and it is included as an ARB extension in the recently announced OpenGL 1.5 specification. Although the course covered the specifics of the language itself and the details of the extensions supporting it, I don't have the time or space to give more than a high-level overview here.

OGLSL is similar in syntax to other high level shading languages, such as Cg or HLSL, though it is probably most similar to Pixar's Renderman. The language was designed so that the vertex and fragment shaders use the same syntax. The intent is that if/when programmability is added in other areas, they'll use the same syntax as well.

To use the OGLSL, you pass the program to OpenGL as a string, and have it compile the program as a shader object. You then link shader objects (e.g. one for the vertex shader, another for the fragment shader) together to create a shader program, which you then execute. There are also APIs that allow you to create attribute and uniform variables to pass data to the shader.

One of the major differences between OGLSL and other shading languages, then, is that the compilation of the shader is done at run time, by the OpenGL driver. The advantage of this is that hardware vendors theoretically have more room to innovate and optimize, since they aren't limited to a publically defined assembly language interface. As a developer, it means that you should be able to write your shaders once, and then have them not only work on any hardware that supports OpenGL 1.5, but to take full advantage of future hardware for free.

At the time of writing, 3D Labs is the only IHV shipping a driver that supports OGLSL. ATI currently has drivers in beta, and NVIDIA is promising supporting drivers by the end of the year.

In case you're wondering, the reason for including OGLSL as an extension for now is so that everyone involved can get some field experience using it so they can work out any issues before promoting it to the core. Once that happens, which is expected to be in the next 6-12 months, we'll officially have OpenGL 2.0.

Day Three: Nature, and More OpenGL
There was a full-day course on Tuesday called "Simulating Nature", covering topics such as fractal modeling, fluid simulation, cloud modeling and animation, smoke and fire simulation, and plant modeling and rendering. Unfortunately, I was only able to attend the first half of the course, due to other events in the afternoon.

I can't get into the implementation details, but screenshots of some of the demos related to the topics covered are show below. As you can see, smoke and fire techniques are becoming quite realistic at interactive speeds. Terrain rendering is getting very good as well, though as Ken Musgrave pointed out, the worlds we're creating look good but not necessarily real. In the realm of plant rendering, creating realistic-looking vegetation and interactive speeds haven't quite come together yet.

In the afternoon, there was an OpenGL ES Birds of a Feather session by the Khronos Group. This was a must-attend session for me since I'm implementing OpenGL ES at work.

The first official OpenGL ES 1.0 specification was announced and released during the conference. OpenGL ES is a subset of OpenGL intended for use on mobile and embedded devices (hence the ES - Embedded Systesm). The area it's going to have the biggest and most immediate impact is for cell phones, since the next few years will see the emergence of hardware accelerated 3D graphics on mid- to high-end mobile phones.

The OpenGL Birds of a Feather was in the evening. Members from the ARB reported on 1.5, focusing mainly on the shading language. The superbuffers working group also reported, stating that now that the shading language is done, they'll be able to devote more resources to superbuffers, so we should be seeing them fairly soon. There was an OpenGL ES recap as well, and the session finished with a discussion of the recent announcement by Sun and SGI of Java bindings for OpenGL. This announcement caused some confusion, since there have been Java bindings for OpenGL for a while, most notably GL4Java. But since existing bindings are incomplete or have issues, Sun is making concerted efforts to release a new set of bindings, which they're doing with the original creators of GL4Java (who had since gone on to create Jungle, which is now jogl, and which will probably undergo yet another name change before it is released).

Day Four and Five: The Expo
The expo floor actually opened on Tuesday, but I didn't get to check it out much until Wednesday and Thursday. It seemed a bit larger than the GDC expo, but there wasn't as much hype. A lot of the same companies were there of course, such as ATI, NVIDIA, discreet, Alias (which has dropped the |Wavefront), and a lot of book publishers, but there wasn't much that was game specific. There was also a presense from the film industry, such as Pixar, Dreamworks, and Sony, and a lot of educational institutions that offer graphics related courses.

One of the products that really made an impression on me was Animation Master 2003. I'm familiar with the product, since many of the artists at Avalanche were using it, but I'd never closely checked it out before. Feature-wise, it's extremely competitive with Max or Maya (the artists at Avalanche said it is *the* best modeling and animation package available, bar none), but the really cool thing about it is that it's only $300. Defintely worth checking out if you're an artist, especially if you're on a budget.

I also met with Mark Rein of Epic Games to talk about their $1,000,000 mod contest. You can find out more about it at www.makesomethingunreal.com, but to sum up, Epic, NVIDIA, AMD, ABit, Alias, Atari, CoolerMaster, and Digital Extremes have teamed up to offer $1 million in cash and prizes in various categories over 3 stages to the teams that make the best mods and content for the Unreal Engine. 3D Buzz, whom we've mentioned before here on GameDev.net, has also joined in by offering video training courses for UnrealScript and the editing tools - which, like their other courses, are free. Mark pointed out to me that the majority of new hires at Epic and a lot of other companies are coming from the mod community, so this contest not only provides a shot at some cash, but a great in-route to the industry.

Conclusion
Overall, SIGGRAPH lived up to and in many ways exceeded my expectations. The quality level of the material presented at the courses and papers was outstanding, and the value of being able to meet and talk to some of the major movers and shakers in the graphics biz can not be overstated. I think that most game developers will get at least as much out of SIGGRAPH as they do from the GDC, and at about half the price, it's a much better value.

 Discuss this article in our forums