I’m looking for a little help from one of the resident math(s) gurus. So… with the next generation of consoles in full swing, it seems that more and more games are venturing into the realm of runtime rigging (super exciting!!) Thisis a good example, and The Last of Us rigging video mentions it too.
Runtime IK has been around for ages of course. As more and more dynamically generated motion like this happens in runtime, the funky deformation systems (twist bones, elbow pushy-outy things etc) will need to be dynamically driven too. The most common method of doing this inside of Maya/Max is through some kind ofpose-reader.
Obviously, for runtime stuff, efficiency is key. This pretty much limits us to at most one or two ultra-simple mathematical functions per pose reader. (even that would probably make most programming teams get all sweaty and nervous…)
So far, through my neolithic understanding of trigonometry and matrices, I’ve figured out that simply extracting the y and z matrix components of a joint and using that to power the forward/back & up/down poses may actually be very effective. The end result is basically a sin wave which transitions linearly away from 0, but eases in and out when the joint is fully in line with the respective axis (attached image… looky). Also, straight out of the box it comes as a 1 to -1 scale, which means it can easily act as a scalar for corrective joint deformation/morphs.
Unfortunately, this is where I hit a wall. Currently I have two problems:
1: How the heck do you actually extract a single matrix component from a matrix in Maya using nodes? (I assume that inside of a game engine this would probably be super easy, so I’m not worrying about that bit too much).
2:Probably the most important problem… how do you reliably and efficiently extract the twist rotation? Up to this point my only real technique for doing it is via silliness (…fun?) involving a ton of locators and aim constraints. Obviously this isn’t the type of thing you could convince programmers to stick in a game engine.
None of this is really urgent or anything, I’m just interested to see what people can come up with :D:
The maths is simple enough to be done at runtime (it’s a dot product to compare normalised vectors and remapped within the cone’s angle).
Some pros for doing this in Maya:
[ul]
[li]Offline computation (so uses more memory but takes less cpu at runtime, in the majority of scenarios this is preferable).
[/li][li]All your character setup data is defined in one place i.e. you don’t need to do another stage of setup once the skeleton is in engine to define all the comparison vectors and cone angles.
[/li][li]You don’t need to write new editor extensions to allow you to define the new data and don’t need to worry about where it gets stored or what happens to that additional data when the skeleton gets altered in Maya and reimported.
[/li][/ul]
Some pros for doing this at runtime:
[ul]
[li]Saves memory (at the expense of computation time).
[/li][li]Bypasses artefacts which may be caused by animation blending or layering (since the computation can be done once the final blended/layered pose is calculated the result can be more accurate than blending/layering precomputed (baked) results in some scenarios).
[/li][/ul]
I guess if you use the dot product it’ll result in linear interpolation between the pose being inactive/active, which might work better for correctives in most scenarios. I’ll have to do some tests at some point to see if the ease-in/out which would happen from directly reading the matrix values would actually be counterproductive. It would probably be a lot more efficient to be able to skip the vector comparison if possible.
I’m still a little confused about how to find a twist angle though. I’ve read a little more in to it, and there seems to be a lot of posts which mention that it’s actually very hard to define the twist amount as a simple scalar value without it being history dependent. (Essentially it won’t be able to work out which direction it has been twisted). Maybe something which involves shortest-path interpolation might be sufficient…this would limit the stable angles to +/- 179 degrees, which is usually fine for most things.
Figured I might as well update this thread with what little progress I made to help anyone else on a similar path.
So, directly extracting the matrix values was not really suitable for a standard pose reader- the values it output generally caused driven deformer objects to zip way ahead of their driving bones before the bone catches up. Might be a nifty and efficient way to create that kind of behavior for some very specific scenarios though. Using the dot product (or an angleBetween node in Maya) smooths them out, so that 45 degrees is always gonna be 0.5 etc. Much nicer for most scenarios.
In terms of the actual idea of having a pose reader which looks at just +x/-x +y/-y etc… There were problems when rotating past 90 degrees. Essentially, if you rotated a bone so that it faced the complete opposite of it’s original position, there is no way of working out which route it took to that point. One solution is to choose a dud angle, and wire up the numbers so that any rotation past the 90 degrees mark always counts as being from the non-dud axis. This is actually kinda suitable for things like legs- you can lift your leg directly forwards so that your knee touches your chest, but it would be impossible to rotate it up from the side and make it touch your chest. So the dud angle would be the side.
Finally, for twist, I still haven’t found a decent way to do it with maths. I tried using the cross product of an arbitrarily chosen upvector (the bit which points up on a shoulder for example) and the current aiming direction of the expose bone. This works pretty well until you’re aligned with the upvector- then things start flipping. So next, after reading Theodox’s tips on another thread, I made the upvector partially inherit some of the motion of the bone. This did extend the range of motion, but also introduced some innacuracy. It also had flipping issues at extreme angles.
In conclusion… It might be best to stick with just individual cone angles for the exact deformations you wish to power. I think the key to success may also be through crafty solutions which only work for specific scenarios instead of an omnipotent pose reader.
