New Broad Phase Detector (SingleSweepDetector)

[BioSlayer]

I have designed a new broad phase Detector called SingleSweepDetector
that kicks sweep and prunes butt.

It's like sweep and prune in that it sorts a list of nodes but it only
maintains one list of nodes. It does a sweep just like sweep and prune
on one axis but instead of storing this result for the second sweep it
just goes ahead and tests for a collision on the second axis.

It uses the single node list to represent the axis with the least
collisions. It determines which axis has the least collisions by
switching to the one it thinks has more every 7th time step and stores
the results. Look at the code in the SVN to get a better picture.

SingleSweepDetector is 2-3 times faster then SweepAndPruneDetector,
according to my profiler (nProf), based off percentage of CPU time
used. I would have to get a better profiler to make an actual
comparison.

[Daniel Story]

Thanks for the update, just for the heck of it. I downloaded and
compiled the SVN version, imported it into a demo I made (boxes that
fall on-top of a platform). I then increased the boxes count to 25625
(yeah I know, I'm crazy).

"SweepAndPruneDetector" would update roughly every second.
"SingleSweepDetector" would update three times then pause for roughly
half a second.

Guess you can't really "judge" the speed of these 'eye' measurements,
but it answers a what if question...
"What if you had 25626 boxes applied to physics?"

Anyways, I'll much enjoy the release of 1.5 :-)

[BioSlayer]

I have just implemented a different and better implementation then the
SingleSweepDetector I have called the SelectiveSweepDetector. This one
keeps the 2 list nodes of sweep and prune and sorts both of them but
does not do the sweep and prune. It uses both lists to do a linear
test on both to find out which has the least collisions then runs the
single sweep on that list of nodes.

It does not have the stutter that you where talking about and does
seems to run faster then Single sweep, but it has to sort the 2 lists
or nodes and the profiler tells me this is the most expensive part of
the algorithm (with 25,000 objects).

I'm thinking about keeping the SingleSweepDetector because it does
less sorting. What do you think I should do? Keep it or delete it?

I made a demo like you were talking about with over 25,000 objects,
and it ran better then I was expecting (I thought you had some kind of
super computer) with a few updates a second.

I also accidentally made a demo that had 250,000 objects and Vista
froze. So don't try this at home!

> > comparison.- Hide quoted text -
>
> - Show quoted text -

[Daniel Story]

While I don't have the complete understanding of each of the detector
classes, but each one I presume has a strength and weakness; being
that for less of accuracy you get speed. As the physics library isn't
aimed at one type of game genre/type it makes it a test bay for which
detector runs best for a type of game. e.g. A platform game v.s. a
pool game. While a platform game is fun with physics applied, It
doesn't require much accuracy; aka "If it looks right, it is right".
For a pool/billiard game your going to want accuracy over speed; pool
is a much more controlled environment, there is only going to be a max
number of physically enabled objects in the "level" and only three
ways for the objects to encounter collisions.

So one detector might be better for a platform game while another for
the pool game. Besides all the more to add to the "feature" list ;-)