The RT’08 symposium is a small conference (160 people, vs. 28,000+ people at SIGGRAPH) focussed on interactive ray tracing research. It was twice as large as last year’s due to its co-location with SIGGRAPH. There were no big breakthroughs; rather, people were exploring how best to take advantage of new hardware. Of personal interest, there were also talks on optimizing various acceleration structures. I should be making an issue of the Ray Tracing News pretty soon with a summary.

One happy event for me was that my keynote went well, after losing sleep over it the night before. The subject was ray tracing, rasterization, and hardware, past and future. It was one of the best talks I’ve ever given, which is somewhat equivalent to “one of the best films Rob Schneider’s ever made”. Well, maybe better than that. It was fun to dig up provocative quotes and engaging images for the talk; that said, the slideset doesn’t include most of my jokes (though it does include a photo of an object that luckily did not burn down my office’s building). I would have liked to go even further in the direction of more images and less text–it’s a time-consuming task to find good images! I did sometimes break my own personal rule of a maximum of 6 lines per slide, but usually for effect, to overwhelm the viewer with text; my favorite is my “buffers slide”, which lists all the named buffers I could find up to the year 2000.

After the talk Larry Gritz and Dan Wexler pointed me at the new art of Pecha Kucha, where a presentation consists mostly of images and runs at a constant rate. This sounds pretty ideal for most talks. I sometimes find myself distracted between looking at the text on a slide while also trying to listen to the speaker. At least I didn’t show any equations, which are absolute death most of the time. An equation is highly dense information, suitable for a talk only if (a) you are noting what the equation looks like, so people will recognize it later when they read your paper, (b) you actually spend the time to slowly explain each term in the equation and let it sink in, or (c) everyone in the audience already knows the equation (in which case it would be better to just say the equation’s name). Even then, you risk losing much of your audience when you put up an equation. Same rule applies to long shaders or pseudocode samples.

I think this phenomenon of too much information occurs more frequently now than in the past because slidesets often take the place of white papers. This happens quite frequently with GDC, XNA Gamefest, SIGGRAPH class talks, and many other venues. It’s nice that people who can’t attend the talk can at least see the slides, but it leads to slidesets having two purposes: one is to enhance the verbal part of the talk, the other is to reiterate the verbal part of the talk. Enhancement favors succinct bullet items, which can be hard to understand when downloaded. Reiteration helps the downloader, but is either overwhelming (read, or listen?) or boring (OMG he’s reading his slides, line by line) during the talk itself. OK, end of rant.

I’m as guilty as the rest (and now wish I had trimmed back on text on my last talk, now that this phenomenon has dawned on me), but part of the solution is to add at least some further notes (not seen on the screen) with the slides, which I did do with my slideset (the non-PDF version). Better is to write a blog entry, webpage, or paper about the subject, as PowerPoint is not really a word-processor. And of course I probably won’t do so myself for my own talk, as that’s too much time and I don’t think I’d add much to the presentation. But, my excuse is that my presentation is a high-level “soft” talk than anything with a lot of technical chew.