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
For the past 10 years, IfcOpenShell has had a tight coupling with OpenCASCADE as its only geometry library and OCCT providing the datatypes in the IfcOpenShell C++ APIs.
In IfcOpenShell v0.8 an additional abstraction is introduced over the geometric concepts in IFC (taxonomy.h) and the evaluation of such concepts using pre-existing geometry libraries (AbstractKernel).
Also in v0.8, CGAL is introduced as an additional runtime selectable choice besides OpenCASCADE, because of (a) it's extensive set of modules for analysis (e.g convex decomposition, skeleton, ...) and (b) it's arbitrarily robust (and precise) implementation of boolean operations using Nef polyhedra on a number type represents a binary tree of operands taking part in the construction of that number.
Both OpenCASCADE and CGAL are high quality efforts, but quite complex and resulting in fairly large compiled object sizes. This project proposal aims at introducing Manifold as a 3rd geometry library implementation. Manifold is modern, efficient and robust.
Another AbstractKernel implementation that uses Manifold to evaluate a small set of geometrical concepts (boolean, extrusion, brep for example) in IFC. Expecting reasonable outcomes on a small building model (such as the Duplex A model) without necessarily resolving all complexities and corner cases encountered in that model.
Future Possibilities
Comparison between implementations and development of a hybrid composition of these libraries that based on prior inspection picks the most suitable implementation for a specific IfcProduct or representation item. For example, OpenCASCADE will likely still excel at curved surfaces (e.g nurbs), but suffers a monumental performance overhead when ingesting detailed triangular meshes (that are also prevalent in IFC) due the overheads of it BRep data model.
Additional Information
Potential mentor(s): Thomas Krijnen (aothms)
The text was updated successfully, but these errors were encountered:
Awesome, thanks for letting me know! If this is successful, you might be interested in our smooth mesh interpolation functions. They aren't NURBS, but they may have related uses. For instance, I think they may be valuable for generating fillets on arbitrary mesh intersections, especially since they can maintain manifoldness. They are effectively a 3D extension of piecewise cubic Bezier splines.
Outline
For the past 10 years, IfcOpenShell has had a tight coupling with OpenCASCADE as its only geometry library and OCCT providing the datatypes in the IfcOpenShell C++ APIs.
In IfcOpenShell v0.8 an additional abstraction is introduced over the geometric concepts in IFC (
taxonomy.h
) and the evaluation of such concepts using pre-existing geometry libraries (AbstractKernel
).Also in v0.8, CGAL is introduced as an additional runtime selectable choice besides OpenCASCADE, because of (a) it's extensive set of modules for analysis (e.g convex decomposition, skeleton, ...) and (b) it's arbitrarily robust (and precise) implementation of boolean operations using Nef polyhedra on a number type represents a binary tree of operands taking part in the construction of that number.
Both OpenCASCADE and CGAL are high quality efforts, but quite complex and resulting in fairly large compiled object sizes. This project proposal aims at introducing Manifold as a 3rd geometry library implementation. Manifold is modern, efficient and robust.
https://github.com/elalish/manifold
cc @elalish just fyi.
Expected Outcome
Another AbstractKernel implementation that uses Manifold to evaluate a small set of geometrical concepts (boolean, extrusion, brep for example) in IFC. Expecting reasonable outcomes on a small building model (such as the Duplex A model) without necessarily resolving all complexities and corner cases encountered in that model.
Future Possibilities
Comparison between implementations and development of a hybrid composition of these libraries that based on prior inspection picks the most suitable implementation for a specific IfcProduct or representation item. For example, OpenCASCADE will likely still excel at curved surfaces (e.g nurbs), but suffers a monumental performance overhead when ingesting detailed triangular meshes (that are also prevalent in IFC) due the overheads of it BRep data model.
Additional Information
The text was updated successfully, but these errors were encountered: