Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.

[ttengffei-sudo]

Thank you for this interesting project, but we encountered the following error while running the training scenario in train.py. It appears there may be an issue with the logic in the original prefilter_voxel() function in the project. I would appreciate your guidance and advice.

Traceback (most recent call last):
File "/home/Proxy-GS/train.py", line 821, in
training(lp.extract(args), op.extract(args), pp.extract(args), dataset, args.test_iterations, args.save_iterations, args.checkpoint_iterations, args.start_checkpoint, args.debug_from, wandb, logger, args.ply_path, mesh_path=args.ply_mesh, depth_npy_dir=args.depth_npy_dir)
File "/home/Proxy-GS/train.py", line 235, in training
voxel_visible_mask, depth_m = prefilter_voxel(viewpoint_cam, gaussians, pipe, background, depth_map=depth_m)
File "/home/Proxy-GS/gaussian_renderer/init.py", line 488, in prefilter_voxel
visible_mask = (radii_pure > 0)#&pc._anchor_mask
RuntimeError: CUDA error: an illegal memory access was encountered
Compile with TORCH_USE_CUDA_DSA to enable device-side assertions.

[ealicesora]

Hi, thanks for reporting this issue!

The root cause is a tensor shape mismatch in gaussian_renderer/init.py, inside the prefilter_voxel function. We forgot to modify it as we upload an older stable version. Please following the instruction below to fix it. We will re-update the code later.

Fix: In gaussian_renderer/init.py, change lines 479-480 from:
scales = pc.get_scaling[pc._anchor_mask]
rotations = pc.get_rotation[pc._anchor_mask]
to:
scales = pc.get_scaling
rotations = pc.get_rotation

[ttengffei-sudo]

Thanks for your reply, the question which upload above has been resolved. But now we find a new question from your project, the output ".ply" don't include low dimension SH, so we can't display that result on SuperSplat viewer.

[ealicesora]

Oh, our project is build upon scaffold 3DGS, where can't be viewed like previous explicit 3DGS viewer. By the way, do you incorporate mesh during the training process?

[ttengffei-sudo]

yep, we based on input_points.ply to build mesh.ply, as well as choose it to be "--ply_mesh" into model train process. Our execution information are as follow:

(proxy-gs) root@yons-MS-7E06:/home/Proxy-GS# CUDA_LAUNCH_BLOCKING=1 python train.py -s ./2_0323 -m ./2_0323/output -i ./2_0323/images --depth_npy_dir ./2_0323/depth --ply_mesh ./2_0323/sparse/0/mesh_poisson.ply --ply_path ./2_0323/sparse/0/points3D.ply --ratio 8

So, the way to view output only based on local SIBR-Viewer? And whether you can provided a instruction about visualization solution? Thank you very much.

[ealicesora]

Hmmm, good question. In fact, the viewer we use for testing is our internal viewer, which may be difficult to share. However, we are planning to integrate Proxy-GS with our open-source 3DGS viewer, Visionary (https://github.com/Visionary-Laboratory/visionary). While there is a version built with Scaffold-GS using the local SIBR Viewer (https://github.com/city-super/Scaffold-GS), I think you can modify that viewer by adding our depth rendering and culling components to enable real-time viewing. Otherwise, you may need to wait for the integration of Visionary and Proxy-GS.