|
Here’s something I’ve been procrastinating to post for half eternity now. Some might have seen this already on stray clips on vimeo.
[VIMEO]2489495[/VIMEO]
IK and mesh control:
The first draft of the rig was using the unsupported kinematics and had actual bones for legs. I built my own simple ik solver with basic trigonometry, which had limit of 2 bones, but otherwise was at par with native bones. There was some talk a while ago about ICE being too slow for custom IK rigs, but to my experience that is not true. There are some severe issues with the kinematics still(hence they are unsupported), but speed wise they should work quite well for simpler rigs. In the end it was nowhere near fast enough for this extreme case though(neither were native ones btw), so I had to find a speedier workaround.
This will probably be in my reel so I spiced up the graphs a bit…
[VIMEO]2489369[/VIMEO]
This is what I call Pseudo-IK. It’s the simplest possible way I could think of to represent a limb with one join. It inputs 3 points (start, end, up-vec), and roughly fits in 2 matrices as bones. Calculations for this are extremely simple and take hardly any processing time. Mesh itself has a weightmap that decides which matrix the point belongs to. On initialization points are multiplied by inverse of the matrices and cached; on each frame the cached points are again multiplied with the right matrix to get final position. The whole process happens in point context, which was somewhat tricky to implement, but appears to be very fast.
In conclusion, it’s hacky but fast. I believe it multithreads nicely too, but I only have one core so can’t really test…
Dynamics:
[VIMEO]2489401[/VIMEO]
At the core it has a pointcloud that handles pretty much everything the rig does. The vid quite elaborately shows the basic process that produces the walk. The body and leg attachments are using the “deform by two curves” I made some time ago. It’s on the compound exchange.
-Body moves forward, toes are attached to ground
-hind legs are released when they are too far from their rest position, be it forwards, backwards or sideways.
-rest of the legs are released by timer in frames. This is bit inaccurate since you might want the bug to walk really fast and it’s impossible to have the wave form in sub-frame time.
-free animation is triggered. There are 2 separate fcurves to control up-down and back-forward motion. The system tries to satisfy certain rules that are weighted together:
-reach for back-fwd motion goal angle
-repel legs in front and behind to avoid overlaps
up-down just follows its anim curve.
-free anim continues until the toe-particle hits an obstacle, which resets everything and pins the toe on the ground.
There are quite a few top level settings for the anim behavior. Most important ones are probably clip duration and unpin distance. There’s quite a bit fine tuning to do for animation, which is bit pain in the ass.
Problems in development:
I’m actually quite hesitant to post the scene because it may appear bit hacky and convoluted. It is not meant as reusable rig, and at best you can change the mesh parts. At some point the system became pretty unstable, and development became quite frustrating. It should be stable to use and play with, but changing anything internally quite often causes a crash. Most of the dev time was spent on waiting xsi to restart :p. Some of the key components work fine alone, but cause problems when put together. As example, changing leg mesh has to be done in 2 places (modeling and simulation trees) and that will crash xsi if done in wrong order.
The rig needed quite a few workarounds to work properly. If you dig in deeper in the graph, you’ll find I constantly read data from what I call “siblings”, which are different parts of the leg (base, knee, toe), and further cache lots of variables in all 3 parts. Ice has pretty restricted data flow, and I probably should have spent more time in the beginning to design more optimal way to communicate between the siblings. There are tons of similar workarounds in the graph, which complicate and slow down the rig. I also noticed that sometimes unconnected nodes can completely mess up the outcome of some branches, which makes debugging extremely tedious.
So in conclusion, while it was interesting to work with, I probably wouldn’t try doing this in production environment. Ice isn’t really suited for this kind of thing in my opinion. I think it would have been easier to do it with script and sdk.
Quick question at the end: Is there any easy way to cache the animation. Using the cache node in ice is a lot of extra work and the environment cache makes the mesh go nuts. Also, once cached, why does scrubbing timeline still cause “resimulating” to pop up instead of just jumping to the right spot.
I’ll attach the scene file tomorrow, seems it could use some cleaning first.
| 
