From what I've seen, leaf_index keys (used for insert, remove, etc with Bvh) are current u32. However, leaf_node_indices is using usize keys, which will be 64-bit on 64-bit systems.
My problem lies in having data in a SlotMap with 64-bit keys, and wanting to perform collision detection on that. It would be trivial to do if either the leaf_index was generic (or at least 64-bit). However, since I only care about 64-bit support, I would be happy enough to have it take a usize instead of a u32 and just avoid the casting internally. If not, I'll have to keep a secondary table to map the collision indices to the SlotMap keys adding significant overhead to the process.
A similar (but much older) thing is discussed in #117 , which discusses making it generic over keys of Eq + Ord + Hash, which I don't think is necessary to be so strict as internally Bvh is using VecMap, however, using HashMap may be faster.
From what I've seen,
leaf_indexkeys (used forinsert,remove, etc withBvh) are currentu32. However,leaf_node_indicesis usingusizekeys, which will be 64-bit on 64-bit systems.My problem lies in having data in a
SlotMapwith 64-bit keys, and wanting to perform collision detection on that. It would be trivial to do if either theleaf_indexwas generic (or at least 64-bit). However, since I only care about 64-bit support, I would be happy enough to have it take ausizeinstead of au32and just avoid the casting internally. If not, I'll have to keep a secondary table to map the collision indices to theSlotMapkeys adding significant overhead to the process.A similar (but much older) thing is discussed in #117 , which discusses making it generic over keys of
Eq + Ord + Hash, which I don't think is necessary to be so strict as internallyBvhis usingVecMap, however, usingHashMapmay be faster.