Industrial Arithmetic

Meeting Steve Jobs

2011-08-26T04:50:00.000-07:00

With the recent news about Steve Jobs leaving Apple, everybody seems to be posting their stories about him. Mine isn't that funny, but here goes.

One of my first projects at NVIDIA was working on a real-time version of Pixar's famous "Luxo Jr" short film. Shadows maps were a new feature on the GeForce 3 graphics card, and our marketing guys thought this would be a great way of showing them off (without any concept of how difficult this would be, obviously). The GeForce 3 was planned to be launched with the new iMacs at MacWorld Tokyo 2001.

The crazy thing was that we developed the whole demo without any permission (or help) from Pixar whatsoever. As my boss liked to say, it's easier to ask for forgiveness than permission.

Our intern Eugene D'Eon (now at Weta), modeled the lamps and rotoscoped the entire animation frame-by-frame from a rip of the original DVD. I worked on the shadows and shading. We finished the demo with a few days to spare (those bendy lamp cords were a real pain to get right, let me tell you), and our execs showed it to Steve at Apple. He said it was pretty close to the original, talked to Pixar, and gave us permission to show it at the launch.

So me and our chief scientist David Kirk flew out to Tokyo for the launch. My job was to drive the demo on stage, which was somewhat nerve-wracking, as you might be able to tell from the video above. During the rehearsal one of Steve's assistants told us we might have to leave the room because he was getting upset that his slide remote control wasn't working, and we wouldn't want to see that. I got the impression this happened quite often!

Later, David and I had a brief chance to talk to Steve. From what I remember of the conversation, he mainly talked about how great the new OS X user interface was. In my youthful ignorance I jumped in and said it was pretty, but had they thought about using the graphics hardware to speed up the rendering? (It was pretty slow at the time). He said he had talked to his best engineers about this, and they told him it was impossible. There was no way they could get the quality they needed using the GPU. Anyway, a year or so later OS X did introduce a GPU accelerated UI with smoothly scaling icons etc. Coincidence? I don't think so!

We only got to show that demo once, but it was worth it, I think.

Tribute to MC Escher

2011-08-16T04:47:00.000-07:00

Another distance field ray marching experiment in WebGL. Inspired by this interesting blog post on distance estimators.

Click the button below to see the interactive version. It's a bit glitchy, but I kind of like that.

Warning - not stable on all browsers! I recommend Firefox with the "webgl.prefer_gl" and "webgl.prefer-native-gl" preferences both set to "true" (type "about:config" into the address bar and filter for "webgl"), or Chrome launched with "--use-gl=desktop" on the command line.

Update - fix for stupid WebGL shader validator.

SGI's Finest Product

2011-04-26T11:11:00.000-07:00

I worked for Silicon Graphics for a while in the late 1990s. It was a fun time, but the one thing that has stayed with me is this brilliant reversible screwdriver (part no. 9980915) which they used to include with graphics board upgrades. If SGI had any sense they would re-release this as a collectors item!

Volume Scattering Is Cool

2011-04-21T02:48:00.000-07:00

Without scattering

With scattering

A big part of the look of explosions is the very hot bright interior light being scattered (i.e. blurred) as it travels towards the eye and is attenuated by the surrounding smoke. These images are from a work-in-progress real-time explosion simulation and show the benefit of adding approximate volume scattering.

I'm using the slice-based scattering technique from the volume rendering chapter in GPU Gems 1 by Joe Kniss et. al. This is one of my favourite tricks, and is the same technique I used in the old smoke particles sample in the CUDA SDK. The main difference here is I'm always drawing the slices from back-to-front, instead of using the half-angle direction. It turns out for emissive volumes like explosions, where most of the light is from the inside,this works pretty well. It's quite a lot slower than doing ray marching in a pixel shader (lots of passes, and you're blending in the frame buffer), but I think the results are worth it.

Random Screenshot of the Week

2011-01-28T02:35:00.000-08:00

I generated this image the other day when messing around with my CUDA 2D fluid simulation code. For the technically minded, it's the magnitude of the velocity mapped to a color gradient, the velocity field has some turbulence added using curl noise. For the non-technically minded, it looks like THE BURNING FIRES OF HELL!

ShaderToy for Android

2011-01-18T13:13:00.000-08:00

At GDC last year, a little-known search engine company called Google were kind enough give me a free "Android" phone (a Motorola Droid). It turned out this was CDMA and so wasn't of much use to me as a phone in the UK, but fortunately it had a keyboard and could run OpenGL ES 2.0, so my next thought was that it would be cool to write a little app that let you edit and compile GLSL shaders directly on the phone. And this is the result.

It's not that easy editing code on a tiny keyboard, and the shader performance of the current generation of Android phones isn't great, but even so it's fun little app for messing around with shaders on the train or whatever.

It requires Android 2.2 and OpenGL ES 2.0. I've only really tested it on the Droid and my Tegra 2 devkit, so I'd be curious to hear how well it works on other devices. It's free, so you can't complain too much.

This is largely inspired by Inigo Quilez's ShaderToy, and I included some of his shaders, so all due credit to him.

To install it, search "ShaderToy" in the Android Market, or if you're reading this on your phone, just click the link above.

WebGL in a blog post

2011-01-07T09:51:00.000-08:00

I was looking for somewhere to host my WebGL shaders when I came across this post. And it actually works!

You'll need Firefox 4.0b8 with the "webgl.prefer_gl" config set to "true" for this to work.

Ray traced Google Robot in WebGL

2011-01-06T12:21:00.000-08:00

It seems like everybody is rendering with distance fields these days. I'm somewhat late to the party, but distance fields do have a lot of interesting advantages:
- you can ray-cast them very quickly using sphere tracing
- it's very easy to do CSG operations on them (union, difference etc.)
- there's a clever fast approximation to ambient occlusion (originally due to Alex Evans, I think).

My original plan was do to a real-time version of the original light cycle from Tron (which is apparently comprised of only 57 geometric primitives), but that turned out to be a bit complicated. When I saw the Google Android robot, it seemed like a more suitable target (it's very easy to calculate the distance to spheres and capsules, and you can see the result above.

Anyway, the code is below, you can paste this into Iniqo Quielz's excellent ShaderToy and play with it yourself using WebGL. (It's somewhat better commented than most of the example shaders there, too.) You'll need the latest Chrome or Firefox beta to run this, there's a good FAQ here.

// distance field ray caster
// simon green 06/01/2011
//
// based on Iniqo Quilez's:
// http://www.iquilezles.org/www/material/nvscene2008/rwwtt.pdf
// http://www.iquilezles.org/apps/shadertoy/
//
// Google Android robot:
// http://www.android.com/branding.html

#ifdef GL_ES
precision highp float;
#endif

uniform vec2 resolution;
uniform float time;

// CSG operations
float _union(float a, float b)
{
   return min(a, b);
}

float intersect(float a, float b)
{
   return max(a, b);
}

float difference(float a, float b)
{
   return max(a, -b);
}

// primitive functions
// these all return the distance to the surface from a given point

float plane(vec3 p, vec3 planeN, vec3 planePos)
{
   return dot(p - planePos, planeN);
}

float box(vec3 p, vec3 abc )
{
   vec3 di=max(abs(p)-abc, 0.0);
   //return dot(di,di);
   return length(di);
}

float sphere(vec3 p, float r)
{
   return length(p) - r;
}

// capsule in Y axis
float capsuleY(vec3 p, float r, float h)
{
   if (p.y < 0.0) {
   return length(p) - r;
   } else if (p.y > h) {
   return length(p - vec3(0, h, 0)) - r;
   } else {
   return length(vec2(p.x, p.z)) - r;
   }
}

// given segment ab and point c, computes closest point d on ab
// also returns t for the position of d, d(t) = a + t(b-a)
vec3 closestPtPointSegment(vec3 c, vec3 a, vec3 b, out float t)
{
   vec3 ab = b - a;
   // project c onto ab, computing parameterized position d(t) = a + t(b-a)
   t = dot(c - a, ab) / dot(ab, ab);
   // clamp to closest endpoint
   t = clamp(t, 0.0, 1.0);
   // compute projected position
   return a + t * ab;
}

// generic capsule
float capsule(vec3 p, vec3 a, vec3 b, float r)
{
   float t;
   vec3 c = closestPtPointSegment(p, a, b, t);
   return length(c - p) - r;
}

float cylinderY(vec3 p, float r, float h)
{
   float d = length(vec2(p.x, p.z)) - r;
   d = difference(d, plane(p, vec3(0.0, -1.0, 0.0), vec3(0.0, h, 0.0)));
   d = difference(d, plane(p, vec3(0.0, 1.0, 0.0), vec3(0.0)));
   return d;
}

// transforms
vec3 rotateX(vec3 p, float a)
{
   float sa = sin(a);
   float ca = cos(a);
   vec3 r;
   r.x = p.x;
   r.y = ca*p.y - sa*p.z;
   r.z = sa*p.y + ca*p.z;
   return r;
}

vec3 rotateY(vec3 p, float a)
{
   float sa = sin(a);
   float ca = cos(a);
   vec3 r;
   r.x = ca*p.x + sa*p.z;
   r.y = p.y;
   r.z = -sa*p.x + ca*p.z;
   return r;
}

float halfSphere(vec3 p, float r)
{
   return difference(
   sphere(p, r),
   plane(p, vec3(0.0, 1.0, 0.0), vec3(0.0)) );
}

// distance to scene
float scene(vec3 p)
{
   //return box(p, vec3(1.0, 1.0, 1.0));
   //return sphere(p, vec3(0.0), 1.0);

   float d = 1e10;

   p -= vec3(0.0, 1.0, 0.0);
   vec3 hp = rotateY(p, sin(time*0.5)*0.5);

   // head
   //d = sphere(p, 1.0);
   d = halfSphere(hp, 1.0);

   // eyes
   d = _union(d, sphere(hp - vec3(-0.3, 0.3, 0.9), 0.1));
   d = _union(d, sphere(hp - vec3(0.3, 0.3, 0.9), 0.1));

   // antenna
   d = _union(d, capsule(hp, vec3(-0.4, 0.7, 0.0), vec3(-0.75, 1.2, 0.0), 0.05));
   d = _union(d, capsule(hp, vec3(0.4, 0.7, 0.0), vec3(0.75, 1.2, 0.0), 0.05));

   // body
   d = _union(d, capsuleY((p*vec3(1.0, 4.0, 1.0) - vec3(0.0, -4.6, 0.0)), 1.0, 4.0));
   //d = _union(d, cylinderY(p - vec3(0.0, -1.1, 0.0), 1.0, 1.0));

   // arms
   //d = _union(d, capsuleY(p - vec3(-1.2, -0.9, 0.0), 0.2, 0.7));
   //d = _union(d, capsuleY(p - vec3(1.2, -0.9, 0.0), 0.2, 0.7));
   d = _union(d, capsuleY(rotateX(p, cos(time)) - vec3(-1.2, -0.9, 0.0), 0.2, 0.7));
   d = _union(d, capsuleY(rotateX(p, sin(time)) - vec3(1.2, -0.9, 0.0), 0.2, 0.7));

   // legs
   d = _union(d, capsuleY(p - vec3(-0.4, -1.8, 0.0), 0.2, 0.5));
   d = _union(d, capsuleY(p - vec3(0.4, -1.8, 0.0), 0.2, 0.5));

   // floor
   p += vec3(0.0, 1.0, 0.0);
   d = _union(d, plane(p, vec3(0.0, 1.0, 0.0), vec3(0.0, -1.0, 0.0)));

   return d;
}

// calculate scene normal
vec3 sceneNormal( in vec3 pos )
{
   float eps = 0.0001;
   vec3 n;
   n.x = scene( vec3(pos.x+eps, pos.y, pos.z) ) - scene( vec3(pos.x-eps, pos.y, pos.z) );
   n.y = scene( vec3(pos.x, pos.y+eps, pos.z) ) - scene( vec3(pos.x, pos.y-eps, pos.z) );
   n.z = scene( vec3(pos.x, pos.y, pos.z+eps) ) - scene( vec3(pos.x, pos.y, pos.z-eps) );
   return normalize(n);
}

// ambient occlusion approximation
float ambientOcclusion(vec3 p, vec3 n)
{
   const int steps = 3;
   const float delta = 0.5;

   float a = 0.0;
   float weight = 1.0;
   for(int i=1; i<=steps; i++) {
   float d = (float(i) / float(steps)) * delta;
   a += weight*(d - scene(p + n*d));
   weight *= 0.5;
   }
   return clamp(1.0 - a, 0.0, 1.0);
}

void main(void)
{
   vec2 pixel = -1.0 + 2.0 * gl_FragCoord.xy / resolution.xy;

   // compute ray origin and direction
   float asp = resolution.x / resolution.y;
   vec3 rd = normalize(vec3(asp*pixel.x, pixel.y, -2.0));
   vec3 ro = vec3(0.0, 0.5, 4.5);

   float a = time*0.5;
   //rd = rotateY(rd, a);
   //ro = rotateY(ro, a);

   float t = 1.0;
   bool hit = false;
   vec3 pos;

   // cast ray (sphere tracing)
   for(int i=0; i<64; i++)
   {
   pos = ro + t*rd;
   float d = scene(pos);
   if (d < 0.01) {
   hit = true;
   break;
   }
   t += d;
   }

   // shade
   vec3 rgb;
   if(hit)
   {
   // calc normal
   vec3 n = sceneNormal(pos);

   // lighting
   const vec3 lightPos = vec3(5.0, 10.0, 5.0);
   const vec3 color = vec3(0.643, 0.776, 0.223);
   const float shininess = 100.0;

   vec3 l = normalize(lightPos - pos);
   vec3 v = normalize(ro - pos);
   vec3 h = normalize(v + l);
   float diff = dot(n, l);
   float spec = max(0.0, pow(dot(n, h), shininess)) * float(diff > 0.0);
   //diff = max(0.0, diff);
   diff = 0.5+0.5*diff;

   float fresnel = pow(1.0 - dot(n, v), 5.0);
   float ao = ambientOcclusion(pos, n);

   rgb = vec3(diff*ao) * color + vec3(spec + fresnel*0.5);
   //rgb = vec3(ao);
   //rgb = vec3(fresnel);

   } else {
   rgb = mix(vec3(1.0), vec3(0.0), rd.y);
   }

   // vignetting
   rgb *= 0.5+0.5*smoothstep(2.0, 0.5, dot(pixel, pixel));

   gl_FragColor=vec4(rgb, 1.0);
}

Random screen shot of the day

2010-11-17T05:21:00.000-08:00

I realised that I haven't been posting much here recently, so I decided to post some of the random images that are sitting around on my hard drive gathering dust. These are from a 2D CUDA fire simulation which I submitted as a talk to Siggraph this year, but was cruely rejected. I'm still sulking about this, but I guess I shouldn't feel too bad since we were up against ILM, Dreamworks and DNeg, none of whom are exactly amateurs in the simulation department. The technique is based on Chris Horvath and Willi Geiger's excellent paper from Siggraph 2009. In my opinion one of the most interesting contributions of this paper is its use of a noise texture which is advected (i.e. moved) by the velocity field, and used to add detail to the rendering and simulation. The simulation code is based on Mark Harris's chapter from GPU Gems 1, and he helped optimizing the CUDA solver. The idea was to use this to replace those obviously repeating animated fire sprites you see in many games these days - you would run a bunch of small independent simulations on the GPU and display them on billboards. Anyway, hopefully someday soon I'll finish this up and release the code!

Digital Splash Paintings

2010-03-19T03:47:00.000-07:00

As part of my work on fluid simulation I've been experimenting with methods to make fluid leave marks on the environment as it moves. As an offshoot of this work, I thought it would be fun to try generating some Jackson Pollock style splash paintings. Here are the results, generated by my GPU fluid simulator. I'll post more pictures on flickr as I generate them. While not great artistically, it's satisfying to me how close to real paint these look. This whole thing may seem slightly pointless to some (why not use actual frickin' paint and paper?!), but doing this in the digital domain does offer some interesting non-realistic possibilities, such as paint that changes colour based on its velocity etc. Next step - submit to pretentious art gallery ("it's done on a computer, see?"). Step two, profit.

How to Scan 35mm Slides Using a Flat-bed Scanner And an iPod As a Backlight

2010-01-10T10:59:00.001-08:00

I had a few old 35mm slides I wanted to scan this weekend. Not wanting to shell out for a dedicated slide scanner, it seemed like I should be able to use my flat-bed scanner instead. It turns out there are a couple of problems with this. First of all, these kind of scanners are designed to scan images that are flat on the glass, and so mounted slides (which are offset slightly from the glass) appear very out of focus. This is easily fixed by removing the slide from the mount and putting on the glass directly. The second, more serious problem is that the scanner is designed to measure light reflected from paper, where as slides are meant to illuminated from the back (transmissive), so they usually turn out much too dark in the scan. Searching for answer, I found this link, where someone has built a simple backlight out of paper that attempts to reflect light from the scanner around the back of the slide. Unfortunately this didn't work for me, probably because my Canon Lide scanner uses LEDs for illumination. So instead I had the idea to use my iPod, displaying a pure white image, as a backlight. This works amazingly well. The iPod screen fits flush on the glass, and you can change the display brightness to adjust the exposure. Sadly it only works in black and white, because the white light interferes with the R/G/B illumination of the scanner, but the results are still pretty good (see above).

Adventures in Rapid Prototyping

2010-01-05T08:25:00.000-08:00

Happy New Year! A slight change from our usual subject matter here. I had a bit of free time over the holidays, so I decided to try out this 3D printing technology all the cool kids are talking about. I had visited the Shapeways booth at Siggraph, and was impressed with their sample models, so I decided to try out their service (they're based in the Netherlands, so they're pretty convenient for here in the U.K.). Not having a huge amount of modelling skills, I chose to try and recreate Kay Bojesen's classic monkey sculpture, which has the advantage of being mainly constructed out of geometric cylinders and spheres! The trickiest part is that you have to provide them with a polygon mesh which is completely water-tight and manifold, which is easier said than done in Maya. Anyway, the results can be seen above. It turned out amazingly well, you can see a bit of stair-stepping (physical aliasing?) but every tiny detail is visible (I kind of wish I'd smoothed the mesh more). The material is surprisingly hard and has a rough finish. I would recommend Shapeways' service, although it's a little expensive - this little guy was $15. They also have an amazing new stainless steel material which would be fun to try out with a smaller model.

2012 == Fluid

2009-11-17T01:16:00.000-08:00

Went to see 2012 this weekend. Stupid film, but some great fluid simulations! Pretty much the whole thing is people being chased by natural phenomena. But where else can you see Danny Glover (playing the least convincing American president ever) get hit by an aircraft carrier being carried on a giant tidal wave?

Real time Toy Story 3D?

2009-10-01T10:01:00.000-07:00

As the first all-CG movie, Pixar's Toy Story has always been something of an aspirational target for real-time graphics. When NVIDIA launched the GeForce 2 back in 2000, Jen-Hsun Huang said it was a "major step" towards achieving "Pixar-level animation" in real-time. This may have been overstating things a bit, and it elicited the following hilarious response from Pixar's Tom Duff on the comp.graphics.rendering.renderman newgroup:

"These guys just have no idea what goes into `Pixar-level animation.' (That's not quite fair, their engineers do, they come and visit all the time. But their managers and marketing monkeys haven't a clue, or possibly just think that you don't.)

`Pixar-level animation' runs about 8 hundred thousand times slower than real-time on our renderfarm cpus. (I'm guessing. There's about 1000 cpus in the renderfarm and I guess we could produce all the frames in TS2 in about 50 days of renderfarm time. That comes to 1.2 million cpu hours for a 1.5 hour movie. That lags real time by a factor of 800,000.)

Do you really believe that their toy is a million times faster than one of the cpus on our Ultra Sparc servers? What's the chance that we wouldn't put one of these babies on every desk in the building? They cost a couple of hundred bucks, right? Why hasn't NVIDIA tried to give us a carton of these things? -- think of the publicity milage they could get out of it!

Don't forget that the scene descriptions of TS2 frames average between 500MB and 1GB. The data rate required to read the data in real time is at least 96Gb/sec. Think your AGP port can do that? Think again. 96 Gb/sec means that if they clock data in at 250 MHz, they need a bus 384 bits wide. NBL!

At Moore's Law-like rates (a factor of 10 in 5 years), even if the hardware they have today is 80 times more powerful than what we use now, it will take them 20 years before they can do the frames we do today in real time. And 20 years from now, Pixar won't be even remotely interested in TS2-level images, and I'll be retired, sitting on the front porch and picking my banjo, laughing at the same press release, recycled by NVIDIA's heirs and assigns. " Well, it's only 10 years later, and I have no idea if Tom is sitting on his porch yet, but our "toys" are certainly getting closer to achieving this. 500MB of data per frame doesn't sound unreasonable these days. Anyway, I was reminded about all this by the recent re-release of Toy Story in 3D, and this news story that claims when they re-rendered it, it took less than 1/24th of a second per frame: "The process of rendering the films — or translating computer data into images — was vastly accelerated by current technology. Where the original “Toy Story” required an hour per frame to create, Mr. Lasseter said, rendering the new 3-D version took less than 1/24th of a second per frame.— Disney Seeks Buzz With ‘Toy Story’ Re-Release, The Wall Street Journal, September 4, 2009" So maybe we can already render Toy Story in realtime, given a big enough render farm. It's impressive how far we've all come.

New fluid simulation video posted

2009-10-01T09:28:00.001-07:00

On YouTube here. The main improvements here are that it's been optimized (so we can do 128K particles with SPH at 70fps now), and includes surface tension effects so you get nice droplets and splashes. It also includes some improvements to our screen-space surface rendering technique (thanks to Rouslan Dimitrov for helping with this). Can't wait to see this running on Fermi. Stop me if you're getting bored of these...

Siggraph 2009 papers

2009-05-07T07:53:00.000-07:00

The official lists haven't been posted yet, but as usual Ke-Sen Huang is maintaining a list of accepted papers at Siggraph 2009: http://kesen.huang.googlepages.com/sig2009.html Only a few PDFs are available - there are a few interesting sounding titles (I dig Energy-Preserving Integrators for Fluid Animation, for example), but so far it seems like the reviewing panel has really excelled themselves this year in accepting mathematically interesting but so-far-from-being-practical-it's-not-even-funny papers! Or maybe I'm just getting old and miserable.

GDC 09: Cool new fluid simulation demo

2009-03-24T09:00:00.000-07:00

NVIDIA just released video of a very impressive new fluid simulation demo. It uses a grid-based fluid simulation running on CUDA (written by Jonathan Cohen) that translates and interacts with the car, and is used to advect about 0.5 million particles which are rendered with volumetric shadows. It's running on two GeForce GTX 280s, one running the simulation, and one doing the rendering (but it's scalable). It's amazing to me that this kind of thing was only possible offline only a few years ago, and is now running in real-time.

GDC Direct3D Tutorial Slides Posted

2009-03-16T10:32:00.000-07:00

The GDC organizers have made the unusual move of publishing slides from some of the tutorial sessions ahead of the actual conference. You can find them here, but I think it it's still worth attending the tutorials for all the extra details.

GDC 2009

2009-02-26T03:16:00.000-08:00

I have to say that I've never been a huge fan of the Game Developers Conference. It's massively over-priced (if you're unfortunate enough to have to pay), often poorly organized, and on the whole the quality of the technical presentations (including my own) is somewhere between a high school science fair and an Asperger's syndrome help group. It ain't no Siggraph, that's for sure. At least they moved it from the incredibly dull San Jose to San Francisco, where they have such luxuries as bars that stay open past 10pm. GDC's only saving grace is that everyone in the games industry goes there, so it's a great place to network and meet people (read: find a new job). All that said, I'll be there this year, and there are a few talks that look interesting: Advanced Visual Effects with Direct3D for PC - learn about the latest developments in Direct3D, and see AMD and NVIDIA make snide digs at each other under their breath. Math for Programmers/Physics for Programmers - these guys know their physics. Takahiro Harada (who shares my love of simulating colliding balls and now works at Havok) and Erwin Coumans (of Bullet fame) will be talking about implementing rigid body physics on CUDA/OpenCL, Cell SPU and Larrabee, which should be interesting (especially given how different these 3 architectures are). Mixed Resolution Rendering - sounds like Jeremy is really into cross-bilateral filtering. Rasterization on Larrabee: A First Look at the Larrabee New Instructions (LRBni) in Action - apparently Intel have some kind of new CPU that's meant to do graphics and this talk is about some new variant of MMX it has. Michael Abrash is something of a legend and always an entertaining speaker. The Rendering Technology of KILLZONE 2 - this game looks great, and it's always interesting to hear from developers who have managed to get the PS3 to do something impressive. Anyway, I should probably do some work now, see you there!

Interview with NVIDIA's Jensen Huang (and some books)

2009-01-30T07:19:00.000-08:00

I just came across this entertaining interview with Jensen Huang. I particularly love this quote: "Q: Jeffrey Katzenberg is giving effusive testimonials for Intel’s Larrabee graphics chip. A: You and I don’t know what Larrabee can do. It doesn’t exist. If you pay for Katzenberg’s compute farm, he will tell you your lawnmower is great for making movies. " The interview was done by Dean Takahashi, who also wrote the book "Opening the Xbox: Inside Microsoft's Plan to Unleash an Entertainment Revolution", which I only recommend if you're really into games consoles and high-tech folklore. While we're on the subject of nerd books, I also just read "The Race for a New Game Machine: Creating the Chips Inside the XBox 360 and the Playstation 3", which all about the IBM/Sony/Toshiba project to develop the Cell processor. It's no "The Soul of a New Machine" (which the authors credit in the intro), and it doesn't really cover the subsequent total lack of success of Cell outside the PS3, but it's somewhat interesting if you're into chip design. It also reads like their publishers tried to turn it into a management book half way through, which is a shame.

Visual Adrenaline

2009-01-15T04:02:00.000-08:00

I just love Intel's "Visual Adrenaline" magazine. It's such an unabashed marketing vehicle! This month there's a real treat in the form of a article by Daniel Pohl on his new ray traced version of the game Quake Wars. It was this paragraph at the beginning that really got my goat (my emphasis): "Today’s games all use a rendering technique called rasterization. Rasterization requires difficult programming work and as many special effects (such as shadows or reflections) need to be calculated as approximations over multiple rendering passes and are often stored in resolution-limited textures in between." (sic) Now, don't get me wrong, I love ray tracing, and I think that soon (like in the off-line rendering world) real-time graphics will probably converge to a hybrid model that uses rasterization with ray-tracing effects where they make sense. But to claim that rasterization requires "difficult programming work" and is any more of an approximation than ray tracing is just misleading. Rendering is all an approximation, and real-time rendering is more approximate than most. Sure, it's easier to to do hard edged shadows using ray tracing, just shoot another ray, but start adding soft shadows and you might start wishing you had a shadow map to blur. And what about the "difficult programming work" and run-time cost of constructing the spatial data structures which are essential to make ray-tracing perform decently? Ray tracing advocates too often ignore this. He then actually goes on to discuss in detail how badly ray tracing handles the alpha-tested trees in the game because of the thread divergence this causes. He says: "Another advantage of using a ray tracer for partially transparent objects is that they don’t need to be sorted by their depth" Err, I believe the trees in Quake Wars are rendered using alpha-to-coverage, so no sorting is necessary. (Addendum: you could also argue that ray tracing is also essentially doing a sort by traversing a spatial data structure of the scene and returning the closest hit.) The final icing on the cake is the image above, which is supposed to show ray-traced refraction, but as far as I can tell doesn't actually show the back faces of the dome and thus spectacularly fails to demonstrate an actual benefit of ray tracing!

Volumetric Particle Shadowing

2009-01-07T05:14:00.000-08:00

This has been available for a while in the CUDA 2.1 SDK beta download, but since the PDF isn't on the web yet it hasn't had much exposure, so I thought I'd post something about it here. It's a very simple technique which is based on an old volume rendering trick by Joe Kniss, but it can achieve some great looking results. The basic idea is to that instead of sorting the particles in back-to-front or front-to-back order, you sort them along a vector half way between the view and light directions. You then render the particles in batches, accumulating the shadows to a 2D texture as you go. You can even add some blur to simulate scattering. Details are in the PDF (fixed link). Oh, and there's a short movie here.

Screen Space Fluid Rendering with Curvature Flow

2009-01-07T05:05:00.000-08:00

Our paper "Screen Space Fluid Rendering with Curvature Flow" is now available to download here.

I3D 2009 papers online

2009-01-07T05:01:00.000-08:00

The always reliable Ke-Sen Huang has posted a list of the available papers from I3D 2009, although quite a few are missing at this point.

Siggraph 2007 papers available

2007-05-18T05:46:00.000-07:00

Most of this year's Siggraph papers are online now, why actually go to the conference? I particularly like the curl noise one.