# Posts tagged ‘Modularity’

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 was thinking about simplification in rigs today, and how we can modularize the joining of parts of the rig together – for example gluing together the upper arm to the chest via the shoulder. It would be cool to specify how this join would work e.g automated shoulder, stretchy shoulder, fk/ik etc

I was trying to figure out a problem at cgtalk only to think about systems that have existed in the internet for years – ‘one button’ do all’s. Amazon does it,  Apple does it so why cant rigs do it? Well theres two problems: encompassing options and allowing the animator/rigger to easily build the nessary limb.

Now these can be built into a rig, building changability into a rig is possible to a certain extent, add extra bones in a spine for instance could work and would have to be set prior to hitting that shiny one button that, not only builds everything but also frees up easy posing and adjust of the said limb, before you skin it.

I really like the idea of  modular  rigs  as a whole complete with bones, setup and controls – and also adjustability. Press one button, build a spine, move the controls where you want them, everything updates and is ready to go!

The finer elements are hard to work out – the problem comes in how finite you want to go.  I like the idea of chunks: foot, hand, spine, head. And smaller chunks finger, toe etc. I dont know if id go really finite? but maybe you need it. Another problem is say you’ve made a spine, and an arm – how these connect is interesting? Would there be a one button select the parts and press – which glues them together? Like a shoulder bone joining an arm to a chest?

A toolset of modules and tools?

Could we define a toolset of modules and tools?, for instance we could have spine, limb, hand, foot, head, digit – modules? and a set of tools to essentially glue them together based on what they are. I.e could we build spore as a tool for riggers?

Would we need a toolset for deformation, adding twist? etc – maybe this would be plugged into the modules automatically. For me i see it as a very simple process: build your modular parts, adjust them and parent them as need be. A fast rig.

I think the modules would have to be in seperate units – i see one set of just the building blocks. One set of controllers eg. torso control and a finally toolset of ‘setting up’ essentially the modules e.g

pick the head, pick the torso and it builds in keyable transform spaces onto the head?, i dunno just ideas.

Edit: The keyable pivot is an idea inspired by  Jason Schleifer, Animator friendly rigging. Go check out his site here.

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)

Im looking into areas that can essentially be shared  – modular continuity between arms/legs etc on biped and quadrapedal rigs (even bird rigs). Its opened up some interesting ideas namely to first break the lower arm in half and some oddities in the foot.

Breaking the lower arm in half basically allows for a front arm to act like a front leg of a quadrapedal – why is this important well for one thing it allows a quadraped to act like a biped and vice versa. It doesnt mean you would nessesarily use it in a biped rig, but its a simple additional that allows for the control.

For the foot rig – ive seemed to find a stumbling block namely where the control of the foot goes? In human locomotion the pivot exists at the heel, but when its on the ground its at the ball. The problem is even more compounded in that we both swivel and hinge about the heel – hinging is a simple heel<>ball setup, but swivel is more of a problem. Do we change the transform space of the main control if its at the ball or add an additional layered control?

The problem is exactly the same and virtually opposite if the main control is the ankle, you get heel and swivel control but ball of foot swivel is lost.  Its not truely lost, you could drive its z rotation of the roll controls z rotation but, as where dealing with ik system our trigonometry plane space would freak out and the foot as a whole would twist – the old gimbal problem looming as two rotations overlap each other.

I was thinking today about a modular method to handle deformation – this would be able to handle twist, stretch, curviness and scale all in one system – that would be easy to setup and dynamic to the user in both control method stretch on/off for instance and speed/interactivity etc.

I was thinking of modular chunks that bolt onto a simple control rig, and allow for control of twist, deformation, scale and stretch/compression all in one handy system. Most of this module I’ve spec’d out and written. Gluing it all together is another matter, but relatively straight forward.

The module would work on what your rig can do in its current state – for instance if your rig can stretch, this layer of deformation if turned on to stretch would do exactly the same thing but add additional twist, scale, compression, plus a layer of control for all this. Twist itself would have a bias control to fix popping.

It would be you build a pretty simple rig and bolt on a more detail layer of deformation – animators could still use the base rig – but TDs could add a pass or even snr animators a more finite level of detail.

Im coming to a point where im trying to turn most of my functions into pure data driven. I’m trying to modularize my rigging so it can be used across platforms and even into standalone app. (no thats just a pipe dream atm)

How to approach modularity?

Its pretty difficult to standize a rig, if its a one off, but you can certainly standardize bipedal, quadrapedal and possible ornipedal (birds) rigs.  I was playing with a friend on mines Japanese toy at work, it was a robot you could plug joints together – simple joints revolute, hinge, spherical and hubs.  This is the kinda modularity in rigs id like.

Whats needed? The criteria?

Well for bipedal/quadrapedal i think a base structure is needed in some aspect, even if there generalize areas: spine, head, arm, leg, foot, hand. And we can assume some rigs will have more bones in e.g. 8 in one spine and 4 in another. Modularity is how we define these areas – plus after setting up there definitions, its connection with other parts.

For example, we set the spine to be RBSplineIK (rational bezier spline ik), and the head to be pure FK – how do we join the two together? If its a typeIn box “head>chest” so it builds a neck, how does this neck work? FK, IK? spline IK?

If we go back to clumping a whole system like head, an encompass the neck etc to it – this would make it easier to define itself.

I read a paper recently on ILM/R&H’s rigging pipeline – it sounded stunning and at its heart was ‘modular’ rigging. That taking several key ‘rigging’ blocks one could build, iterate and change on the fly a rig. Modular ‘blocks’ of rigging setup would be linked through a simple text entry, for example:

modular rigging block hand would link to arm via ‘wrist’ and so on and so forth. It made me think about what the future holds for rigging. First of the current situation in rigging is majorily hindered in my opinion with the locked state of skeleton to rig. And so these two systems along with twist need to be abstracted – if iterating on a rig, that didnt change or break the skin was a simple as modularly switching different setups on the fly per scene/shot things would be a lot easier.

So what essentially is a rig – its a skeleton which is driven by a setup, and controlled by puppets.  This skeleton is primarily a tool for skinning to, and also referencing animation, mocap, building other rigs off. If the skeleton was just a layer essentially that looks at a setup, itself built modularly on the fly, then itself could be changed, added to, even animated in FK off a setup.

Abstracting two systems is complex though, and made worse by the sheer amount of referencing that goes onto a rig, twist for example needs bones, transform, relative parents and nodes – so to tear a system like spine, arm twisting etc you’d need the essential nodes to make it work. So with this twist is a system unto itself, that needs a system in place – therefore its a final layer of setup after the primary rig’s been built ontop of a changed skeleton or a skeleton thats driven off a modular rig.

What is ‘modularity’ can it be broken down into systems? – Interms of rigging automation out there, systems still rely heavily on other systems existing, an arm system needs a shoulder/hand etc; a leg needs a foot but can this like ILMs tool be abstracted even further to pure body parts: spine/head/arm/leg/hand/foot I think it can. Whats needed for consistency with modularity that makes joining systems together work?

Well for one thing its puppets, without puppets to there respective ‘block’ the system doesnt work – take for example an arm. To build it you need a shoulder position (not the shoulder) an elbow position and a wrist position. Ontop you need the controls at the shoulder, wrist and hand – even if the wrist controller isnt controlling anything, it will do once it knows what to link to: hand. And because hand is now pointing to arm via wrist it just finds its respective controller – this could be as simple as just parenting it or typing in the ctrl it needs to link too.

Ontop of this modularity combinations of rig become far easier, like as the paper discussed building a centaur was a case of linking a horse lower torso to a human upper one. The system needs essentially three layers: skeleton > setup (with puppets)>twist (in theory the skeletons bones needed for twist could use this)

Issues arise with this approach too though, namely orientation of joints, can for instance an arm be attached to a neck? and if so how is its orientation, its initial setup posed? Can modularity co-exist with a skeleton do they both need to be present, can a modular rigging system only work on an already existing skeleton? to me a skeleton is a layer what the skin needs and also it bridges the gap between model and rig, most importantly with twist and stretching…