Colors/materials can be wrong.
The reason seems to be the following:
Sub-shapes may intentionally include the same faces as the parent shape, but overwriting the color of the same faces contained directly in the parent shape. Often the parent shape has faces without colors, but then the "real" colors are assigned to these same faces in sub-shapes. Currently the build_trimesh function produces such equivalent faces but with different colors multiple times, coming from the parent and from the sub-shapes, but the importer then eliminates these duplicate polygons in the filter_same_face function. However, filter_same_face may keep the polygons from the parent having no color and remove the duplicate polygon from a child having the desired color, so that we get the wrong color - no color - for such polygons, falling back do this bad STEP_hex material name.
The line
|
face_data[face] = (0, mesh, "EMPTY") |
is supposed to solve this problem: If the same face is in the parent and in a child, then the child face is supposed to overwrite the parent. Therefore, such duplicated faces are supposed to be eliminated already here instead of relying on
filter_same_face. This seems to be the better approach anyway. However, this implementation is broken, because
ex.More() seems to return different Python binding wrapper objects for the same face, and therefore these duplicate faces end up all in the
face_data dictionary.
Proposed solution:
Replacing
face_data[face] = (0, mesh, "EMPTY")
by
facekey = face.TShape(), face.Orientation()
face_data[facekey] = (0, mesh, "EMPTY")
solved the problem for us. In contrast to face, face.TShape() has the same id and hash value for the same face. But it may be also the same for two identical faces but having different orientations. This is why face.Orientation() is used for the key, too.
A even better approach would be the following:
Right now the same shape may be triangulated multiple times, but only the last one is kept in face_data. Instead we could reverse the loop and triangulate a face only if its key is not in face_data yet:
Colors/materials can be wrong.
The reason seems to be the following:
Sub-shapes may intentionally include the same faces as the parent shape, but overwriting the color of the same faces contained directly in the parent shape. Often the parent shape has faces without colors, but then the "real" colors are assigned to these same faces in sub-shapes. Currently the
build_trimeshfunction produces such equivalent faces but with different colors multiple times, coming from the parent and from the sub-shapes, but the importer then eliminates these duplicate polygons in thefilter_same_facefunction. However,filter_same_facemay keep the polygons from the parent having no color and remove the duplicate polygon from a child having the desired color, so that we get the wrong color - no color - for such polygons, falling back do this badSTEP_hexmaterial name.The line
STEPper-Reborn/importer.py
Line 767 in eeb1a76
filter_same_face. This seems to be the better approach anyway. However, this implementation is broken, becauseex.More()seems to return different Python binding wrapper objects for the same face, and therefore these duplicate faces end up all in theface_datadictionary.Proposed solution:
Replacing
by
solved the problem for us. In contrast to
face,face.TShape()has the same id and hash value for the same face. But it may be also the same for two identical faces but having different orientations. This is whyface.Orientation()is used for the key, too.A even better approach would be the following:
Right now the same shape may be triangulated multiple times, but only the last one is kept in
face_data. Instead we could reverse the loop and triangulate a face only if its key is not inface_datayet: