Skip to content

Posts tagged ‘Fourier Series’

Rigging retrospective (part one)

August 20, 2007


So Ive been away on vacation over the past two weeks in beautiful Montreal (an amazing city). I had time to think about rigging, ways to break it up and what it is at its heart: intergrating systems.

Rigging can be regarded as modular in one sence and choatic in another. It can also be though of a group of systems that interact with each other in simple and hybrid types of ways. There are three main ‘Driven Systems’ at its heart:

Kinematic – the animator drives the rig with keyframes, purely controlling the puppet and f-curves

Procedural – the animator drives values which adds automatic driven motion, the wave if you will doesnt however have to be procedural and handmade in a fourier synthetic way.

Dynamic – the animator drives controls in which there ‘children’ act in a physically based way. The controls themselves could also act dynamic.

Theses are the bases, but many hybrid versions of these can be combined, waves driving dynamics for instance. A rig should only support this if its really really neccesary – we need to understand what a rig needs. At its heart is what the animator wants, especially interms of control. But we can also make our own assumptions and give some basic rules in constructing a rig:

1. A rig is a series of systems.

This can be a hard idea to understand, but if we treat a part of a rig as a system than a series of joints (more of an outwardly looking in analysis), we can work out what we need. A good example is a tentacle – because were are treating this entirely as a system – e.g. a splineIK base with a layer of FK controls. The tentacle is treated as a whole unit and this is how we should look at it when rigging. Lets break it down:

A tentacle that needs to be fk, dynamic, driven and procedural – we’ll first off we can pair these together fk/procedural and dynamic/driven as a system. By doing this we can see that the fk/procedural can ‘ride’ the dynamic driven system. And this dynamic driven system itself can be treated as one: A dynamic chain solution that rides a bezier spline based on tension, and a fk procedural system that rides this in tern.

A tentacle is essentially an easy example as we regard it as unit, but can this be the same for a wing, leg or even spine? A spine or torso can be summed up as three independant units that are glued together either or additionally by a positon or a main control. It can be regarded as a system. A wing is essentially an arm, that feathers ride along and intern have dynamics (air resistance etc)

Fourier Synthesis and Harmonic Oscillation

July 2, 2007


So currently im looking into a a scripting language to so I can develop my math stuff outside of the software and keep it a data driven as possible – currently its between JavaScript or Python. All I really care about is class definitions and handling functions.

I’m also looking into fourier synthesis, harmonic oscillations and and analog synthesis as a friend and I have a plan for an interesting tool! 🙂 Should be fun. Im also looking into oscillation and phase shift as a tool for animators – something along the lines of the ‘Wiggly Splines’ Pixars paper – I understand the basics of it, but it gets into territory dealing with basis function and new curve generalizations which in theory is possible but for max I’d either have to write sdk something else.

As to fourier synthesis, it’s really very very powerful as it allows paramaterisation of the wave form, such as quantization, rectify and full-rectifying with relative ease. Phase shift, frequency, amplitude and magnatude (terms of cosine and sine) can be handled in a deterministic fashion. Functions such as high-pass, reverb are a little more complex but if ineffect you controlling just the terms of the synthesis it might be easier.

High/low pass deal with frequency cut-off using two variables: the frequency and the attenuation: a range of q1-q10. I’m still a little confused as to how to affect the waveform as a process of the fourier – but I’m looking into it.

Using quaternion ‘Dirac’ belt-trick inconjunction with fourier waves.

May 12, 2007


I’ve been looking into double quaternions and the belt-trick. The trick also known as the ‘waiter trick’ allows  a rotation with respect to axis order, to rotate from -360 to 360 – full 720 degrees of twist. This alone wont work in a rig and  needs additional support for the identity matrix and a feasable way to produce (t) the tracking value along the surface of the hypersphere,  between each frame (frenet).

Possible ways to achieve the (t) value of the Dirac algorithm is to use a simple slider from a range of 0 – 2Pi. This is a simple solution but takes away controllability to the animator – essentially we need to derive the value from the controls themselves.

Ive been looking into fourier waves and the sawtooth wave, its amplitude and frequency can both be accurately achieved with the phase offset being directly linked to the (t) of the belt trick.

Passing the output of the belt-trick is a simple process of converting the quat to eulerangles. But deriving the t value is a lot more tricker, due mainly to the hemispherical problem of quaternions. A quaternion [v,w] is a vector and a twist on the surface of two 4d hemispheres,  where abouts a transform travels across the hemispheres is Slerp.

What can happen is that if the vector crosses the equator of the hemispheres a 180 degree flip can happen – this is entirely correct but tricky to send to a fn as it keeps flipping. If we take the transform of two objects ‘a’ and ‘b’ with us storing the transform of ‘a’ relatively to ‘b’ as a script_function we can get the constantly updating angle of the transform.

But once we hit 180 degree’s it’ll flip and the transform will reverse – one way to fix this is to reset the transform space when we pass 180. Essentially resetting the rotation of of the transform: 0 -180, 0-180 – a sawtooth wave. A problem with this is rotating backwards.

We need a way of dialing up the transform space rotation, up and down and then feed this in the quat fn.

Full-Wave Rectified Sine.

March 25, 2006


Converting math notation into maxscript can be quite difficult, take our full-wave rectified sine equation. It contains sigma (summation) of n=1 to infinity do cos(n*omega*t)/(n^2-1). So in max this cant happen as its a for loop going from 1 to infinity adding the results! So we have to use less iterations.

Sigma is basically a for loop adding up the results, where as PI (II) is multiplication of the results. With this knowledge we first have to get our variables:

t = time

0 = omega

a = amplitude

r = 0

(r) is used for the summation of cos(n*o*t)/(n^2-1) which we get with:

for n = 1 to 30 do


 r = r + (cos(n*o*t)/(n^2-1))


So now we have (r) which is basically the accuracy of our equation, we could go to 1000 iterations but max would probably crash. Now all we do is multiply the front of the equation by (r):