[ODE] [ opende-Patches-1335198 ] Sweep and Prune Space

[David Walters]

> It does seem slightly better - it now outperforms QuadTree space by a
> small amount (2-3%) for the test case I was previously working with.

That's great to hear, glad I could help.


> I'm using GIMPACT and everything builds fine out-of-the-box (linux gcc
> 4.0.2) - single precisions only here, because of existing issues with
> double/GIMPACT, though. I've not seen any memory leaks.

The SVN mailing list seems to have skipped reporting a checkin I've
just made (despite logging SVN #1303 that I put in straight
afterwards) - so I'll just say here that I've ripped out my redundant
scratchpad buffer and replaced it with a dArray. This shrinks the code
a little and should operate at the same performance.

I also fixed the 64-bit warnings. They occurred from the hijacking of
the geom pointer values intended for a space to uses as a linked list,
but used here to store index values. There are no mixing of genuine
pointers and integers so it was safe to silence them.


> I'd love to see some documentation on this added to the Wiki, if
> possible, especially regarding how to establish what the best "axis"
> might be for a given configuration.

Well, although it wasn't a straight job of importing a patch, the work
I have done on this is just to make it comply with ODE's requirements
for spaces and a few optimisations - the core work should be credited
to Aras Pranckevicius for the submission and Pierre Terdiman for the
radix sort function.

I roughly understand what it's doing but not to the extent that I
could write any meaningful documention. I know the gist is to pick an
axis order such that your 'up' is last, so XZY typically - but I have
no idea why!

Your best bet is if Aras is reading this list, and he could comment on
the specifics for tuning. Alternatively profile the options as it will
obviously have some degree of dependence on the world you're
simulating. I suppose also doing some research on SAP as a general
concept might help?


> It's a great job as far as I can tell so far, and will be using it as my
> "default" collision space in the future!

I've always stuck with hash space because it's zero configuration, but
never really experimented with the alternatives - this certainly wins
on the low effort front!

Glad to have contributed,
Dave