Skin Rendering: Work in Progress

After my last post, I was like hey, it's winter break - why don't I do skin rendering now. I've decided to post my current progress. Still needs a lot of work, but it isn't too terrible:

Unity's giving me a lot of grief with texture-space diffusion and linear space lighting calculations. But hopefully things will only improve from here! I have a feeling this might become one of my longterm goof around projects like Bioshock Pinball was.

An overview of Real-Time Skin Rendering

I recently gave a 15 minute presentation about Real-Time Skin Rendering for my Advanced Graphics Course and I thought maybe I would write up some of the significant bits here. First and foremost this talk was based off of information from 2 sources: Eugene d'Eon and David Luebke's article in GPU Gems 3 about their work on the Human Head Demo, and John Hable's course notes from his presentation on Character Lighting and Shading at Siggraph 2010. Note that all the images in this post are from Hable's presentation.

Skin rendering is notable primarily for the challenges of replicating the subsurface scattering found in human skin. This subsurface scattering creates a vibrant glow of sorts in the diffuse component of the skin, and without it the skin can appear dry and unnatural.

Here's a shot from Hable's presentation of skin rendered with standard Blinn-Phong shading model:

An important comment that Hable makes in his presentation is that the input mesh is very high detail with high detail diffuse color and bump textures, and although the skin appears too rough in the Blinn-Phong model, blurring those is a hack and not a good solution. Rather, modeling subsurface will smooth a lot of the rough feeling in a much more vibrant manner.

NVIDIA calculates subsurface scattering by blurring the irradiance texture that has the diffuse component for the skin. The irradiance texture is split into multiple Gaussians, and then these are blended together to create the final irradiance result.

Here's a shot of the same model and lighting conditions using NVIDIA's approach:

Definitely a huge improvement here. But it comes with the price of a lot of texture reads and writes. In a game that can be a lot for skin rendering on multiple characters. Hable presents the alternatives that Naughty Dog examined to try to find a good middle ground between cost and performance. A single 12-tap blur is used in place of the sum of gaussians for cut scenes in Uncharted 2. Here's what it looks like (the differences are subtle):

I'm not going to go into much detail about the approach that Naughty Dog used during gameplay for Uncharted 2, because it ditches the blurs altogether and uses an approximation created by pretending that the normals for each color channel are bent. It's better than the straight diffuse, and as Hable points out, good enough for a game where most of the time the player only sees the skin on the back of Drake's neck if they're not in a cut scene. Here's a shot of the Blended Normals approach:

This post definitely only skims the surface of real-time skin rendering, and I definitely recommend checking out the NVIDIA article and Hable's presentation if you are thinking of implementing specialized skin shaders. Hopefully sometime in the future I'll be able to find the time to try my own hand at it.

A Perfect Game?

I don't write about design so much as of late, but I decided to partly because of the impact a game made on me over thanksgiving break and the brainstorming I've been doing to come up with an idea to pitch to my class at the beginning of next semester (due on the first day of class, crazy right?).

So this game that made such a huge impression on me: Braid. A little late to the game on my part, because I had only heard good things about it... but I had trouble finding myself in the mood to seriously sit down and play a 2D platformer, but when I did, Braid just blew me away. And the reason is that Jonathan Blow sat down and made what I would be tempted to call a perfect game. Maybe not my favorite game of all time, or even the best game, but a perfect game. The reason that I say perfect is because Braid is a complete game. Something that developers I think have learned to think of as impossible because no matter what it's got to ship on time, right?

Wrong. Chris Hecker had a very interesting rant about this at GDC entitled "Please Finish Your Game" that uses Braid as one its core examples. Braid is a finished game, and to me that's very important, because that means that Braid can convey its ideas in much the same way that a good piece of literature can.

But what makes Braid feel like a game that's been completed? It's partly because there are a set of underlying concepts, messages, and themes that drive the games purpose for existence to be something other than end of quarter profits. That's just the first step though. The second is that from these ideas came mechanics and puzzles that complement those ideas. These core elements of the gameplay are accompanied by art, pieces of writing, and music that all fits with what is happening. and part of it is that I understand is that Jonathan Blow had time to go through and polish the gameplay multiple times while his artist iterated over an art direction several times. As a result the game stands as a testament to what a game that wants to be called "art" should actually be striving for- it should be something that conveys its underlying message from every angle you examine it from.

Nothing is without purpose in the game. I was recently asked at a party what type of games I want to make after I graduate. That's the type of game I want to make. But I don't want to make them after I graduate. I want to make them now.

Advanced Graphics Final Project: Motion Blur

For part of my final project in CSE 872: Advanced Graphics, I did a variety of implementations of Real-Time Motion Blur. It was a fun project, and this blog might see me post more implementations in the future (I've been playing around with a velocity buffer based one), but for now:

Technique 1: An Accumulation Buffer

This is a really easy technique that essentially is just the averaging together of several frames, causing motion from dynamic objects and camera motion to become blurred. The reality is that is really just impractical, but converges to a correct solution if a small enough time step and enough samples are used. But in a real-time implementation, this will almost never be feasible. As a result, under-sampling known as "ghosting" can be seen. Check out this shot from my project:

Technique 2: Motion Blur as a Post Process

This is a technique presented in the excellent GPU Gems 3, where world space positions are reconstructed from the depth buffer during post processing. The difference between the current frame's position and the previous frame's position will produce a velocity vector that can then be used to blur the image. However, this technique only works for static geometry (camera motion), but the results are good:

Technique 3: Just Fake It with a Radial Blur already

This one I actually used in a game project recently that I will probably be posting about in the near future. This is something that Real-Time Rendering points out about Assassin's Creed- the effectiveness of a simple radial blur looks very favorable for certain instances of forward motion. We use it for the boos functionality on the vehicle in my game, and Assassin's Creed uses it for chase sequences. Here's a shot of my demo scene:

So that sums up my current round of motion blur techniques for my final. I might talk about the Depth of Field component of my project, but then again maybe not.

Next Semester: Enter Teaching Assistant

So I'm taking a break from my most recent project (which I'll be posting about soon I promise) to write a little post on something I'm doing this spring. I will be a TA for the Digital Game Design class at Michigan State, the first class that students take in our Game Development Specialization.

This is really exciting to me for a variety of reasons:

• I like helping people make games. Its awesome to help someone learn the technical aspects in game development so that they can craft interesting experiences. Art games anyone? (hint: go play pOnd)
• I know that by helping others, I am helping my development community in an important way. When I was a freshman, I worked with several seniors on game projects and game jams. They helped me every step of the way and it's the only reason I'm where I'm at today.
• Maybe I can help people not write such terrible code. Us programmers are supposed to be the enablers right? Aras had some really good points in a recent presentation.

Unite 2010 round-up

I've been in Montreal all week for Unite 2010 and I figured I post up my thought on the conference now that things are winding down as we wait for our flight back to the states. In short summary - the conference was awesome, for something that is substantially cheaper than the spring's GDC festivities, the quality of sessions was superb.

Some highlights of the week were:

• Tools: Lots of talk about developers simplifying their workflow and empowering their artists/designers by writing custom tools with Unity's great flexibility. Adam Mechtley = genius editor tools, best hope his recorded talks get posted.
• New breadth of platforms: Unity Technologies is trying to become all encompassing, now spreading to support for Windows, Mac, Web Player, iPhone, Android, 360, PS3, and Wii. The demo of the PS3 version looked like it was very easy to use.
• Unity Asset Store means that Unity Tech now also includes people that make middleware for middleware in their target consumer base.
• Great Conference party hosted by Unity Tech on Thursday. Open bar = win.
• David Helgason's collar was, as usual, popped straighter than god.

What makes games look good?

After several rounds of seeing games in my game development portfolio class, I;ve begun to ask myself why do so many of the games struggle to achieve an acceptable level if visual quality. As a graphics programmer this is something that concerns me greatly because often times our purpose is to facillitate the best looking game possible. So why then do many student projects fail to achieve a professional level quality in their aesthetic?

It would be simple enough to argue that academic programs with a smaller pool of artists will be the driving factor behind poor game aesthetics. I think the issue goes a lot deeper than this for a couple of reasons, but having a stronger artist community will indirectly be associated with better looking games. The reason I think this is that it takes a large slice of the team to make a visually pleasing game. Programmers need to have good animation controllers and neccessary shaders, artists need quality textures and animation, and designers need to create levels that allow players to take in the aesthetics of the game properly.

So in the end, I almost feel like the greatest obstacle to good looking student games is a general lack of caring, which almost seems a little harsh. However, I think students too readily cave to only just scraping by with their games for class. This is why a strong artist community will have a strong impact, because not only will artists have better resourcces and expectations for their artwork, but they will also know when their programmers and designers are screwing them over.

All in all, I hope to see more good looking student games in the future.

New Project: Motion Blur + Depth of Field

Before the end of the semester, I have to complete a final project for my Advanced Graphics class, and I picked the topic earlier this week. I'm going to be focusing on doing implementations of Motion Blur and Depth of Field. The plan is to do at least two different implementations of Motion Blur, one focused on the version in GPU Gems 3 and the other implementing the accumulation buffer method, where previous frames are averaged together.

I haven't entirely decided how I'm going to implement Depth of Field. There's one good article also residing in my ever mentioned GPU Gems 3, but I haven't looked at too many other methods yet. More on that later :)

Half-baked State Machines: Living with Regret

So I feel like programmers sometimes look at system that needs to be stratified into a state machine, and they ask themselves a very dangerous question "Do I really need to make this all that robust?" The answer should usually be STFU and write a decent state machine. I've had to deal with a state machine built on a switch statement that has now grown to over 2500 lines, which is the players character controller, and I want to smack the code's original author for giving me such a bee's nest to inherit.

Even with this most unfortunate experience under my belt, I still looked at a simple AI that I needed to write for my latest project, and thought "I bet I could get away with just a switch statement." In the end this is by and large a failure on my part, because even though the state machine get's the job done, I'm going to have to rewrite it if we decide to expand the scope of the game beyond the 4 weeks its currently set at.

Things that are important for any state machine:

1) Calling the active states update function each frame (or however frequent the state machine is supposed to act)

2) Letting the active state know when it is being exited

3) Informing the new active state that has just been entered

Anything that does not incorporate all 3 of these in a smooth and coherent manner can rapidly become a headache. This should be commons sense, but I've caught myself and another programmer falling into the same trap with this... So I figured it might be worth ranting about.

Mansion

I'm currently working on a game tentatively called mansion about a boy with a flashlight. I've got some very cool technical things going on in it that I will hopefully be discussing here in the future. In the mean time here's a tools screen shot of one of the prototype levels that has been set up. I've got some fancy gizmos showing some important information that my rendering system uses:

The game will be 2.5D and I hope that it turns out well enough that the team feels like working on it beyond our current 4-week scope. Its got that cool "indie" feel that makes me want to sink some deeper themes into the game.

Software Rasterizer

I'm currently taking the grad level graphics course at MSU. One thing that's really cool about the class is that for the first project we implemented a rasterizer in software. Unfortunately, I totally lost half my work when my computer died 24 hours before the deadline, this resulted in me staying up until 4 am finishing the project, and you know - I wouldn't want it any other way.

Check out me rasterized teapot:

In the next several weeks I'll be expanding this to utilize a camera and Phong shading. I'll post the results (assuming it goes well).

A Glorious Return and a word on Optimism

So apparently I think it might be good to start talking to the wonderful abyss of the internet again, here in my dorm room at 2 AM. To be honest I wish I hadn't stopped, but maybe it took Meaningful Play last week to get my ass back into gear. I've missed out on giving everyone the lowdown on the awesomeness that was GDC 2010, as well as any discussion of games about squirrels, sheep, or minotaurs (significant parts of my endeavors since I disappeared from this blog).

I think maybe I had the urge to blog again because something is distressing me about the discussions I've had with designers hear at MSU after Meaningful Play. They're opposed to the guy that advocates games striving to be artwork. Few things have weirded me out more than design students, who I always picture as being overly optimistic about game design, being opposed to games as art. Maybe I'm being naive, but I'd like to think that aspiring game designers want to make games that have meaning, not "entertainment that is consumed much the same as a Coke." I know I'm still trying to be optimistic enough to think that there's potential for great art in game design.

It's Official!

We won the Ford Project, which means that myself and several other members of Spartasoft will be flown out to GDC by Ford Credit to attend the conference and present our game on the Expo floor. Which, needless to say, is really exciting. I've updated my portfolio to include a short description of the project and my contributions, as well as a link to the beta version that is hosted on Spartasoft's website.

Ford Project

Monday was an exciting for me and several of my fellow Spartasoft members, as we presented a game to Ford Credit that we've been developing for three months now. We were in direct competition with a team from University of Michigan's Wolverinesoft. All in all, I'm happy with the outcome of the project, even though Flash development does not tie strongly into my long term goals, because 3D is definitely where my hearts at. We find out next week if Ford Credit has decided to use our game or Wolverinesoft's game, and the suspense is killing me!