Support for BREP geometry

[yorikvanhavre]

This format is really interesting for several reasons, mainly its simplicity and its easy compatibility with IFC. I will write importers/exporters for FreeCAD. (issue).

However, FreeCAD, as many other BiM applications, can work with higher-level geometry types than mesh, for ex. solids, NURBS curves and surfaces, or B-Rep geometry. These geometry types can for example represent curves in a much more precise and parametric way than triangle meshes.

So this issue is more to start a brainstorming: Could we support NURBS/BRep geometry in dotbim? And how?

I know ofseveral open formats available for Brep: opencascade's native brep format, opennurbs (rhino), there is ACiS too which has open implementations (but almost never used anymore in favor of autodesk's closed ACIS version), and IFC itself, with IfcAdvancedBrep.

All these formats could either be represented as a string or (to be investigated), probably as a json structure. Speckle has json-like support for openNURBS brep, that could be an easy path.

Last question about implementation, would a brep geometry replace the mesh, or come alongside? Keeping always a mesh representation, even if there is brep too, could be interesting as it would allow non-brep apps to open the file too. But it would inflate the file size. Best path maybe, let it optional? Mesh, Brep, or Mesh+Brep?

I'm willing to explore this topic further, if there is interest

[paireks]

Hello @yorikvanhavre!

FreeCAD importer / exporter would be amazing!

Regarding BREP support - dotbim by definition is a mesh-only file format, similar to .stl. There is no plan to change it, because that's one of it's strengths, that it's actually limited to that. E.g. this makes it thousands times easier to create importers or viewers then, when you only have to deal with meshes only. The communication is also much more reliable, because there is no BREP reconstructing during import as it is with BREP-based file formats.

That means any geometry you have - it needs to be discretized to meshes and then exported. It works like this for e.g. Grasshopper that deals with many complex NURBS surfaces, or with cadquery when some BREPs are created.

You're right about file size. That's described a bit there: https://github.com/paireks/dotbim/blob/master/DeveloperTips.md#file-size In short: if there is a way in FreeCAD to deduplicate geometries - then you can save mesh in a file once, and then use it thousands of times in different places, which makes file much smaller. But generally yes, BREP-based file formats can be much more optimized regarding size, so this is some sort of limitation.

Let me know if you will have any questions or comments :)

[yorikvanhavre]

I understand your points of course.. indeed the simplicity of mesh-only geometry is unbeatable and a design choice I totally respect. But for ex. a washbasin or a HVAC duct imported as a mesh is rather unusable in FreeCAD..

I'll research a bit over storing brep data in a string, though. I think that might fit into the current dotbim format if we store some custom text property with such data.. Maybe that leads to something useful for both projects?

[paireks]

Hmm, storing brep data as a property would be really interesting approach, let me know if you will come up with any conclusions.

Will mesh that represents HVAC really be unusable in FreeCAD? I was trying out few HVAC models converted to .bim and it was great as a reference file, for instance to check the collisions.

Generally I would say that if the goal is to take the native geometry and data from software A and turn it to the native geometry and data in a software B, then all other existing solutions (IFC, Speckle, Hypar elements, BHoM) will be much better at it, cause they are designed for that. Dotbim was designed to just move geometry and properties correctly as a reference file in a destination software :) Having it not converted to the native elements of the end software is actually really popular and useful use-case in AEC, yet everyone is trying to solve this native-native transfer for years and years, which requires much more complex approaches. These much more complex approaches impacts how difficult it is to create your own exporters or importers for them. It's great to have them all, but the lack of just one, that limits itself and doesn't require months and years of learning and constant improvements in code was the motivation to come up with one ;)