Mar 312011
 

[FILES UPDATED TO WORK WITH 2.57b]

.blend files (2.57b – r36339) right-click, save-as
Uno/Deuce/Pogo
Rigid Body Walking Machines
Extras

link to BA thread

This is a collection of studies and experiments in rigid body dynamics and pose control using Blenders game engine and python API. All the animation data was generated in real-time simulations (with the exception of the camera which was keyframed and the cloth which was not real-time)

———NON-BLENDER/3D NERD BRIEF———
These animations are essentially of 3d games. The games have gravity, inertia, object collisions, joints connecting objects and ranges for those joints. Each scene was created by setting up a game, and running it several times (sometimes with simple keyboard interaction which pushed or propelled a projectile). The animation data (the rotation and location of each object) was recorded during each game. The most amusing or interesting results were saved, one was selected to be rendered later.
Camera moves were keyframed (traditional/manual 3d animation) for more interesting views. Hours and hours of painful rendering, and voila.

The rectangular biped and monopod characters are seperate programs within each game. Each has the ‘joints’ and ‘muscles’ of a simplified human. The joints are functions that limit the location and rotation of an object (such as a hip) with respect to another object (such as a torso)

The muscles are ‘PD’ functions (proportional-derivative). At each frame the functions return the torque value that must be applied at a given joint to attempt to reach a given ‘pose’. These actually behave more like damped-springs than muscles.

The poses are defined by a ‘finite state machine’. This is a set of inputs and instructions that tell the robot (or a part of the robot) what state, or pose, it should try to be in. For example, the robots current ‘state’ is its left leg is down (‘stance’ state) and its right leg is swinging (‘swing’ state). The robot detects that its swing leg is now ahead of the stance leg and has made contact with the ground. The state machine will now instruct the stance leg to change to the swing state, and vice-versa.

There are other states that determine what to do when the robot is off-balance (center-of-mass outside of center-of feet) and when the legs become crossed. The monopod has other sensors and states that determine if it in at a safe position to flip or if it should just hop (sometimes comes up wrong), and compensates for linear velocity (tries to slow forward momentum after each jump)

The weird glowing red walking machines are another thing entirely.

These are not programs, they are structures ‘built’ in a game that work pretty much like they look like they work. The only ‘animation’ that is done is that their ‘motor’, red glowing thing is rotated by magical hogwarts force. Everything else is a result of that motion. Axles, cranks, rods, levers, etc, do what you’d expect them to do (though with infinite strength and sometimes invisible and/or impossible connections)

The designs are more or less lifted. The hexapod and ‘toothpicks’ are the only ones I didn’t actually look at internal blueprints of something for, and those are clearly not original mechanisms either.

There are a few other tests and experiments that worked their way into this collection but I won’t go into detail about those. If you’re curious- ask. Better yet, look it up. Better still, figure it out yourself.

———FOR THE BLENDER/3D INCLINED———

—POSE CONTROLLERS—
Simple pose controlled ‘robots’ were created in Python after studying the work of Ari Shapiro (DANCE Dynamic Animation and Control Environment) and Philippe Beaudoin (SIMBICON/Cartwheel-3d). Primarily
-Generalized Biped Walking Control. Siggraph 2010
-Composable Controllers. – Siggraph 2001
-Controller Development. – Siggraph 2007

Not surprisingly, most of the brilliant methods put forth in these papers are absent in these programs. These are just ‘steps’ towards gaining a better understanding of dynamic character control concepts.

These robots are finite state machines with proportional derivative controller ‘muscles’. They also respond to feedback provided by center-of-mass, foot contact with ground, swing/stance foot positions relative to center of mass and torso heading. Uno knows the ‘uprightness’ vector between the feet and torso. Deuce can also detect if his feet are crossed, and will attempt to correct by standing on one leg and swinging the front leg outwards. They also have threshold ‘KO velocities’ beyond which they will go limp. This should be from acceleration but this works for now.

These robots run independent copies of their controllers so they can be copied for rudimentary crowd simulation. Their individual ‘heading goal’ is controlled by a ‘game property’ string in the robots ‘torso’ object. The goal can be another objects name, or use the prefix ‘a:’ then an angle (in degrees). Do not change the object names or numeration after copying, the program depends on these.

DEUCE – v.0001a of my ultimate goal of creating a real-time interactive break-dancing/kung-fu-master/soccer-playing/gymnast pose controller. What the heck- let’s throw in piano and chess-playing too. 15 DOF: Torso-XYZ, Hips-XYZ, Knees-X, Ankles-XY. Next version I will probably add 1-DOF toes and change Ankles from Pitch/Roll to Pitch/Yaw. I plan to utilize more of the SIMBICON methods and I am also looking at work on ‘genetic algorithms’ for evolving different controller params.

UNO – Created as a study for balance feedback. Eventually learned to hop, then to flip (sort of). Uno also alters his hip angle to compensate for linear velocity to try to stabilize his momentum after each jump. 9 DOF: Same configuration as Deuce

POGO – First study of proportional derivative controller. Just a collision sensor that triggers an upward force. Uses PD to angle the peg to compensate for linear velocity on the next bounce.

—RIGID BODY CONSTRAINT WALKING MACHINES—
Obviously a ‘dumber’ approach to walking animation, though strangely visually appealing. It started with a goofy thought, and ended with hours and hours of trial-and-error learning how bge handles various constraint configuations. There is a lot more that could be done with this technique. These are just a few setups.

THEO – based on Theo Jansen’s ‘Jansen Mechanism’
GOODWIN – based on W.F. Goodwin’s – ‘Automatic Toy’
NOGOODWIN – based on W.F. Goodwin’s – ‘Horse Toy’.
HEX – a semi-original design derived from observations of several 6-legged robot designs.
LE STECCHINI – based on those ubiquitous wind up walking toys we all know and love.

—OTHER—
MORTIMER/RINGO – Extremely simple self-firing ‘mortar’ objects. Created to test uno/deuce reaction to perturbation. Actually these should serve as a warning to anyone who thinks Algebra isn’t important. I got tired of trying to learn all the stuff I avoided learning in high school so I ended up finding the midpoint between the mortar and target, choosing an arbitrary height and firing on that vector. Amazingly, it’s a functional targeting system but it’s an insult to mathematics.

DRAWN-AND-QUARTERED RAGDOLL – Joint constraints had to be created programmatically (as opposed to using Blender UI constraints) so joints could be removed in the simulation. Keyboard events trigger joint ‘breaks’. I could probably figure out a way to calculate limb tension and trigger breaks based on a threshhold- but the whole thing was kind of a lark anyway.

TAD – Failed attempt to create a stable unpowered ‘passive walker’ based on Tad McGeers work. Has never taken more than three steps. Unpowered passive walkers are pretty sensitive to begin with and I’m not sure if a game engine simulation is enough to create one that works anything like in real-life. I’ll give it another go at some point.

H.M.S. STUPID – Another early test. A board that keeps level by using 4 ‘thrusters’. Each fires only if it is below the thruster on the opposite side.

—FILES—
All the models/rigs/programs in this .blend file are free to use for any non-machines-destroying-humanity related purposes as far as I’m concerned. Though keep in mind, though this work is original, some of the concepts and designs utilized and referenced are not. The Jansen Mechanism for instance; I have no idea what kind of intellectual property that is.

If you do use these for anything I’d appreciate a nod.

Word to your matrix.

teldredge

  20 Responses to “Progranimation – A study in physics based animation”

  1. teldredge, I am impressed, what you did!
    So you mean that SIGGRAPH (2010) paper should be read?
    Greets
    Peter

  2. Pretty awesome motion. Enjoyable to watch and listen. I love the credits.

  3. Really cool.

    What I would really like is a way to use this system to create the in-betweens for traditional keyframed animation.

    • SIMMOCAP also uses an approach like that. I might try to use blenders poselib to define state goals for joints but this controller is too simple to tween like that yet.

  4. Very impressed!!! I’m also working in a physic simulation… mine much simpler (balls as rigid bodys jumping around). My problem is that I’m also learning to program in python, so it will take time!

    congratulations!!!

  5. OK, so how does the UNO somersault work? It looks alright, but then it just seems to stop turning, as if the rotation momentum had gone. Is that a non-physical trick?
    Also: Have you been playing sodaplay a lot? Cause it sure looks like you have.

    Cheers,
    Zak

    • Yeah, his torso servo kicks in and gives him an unnatural drag. It’s a bit of a bug. The state machine for the flip is pretty hacky. Still working on a more versatile setup.

      • Well I guess doing a flip with one of those is not easily done if the surface isn’t even level.
        A human can’t do it either without knowing where he’s gonna land, at least roughly, and I guess your actors aren’t aware of things like that. it would have to either not jump as high or turn slower depending on what level it’s gonna land on.
        It looks as if its timing might work just fine on a flat surface, though (does it?). I mean, even that would be difficult for a human, on just one leg …

        That said, and besides the rest of the physics which are cool (and look pretty real), the whole style and the mechanics of all the machines are really really lovely. Well done!

  6. I can not download the file, would be helpful if you could clarify, the managers tried to download, but I could not, appears to like the movie Matrix, I’m not expert on the subject but it is exactly the content that I’m studying, I know the animation, was very good I have some good ideas so that I can not run the tool without knowing better, thanks.

  7. clarifying, not that I want to do scenes from the movie Matrix was a joke, than appears on the page when I try to visualize it. thanks again.

  8. I am studying his examples, very good. Thank you.

  9. I tried to do this kind of stuff some month ago, specialy with the strandbeest legs, but had a good load of problems with joints escaping the constraints too easely… (and finaly left the thing untouched since)
    I’ll look into those blend file with care, ‘cos this is realy good someone found a way…
    thanks for the sharing !

  10. Awesome.

    The one-legged caped Uno character has such a strong personality. How about giving him the Blender logo for a head (extruded in profile and with a slice out of the outer orange ring for a mouth) then rounding and cartoonyfying his body in blue, leg in orange, foot in blue and cape in orange, and animate him on an heroic acrobatic jumping and somersaulting parkour style adventure through a cityscape. He could be an iconic character for Blender (and Blenderheads) and be an amusing parody of the famous Luxo Jr. character that Pixar created…

    http://en.wikipedia.org/wiki/Luxo_Jr.

    And imagine a parkour Blender physics game where the player controls Uno.

  11. Really great thing, it’s undeniable.
    I’m just curious, if Duoce would handle more weight attached on him. I’m gonna try to analyse it, though I usually use C++, and avoid Python. Oh well, it can’t be that hard…
    Anyway, pro made job.

  12. [...] is the unexpected result of some of what I learned from the whole progranimation thing. I thought I would make a more complex pose-control system, but I ended up wanting to make a [...]

  13. [...] is the unexpected result of some of what I learned from the whole progranimation thing. I thought I would make a more complex pose-control system, but I ended up wanting to make a [...]

  14. Very nice script! Demos are miraculous, congratulations!

    Tade-movie
    My first experiments… The site is Hungarian but ProgrAnimation is readable.

    Tade

  15. [...] Animation data generated in real-time simulations. Finite state machine/PD pose control and rigid body constraint walking machines. made with Blender 2.56 / Python files available here http://www.funkboxing.com/wordpress/?p=267 [...]

  16. Ah! I take a small coffee break from the blogging cosmos and come back to find that you have become amazing?
    ! Wow, times have changed! Keep up the far out
    work!

  17. I enjoy reading this kind of stuff. Thanks for sharing good knowledge

Leave a Reply

%d bloggers like this: