Archive for May, 2007

The Cave Troll; Photorealism on the GPU; “Cali”

Friday, May 4th, 2007

I haven’t posted in a while, so my current work is shrouded in mystery.

First off, a quick update on last term: I’ve produced a procedural city/garden generator in Houdini, but I don’t have screenshots here. I will post some up the next time I’m at Uni. Also, there was the infamous GLSL demo, which I’m moderately pleased with and has inspired me with regards to my major project this year. More on that in a moment. If you have a GeForce 6800 or above, please do check that out! It’s quite basic compared to a lot of stuff out there right now, but I’m still pleased with it as I managed to cobble it together in five or six weeks.

Last term also saw the end of the Cave Troll. Now, while I’m pleased with a lot of the features that were incorporated into the project, it seems that fate conspired against us to ensure that everything that could go wrong went wrong. However, I was responsible for the lighting and Maya to RenderMan pipeline, and both of those things worked out a treat. You can see a copy of the presentation slides for details on how the median cut algorithm works, and also details on the RIB exporter. There is a dodgy video showing how the ambient light maps onto a sphere. I may write a new page on these tools soon.

The reason I’m so annoyed with the project is that the mocap data that we were so proud of was completely unusable. Malcolm, our only animator, used XSI to hand-animate the troll using the mocap video as a reference, but then we couldn’t get our animation from XSI to Maya. Given the remaining time, Malc had to learn Maya in two weeks and animate from scratch. He deserves a medal for that, to be honest.

The muscle system was developed by Johannes, but unfortunately he was stuck in Germany when it came to actually applying the muscles to the troll. I had to botch the job in the last week and wasn’t able to tweak it, so if you want a laugh watch the belly of the troll very carefully as he runs…

The main topic I wanted to cover in this entry is photorealistic rendering using a graphics card. As John Carmack said in his 2004 Quakecon speech, it won’t be long until we start seeing low budget visual effects studios switching to a more affordable and faster method for rendering C.G. scenes. With games companies producing stuff like Gears of War, that day is getting closer and closer. This is currently what I’m looking to investigate, and I’m planning to write a RenderMan compliant GPU-based renderer (codenamed “Calistos”, or just “Cali”) over the coming months.

However, there are a number of things that clearly make offline rendering superior to rendering on a GPU, and these need to be resolved somehow in order to produce better results. The first thing that I notice every time I look at games is the terrible, terrible aliasing. Frankly the antialiasing on current hardware is dire, and that really need to be improved. Even at 8x, it still looks pretty bad. I’m looking forward to the day when hardware has in-built 16x anti-aliasing at decent rates.

Another thing I don’t like is the texture filtering. It can be fine in a lot of cases, and mipmapping certainly helps to reduce aliasing on distant textures. However, the closer you get the more a texture looks bad, and the only way to solve this is to use a very high resolution texture. In an offline renderer you can have a texture any size you like, but on a GPU you’re limited to 128MB or less in most cases. For the cave troll, we had a 32-bit floating point displacement map that was 4096 pixels square and took up 100MB of disk space. That’s certainly not going to be viable on a GPU in any circumstances.

There are some things that the GPU does as well as offline rendering or better. For example its a hell of a lot faster to rasterise than to raytrace or even use a REYES algorithm. Fragment shaders are pretty damn good at doing most of the post-process effects that are used in offline rendering, and doing them better in a lot of cases. There are still times when precision becomes a problem, but unclamped floating point pixelbuffers make this a non-issue most of the time. Finally, with the advent of GLSL, Shader Model 3 and OpenGL 2.0, things are becoming a lot more flexible. I don’t know what the instruction limit is for shaders these days, and I make a point of not looking. However, I’ve written some pretty nasty shaders over the last few weeks and the card has just done its job with no complaints.

I shall report back in a few weeks with news on Cali’s development, and hopefully some screenshots.

  • View Peter J. B. Lewis's profile on LinkedIn
  • Journal Categories

  • Meta