Performance comparison with BRepNet encoder

[leopoldmaillard]

Hello and thank you for unveiling this comprehensive code ! 😄

I've read the JoinABLe supplementary material, and I was wondering why your baseline experiments do not include a model with the encoder from BRepNet (minus the layer for face classification used in the original architecture), the same way you use UV-Net as a baseline encoder.

Is that something you tried and decided not to include in the paper, or are there any specific reason why you haven't give it a try ?

I may try it myself, but I noticed BRepNet takes .step parts as input, and I'm afraid it won't preserve the critical topological entities order used in a part .json, and in the joint sets annotations.

Thank you as always and have a nice day !

[karldd]

Yes this is a good question.

After publishing UV-Net and BRepNet last year @JoeLambourne and @pradeep-pyro did some experiments to compare both on the Fusion 360 Gallery segmentation task. The result was a slight advantage for UV-Net. They found that both the input features of UV-Net (i.e. grids of points and normals) and the encoder of UV-Net offered slight advantages. Based on those experiments we chose UV-Net as the slightly stronger baseline.

That said, we have found this task is quite different from segmentation and it might be interesting to try BRepNet. And yes you are right that there are some issues in mapping the face and edge indices over to step files. Some of these issues are explained in this document. If you are going to give it a shot, I would ask @JoeLambourne for some tips.

One thought is it might be possible to write a dataloader that reads the information in the graph json file and obj file directly into pytorch and skip the step file part of the process. Although the json files do not contain the coedge information, it is stored in the obj files. So it may be possible to recover the topology information BRepNet requires.

[leopoldmaillard]

Hello @karldd and thank you for your answer ! 😃 Indeed, my intuition would be that BRepNet might perform better at encoding the topology of a part, which seems to be important for this task.

Thanks for the obj tip, as long as the topological entities indices are consistent with the json file, we might find a way to construct the coedges N, M, P, F & E tensors.

Thank you again !

[JoeLambourne]

Hi @leopoldmaillard,

The indices of faces tend to change when conversion from Autodesk's modeling kernel to STEP causes faces to split. Your first line of defense is to double check that the number of faces in the json files and STEP (or Open Cascade) are the same.

When converting the segmentation dataset I performed multiple checks and discarded models where they failed. The checking was done by this script and you can see a detailed description of the checks in there.

Using our proprietary code I could set a color on each face which encoded the face index. You will not be able to do this with open source tools sadly.

I recommend taking my validator script and removing the checks involving the colors. Provided you have OBJ files with the face indices in there then you can still check that the boxes of the faces are the same. You will inevitably find that in some cases the boxes are slightly different. This is often due to differences in the triangulation. You will need to decide on how strict you want to be. I used 1/10th the diagonal of the bounding box of the face as a tolerance. I visually inspected some 20 or 30 times this check failed and in each case thought they were due to differences in the triangulation.

we might find a way to construct the coedges N, M, P, F & E tensors.

This script should create the data you need.

my intuition would be that BRepNet might perform better at encoding the topology of a part

Mine also, but I think this might be because we come from a solid modeling background where cyclic order is very important. The way these networks operate I think they are more sensitive to other patterns.

[karldd]

Closing this for now, feel free to reopen if you have further questions.