Posts Tagged ‘2d physics’


interwebs are back! new laptop arrived! CAMERAS!

November 27, 2008


afk is a fairly disgusting statement.  It was coined by a friend who thought there should be texting abbreviation for anally fucking kittens.  He came up with it.  Not me.  Though it does make a great expletive.  gggrrrraaAAAHHH!  ANALLY FUCKING KITTENS, THIS SUCKS!  Packs a punch.

Now that I have full access to ye olde intarwebz0rz again, allow me to fill you in: my new laptop is here.  Yes here.  Not almost here, ACTUALLY HERE!  It runs Ubuntu 8.10 Intrepid perfectly, and Windows Vista because if I take it off I’ll lose the software license.  Microsoft bitches.

I have tested my stuff under Vista though, and I was pleasantly surprised that it ran!  My code has always been very raw and portable, something I am very proud of.  It also runs on Ubuntu Intrepid just fine.  Actually, better than anywhere else, because this is an AMD64 (Athlon64X2) machine.  It came with 32-bit Windows, which makes no sense to me, it’s like putting two toilets in an apartment with only one ass.  But the Ubuntu half is full on 64-bit, and I have to say it’s a big improvement, especially since this baby is dual core.  Multitasking!  Also, the physics engine has a build now just for 64-bit GNU/Linux, available through both GNU Make and C::B projects.  It’s really fast on this machine, and this build is always double precision too, because of the 64 bittage!

Here’s a screenshot of the pyramid example running on the laptop:



Yeah.  Now look at the zooming in on the frame rate:



Okay, that’s about it.

But hey, webcam fun! 🙂  LOOOOKIIIT



Yes, the laptop has a webcam to.  Camgasm that’s awesome.

Oh, wait!  I’ve also just been messing around with shaders, because my laptop can actually handle this shit!  This is my phong lighting shader.  I have it split in to ambient and diffuse/specular passes, so that luminance occlusion multipass shadows can be easily integrated.  I’m working on a shadow mapper right now.  But anyway, last picture:


See all y’alls!


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.


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