Potential bug about code to pre-filter out of bounding box sample rays

[cc]

nice-slam/src/Tracker.py

Lines 94 to 104 in 7af15cc

 # should pre-filter those out of bounding box depth value 
 with torch.no_grad(): 
     det_rays_o = batch_rays_o.clone().detach().unsqueeze(-1)  # (N, 3, 1) 
     det_rays_d = batch_rays_d.clone().detach().unsqueeze(-1)  # (N, 3, 1) 
     t = (self.bound.unsqueeze(0).to(device)-det_rays_o)/det_rays_d 
     t, _ = torch.min(torch.max(t, dim=2)[0], dim=1) 
     inside_mask = t >= batch_gt_depth 
 batch_rays_d = batch_rays_d[inside_mask] 
 batch_rays_o = batch_rays_o[inside_mask] 
 batch_gt_depth = batch_gt_depth[inside_mask] 
 batch_gt_color = batch_gt_color[inside_mask] 

I'm having some trouble trying to understand the method to create masks to make sure ray ends within the mapping bound. We need the end-points of rays to satisfy that

b_l <= depth \cdot dir + origin <= b_u

I'm confused why the min-max operation here is correct. Is this a bug?

nice-slam/src/Tracker.py

Line 99 in 7af15cc

 t, _ = torch.min(torch.max(t, dim=2)[0], dim=1) 

My implementation is provided below:

            with torch.no_grad():
                # pre-filter those out of bounding box depth value for niceslam
                # b_l <= depth \cdot dir + origin <= b_u
                det_rays_o = batch_rays_o.clone().detach().unsqueeze(-1)  # (N, 3, 1)
                det_rays_d = batch_rays_d.clone().detach()
                # normalize ray direction
                det_rays_d /= torch.linalg.vector_norm(det_rays_d, dim=0)
                # bounds in ray coordinate
                bounds = self.bound.unsqueeze(0).to(device) - det_rays_o
                end_points = batch_gt_depth.unsqueeze(-1) * det_rays_d
                # both sides should be inside the bounding box
                left_mask = (end_points >= bounds[..., 0]).all(dim=1)
                right_mask = (end_points <= bounds[..., 1]).all(dim=1)
                inside_mask = (left_mask & right_mask).squeeze()

[Zihan Zhu]

I double checked, I think it is correct.

[cc]

But the generated ray direction isn't even normalized?