|
There seems to be a peak in the current approach to animation. I’m not talking about IK/FK controllers, or animation techniques, or how we translate motion capture to something usable within a game engine. I am talking about the low-level process of animating a group of vertices using transform clusters.
In the beginning, we had baked keyframes and used simple vertex tweens to generate our frame data. Eventually we had the horsepower to animate organic models through a rigid bone structure. This evolved into a multi-weighted animation system, and now we have models that may be affected by 2 to 4 transforms per vertex.
Until the advent of GPU assisted bone animations we had to animate this content on the CPU and render them from client arrays (or system memory buffers, depending on your API). The disadvantage of the CPU approach was an obvious lack of data vectorization and the significant burden on the AGP bus. The GPU approach was an instant success; resolving both of these issues, but at what cost?
Many GPU based approaches have significant disadvantages. Register limitations means that a model was limited in the number of bones that could be used for any one object or scene. Bone indexing schemes are often unsigned bytes, which means a maximum of 255 bones and a limit of only 4 bones per vertex.
Some of the more complicated rigs of today may (sometimes unintentionally) apply 5 or 6 weights to a single vertex or contain hundreds of bones for a large compilation scene, which means invalid or impossible imports of this animation data.
One CPU-based approach to dealing with an arbitrary number of weights is to pre-multiply each vertex by all of the bones that it is bound to; effectively creating multiple partial vertices that eventually will be summed together when a specific frame is being constructed.
Unfortunately without 1-N or N-1 support within a GPU vertex shader, it becomes nearly impossible to repeat this functionality. That kind of support only seems to be available in more advanced API’s such as DirectX 11 (maybe 10). Since there are still games that are being designed for fixed-function pipelines, I am assuming that DirectX 11 will not reach critical mass for some time.
Is there a better way to the current approach to bone animation? It feels like animation has peaked until we reach another generational leap, such as Larabee or some other CPU/GPU hybrid.
|
Unfortunately, coding these more advanced algorithms will be even more difficult with current GPU programming methods. I think the many-core paradigm is ripe to revolutionize this aspect of videogame engines... possibly more-so than the rendering stuff which seems to get a disproportionately large amount of attention.
That said (as I am a tech head myself) having any weighting that includes more than 4 bones per vertex is overkill for almost everything except facial and hyper-detailed content (most of which remains unseen during gameplay, and is usually reserved for cinematic content, which we can simply render with less restrictions)- but even complex and clean musculo-skeletal deformation can be achieved with that 4 bone limit. It means working cleaner, sure, but this is something we all need to be doing anyhow.
But processing falling short of our need has always been true. Every time new tech, engine or console comes out, we hear the blather about how the cap has been lifted. But to date, this has always been a blatant untruth. The truth is we cram our projects so full of un-needed content, or worse, content that is "dirty" (meshes with unwelded verts, or scaler values that haven't been wiped. environs with overlapping meshes that cause radiosity or lighting solutions to choke; unoptimized assets like FX, streaming being used unwisely, etc.) that we undermine our ability to even use what we do have.
So to my point- the cap is always gonna be there- CPU, GPU, or whatever comes next. But regardless, we all (coders, tech's, artists, animators, etc.) need to work smarter and cleaner, in order to avoid the uneccesary pile up of dirty data beneath. Doing this, among a few other things, will relieve some (though admittedly not all) of what our processing lacks. Unfortunately, everyone is so worried about pushing the envelope, they rarely take the time to work clean up front, and portray little affinity or effectiveness for returning to clean up the mess on the back end once production is over or nearing its end. But it needs to be done. All it requires is the proper sharing of info between the team members, and people actually being professionals, and adults.
Whew- ok; glad that's off my chest :) Thanks for the chat.
I agree though about the cap always being there. When 3d hardware first came about the games all started to look the same. Then came shaders, which really opened things up. Now we are hitting some other limits. The hardware will probably become even more general and some of these limits will dissapear too, to be replaced by other limits. :)
With regards to bone counts, it is a common practice to just keep the 4 most important bone influences. 99% of the time noone will see a difference. For high-quality in-game facial animation you can always do the transformations on the CPU. It's an ideal candidate to push off onto another core.