As it is now written, hashIndex(const THREADPTR(T) & blockPos) in ITMSceneRepresentationAccess.h yields the same hashes for some hash block coordinates.
For instance, hashIndex(-6, -6, 90) and hashIndex(6, 6, 90) yields the same value, 122790. In otherwords, changes in sign only to the coordinates tend to yield hash collisions.
In the reconstruction engine, the pixels are first traversed and necessary hash blocks marked in a flag list for allocation in the ordered or the excess lists. The hash blocks are allocated based on the generated flag list.
This means that during the initial pass, when buildHashAllocAndVisibleTypePP is being called, the collisions such as (-6, -6, 90) and (6, 6, 90) blocks are unhandled, and the coordinates for the corresponding hash (e.g. 122790) are being overwritten by whichever occurs last. As a result, some blocks are not at all allocated.
This results in incorrect reconstruction. Simple example: you have a plane perpendicular to the camera axis in the center of the view at the very beginning of the processing, when camera is still at the origin. Instead of a plane, you'll get something that looks like a checkerboard with missing blocks.
The basic single-threaded fix for this is simple, but a thread-safe fix with optimizations is not as trivial.
Algomorph
commented
4 years ago
As it is now written, hashIndex(const THREADPTR(T) & blockPos) in ITMSceneRepresentationAccess.h yields the same hashes for some hash block coordinates.
For instance, hashIndex(-6, -6, 90) and hashIndex(6, 6, 90) yields the same value, 122790. In otherwords, changes in sign only to the coordinates tend to yield hash collisions.
In the reconstruction engine, the pixels are first traversed and necessary hash blocks marked in a flag list for allocation in the ordered or the excess lists. The hash blocks are allocated based on the generated flag list.
This means that during the initial pass, when buildHashAllocAndVisibleTypePP is being called, the collisions such as (-6, -6, 90) and (6, 6, 90) blocks are unhandled, and the coordinates for the corresponding hash (e.g. 122790) are being overwritten by whichever occurs last. As a result, some blocks are not at all allocated.
This results in incorrect reconstruction. Simple example: you have a plane perpendicular to the camera axis in the center of the view at the very beginning of the processing, when camera is still at the origin. Instead of a plane, you'll get something that looks like a checkerboard with missing blocks.
The basic single-threaded fix for this is simple, but a thread-safe fix with optimizations is not as trivial.