This discrepancy propagates to Step 5, resulting in a much lower-quality 3D reconstruction compared to the official demo.
The behavior is similar to the issue discussed here:
Some improvements were observed, but results are still far from the official output
Reproducibility Data (Logs + Outputs)
I have collected:
Full outputs and logs for all pipeline steps
Several resulting occupancy maps for comparison
These are available here:
Questions
What exact parameters/configuration were used to generate the official r2b_galileo reconstruction (especially for nvblox / Step 4)?
Are there additional preprocessing steps or implicit assumptions (e.g., filtering, coordinate normalization, depth scaling) not documented in the pipeline?
For custom datasets, what is the recommended methodology to systematically tune nvblox parameters beyond trial-and-error? Are they related to the camera or the recorded scene?
Are there guidelines based on sensor characteristics, scene scale, or motion profile?
Any diagnostic metrics or intermediate outputs that should be monitored?
Any guidance would be appreciated, especially if there is a reference configuration or reproducible setup matching the official results.
Thanks for the detailed clarification and for sharing the exact command/configuration used.
I reran the pipeline using the HuggingFace version of the dataset. Initially I assumed it was identical to the dataset referenced in the documentation, but apparently there are relevant differences.
Using that dataset version, and your parameters, the generated occupancy map became much closer to the official HuggingFace result.
However, the final reconstruction quality is still significantly below the expected result and also far from the reconstruction/gif published on HuggingFace:
My reconstruction result:
At this point I am trying to understand whether there are still undocumented differences in the pipeline.
--config-name apps/cusfm_3dgut_mcmc.yaml or apps/colmap_3dgrt_mcmc.yaml
copy & paste from doc.
We use the apps/cusfm_3dgut.yaml configuration in this tutorial, but you can also use apps/cusfm_3dgut_mcmc.yaml, which pairs 3DGRUT with an MCMC (Markov Chain Monte Carlo) densification strategy. In practice, this approach samples and densifies Gaussians in regions where the reconstruction is uncertain, sharpening thin structures and edges while improving overall fidelity, with only a modest increase in training time compared to the baseline configuration
Tested the reconstruction using MCMC, but the results were actually worse than the default configuration.
For example, the resulting mean_psnr dropped from ~22 to ~14, which is significantly lower. The final reconstruction quality was also visually degraded.
For reference, I uploaded the complete outputs and logs here:
\[INFO\] Initializing from accumulated point cloud: minha_cena/nvblox_mesh1-default/nvblox_mesh.ply logger.py:67
\[INFO\] Loading fused point cloud from minha_cena/nvblox_mesh1-default/nvblox_mesh.ply... logger.py:67
[ 13:47:13] [INFO] Loaded 112930 points from accumulated point cloud logger.py:67
\[INFO\] Initializing from accumulated point cloud: minha_cena/nvblox_mesh4-max5-voxel2/nvblox_mesh.ply logger.py:67
\[INFO\] Loading fused point cloud from minha_cena/nvblox_mesh4-max5-voxel2/nvblox_mesh.ply... logger.py:67
[01:42:59] [INFO] Loaded 2987747 points from accumulated point cloud logger.py:67
I think one of them uses the intended mesh, but it loads 2987747 points and hits the CUDA OOM error.
[3dgut][ERROR] ::: cudaMallocAsync(&ptr, size, stream) failed: 2: cudaErrorMemoryAllocation - out of memory at /workspace/PEDRO/humanoid/humanoid/packages/3dgrut/threedgut_tracer/include/3dgut/utils/cuda/cudaMemoryAllocator.h:44
[3dgut][ERROR] ::: CUDA error 2: cudaErrorMemoryAllocation - out of memory)