You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allocated voxel blocks in local GPU buffer: 10000
Last free block ID: 9999
Last free excess list ID: 524287
Allocated size: 5120000
The main hash map buffer has 10k entries, but the excess list has ~500k, even though it's almost never used for such a small volume.
The problem is that the excess list size is defined as a global constant. We need to fix that. This is particularly important for speeding up the cleanup for instance reconstruction, which should run on the entire volume in real time, but is made much slower by the pointlessly large excess list.
Warning: Note that the large excess list size does not imply we're actually allocating those blocks; just the hash map entries, which are still quite big, but not quite as big as the actual VBA entries, i.e., the actual blocks. This was something I originally got confused with. SDF_EXCESS_LIST_SIZE and SDF_BUCKET_NUM dictate the size of the hast table, NOT that of the VBA. There's just one VBA, of course, and elements from either the hash map itself or the excess list point to locations in the VBA.
The text was updated successfully, but these errors were encountered:
Example for reconstructing a car:
The main hash map buffer has 10k entries, but the excess list has ~500k, even though it's almost never used for such a small volume.
The problem is that the excess list size is defined as a global constant. We need to fix that. This is particularly important for speeding up the cleanup for instance reconstruction, which should run on the entire volume in real time, but is made much slower by the pointlessly large excess list.
Warning: Note that the large excess list size does not imply we're actually allocating those blocks; just the hash map entries, which are still quite big, but not quite as big as the actual VBA entries, i.e., the actual blocks. This was something I originally got confused with. SDF_EXCESS_LIST_SIZE and SDF_BUCKET_NUM dictate the size of the hast table, NOT that of the VBA. There's just one VBA, of course, and elements from either the hash map itself or the excess list point to locations in the VBA.
The text was updated successfully, but these errors were encountered: