You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The documentation says that Compound is "a collection of disconnected solids". But this is not the exact definition. If we refer to the OpenCascade documentation, we can find the following sentences:
"COMPOUND: A group of any of the shapes below." TopAbs_ShapeEnum Description
"A TCompound is an all-purpose set of Shapes" TopoDS_TCompound Description
This inaccuracy leads for the unexpected behavior.
Examples:
Compound's center of mass
sk=cadquery.Sketch().rect(50, 50).faces()
face1=sk.val()
face2=face1.copy().translate(Vector(100, 0, 0))
compound=cadquery.Compound.makeCompound([face1, face2])
compound_center=compound.Center()
Properties=GProp_GProps()
BRepGProp.SurfaceProperties_s(compound.wrapped, Properties)
expected_center=cadquery.Shape.CombinedCenter([face1, face2]) # Vector: (50, 0.0, 0.0)actual_center=compound.Center() # Vector(0.0, 0.0, 0.0)assertactual_center==expected_center, "Incorrect center of mass of the compound, expected {}, got {}".format(expected_center, compound.Center())
The following code makes a compound consisting of 2 faces and calculates the center of mass. The problem is that shape_properties_LUT interpets TopAbs_COMPOUND as a volumetric shape and provides an incorrect result.
Shell
Similar behaviour occurs in the Shell.makeShell method
This code creates 2 shells: one from the connected faces, and another from disconnected. The type of the second shell is TopoDS_Compound, which corresponds to the OpenCascade definition. However, cadquery states that the wrapped attribute of the shell object should be TopoDS_Shell. If we call Center(), we'll get the same behaviour as in the previous example.
If this feedback is relevant, I’d be happy to open a PR with a solution that addresses the specific issue with Center(). However, I’m unsure whether other operations may also be affected by this underlying inconsistency.
The text was updated successfully, but these errors were encountered:
Thanks, the Center() thing is definitely a bug. Regarding shell, I'd suggest using shell from the free function API. Parts of the cq.Shape API are rather dusty, and not really meant for end users.
Regarding PR, I'd rather reimplement Center() for cq.Compound.
Thank you, @adam-urbanczyk. I opened a PR where I reimplemented Center for cq.Compound. There is also a utility method that that inspects the Compound. #1822
Regarding cq.Shell, in my opinion, this is not a major issue. Technically, it’s incorrect to attempt to create a shell from disconnected faces. A possible compromise from a UX perspective would be to handle this edge case and throw an exception.
The documentation says that Compound is "a collection of disconnected solids". But this is not the exact definition. If we refer to the OpenCascade documentation, we can find the following sentences:
"COMPOUND: A group of any of the shapes below."
TopAbs_ShapeEnum Description
"A TCompound is an all-purpose set of Shapes"
TopoDS_TCompound Description
This inaccuracy leads for the unexpected behavior.
Examples:
Compound's center of mass
The following code makes a compound consisting of 2 faces and calculates the center of mass. The problem is that
shape_properties_LUT
interpetsTopAbs_COMPOUND
as a volumetric shape and provides an incorrect result.Shell
Similar behaviour occurs in the Shell.makeShell method
This code creates 2 shells: one from the connected faces, and another from disconnected. The type of the second shell is
TopoDS_Compound
, which corresponds to the OpenCascade definition. However, cadquery states that the wrapped attribute of the shell object should beTopoDS_Shell
. If we callCenter()
, we'll get the same behaviour as in the previous example.If this feedback is relevant, I’d be happy to open a PR with a solution that addresses the specific issue with Center(). However, I’m unsure whether other operations may also be affected by this underlying inconsistency.
The text was updated successfully, but these errors were encountered: