Octree + COLDET Pitfall

not sure I understand, but usually, particles are bounded by a box, taking into account their displacement in a frame. You test the particle''s box against the octree and gather the triangles in the intersected leaves in a list, and test for collisions with those triangles. When a collision is found, the particle is reflected/bounced, the box around the particle is recomputed, and the you test the particle''s box vs. the octree again to find the next collision.

Alternatively, yuo can make the particle box bigger, to account for possible change in direction, and you collect the potentially collidiong triangle once, and bounce the particle off them.

You can also have a in-between (more like a fail-safe system) culling algo. When the particle bounce, you re-compute the box again, and only if the new box is not fully contained into the previous box, you test the octree again.

if you don''t use a bounding box, then you trace the ray/segement of the particle movement into the octree everytime you find a collision. Particles aren''t supposed to move that much, so the bounding box can work better. It''s easier to test a box vs a box in the octree than a ray/segment versus a box in the octree.

I myself use loose compressed AABB binary trees. like a CAABBBtree

I came up with a temporary fix (may become permanent if I can''t find a better way).
For each environment model, create 2 octrees; one for visibility culling (irrelevant) and one for collision detection. The coldet octree starts off as a visibility octree, and becomes a coldet octree by making each node''s size bigger (size+=size/3). I know this negates some of the efficiency in the octree system, but it appears to work for the most part.