Hash space unnecessary slow.

[Bram Stolk]

From the ODE sources:

void dxHashSpace::collide2 (void *data, dxGeom *geom,
                            dNearCallback *callback)
{
    dAASSERT (geom && callback);

    // this could take advantage of the hash structure to avoid
    // O(n2) complexity, but it does not yet.

    lock_count++;
    cleanGeoms();
    geom->recomputeAABB();

    // intersect bounding boxes
    for (dxGeom *g=first; g; g=g->next) {
        if (GEOM_ENABLED(g)) collideAABBs (g,geom,data,callback);
    }

    lock_count--;
}

So colliding against a hash space is not accelerated at all, it visits all entries in the hash space, acting like a simple space.

[Daniel K. O.]

ODE's spatial hashing is not persistent. The hash table is computed during the call to collide, then discarded. The SAP space uses a similar approach. This is just a design decision; the code is simpler (since the data structure is never updated), while sacrificing performance on a use case deemed less important (by whoever implemented those spaces to work like this). We either need dxHashSpace to be rewritten, or a note added to dCollide2's documentation warning that a space might not accelerate this kind of query.