Labs.byHook 

Scripts, Tools & Methods Developed at Hook 
While positionbased dynamics can quickly create cool IK and rope effects due to its particle/constraint structure, it is often mentioned solely in the context of cloth and softbody simulation while rigid body dynamics are only hinted at, and for good reason. Most behaviors of positionbased systems are emergent and make much of the work feel more like alchemy than robotics, melting together a combination of vertices and constraints in hopes that you’ll get something solid and wellbehaved. But those complex behaviors that materialize from such simple means are what makes the positionbased approach so great.
As opposed to particlebased dynamics, rigid body dynamics are differentiated by an additional degree of freedom or 3, along with big scary words like inertia tensor, center of mass, angular momentum, moment of inertia, torque, quaternions, etc. While these concepts are valuable to be aware of, it sure does complicate simulated and interactive movement, so I’m after something I can handle early in the morning without first mainlining a case of Red Bull.
Spending hours sifting through the search engine desert with a hair pick doesn’t turn up much in terms of specific implementation of rigidbodies with positionbased dynamics, but, there are a few decent starting points that can be found, with varying complexity:
Each has a certain driving force behind its use, and along with that, certain strengths and weaknesses. One of the main things I’m looking for is the ability to arbitrarily add particle ‘effectors’ to the body, moving it by imparting both translational and rotational (torque) forces. As such, these particles can represent attachments, contacts, or mass distributions. This is where things start getting esoteric and nebulous, as the pointmasses that make up a body can end up moving in completely independent ways as dictated by other connected bodies or forces. Also, something closer to wellbehaved softbodies would be sweet too.
I plan on running some experimentation with each to get a feel for the nuances and sticking points, or possibly develop a different approach entirely. This post will focus on Jakobsen’s loose box construction (as opposed to the basisvector coordinate/particle system, or the triangle/tetrahedron approach), specifically on applying arbitrary forces to it.
The SpringMass Model
The real strength of the springmass rigid body model as described by Jakobsen is the absolute simplicity with which you can create a simple object that can fall, bounce and settle into place fairly realistically. Besides friction and standingcontacts, this can be implemented completely with the standard Verlet integration and constraint relaxation as discussed previously. The particle dynamics are then magically transformed into rigid body dynamics.
While moving a vertex and thus the body is as simple as moving a particle, applying a torque to somewhere other than a vertex is a little tricky. To this end, I started with a more simplified case based on Jakobsen’s stick collision correction. The objective here was to create an ‘edge’ rigid body, which is pretty much the most basic rigid body type you can get, defined by twoend points (a single point can’t have rotational movement applied so its not a rigid body, deal with it).
The above example illustrates the pointforce that will be used to push the edge. For simplicity’s sake I am using mouse movement, but that could very well be replaced with any sort of force you can boil down to the movement of a particle. Displayed are the crucial pieces of information we need initially: the point on the edge where the collision happened and the movement of the pointforce as created by the collision. What we want to do is move the collision point on the edge towards the particle that flies off, and translate that movement to the edge’s endpoints relative to where along the edge we collided. This is done by using the equations for stick correction as described in ‘Advanced Character Physics’.
The first step is to define point p along the edge. This is done using the equation:
where:
& are the endpoints of our edge, and & are constants (totalling 1) describing where along the edge the points rests. For example, if is the way between and , while . Though a little abstract, what this affords us is less vector or matrix operations doing coordinate conversions, and the location of will adjust as the edge scales. Likewise, because of those constants, we can use it to define points , and after correction:
where indicates the state after correction
To jump off a bit from Jakobsen, I applied the basic distance constraint math to & (our pointforce position) to find as is illustrated here:
As you can see is about midway between and the applied force particle.
This is where Jakobsen gets a little crazy with the linear algebra, and ends up with the following formulas for x1′ and x2′
After digging through his derivation for for a little too long, it turns out to be 1 over the summed squares of the line coefficients:
while is just the displacement vector between & . As you can see, the endpoints are moved relative to how close to they are, this is what gives us that tasty torque rather than just moving the edge along the direction of the pointforce’s movement.
You may notice in the above illustration that while keeps its relative distances intact, the edge stretches (especially in more extreme angles and velocities). This gets corrected in time by the distance constraint binding the edgepoints, so adding additional logic to correct that wasn’t really of concern.
Here I’ve just taken the above code and worked it within my update, with 1 iteration for constraints and it feels pretty tangible. To play around with the implicit momentofinertia created by this technique I’ve modified the original formulas for and to factor in the mass of the system:
where is a weight variable (inverse mass of the pointmass)
To see how this works within the context of a rigid body, I created Jakobsen’s simple box body with an additional cross constraint (cross constraints not shown). The edge model above was then applied to the 4 sides of the box. Through simple distance constraint relaxation, the box maintains its shape, while plausibly being affected by the mouse.
Though I kept these examples minimal with some basic mousestriking to simulate forces, this edge model technique would likely work very well with other methods of applying movement, like attached ropes or springs. How about a good old fashioned pros and cons list?
Pros:
Cons:
Either way, the speed and simplicity with which you can create some simple semirigid forms is astounding, and the springmass technique for rigid bodies can be a great option for more simple projects where a fullblown rigid body simulator would be overkill. But as the bodies start becoming more complex, more constraints are required to keep things in place, becoming more like ducttape than a tool to model behavior.
While the edge model and collision response can definitely be useful in creating ropes and chains (eliminating the inherit gap in rigid joint chains), we are still lacking a truly useful way to define a local coordinate space to apply points to create rigid body effects. To this, a flattened version of Jakoben’s tetrahedral approach may be just the answer, as we can define vertices and pointforces with barycentric coordinates to simplify coordinate conversion. But thats a topic for another post…
@d34n: thanks! more coming, soon
@dfm: you’re correct, I had accounted for that in a formula just below example 3
To acount for mass, I believe the edge resolution also requires:
(upsideDownY) = 1 / (c1 ^ 2 * (w1 / (w1 + w2)) + c2 ^ 2 * (w2 / (w1 + w2)))
This is a brilliant article!
Really informative and well written.
best,
d
[...] Ok, I’ll be the first to admit… logging isn’t the most exciting topic out there especially compared to some of the other hotness on this site: Kutout – An application for cutting out images and Fuzzy Physics – 3.1: Rigid Body Dynamics, pt 1 [...]
[...] experiments (a continuation from my previous post on Jakobsenstyle position based dynamics: here) , the hooplah around the iPad and Apple getting all ‘The Hills’ on Adobe provided a [...]
Yeah, using a stick as a basis is analogous to a triangle, it’s just simpler (or at least, it makes a lot more sense for me); actually now that I think about it, it’s just an extension of your singlestick examples above.
In all cases you have some “embedded” geometry (collision shapes, joint positions) which is defined relative to a dymamic model — the simulated particles — using some sort of “parametric” coordinates (in your above case, a single scalar coordinate describing position between particles; when using a triangle, the coordinates would be a triplet of barycentric weights).
Constraints are defined relative to this embedded geometry, and you then need to figure out how to satisfy them by altering the dynamic model (i.e moving particles around in order to move the embedded points around). Your examples above are great because they’re easy to understand and in they’re exactly what happens in general regardless of the dynamics model — the only thing that changes is the “embedding” equation/coordinates.
Our stick basis (well, one of them.. we found that you can get lots of weird/interesting behaviours by using different bases) is very similar to yours above; you have:
p = c1*x1 + c2*x2
but instead of thinking about it as blending between two points x1,x2 using weights c1,c2, you could also think about it as starting at x1 and adding some amount a of the vector between points (x2x1):
p = x1 + a*(x2 – x1)
This can describe any point on the line containing x1,x2. To get a full 2D space in which to embed points, the wonderful “perp” operator lets us define an axis perpendicular to the line through x1,x2:
p = x1 + a*(x2 – x1) + b*Perp(x2 – x1)
Where Perp(v) = [v.y, v.x]
This provides you with a full 2D coordinate system in which to embed constraint geometry, using the coordinates a,b. Of course, you can construct lots of other types of embedding too, such as:
p = 0.5*(x1+x2) + a*(x2 – x1)/Len(x2 – x1) + b*Perp(x2 – x1)/Len(x2 – x1)
This basis is a bit more complicated, but it behaves better when the particles are stretched (i.e the original basis scales as the particles are stretched, which makes things a bit bouncy; this more complicated basis keeps constraint geometry centered on the midpoint between particles and doesn’t scale as the distance between particles changes).
Anyway, I’m interested to see what you come up with because our understanding is very vague and different perspectives would be useful — it’s quite possible that there are better or different ways to apply these basic ideas.
Raigan
p.s – sorry for belching this out here, I’m definitely an amateur and I don’t really have a great grasp on vector calculus so there’s a lot of fumbling as I struggle to understand the fundamentals of why this all works
Thanks Raigan!
I’m currently doing some tests with a trianglebased/barycentric rigidbody dynamics model (along with haXe and canvas), it’s looking promising thus far. I’m hoping that will give me some greater insight on the stick approach too.
I’m looking forward to seeing what you guys do postGDC, looked like there was amazing stuff on display there!
Yeah, keep up the great posts!
I’m especially interested in hearing your experiences with the stickmodel. We really want to write something up about our experiments, but we want to have a game finished first
These are great, please keep going.
@Petermonium: Yeah, that’s definitely one of the downsides of this approach as noted, it has the possibility to cave in and invert under extreme forces. I’m going to try out a couple other methods to get something stable in the future, hopefully before the Large Hotdog Collider is complete
If you SLAM the box just right, you can get it to deform and spin forever. Hard to reproduce though.