Thank you for your valuable comments and kind words to our work. Below we address specific questions.

Q1: Some part is not clear to me, such as line 148-153. There are several different aggregation methods. Can you explain why?
ANS: The use of different aggregation methods in lines 148–153 is intentional and serves distinct yet complementary purposes. The first aggregation (line 150) applies max pooling to encode segment features. However, simple max-pooling ignores the varying contributions of different points within a segment. For example, points close to boundaries are usually more inconsistent with the segment label and should be downweighted.

To address this problem, the second aggregation (line 152) refines the segment representation by performing a weighted aggregation of point-level DINOv2 features. This weighting mechanism leverages the pooled segment feature to estimate the importance of each point, allowing the model to downweight noisy or ambiguous points—particularly those near segment boundaries that may partially belong to other categories. This design enhances the robustness of segment-level semantic features by mitigating boundary noises and improving within-segment consistency.

Q2: I guess the optimization of the graph is time consuming. Can you provide a optimization time comparison with other models?
ANS： The optimization of the graph is quite efficient. In the table below, we report the optimization time for one epoch, the inference time for a single shape, and the inference time of PartSLIP++. Our method is more efficient than PartSLIP++. Since the training code of PartSLIP++ is not publicly available, we do not report its training optimization time. Nevertheless, the one epoch training time required for our graph optimization is still smaller than the inference time of PartSLIP++.
The preprocess time for the two methods:

The training and inference time:

Q3: Is the graph constructed from the segments of multi-views? How large is the graph? How many nodes and edges?
ANS: Yes, the nodes in our graph are directly formed from the segments obtained by applying SAM to multi-view images. To quantitatively illustrate the size of the constructed graphs, we report the average and maximum number of nodes, adjacent edges, and overlapping edges per object on the PartNetE dataset.

As shown in the table, the constructed graph (with an average of a few hundred nodes and several thousand edges) is significantly smaller compared to the point clouds of each object in PartNetE, which typically contain hundreds of thousands of points.

Q4: How to compute point normals at eqn 2?
ANS： We estimate the point cloud normals as follows. For each point, we consider a local neighborhood within a radius of 0.02 and employ the built-in function in Open3D to estimate the normals. Specifically, Open3D performs a PCA analysis on the local neighborhood of each point, and the normal vector is taken as the eigenvector corresponding to the smallest eigenvalue of the covariance matrix. Optionally, Open3D applies normal orientation adjustment to ensure consistency in the normal directions.

If you have any further question, please let us know. Thank you very much!

Thank you for your valuable comments and kind words to our work. Below we address specific questions.

Q1： If the few-shot examples are under various granularity scales, the performance of the graph formulation is questionable.
ANS: Our method can be extended to multi-granularity once the annotation is available. For example, 3DComPat++ $1$ provides coarse-grained annotations (at most 5 part categories) and fine-grained annotations (10-20 part categories). Due to limitations in time and computational resources, we selected three categories—airplane, bicycle, and chair—for evaluation. Airplanes have 14 fine-grained and 3 coarse part labels; bicycles have 26 fine-grained ones and 3 coarse ones; chairs have 22 fine-grained labels and 4 coarse labels.
We extend to multi-grained segmentation by tuning separate networks. In the table below, our method demonstrates significant advantages across different levels of part annotation granularity.

Q2： The overall performance increase may be attributed to the application of powerful DINOv2 rather than the proposed method. Tab.5 shows the efficacy of SegGraph, but also shows that when replacing it with CLIP, the SegGraph only has 49.5 mIOU, lower than most of GLIP+SAM methods in Tab.1, which is basically CLIP+SAM.
ANS: We would like to point out that GLIP is generally more powerful than CLIP. CLIP primarily focuses on global semantic features at the image level and falls short in localization tasks, such as detections and part segmentation, as illustrated in Figure 5 of the paper "Foundational Models Defining a New Era in Vision: A Survey and Outlook". In contrast, GLIP is designed for object detection and is trained using large-scale detection datasets. Therefore, GLIP demonstrates advantages in fine-grained localization and facilitates much better part localization than CLIP, leading the performance gaps when using different backbone features.

To isolate the influence of foundation models, we evaluate the results of using GLIP as the 2D feature extractor in place of DINOv2 on the PartNetE dataset. Specifically, we used the multi-scale visual features from GLIP after fusion with text features, and employed a Feature Pyramid Network (FPN) structure to further fuse these multi-scale features. The resulting fused features were then used as the GLIP features for SegGraph aggregation. However, we need to notice that this design is inferior as it ignores the bounding box outputs. The results in the table below show that even when using GLIP, our method still achieves competitive performance, second only to our results using DINOv2. This demonstrates that the overall performance increase is not solely attributed to the application of the powerful DINOv2.

Q3： The proposed method seems not be able to handle the semantically different but geometrically similar parts.
ANS： Thanks to the semantically rich features extracted from DINOv2, our method is capable of segmenting parts that share similar geometric structures but differ in semantic meaning. For example, the screen and the base of a laptop are both rectangular and flat in shape, exhibiting high similarity in 3D geometry. However, as shown in Figure 6, visualizations of their features reveal that they are highly distinguishable in the feature space.

Q4：How does the method perform for real-world data? What about its performance on raw and noisy point clouds from real world. For example, the algorithm reconstructed 3D objects, 3D assets represented by 3DGS. Can the graph be correctly built and maintain the performance?
ANS： To verify the robustness of our method to noise, we conducted experiments by adding noise in the normalized point cloud space. We evaluate the method against added noises with a standard deviation of {0.005, 0.01, 0.02，0.05}. Extending the method to 3DGS requires substantially changing the pipeline, and we leave it to future work.

Q5：How does the method compare with semantic mask-based approaches? They may not focus on the same task in their papers, but exhibit capabilities in SegGraph's tackled task. Some of them even have performance advantages.
ANS： The following table provides a comparison with the methods you mentioned—OpenMask3D, SATR, and Find Any Part in 3D (Find3D). The method "Open-Vocabulary Semantic Part Segmentation of 3D Human" is not included in the comparison because its code is not publicly available. Among these, our approach consistently demonstrates a significant performance advantage. One important factor is that OpenMask3D relies on Mask3D as its 3D feature extractor, which is pre-trained on ScanNet—an indoor scene dataset. This domain gap makes it difficult for OpenMask3D to generalize well to the more diverse and structurally complex 3D shapes in PartNetE. Moreover, as mentioned in the Find3D paper, PartNetE is particularly challenging due to the presence of many small parts that lack distinct geometric or color features (e.g., buttons on a surface of the same color), which significantly hinders the performance of Find3D and SATR. In contrast, our method excels in identifying and segmenting such small, indistinct components, which underscores its robustness in fine-grained part segmentation.

$1$ 3DCoMPaT^{++}: An improved Large-scale 3D Vision Dataset for Compositional Recognition

If you have any further question, please let us know. Thank you very much!

Thanks for the response. It addresses most of my points.

Regarding the experiment for multi-granularity labels, you mentioned: "We extend to multi-grained segmentation by tuning separate networks." Does it mean you have a network for coarse and a network for fine? My original point is that usually, the granularity of real data label is mixed. It's difficult to just classify them as "coarse" or "fine". Normally, the granularity forms a continuous spectrum. It may not be realistic to tune a bunch of networks. How can this graph structure handle examples under various granularities? That's my original question.

Thank you for your valuable comments and kind words to our work. Below we address specific questions.

Q1: Baseline and foundation model justification: Could the authors provide results or justification for using consistent baselines across all datasets, and for isolating gains from the choice of foundation model?

ANS: We select DINOv2 as the base foundation model due to its good generalization and high-quality output features, achieved through large-scale self-supervised learning. Most baseline methods rely on foundation models with 2D label output, e.g., GLIP, and do not support the use of DINOv2. Moreover, the training codes of PartSLIP, PartSLIP++, PartSTAD, 3-By-2, and PartDistill are not fully available, making it difficult to change their base foundation model for alignment.

To isolate the influence of foundation models, we evaluate the results of using GLIP as the 2D feature extractor in place of DINOv2 for our method. Specifically, we used the multi-scale visual features from GLIP after fusion with text features, and employed a Feature Pyramid Network (FPN) structure to further fuse these multi-scale features. The resulting fused features were then used as the GLIP features for SegGraph aggregation. However, we need to notice that this design is inferior as it ignores the most important bounding box outputs. The results in the table below show that even when using GLIP, our method still achieves competitive performance, second only to our results using DINOv2.

Q2: Significance of thresholds used for graph edges
ANS: We validated the influence of these thresholds in Figures A2 and A3 in the supplementary material. Basically, the method is quite robust to these hyperparameters owing to the good quality of SAM segments.

Q3: What is the number of shapes per category in the few-shot experiments? Reporting the range (e.g., min/max examples per class) would help interpret the model's generalization performance across both frequent and rare classes.
ANS: Thank you for pointing out the omission regarding the number of shots used in our experiments. All experiments in the paper were conducted using an 8-shot per shape configuration. Additionally, we provide an analysis of the model’s generalization performance under different numbers of shots in Appendix C and Figure A1.

Q4：The paper highlights significant improvements on small parts, but does not define how "small" is quantified. Are small parts determined based on point count, spatial volume, or proportion of the object?
ANS: For the categorization of "small parts," we follow the approach used in PartSTAD, which defines small parts based on empirical knowledge of object part sizes. In the PartNetE dataset, the following categories are considered small parts: $"handle", "button", "wheel", "knob", "switch", "bulb", "shaft", "touchpad", "camera", "screw", "handlebar", "trigger"$ .

Q5: Clarification of “w/o SAM” setting in ablation: In Table 4?
ANS: We describe the configuration without using SAM in Lines 253–257. In this setting, we first aggregate multi-view features into the 3D space via average pooling to obtain $F^p$, and then directly apply an MLP to predict the category of each point. The graph structure and SAM segments are completely discarded in this configuration.

Q6: While the method performs well overall, there is little to no qualitative or quantitative discussion of where it fails (e.g., occluded parts, inconsistent multi-view alignment).

ANS: We expect the method will fail on shapes with deep concave parts and inner structures because of occlusions. We acknowledge this is a fundamental limitation of multi-view rendering-based methods.

Q7: Writing and clarity
ANS: Thank you for your valuable suggestions regarding the writing and clarity of the paper. We will revise the relevant sections to improve the overall clarity. More explanations are as follows.

1. SATR does not use a voting-based aggregation scheme as implied in L31–34. Similarly, referring PartField as a zero-shot method (L205) is confusing as it requires part-level supervision during training.
   The Per Face Score Aggregation module in SATR can be described as follows. Each 3D face receives initial votes from multiple 2D views via a 2D detector. These votes are then adjusted through a weighted refinement process based on 3D topology (geodesic distance) and neighborhood information (visibility). The final aggregated score determines the label of each face based on the highest vote score. Therefore, the overall approach still aligns with the description of "aggregating 2D labels to the 3D domain with voting".

   Regarding PartField, we acknowledge that our original description was not fully accurate. PartField indeed requires training on data from Objaverse and PartNet with SAM-generated pseudo labels and contrastive losses. Though the method can work without ground truth annotations, referring to it as a zero-shot method is not entirely precise, as it still requires training.

2. The phrase “an improvement of at least 4%” in L69 does not clarify the metric, baseline, or dataset:
   The reported "at least 4% improvement" in L69 refers specifically to the performance on the PartNet-E dataset. It indicates that, under various configurations using different foundation models as image feature extractors, our method consistently yields at least a 4% improvement compared to not using SegGraph. We will actively integrate the suggestions into our revision.

3. The mathematical representation of segment nodes $V$ and $F_i^{p'}$ in equation 3. Adding equations to explain L148-153 mathematically will also improve clarity.
   Thank you. We will clarify these two parts.

4. Figure 2: The figure is general and does not precisely capture the complexity of the pipeline.
   Thank you. We will incorporate the illustration for graph construction and view pooling in the revision.

5. Figure 3 shows adjacency (solid lines) only within the same view, but the text does not clarify if the adjacency edges can exist across views as well.
   Thank you for the suggestion. We will add cross-view adjacency edges in Figure 2 to better illustrate the adjacency relationships across views.

If you have any further question, please let us know. Thank you very much!

Thank you for your valuable comments and kind words to our work. Below we address specific questions.

Q1: Limited technical novelty: While the combination is effective, the individual components (multi-view rendering, SAM segmentation, graph neural networks) are not novel. The main contribution is in their combination, which limits the technical depth.
ANS: As illustrated in Figure 1, the novelty of this work lies in the construction of a structured graph based on SAM segments as an efficient 3D representation to aggregate foundation model features. The graph effectively encodes the adjacency and overlapping relationships of SAM segments within a single view and across views. Moreover, this graph-based representation helps mitigate the label imbalance between small parts and large parts that have very different numbers of labeled points, by using a more uniform number of SAM segment nodes. For example, in the Laptop category, both the large screen and the small individual keys are represented as single nodes after SAM segmentation. Therefore, our method achieves better results on small parts.
Besides, both you and Reviewer V5oZ acknowledge the novelty of View Quality-Aware Unpooling that is potentially beneficial for other tasks.

Q2: The computational cost compared to simpler baselines should be more thoroughly analyzed.
ANS: The table below presents a detailed runtime analysis of each component in our method, alongside a comparison with the classical baseline PartSLIP++. All runtime is measured on a per-shape basis. The training time is counted for the optimization of one epoch of a shape.
For PartSLIP++, the main computational cost during preprocessing lies in generating superpoints from the point cloud using L0-cut pursuit and computing voting weights for each superpoint (vote_preprocess: 92.38 seconds). During inference, its complex weighted voting mechanism leads to a relatively high inference time (5.8 seconds).
For our method, the main preprocessing cost arises from SAM segmentation for 10 multi-view images. Because the adopted SamAutomaticMaskGenerator processes only one image each time, this step is relatively time-consuming. However, faster models could be adopted in the future to accelerate this process. Even so, our preprocessing time is significantly lower than that of PartSLIP++ (64.921s vs. 110.83s).
In the inference stage, our method achieves higher efficiency (1.46s vs 5.83s for PartSLIP++). It is worth noting that since the training code of PartSLIP++ is not publicly available, its training time is not reported in the table. However, we can reasonably expect that our training time is much faster than PartSLIP++'s based on the inference time comparison. Note that both the "Train" and "Inference" time measurements include the time for DINOv2 feature encoding.

Time spent on preprocessing：

Time spent on training and Inference:

Q3： How does the method perform on objects with significantly more complex part structures than those in PartNet-E?
ANS: Our method is not designed for scene-level part segmentation (ScanNet) and image-based part segmentation (UDA-Part). Extending the method to ScanNet requires both scene-level part annotations and non-trivial designs to handle thousands of frames all at once, which is out of the scope of this work and needs substantial efforts. Below, we test on 3D part segmentation on ABC primitives and more complex shapes.
1. We selected 8 shapes for training and 100 shapes for evaluation from the ABC-Primitive dataset. We compared our method with PartSLIP++. However, as PartSLIP++ has not released its training code, we evaluated it in a zero-shot setting instead. Since the ABC dataset does not contain color information, we followed the approach used in PointCLIP-v2 by rendering the point clouds into depth images for processing. However, depth images are not a native input modality for models like GLIP, DINOv2, and SAM, leading to varying degrees of performance degradation for both PartSLIP++ and our method.

2. We note that the part annotations in Objaverse are quite inconsistent, and evaluate on the 3DComPat++ $1$ dataset for complex shapes with fine-grained part segmentation annotations. Due to limitations in time and computational resources, we selected three categories—airplane, bicycle, and chair—for evaluation. The number of fine-grained part labels for each of these categories is as follows: the airplane category contains 14 parts, the bicycle category contains 26, and the chair category contains 22, reflecting the complexity of these shapes.
We use the mesh data provided by 3DComPat++ and sample 100,000 points from each object as the experimental data. We compare our method with the representative baseline PartSLIP++. Since the training code of PartSLIP++ is not fully open-sourced, we evaluate it under the zero-shot setting. In contrast, our method is evaluated under both 1-shot and 8-shot settings. The evaluation metric reported in the table below is the mean Intersection-over-Union (mIoU).

As shown in the table, our method performs well even when faced with more complex part structures, demonstrating strong generalization capability.

Q4: How sensitive is the method to the number of views used for rendering?
ANS: Both PartSLIP and 3-by-2 show that when the number of views exceeds 10, the performance gains begin to plateau. Based on this observation, we also adopt 10 views as the default configuration in our experiments.
Our results are shown in the table below. When the number of views exceeds 10, the improvement in model performance significantly diminishes as the number of views increases. Conversely, when the number of views is fewer than 10, reducing the number of views leads to a substantial decline in model performance, highlighting the importance of sufficient multi-view information for the model’s effectiveness.

$1$ 3DCoMPaT^{++}: An improved Large-scale 3D Vision Dataset for Compositional Recognition

If you have any further question, please let us know. Thank you very much!

Dear Reviewer,

This is a friendly reminder to check the authors' rebuttal and adjust your rating if necessary. Thanks for your contributions to the NeurIPS reviewing process.

Thanks,

Your AC