Archive for October, 2008


islands + rigid body sleep + time of impact

October 30, 2008

So, on the topic of time of impact.  The first thing I realized, is that time of impact calculations if done with the proper time conservation (advance all by nearest time of impact, solve, and repeat until timestep is gone) are enormously costly for massive groups of bodies.  This is because you update EVERY BODY in the system all those times whether you need to or not.  A good fix, which is also practical for putting bodies to sleep, is solver islands.  Basically, isolate groups of topologically adjacent bodies through contacts and constraints.  Then simulate them independently, including doing less TOI substeps for islands that don’t need that many.  It’s actually not even possible to do the unneccessary steps on an island solver architecture.  The reason this is also good for the sleeping scheme, is that putting islands to sleep as a whole instead of each body individually is much more stable, because you know that once all have settled, there is nothing still moving to keep the others awake.  And again, doing this per island allows you to be more efficient, because per body takes longer and is less stable, and per world is useless because there is always something moving in a video game.

Well, one of my dad’s friends reviewed my presentation (he’s an electrical engineer with programming experience in microcontrollers) and he said it was so good it could get me in to MIT.  I have a good feeling about this.  😀


looks like talk is a go + preparation of examples

October 25, 2008

So, it looks like the talk is gonna be a GO.  :3  We’re reserving a room for some coming Tuesday.  I’m basically preparing like a crazy person, because I need to make this count.  Think about it… this could literally evolve in to a free ride for me.

I’ve got my slides, peer reviewed them with a friend, (who was surprisingly supportive,) and got my presentation planned.  Now I’m working on the software aspects of my presentation.  I want the examples program to be at least half full of numbered demos.  I’ve got a Pinchinco like example with balls falling through triangular pegs, but I also want some more practical demonstrations.  Varying restitution, varying friction, dominos, maybe a character control application demo.  I fixed the timing code in both the testbed and the examples program, so that’s all good.

It’s a race to the finish line, and this time it’s not on a motherfucking circle track!  There’s actual progress to be made!  Why couldn’t highschool ever be like that?


time of impact islands + talk presentation thingy

October 23, 2008

HEY HEY HEY HEY HEY HEY HEY HEY *gets smacked down*


You’re not guessing.  I’ll tell you!  I’m actually giving a talk at Columbia College about my physics project.  Here’s essentially what I got off Dr. Liow.  Dr. Liow is probably one of the best people to recognize anything you do, because he seems like he’d be honest if he didn’t like what you’ve done.  In an email he was all: “Your program is interesting.  Do you want to give a talk about it during lunch, blabitty bloo, blabitty bloo, blabitty bloo, it’s totally unofficial, blabitty bloo, it’s in a room with some people, blabitty bloo, blabitty bloo, this is totally gonna be like a presentation during lunch so omg r u interested?”  Man, I hope he doesn’t read that.  Meh, I don’t really care.  Anyway, I was all “shit yeah” and he’s all “omg I haven’t even checked my email yet so I haven’t responded yet.”  So I’m still waiting for a reply.  But I’m psyched, and I really like the idea of publicising my physics engine, if even on a local scale, so I’m definitely going to be there.  I’m gonna make slides, demos, tacos, nachos, and paper mache!  Okay, actually just slides and demos.  Can you tell I’m giddy?  Huh?  Is it showing?  ANSWER ME!  YAAAAAAAYYYYY!!!!!!!!

This is pretty awesome.  All I’m sayin’.

NOW.  On the topic of actual work that I’m doing on physics.  You may have thought about time of impact and how it would slow everything down.  You’re damn right it will.  The question is, how can we optimize it as much as possible?  In the most accurate TOI model, you find the pending collision with the smallest TOI, advance by that amount, (of course setting a minimum fraction of total timestep so we don’t get stuck at toi==0.0 forever,) handle collisions normally, run the impulse solver, and repeat until the timestep is done.  But what about Joe McStranded off in the distance who won’t collide with anyone for at least a dozen frames?  Should we waste time sub stepping him?  NO.

The solution: islands.  This is a technique I am shamelessly stealing from Bullet Physics.  But we all stand on the shoulders of giants, right?  Anyway, an island is essentially a field of objects which will all interact with one another in the next frame.  An island of objects are all linked by constraints, contacts, and bounding box sweeps.  Anything which may collide with other bodies in the island or be affected by a body in the island is in, basically. This means the loners are all omitted from the expensive sub steps in time of impact solving, and this also means smaller islands who will do less sub steps than the bigger ones.

So, as for sweep algorithms, I have circles down, and I’m trying to do the MSA-sweep now.  I’m not exactly sure of how it will turn out on rotating bodies, as I’ve said before.  I may wind up using the conservative advancement method.  I’ve said this before, I’m just rehashing it.

Think about using islands in your own work.


CCD stuff

October 21, 2008

Aaah, the many ways of doing continuous collision.  After looking at conservative advancement in Box2D, I realized it just wasn’t what I needed.  I wanted a process that could finish in one iteration.  So I started looking at sweep tests, and my first was circle-circle sweeps.

Basically circle-circle sweeps are a quadratic equation, where A is the relative velocity squared, B is two times the relative velocity dotted with their relative position, and C is their relative position squared minus the sum of their radii squared.  BLARGH!  So, here’s the math:

v is a vector describing their relative velocity
p is a vector describing their relative position


Then you just crunch that with the good ol’ quadratic formula and the smallest of your two roots is the time of impact.  The larger root would be the time they separate after passing through eachother, but who the fuck needs that?  Not me.  Here’s a picture.  Joooocy peeectoooor.  Yaaaaah.

Aaaaw yeeeaaaah.  It’s an exact answer too, no dicking around with approximations.

Polygons might be trickier though.  I CAN get an exact answer using extended separating axis, (where each axis’ interval is extended by the velocity component dotted with said axis,) but it is only a result given linear velocity.  When you have screw motion, it becomes approximate, because a lot can change between now and projected time of impact when they rotate.  You may wind up hitting totally wrong, or worse, missing just as badly.  So, I may need conservative advancement for this one, or else I’ll have to dig for papers on Google about more advanced methods my feeble brain can barely comprehend.

More on this later.  For now, I will headbang.  To Dream Theater.


continuous collision detection

October 18, 2008

Do you people think it’s about time?  HUH?  Well, I do.  So, several things are planned for addition soon.  This will involve a lot of lists:

  • 0 degrees of freedom constraint: pivot constraints (the anchor point on each object are forced to share a common point in global space.)  Basically a bar constraint, but with a length of zero.  This is needed because a length of zero creates a singularity in bar constraints.
  • 2 degrees of freedom constraint: groove constraints (probably.)
  • Continuous Collision Detection by means of sweep test + a time of impact advancement method.

In the future, I will probably add force fields, but not just yet, all we have is the global gravity constant for now.  My current collision algorithm is completely discrete, and is as follows:

  1. Update positions by delta time.
  2. Cache AABBs and world transforms.
  3. Check for intersections.
  4. Generate collision contacts and update arbiters.
  5. Do response.

Continuous collision detection is trickier:

  1. Cache swept AABBs and swept world transforms using the Minkowski Sum method or gift wrap method.  With the Minkowski Sum you could do an iterative deformation for orientation movement, but only if you wanted to handle potentially concave hulls.
  2. Check for sweep intersections.
  3. For each sweep intersection calculate the time of impact of the two hulls.  The best method in my opinion is a convex cast, but there are more accurate ways out there.  The time of impact should have a slight slop to it.
  4. Then take each of those and update positions by time of impact and accumulate lost time as delta time minus time of impact, and update the rest by delta time plus time lost in any previous TOI (time of impact) collisions.
  5. Cache world transforms.
  6. Check for intersections.
  7. Generate collision contacts and update arbiters.
  8. Do response.

As you can clearly see, the only complex part is updating of the position based on advanced timing.  After that, it’s just like the discrete method, as none of the actual collision handling is different.  We’re just making sure there is no tunneling, that is, nothing can pass through anything else.  This is a huge undertaking.  As such, this is a big milestone.  I’ll keep people in the loop about progress as much as I feel like it.

Peace  🙂


the python modules are available

October 17, 2008

At long last, I have something for you to get!  These Python modules are compiled against Rat Physics rev. 286.  In the Windows package, you will find three directories, each labeled win32-2.x.  Replace the ‘x’ with your version of Python, go to that directory, and run

If a Python error says that the module is linked to the wrong version of Python, which is unlikely, simply change the version in the makefile.  The makefile is like 5 lines long, I doubt you’ll have problems with it.  Please note that you MUST have SWIG installed to rebuild the module.

The GNU/Linux version is the same deal, except there are no version options, it is just compiled with the latest version.  You can modify the makefile to suit your version if you don’t have Python 2.5.

Here are the downloads:

GNU/Linux Rat Physics rev. 286 bound against Python 2.5
Win32 Rat Physics rev. 286 bound against Python 2.4, 2.5, and 2.6



October 16, 2008

So, I’ve been hard at work, and here’s what I’ve done.  First off, on campus, Dr. Liow REALLY wanted me to do a python project.  Why?  Because in some strange way it made me a freeloader to hang around in a club where the point was messing with python without actually doing Python.  I was really just there to talk to other people, mostly students there.  So, what I did to make him happy, was Python bindings for my physics engine and  a small demo.  YAY!  Here are some shots of knocking over a tower.  Remember, running in Python, but using my physics engine, which as you probably know is in C.  Check this shit:

oh, yeah, it's a tower.

oh, yeah, it's a tower

let's get ready to rumble, bitches!

let's get ready to rumble, bitches!

steady now...

steady now...

we're down, son!

we're down, son!

It wasn’t that hard.  I used SWIG based on the apparently valid opinions on it from this guy and this guy.  I was really pleased with the results! 🙂  The one thing I had trouble coming to terms with though, was callbacks.  I have world_something_callback(rat_world *world,whateverargs) calls, and setting up a callback system was hard  and ultimately something I failed at.  Here’s why:

I have a function used to set the callback: rat_world_set_body_left_world_callback(rat_world *world,body_left_world_callback *cb).   What I wanted to do was pass a C function that could call a python callable object and convert the arguments properly.  The store the PyObject somewhere I could get back to it.  All went according to plan, until I tried to set up the arguments.  I found I simply didn’t know how I could convert the C (rat_world *) pointer in to the PyObject rat_world class set up by SWIG.  No matter how I diced it, I just couldn’t find a way to pull the whole thing together.  I messed with the idea of SWIG_NewPointerObj, but even with that external runtime header, I could access the type information, because it only defined functions.  Still, the rest of it looks fine.  I’ll be in touch.  And on the C front, I’ve fixed all that sloppy inlining and some really major memory problems with constraints.  So, back to work.

Bye. :3