About the DepthNet

[Hjjfk]

Thanks for your great work!
I have a question regarding the depth supervision mechanism in CM_DepthNet when using the grouped geometry feature.
By diving into the codebase, I noticed the following data flow:
In CM_DepthNet.init, depth_channels is multiplied by geometry_group, making it 448.
In get_downsampled_gt_depth, the ground truth depth is generated as a one-hot vector with num_classes=449.
Since the actual physical depth indices calculated from grid_config are strictly bounded (e.g., 0 ~ 111), the 1 in the one-hot vector will always fall within the first 112 channels. The remaining 336 channels (which correspond to the other 3 groups) will always be strictly 0.
During get_depth_loss, the BCE loss compares the 448-dim prediction directly with this 448-dim one-hot GT.
This implementation seems to result in an asymmetric supervision:
Group 0 (channels 0-111) is supervised by the actual LiDAR depth.
Groups 1, 2, 3 (channels 112-447) are forced to output 0 by the BCE Loss, which seems to conflict with the softmax(dim=2) operation that expects the sum of probabilities to be 1.0.

Is this asymmetric supervision (Group 0 as the main expert, other groups suppressed to 0) an intended design?

[cdb342]

Thanks for your great work! I have a question regarding the depth supervision mechanism in CM_DepthNet when using the grouped geometry feature. By diving into the codebase, I noticed the following data flow: In CM_DepthNet.init, depth_channels is multiplied by geometry_group, making it 448. In get_downsampled_gt_depth, the ground truth depth is generated as a one-hot vector with num_classes=449. Since the actual physical depth indices calculated from grid_config are strictly bounded (e.g., 0 ~ 111), the 1 in the one-hot vector will always fall within the first 112 channels. The remaining 336 channels (which correspond to the other 3 groups) will always be strictly 0. During get_depth_loss, the BCE loss compares the 448-dim prediction directly with this 448-dim one-hot GT. This implementation seems to result in an asymmetric supervision: Group 0 (channels 0-111) is supervised by the actual LiDAR depth. Groups 1, 2, 3 (channels 112-447) are forced to output 0 by the BCE Loss, which seems to conflict with the softmax(dim=2) operation that expects the sum of probabilities to be 1.0.

Is this asymmetric supervision (Group 0 as the main expert, other groups suppressed to 0) an intended design?

The geometry_group switch is meant for CausalOcc and has not been merged into OccStudio yet. All other models in this repo keep it off by default, so they use standard single group depth supervision and the asymmetry you describe never triggers on the released code paths. We will integrate the full CausalOcc code once we have the bandwidth.