Real-Time Physics Simulation Forum

Hey,
We've finally updated our blog with demos of our simulator:
http://www.metanetsoftware.com/blog/?p=23
http://www.metanetsoftware.com/robotolo ... hys01.html

Right now it's not that impressive; we have lots of other stuff working (collision/friction/motors) however we haven't had time to make decent test-scenes. Soon hopefully..

There is also a lot that remains to be done in terms of design -- the biggest benefit of this approach IMHO is the generality afforded by it.. you can plug together all sorts of different "degrees of freedom", for instance connecting the orientation of bodyA to the distance of a point on bodyB measured along a polyline anchored to bodyC; as B moves relative to C, A will rotate. Sadly we're not experienced enough at software engineering to have properly figured this all out yet, so for now things are more or less limited to the standard rigid-body types of constraints.

In a month or so when we have more time to work on it, we'll be posting more demos including some robotics-related stuff.

Thanks,
raigan

Very nice.

I've been reading thru these papers. Interesting stuff. One piece I'm not clear on for rigid bodies is how moment of intertia is handled when everything is basically just a bunch of connected points that get re-positioned every frame.

I'm not done with the papers yet so maybe it's in there....

Anyway, very nice work.

Moment of inertia is definitely the most "ad-hoc" aspect of our simulation, as the dynamics model for each body is a single stick -- which means that the mass distribution will always be symmetrical (reflected across the stick axis).

In practice we just use a stick that's as long as the longest body dimension, it seems to feel fairly natural -- if anyone knows of how to calculate this properly, it would be great.. so far we're just using the stick length to model moment of inertia.

I don't have a good answer, but it seems like something that could be pre-computed (an estimate anyway) using the vertex points and the assumption that mass is evenly distributted.

You just want to find the moment of inertia for a 2D polygon? That's really easy actually.

Here's how I do it in Chipmunk (cpMomentForPoly):
http://aerosol.googlecode.com/svn/trunk ... chipmunk.c

I'll see if I can dig up a link with the original equation.

edit: Wikipedia is always a good choice. http://en.wikipedia.org/wiki/List_of_moments_of_inertia

what's needed is, given the moment of inertia of a polygon, find two particle positions which give the same moment of inertia.

i guess this is pretty obvious in hindsight -- it's just really underconstrained.

What if you solve this problem by setting up a constraint and solving it with the method presented in the pbd paper?

something like

c(p1,p2) = [moment of intertia of the line] - [moi of polygon]

just an idea.. what do you think? can the moi of a line ever match that of a polygon?

I might be confused, but since it's just a scalar in 2D, it doesn't encode mass distribution at all -- just the "angular mass" (amount that the body will resist torque).

Which means it should be possible to model the center-of-mass and moment-of-inertia exactly with two particles -- just make sure that their COM is located on the polygon's COM, and that their moment of inertia is identical -- which is just a case of finding the correct distance from the COM to the particles. The actual orientation of the stick is arbitrary/irrelevant. At least, as far as i can determine.

I have toyed around the idea, what always gets me is how big to make the basis Similarly, if you use a triangle - tetrahedron, how to define it's shape and size? This will obviously affect the moment of inertia perceived. I like the solution, but it has shortcomings and is a bit fuzzy round the edges (friction being a pain). Most of the behaviour is emergent, and that's not really useful for 'realism' and controlling the outcome. Why is nothing SIMPLE!

Also, in 3D, there is the problem of collision detection. You will be working with more than just vertices and faces, for the edge-edge case, I am not too sure if the collision should effect on the end vertices of the edge, or generate a constraint at the collision point on the edges, which will require you to recompute the barycentric coordinates of the collision point. How expensive is that? How much of a difference will it make?

At the moment, the best solution, in my view is to deal with segment-face collisions alone, then you can classify collisions as point-face, and edge-edge really easily (if the segment crosses the two faces connected by an edge -> edge-edge!), and apply the solver on the collision points, even if it means re-calculating the barycentric coordinates.

Plus, there is the problem of collisions working through intersection and interference. I'm still thinking on how this would work with a swept test. It can also be very costly computationaly, if you want stiffness.

In any case, it's all part of the fun, an it's great from you to share your wealth like that. Ain't the Internet awesome!