# Posts tagged ‘Dynamics’

The method ive found  to resolve spherical and circular collisions at high speed is borrowed from the spherical bounding box method. I first store the current distance between the two spheres/circles and then the  future distance between the two  .

$cd = |p0_{1} - p1_{1}|$

$fd = |(p0_{1} + (p0_{1} - p0_{1-1})) - (p1_{1} + (p1_{1} - p1_{1-1})) |$

if this future distance is smaller than the combined radius’s I re imagine the current distance

$cd = (cd \frac{cd}{fd})$

and continue to do the standard method.

The basic verlet algorithm im using is,

$x_{1+1} = x_{1} +(x_{1} - x_{1-1}) + a dt^2$

where x is the current and previous position a the accumulated forces, and dt, the timestep or period over frequency. This is great if the simulation is un-fluctuating i.e baked; if it was realtime i’d introduce the TCV (time corrected verlet) version,

$x_{1+1} = x_{1} + (x_{1} - x_{1-1}) (frac{dt_{1}}{dt_{1-1}}) + a dt_{1}^2$

The nice thing about verlet is that velocity is calculated from the current and old positions, and because of this you can keep throwing collsion and constraint methods at it. It handles the rest. My current approach is to fire the integrator ( verlet) then collisions and constraints – the latter two iterated several times.

I started to think about building a very simple framework for dynamics based on this article: http://www.gamasutra.com/resource_guide/20030121/jacobson_01.shtml

It uses the verlet method and then successive systems to check for constraints, collisions etc. – I like this approach as it seems pretty modular. I think the basic method ill go for is defining objects/verts/lines/etc with attributes, whether there masses or constraints connecting masses together. Then the main system calls the general functions on them.

Im not sure if this is correct but i think the aproach with the main system is to:

1. Calculate all the forces of all the masses
2. Apply verlet algorithm with a timeStep
3. Do a scene check i.e if the masses are in a box if its simple or/and
do some collision/friction checking
4. satisfy the constraints

Im not sure if 4 & 3 are the right order so, ill have to think on that – but this is my basic approach to building a simple system. I thought of attributes because they could be place on anything then, and i could add some function for display methods, like cylinders and spheres.

I tend to think in small chunks – I break down an idea, work out each part and then put it back together hopefully. I’m trying to use this approach with dynamics – I’m looking into a simple system to handle a variety of situations. Currently I’m thinking of simple spherical detection. This method use just a diameter from a point – its a simple system, but it might be scalable for more complexity.

Dynamics I find very hard to get to grips with, I have to take it very very slowly. Just understanding derivatives is hard, as its the function of the equation. Its also very fragile as a system – finite tweaks make big changes, especially in complex systems. My aim is to build simple systems that can be ‘bolted’ together right across the board from dynamics, to transformation stuff. Its sort of the middle man of rigging. I’m not the string or the parts of the puppet, im the knots that tie the string to the parts.

I’ve been looking into curves for quite awhile now, along with waves and dynamics eventually hoping to combine all three. Along with these ive been trying to understand the rules of rigging especially layer and hierachal rigging. A lot of riggers i know dont undestand the idea of ‘layers’ in a rig. In simple terms its like a layer in photoshop but in rigs it free up a lot of issues if you keep aspects of a rig to a layer – so for example your base skeleton could be your first layer, then basic setup then twist, then deformation. So its more like layered relationships – deformation is a good example. If we can modularize deformation in a simple system we can use it all over the place.

Major deformations like  skin simulation are outside of this, but twist, stretch, compression and bulge could be driven by one system. If we treat this system as a curve the issue arises is that its not uniform so control objects along it would bunch up so we need:

• A simplified curve, that possibly introduces horners rule (for speed)
• Uniformity across the curve (important if the tangent vectors are straight)
• The ability to overshoot the curve at both ends* (-0.5, 1.5)

*Why do we need this, well basically to allow for length between the points along the curve to be maintained, for example if we dont want the curve to compress the points along it need to overshoot the curve. This can be pretty simply acheived using a subdivision method. To keep a value at the same value i.e a length of 10 along the curve, all we do is divide this length by the curves length eg. 10/100. = 0.1 10/200 = 0.05. Problem comes in if the length of the curve is shorter than the defined length the ‘bucket’ inwhich t resides wouldnt exist. So you need to do some fiddling around. I’ll post some links accompanying this post.

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)

I was thinking today about skin simulation, and theorising what the key parts you need in a system – what you get for free and what costs. For one, sliding of the skin and volume transformations in world position space come for free. In my mind there result of the same system. What you dont get for free is rotation of the volume in world space, and tension of the skin i.e tickyness.

As firstly you need to store cached vectors, i.e a reference to a base set of vertexs. And these base set need essentially dynamic properties: whether there stationary or sticky about there world trasnform. Most system i take it need to cache a set of positions for the verts of the mesh to rely on, be it with normals or rays.

From writting, i can see a possibly viable solution to sliding and even transformations including world space rotations. You just need to transfrom the matrix of the vectors in an array of sorts. Sticky skin is tougher and even tougher still is what the skin does in the gaps, between the muscles under the skin. Ontop of this does it sag? jiggle? does skin weighting add to the result.

In my mind it should be one solution where you can decide either by paint ala ILM’s tool, whether the vert is sticking, slding or creasing.