mirror of
https://github.com/IfcOpenShell/IfcOpenShell.git
synced 2026-08-29 08:13:14 +00:00
Petru Conduraru
8a5b1ab10d
Exploratory proof of concept for #134, #1409 and #5218: IfcVertexPoint, IfcCartesianPoint and IfcCartesianPointList3D used as top-level representation items ("Vertex"/"Point"/"PointCloud") currently raise "Failed to process shape" because AbstractKernel::convert_impl for taxonomy::point3 is never implemented and point3 cannot appear as a child of the generic items collection. This makes point3/direction3 derive from geom_item instead of plain item, so a lone point3 can stand in as a representation item, and adds: - OpenCascadeKernel::convert_impl(point3): a single point becomes a TopoDS_Vertex wrapped in a TopoDS_Compound, as aothms suggested in #5218. - OpenCascadeKernel::convert_impl(collection): a bulk fast path for a collection made up entirely of point3 children (e.g. a whole IfcCartesianPointList3D) that builds ONE compound with all vertices in a single pass, instead of paying the generic per-item conversion overhead (cache lookup, heap allocation, a separate Triangulate() call) once per point. - mapping for IfcVertexPoint (as a top-level item) and IfcCartesianPointList3D. - loose-vertex emission in OpenCascadeShape::Triangulate, since a vertex-only shape previously triangulated to nothing. This directly tests aothms's "the overhead is enormous" concern from #5218. Benchmarked on this machine (Apple M-series, Release build): - Normal (non-point) geometry is unaffected: a 5178-shape real model processes in 4.48s before this change and 4.49s after (~0.3%, noise). - The bulk fast path scales linearly and cheaply: ~0.5-0.9 us/point for an IfcCartesianPointList3D from 1k to 100k points (100k points in ~93ms total). - With the fast path disabled (pure per-item conversion, i.e. the naive reading of "a TopoDS_Compound of TopoDS_Vertex" with no batching), scaling is still linear, not quadratic, but ~4-7x slower per point (~3.5-4 us/point at the same scale, 100k points in ~380ms). So aothms's concern is real as a constant-factor tax from going through full OCCT BRep objects (TopoDS_Vertex/Compound, shared_ptr taxonomy nodes, per-item caching) rather than flat coordinate arrays, but it is not the asymptotic blowup "enormous overhead" might suggest, and a reasonably-scoped batching fast path narrows the gap substantially. Given Bonsai already has a working, accepted Python-side bypass for this (create_point_cloud_mesh / create_structural_point_connection_mesh in bonsai/tool/loader.py and geometry.py), this is offered as a proof of concept for evaluation, not a claim that it should override the prior "something for 0.9" call. IfcCartesianPointList2D ("PointCloud" in 2D) is intentionally out of scope for this prototype. Adds pytest coverage (no Catch2/C++ test harness exists in this codebase) for all three representation types plus a 1000-point round-trip/timing sanity check. Generated with the assistance of an AI coding tool.