A ‘Big ‘ Challenge for groups of programmers has been created by Nonki. We are recruiting during August for development in September.

In summary the challenge is to create a marionette puppet in Small Basic, here is an extract of the challenge:

*“create a marionette (or puppet) per group which can be moved by user interaction”*

If you fancy working on this in a group effort, **whatever your programming level**, then add a post to the Small Basic Big Challenge Thread. Working in a group can make learning programming more fun.

This blog outlines some ideas for the physics part of the challenge which could be a bit tricky, other aspects of the challenge not addressed here include:

- marionette (or puppet) graphics
- user interface design
- user control

# Physical Principals

Basically, a marionette will consist of limbs connected together. We can say that each limb will have a certain length (L) and perhaps a mass (M). The limbs could all have equal mass or have a mass dependent on the limb size in some way.

The limbs are connected at joints (or nodes), so each node has one or more limbs connected to it.

The simplest analogy is to think of the limbs as connected springs to help calculate their movements.

Here are some physical principals.

- When the marionette is stationary, the force on each node is zero in all directions.
- The limbs connected to a node exert a force down (+Y) proportional to the limb mass.
- If the limbs are stretched beyond their natural length then they are in tension and exert a force proportion to the extension in a direction to contract the limb.
- If the limbs are compressed below their natural length then they are in compression and may exert a force proportional to the compression in a direction to extend the limb.
- Strings connected to limbs only act in tension (strings cannot push something, they only pull).

# Node Forces

Here is a schematic picture of a node at (X,Y) connected to 3 limbs.

The natural length of the limbs are shown in blue (L1, L2 and L3)

Limbs 1 and 2 are stretched beyond this length by E1 and E2, while limb 3 is compressed by distance C3.

- The force exerted on the central node by limb1 is proportional to E1/L1 in a direction away from the node.
- The force exerted on the central node by limb2 is proportional to E2/L2 in a direction away from the node.
- The force exerted on the central node by limb3 is proportional to C3/L3 in a direction towards the node. This compressive force term is not used for strings, and may optionally also be omitted for limbs.

Each force vector can be resolved into X and Y components, and added separately with a contribution to each node from its connected limbs.

- Assume the node is at (X,Y) and the far end of limb1 is at (X1,Y1), the a vector in the direction of the limb away from the node is (X1-X,Y1-Y), so the force vector for this limb on the node is proportional to (X1-X,Y1-Y) * E1 / L1. Note that the length of the vector (X1-X,Y1-Y) is L1+E1, the length of the stretched or extended limb (Lext).
- Additionally, there is a gravity force down (positive Y direction) on the node proportional to the mass of the connected limbs.
- The gravity and limb stretching forces will need to be suitably scaled to provide smooth movement. Scaling will just be fixed numbers that multiply the forces or gravity terms.

Where a and b are scaling factors and Lext is the extended (or compressed) length of a limb. If compression is not used, then only terms where Lext > L are included.

# Animation Scheme

The exact physics isn’t that critical, just the basic principals.

- If the limbs are too ‘stiff’ with large forces (large scaling factor a) the scheme may oscillate or be unstable, if the limbs are too ‘springy’ they may stretch unrealistically far – its a balance to what ‘looks good’.
- If the gravity forces are too large (large scaling factor b) then the limbs may be stretched too far, if the gravity forces are too weak then the marionette will tend to float about and not fall realistically as it is moved.

The net force vectors (Fx,Fy) for each node are calculated, then used to move the nodes towards stationary (zero net force) positions. We can move the nodes by an amount proportional to the net forces and their directions, then recalculate everything with the updated node positions.

, where c is another scaling factor.

In some cases, stability may be improved by averaging (Fx,Fy) from one step to the next to reduce oscillation about a zero force solution.

If the scheme forces are well scaled, then after a few steps the marionette nodes will be balanced with zero net force, until we move the strings. The top of the strings are fixed positions and are moved only by the user in some way.

Wow, thank you, LitDev! Very enlightening!

The concept of limb pieces stretching and compressing, while not impossible, is not standard in a marionette. What one will expect to see is a pendulum effect with decay over time as the limbs are pulled into motion by the strings.

Chris,

True, but a true rigid body rotating scheme would be much harder to code (implicit using canonics and Lagrangians), especially in Small Basic. While not absolutely rigorous, this simple explicit scheme with a little stretch looks physically realistic (limbs do swing like a damped pendulum to rest). Often the point is to do it simple, fast and stable rather than honor all physics exactly.

This is similar to the type of scheme used by most games physics engines (they also usually conserve linear and angular momentum whereas this is approximated here), but they do treat connected rotating joints as slightly stretchy to calculate restoring forces for an explicit formulation force balance solver.

This is the prototype I was playing with, import VTD423.

I just added rain to litdevs prototype:

smallbasic.com/program

Thanks Jibba Jabba!