From the ODE sources:
#!c++
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.
[Issue created by bram_stolk: 2014-10-31]
[Last updated on bitbucket: 2015-01-11]
[Comment created by danielko: 2015-01-11]
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.
From the ODE sources:
So colliding against a hash space is not accelerated at all, it visits all entries in the hash space, acting like a simple space.
[Issue created by bram_stolk: 2014-10-31]
[Last updated on bitbucket: 2015-01-11]
[Comment created by danielko: 2015-01-11]
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.