Replies: 14 comments 4 replies
-
|
What you're describing sounds like https://dev.opencascade.org/doc/refman/html/class_bnd___o_b_b.html but I'm not convinced it's the most logical approach. Bounding boxes seem to be a poor choice in more complex cases when there is a curvature in the direction of the sweep. You can also segment your mesh based on edge angle - so that a rectangle swept along an alignment curve still decomposes into 6 groups. Then find the component pointing most upwards. Get the longitudinal direction of that top-face-group and take the midpoints of the remaining edges. Connecting these midpoints I think gives you the length measure you're after, either with or without ignoring the z-component. Not entirely sure. |
Beta Was this translation helpful? Give feedback.
-
|
Let me back up a couple steps. I'm now trying to explore a programmatic way to determine spacing from the model geometry. I have never done anything like this before, so it brings up some questions:
@aothms Would you be up for a call to talk through this? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks I'm trying to get d1, and s1-s3. Also the same at the other end of the beams. These dimensions are a projection into the XY plane
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Thanks - this is a bit dense for me, but I'll take some time to figure it out before asking questions. I generally understand what you are doing, I'm fuzzy on the details of how you are doing it. |
Beta Was this translation helpful? Give feedback.
-
ifcopenshell::geometry::taxonomy::items are fed into the OpenCASCADE or CGAL-based geometry libraries. There the (potentially) procedural geometry definitions in taxonomy (e.g sweeps, booleans) are made fully explicit into a BRep (OCCT) or a Polyhedron (CGAL) and then triangulated. The namespace names are ugly and need to be unified.
Not generically. taxonomy has a shell concept that could be a triangulated face set, but the algo sketched in python assumes triangle meshes.
CGAL (Surface Mesh / Polyehedron_3) comes closest. We can build it also from the triangulated OCCT geometry. But: the license is GPL which is not ideal. We can also port what I wrote here to C++.
Yes, essentially that's it.
normals are the vertex normals. With weld-vertices=True you have multiple faces per vertex and therefore we never bothered to average the normals. This is a bit of a distinction between rendering (opengl can only use vertex normals) and analysis (for everything like mesh segmentation you would typically care about face normals). Since we started with only rendering we never provided the face normals which is a bit of an omission.
The iterator takes care of this. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Notice how the points for Span 1, Girder 1 are reversed. This because the short ends of the rectangle are the same length, within a very small tolerance. For this one case, the sort order is different than all the rest. My first though was to swap c1 and c2 based on their distance from the origin But this is kind of naive. Beams have a direction - they have a starting point and an ending point. This approach would not work for a beam pointing towards the origin, e.g. running NE to SW in the NE quadrant because the start point is further from the origin. If a model had an alignment, c1 and c2 could be projected onto the horizontal alignment. The point with the least "distance along" would be the start point. Though not all models with bridges have alignments. Any suggestions as to how I might attack this geometry problem? |
Beta Was this translation helpful? Give feedback.
-
|
@aothms would you expect the same results if the beams used IfcSectionedSolidHorizontal and IfcPolygonalFaceSet as representations? I'm not seeing that. The beam spacing is the same, but the end points are different. I also reported the line length (computed using just x and y, ignoring z). The values are very different. The values from the IfcPolygonalFaceSet version are correct. What's even stranger, the beam geometry is correct in Blender. Beams_with_IfcSectionedSolidHorizontal.ifc.txt Also getting a bunch of errors I don't understand with IfcSectionedSolidHorizontal
Beams_with_IfcPolygonalFaceSet.ifc.txt |
Beta Was this translation helpful? Give feedback.
-
|
I have a clue to the problem, but don't know how to resolve it. From what I can tell, the triangulation coming from IfcSectionedSolidHorizontal has the surface normals pointing inwards and from IfcPolygonalFaceSet are outwards. If I change the construction of the faces as follows, the edge length comes out correctly for the IfcSectionedSolidHorizontal case however, the edge/wire coordinates are in the wrong order Where does the loft get converted to the IfcGeom::TriangulationElement*? |
Beta Was this translation helpful? Give feedback.
-
|
... and one more clue... I've been defining the profiles to be swept for IfcSectionedSolidHorizontal in a clockwise direction. If I reverse this to a counterclockwise direction, the surface normals are correct. This leads me to believe that the implementation is correct, it was my modeling that is bad. Though, I can't find any place in the IFC spec that speaks to the loop direction defined by the profile points. |
Beta Was this translation helpful? Give feedback.
-
|
@aothms I'm looking for a way to get the volume of a solid using the C++ libraries.
The problem I am having is how to get at this functions. From the discussion above, I can get a Triangularization from the geometry iterator, but that isn't the right approach. Please advise. Thanks |
Beta Was this translation helpful? Give feedback.
-
The iterator also has a get_native() method which will get you the BRepElement, elem->geometry() will get you the Representation::BRep. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @aothms. Another question if I may - I have breps representing a bridge deck slab and bridge beams. From the meshing work we did before, I can determine the main axis of the solid (e.g. the direction of the beam from start to end). I want to cut a cross section using a plane that is normal to the main axis. The result would be a polygon on the cutting plane. Is there anything built into IFCOS to accomplish this? |
Beta Was this translation helpful? Give feedback.




Uh oh!
There was an error while loading. Please reload this page.
-
My use case is an IFC model that has bridge beams in it. The beams are all IfcBeam and they have representations, either IfcSectionedSolidHorizontal, IfcFacetedBrep, or IfcPolygonalFaceSet.
I want to get the tightest bounding box for each beam. From the bounding box, I want to create a line along the top of each bounding box, at the centerline of the top face. Then I want to computer the distance between the start points of all the lines (and also the same for the end points).
Can you point me in the right direction?
Beta Was this translation helpful? Give feedback.
All reactions