Posts Tagged ‘algorithm’

h1

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  🙂

h1

new educational page

September 18, 2008

This is a blog about programming and technology and stuff.  Music and art may come up occasionally, but that’s not really the focus.  Therefore I must not only make an ass of myself by ranting at the world from a pathetic blog, I must also be USEFUL.  So, I’ve decided to keep a seires of pages about various programming topics on here.  I’ve just finished my first.  It’s on spheres, and how to render them without resorting to the dreaded longitude/latitude fiasco.  I give an approach which was detailed in the OpenGL Red Book, but for some reason, no sample that I know of was given.  None that was simple and easy anyway, as everyone is confused about how to do it.  So I did a page with a simple source sample that’s very self explanitory using OpenGL to draw these suckers.  I also went in to a fairly complicated and deep discussion of why latitude and longitude are not only an inefficient rendering approach, but that they are also skewed (which is what makes them inefficient for rendering) and an obsolete coordinate system in general.  Spherical geometry must be used for newer coordinate systems.  Then I explain great circles and how they can be used to… blah blah blah… hull… blah… just read it.  😛