Harmonic animation beta + walkTools (run from URL)


Harmonic animations - demo

I’ve put together a beta to demonstrate the new walk, walk backwards and idle harmonic animations I made recently:


(paste into ‘Open and run script from URL’ dialog in Interface, please be patient whilst it all loads…)

As before, the animations are made up of 100s of varying sine waves, all added together to produce the animation - not a keyframe in sight! So that the new and existing animations can be compared, I’ve added a dropdown to the settings that enables animation set selection - just click the walk.js icon and select the ‘Original’ setting from the ‘Character’ dropdown.

New idle animation - she breathes!

After harmonic conversion, the animations have had quite a lot of editing (using walkTools editor) to get them looking as they do. Ideally, there’d be no editing required - see ‘Pre-rotations and other issues’ below for more details…

Other updates

~ The animation data is now stored in JSON format, making it easy to store in a database and generally easier to handle.

~ There is now fine grain control over the number of harmonics used per joint, per axis. This has two advantages; generally smaller files sizes and easy low pass filtering.

~ Pre-rotations editing mode (walkTools editor)

~ walkTools oscilloscope - I’ve been using this for a while and it’s proved itself essential for animation, so I cleaned it up a bit and added some more information to the display before adding it to the public walkTools version.


Since I took Amazon up on their offer of a free year of S3 use, walkTools can finally be run from a URL too:


To access the actual tools after loading, simply click the walk.js settings icon and click the ‘walkTools’ button. (Thanks to @ctrlaltdavid for the nicely positioned windows!)

Note on harmonic animation

If you are not familiar with what I mean by harmonic animations, imagine a way of converting keyframe / mocap animation data so that it can be used by a procedural animation system. This is done by breaking the data down into a series of harmonics that are of known frequency and can therefore be used for highly accurate animation timing and synchronisation. Harmonic file sizes are also smaller than keyframe / mocap data files, and have a natural, built in LOD functionality (just reduce the number of harmonics). There are various other advantages, please see my previous forum posts for more details.

Pre-rotations and other issues

The walk, idle and backwards walk are all conversions of @ozan’s keyframe / mocap data downloaded from here: https://s3.amazonaws.com/hifi-public/ozan/support/FightClubBotTest1/Animations
To make them, I first export the animations as bvh files, then read them into Interface using an XMLHttpRequest. The files are then parsed and the animation data applied to the avi.

However, although the keyframe -> harmonics converter is working great, I’m still not happy with the bvh data import process. I’ve thrown together a bvh loader in JS, but despite a LOT of experimentation, I still can’t find a way to 100% accurately recreate the curves I see in a motion editor on the walkTools oscilloscope (and therefore on the avi).

The basic problem is this: high end animation editors, when presented with an fbx file containing pre-rotations, will separate the animation data and the pre-rotations (note Blender does not appear to do this):

When the animation is exported to bvh, the pre-rotations are added to the animation data (note the much larger x rotation value - if adding negative pre-rotations takes the final value below -180, the export process will add 360, so keeping the range between -180 and +180. This complicates things a bit, but is easily dealt with):

Intuitively (naively?), I thought that just subtracting the pre-rotations would give us back the original curve - but check out the blue (Z) curve for the left lower leg - it’s simply not the same! (original fbx on left, walkTools scope on right)

Weirdly, I’m only having trouble with four joints in particular - lower legs and shoulders. I’ve tried different joint rotation orders, different bvh parser libraries, inverting signs, checking joint orientations and a whole lot more. There’s still something going on I don’t understand, and it’s driving me crazy :frowning:

Anyway, that’s where I am - if anyone has any theories as to why only two out of three curves are (more or less) accurate, I’d love to hear from you!

I’m also on the lookout for high grade animation fbx data, particularly short steps and sidestepping, so if you know of a source, please let me know.

  • davedub


I’m an idiot I read that as harmonica animation.

I noticed a thing about the mixamo fuse rigs which may be relevant or may not be
If you have the free arms selected (i use the hydras) and scale the avatar from 1 upto 100 the arms end up
like this

scale it back down to 1 and it goes back to normal
its like the rig scale isn’t zeroed out or something


hey @Judas


Yep, it looks like there’s an issue with how Interface is scaling Hydra data. The way in which Interface performs animation is still shrouded in mystery for me - when I set the upper legs to zero in JS, I’m setting what I KNOW to be a +Y axis orientated joint to zero - so I’d be forgiven for thinking the legs would point straight up in the air - yet they point straight down. This can only mean there MUST be some sort of application of pre-rotations going on, but from my own experimentation, they are not the same pre-rotations as found in the Sintel.fbx file.

Am very confused! (but I WILL get there in the end :wink:


That is a great ‘Whateva’ pose.