I am working on my own dataset (artificial data). As far as is understand the code, the Features [5,N] are extracted out of the edges. The order of the edges depends mostly on the order of the faces. Mostly because somewhere is an sort, i cant remember right now. But lets assume the order of the edges depend on the order of the faces. What is the order how the faces are saved in the .obj file. So the order of the features are absically [edges_face0, edges_face1 etc] This means that there is basically no connectivity in between faces saved in the edges?. For my dataset i permute the order of my faces, do get more randomness into the set. But now i am not that sure anymore, if this is not ruining the Performance of the network.
Maybe it makes sense to order the faces in batches ((1/2Kernelsize-2)half the fist kernel size) around random faces,
80
"For segmentation the result is permutation equivariant. So an input list of edges passed through the network will give some resulting segmentation-per-edge. Now if you permute this list, the resulting segmentations will be permuted. This makes sense, since we segment each edge regardless of where it appears in the (arbitrary) global list of edges." I am somehow not able to wrap my head around that. if all meshes are permuted the same way, i would be able to follow this thought.
The Export method
I just wonder if it is intended that the saved mesh is different to the loaded mesh regarding faces and edges. Meaning exporting a Mesh and loading that mesh again is resulting in different features. Editing the __cycle_to_face() method solved this only partly for me. (Ended up writing a new save function.
def __cycle_to_face(self, cycle, v_indices):
for i in range(3):
v = list(set(self.edges[cycle[(i+**1**) % 3]]) & set(self.edges[cycle[(i + **2**) % 3]]))[0]
face.append(v_indices[v])
return face
Augmentation
The vertex sliding is using the "fixed division method" to normalize the normal vectors, therefore it does not work as expected for the vertex sliding. Further changing the condition for face_flipping and edge_sliding to if min(dihedral[edges]) > 2.65 and max(dihedral[edges]) < 3.63: seems for me reasonable. (convex, concarv)
More Generally i would like to ask, which augmentation methods are the most important ones for MeshCNN.
For Now, i use: upsampling, decimation, reandomize order of edges, sliding_vertizes, (edge_flipping, i think there is a bug in the method). I have not tried adding noise to the vertices (scale_verts) yet.
88
"The reason for the fixed_division is to handle the degenerate case when the denominator is zero, so we add a fixed value to the denominator for numerical stability."
i feel like epsilon should be way smaller, or dependent on the general size of the meshes. All my meshes are within a 1 x 1 x 1. This means that the edges are very short and therefore the length of the calculate normal vector is very small. E.g. to_div = 0.001, this is really messing up the dihedral angles used for the features, humanly thinking. Could you share some thoughts on that?
Hello, maybe someone can help me out.
Segmentation data
I am working on my own dataset (artificial data). As far as is understand the code, the Features [5,N] are extracted out of the edges. The order of the edges depends mostly on the order of the faces. Mostly because somewhere is an sort, i cant remember right now. But lets assume the order of the edges depend on the order of the faces. What is the order how the faces are saved in the .obj file. So the order of the features are absically [edges_face0, edges_face1 etc] This means that there is basically no connectivity in between faces saved in the edges?. For my dataset i permute the order of my faces, do get more randomness into the set. But now i am not that sure anymore, if this is not ruining the Performance of the network. Maybe it makes sense to order the faces in batches ((1/2Kernelsize-2)half the fist kernel size) around random faces,
80
"For segmentation the result is permutation equivariant. So an input list of edges passed through the network will give some resulting segmentation-per-edge. Now if you permute this list, the resulting segmentations will be permuted. This makes sense, since we segment each edge regardless of where it appears in the (arbitrary) global list of edges." I am somehow not able to wrap my head around that. if all meshes are permuted the same way, i would be able to follow this thought.
The Export method
I just wonder if it is intended that the saved mesh is different to the loaded mesh regarding faces and edges. Meaning exporting a Mesh and loading that mesh again is resulting in different features. Editing the __cycle_to_face() method solved this only partly for me. (Ended up writing a new save function.
Augmentation
The vertex sliding is using the "fixed division method" to normalize the normal vectors, therefore it does not work as expected for the vertex sliding. Further changing the condition for face_flipping and edge_sliding to
if min(dihedral[edges]) > 2.65 and max(dihedral[edges]) < 3.63:
seems for me reasonable. (convex, concarv) More Generally i would like to ask, which augmentation methods are the most important ones for MeshCNN. For Now, i use: upsampling, decimation, reandomize order of edges, sliding_vertizes, (edge_flipping, i think there is a bug in the method). I have not tried adding noise to the vertices (scale_verts) yet.88
"The reason for the fixed_division is to handle the degenerate case when the denominator is zero, so we add a fixed value to the denominator for numerical stability."
i feel like epsilon should be way smaller, or dependent on the general size of the meshes. All my meshes are within a 1 x 1 x 1. This means that the edges are very short and therefore the length of the calculate normal vector is very small. E.g. to_div = 0.001, this is really messing up the dihedral angles used for the features, humanly thinking. Could you share some thoughts on that?
maybe you could share some thoughts have a nice weekend mgangl