Morph targets and a disembodied head

It's been a while since I posted something for you to play with.

Well, here you go.

It will take a minute to load (lots of stuff to calculate). Once it does, just play around with the sliders to customize the guy's face. You can click and drag on his face to turn him around. Cool, huh?

Unfortunately, I can't say that I whipped this up after Thanksgiving dinner. Actually I've been working on it for a week or so, trying out different methods of achieving what I wanted -- and some methods of getting nowhere close. Actually, this version is the most complex one I did. The fact that it works is reason enough to post it.

How it works
Now the thrilling explanation. One of the features that Unity lacks at the moment is the ability to handle morph targets (aka blend shapes) imported from 3D tools like Maya or Cheetah. So, the only way to implement them is to code a system by hand. After scouring the Unity forums, I found a script that would handle simple mesh morphs but didn't do anything as complex as multiple blended attributes.

Using the basics of that script, I manged to put together a system that works pretty well. Here's the basic flow of things:

• To set everything up, I assign the base mesh (3D shape) in Unity, then create a list of attributes that I want to adjust. Each attribute has a reference mesh created by editing the original mesh to get the most extreme version of each facial attribute.
• When the scene loads, it first stores several pieces of information (this is why it takes a while to load):
  • For each attribute (24 of them in this scene), it builds a list of vertices in the mesh that are affected by that attribute.
  • At the same time it builds a list of offset vectors for each vertex affected by each attribute. This information stores the maximum possible offset for each vertex per attribute. Lots of data building up here...
  • Then we build a list of which attributes affect each vertex. This is the converse of the first list above, and it's necessary to keep the code running smoothly.
• After all that data has been stored, the default mesh loads along with a bunch of sliders to control the various attributes.
• Each time a slider is adjusted, we calculate the proper amount to adjust each vertex affected by that attribute. This is done by using a weighted average of all the attributes affecting each vertex in question. By using a weighted average, we can combine attributes like the width and height of the eyes without getting conflicts (this part took me forever to figure out).
• Once we have the right offset vectors, we adjust the affected vertices by those values and redraw the mesh. Voila!

Optimization
Because there's so much manipulation of individual vertices in this code, it was really hard to optimize. I spent almost the entire day trying to get it to run at an acceptable speed, and I still don't think it's good enough. The main problem is that when a vertex (or group of vertices) is affected by multiple attributes at once, the weighted average becomes harder to figure out and requires more processing juice. I attempted to store offset values rather than recalculating the average every time a vertex is affected, but I couldn't figure it out before dinner. This version runs well enough, so it will have to do.

Oh, and happy (late) Thanksgiving!

EDIT: I posted a new version of the file after getting some serious optimization help from Jamie. It still takes a while to start up (but not as long), and it runs considerably faster once it loads. My code now also morphs the normals as well as the vertex positions, which I had overlooked before.

Seamless tiling terrain, in pieces

I've still been working away on several things since my last post, but most of the sweat has gone into correcting a few issues with the looping terrain I linked a couple weeks ago. I'm happy to report that I've finally fixed the two things that were driving me crazy:

• Published versions of the file were strangely not rendering the main instance of the terrain from certain angles. Something about it was not working nicely with the camera. I never figured out why the problem was happening, but I did manage to work around it.
• It was painfully obvious where the seams were between tiles. The cause for this was pretty obvious as well: While the vertices lined up perfectly on the edges of the terrain tile, the normals did not, which made light react differently to two vertices located in the same place along the edges. Unfortunately it took way too long to fix the problem. In the end, very little code was involved (which is not to say that I didn't write a lot of unnecessary code along the way), but I used quite a bit of scratch paper trying to figure out how to access normals on the mesh's borders.

Anyway, check out the new, improved version.

But wait, there's more! I also developed a system to generate floor tiles around you as you walk. This means you could walk forever in any direction, and there will always be something to walk on. By itself this isn't terribly interesting, as you can see. Still, the possibilities are pretty cool. If I could generate random terrains a little more quickly, I could generate a truly endless, randomly generated terrain.

Or, even better, I could create any number of seamless terrain meshes and load them in as necessary around the player a la World of Warcraft. I would just need to store a master grid of terrain tiles and keep track of the player's location. I'm still a few steps away from there, but it's starting to look doable. Pretty cool, huh?

Shout out(s) and shaders

Wanted to give a quick shout out to a kindred spirit, Marraboy over at Unity 3D -- Zero to Hero. He recently started a blog to chronicle his progress building a game with Unity and Cheetah 3D. He's only written a handful posts so far, but I just want to say, "You can do it, Marraboy!"

It's still by no means proven whether I can do it, but I did get some much-needed words of encouragement from a good friend over the weekend. This no-budget-game-development thing can get pretty daunting, particularly on days when I realize how much more there is to learn.

Case in point: Unity's ShaderLab. It's a programming interface for creating shaders in Unity (a shader describes how an object will look in the game -- what textures it will use, how it will react to light, etc.). This mind-bogglingly powerful feature of Unity is, I'm beginning to discover, the difference between amateur work and real professional visual quality. Sure, modeling and texture art are essential, but custom shaders add the flair.

Of course, working with shaders requires some knowledge of OpenGL's shader language, of which I have none, so I feel quite outmatched at the moment. As usual, though, I'm probably getting ahead of myself. SPUDZOOKA isn't done yet, and I can't get too caught up in the next thing.

No, I shouldn't be worrying too much about shaders yet. They just remind me that I need to take things one step at a time. Visual polish is not my strong suit, since I never had any formal training. But that's ok. I like to think that what I lack in skill, I make up in blind determination.

The right way round?

One of the challenges for small game development teams must be division of labor. Your standard team might include a programmer, an artist, an animator, and a game designer. If you're lucky, you'll even have a writer (though most big-budget titles don't even seem to have those). But, as with any small team, there is likely to be some crossover in roles, particularly as deadlines approach.

Seems easy enough, but what if your team only includes one or two people? The first thing you would probably say is, "Don't waste your time on an epic RPG." We already know people like me would ignore that, so the question becomes, "Where do you start?"

You could start anywhere, really. Obviously you need a concept and a premise. Then you could work on character designs, level designs, concept art. The right thing to do would be to write up a formal design document to force yourself to think through all your major design decisions.

My answer: gameplay programming. This is odd to me, since I am not a programmer by training, or even by interest, really. So why would I treat it as the starting point for my game? Structure.

The way I see it, concentrating first on programming lets me create a functional skeleton for the game. Once that is in place, I can begin replacing placeholder elements, like my blue box man, with more--interesting--objects. I think of it like the outline of a paper. Once the structure is in place, the real creative work can begin.

Is this the right way round? Who knows, but it makes sense to me, and in a team of two with no deadlines, that's all that matters.