claymonkey (May 18 2025 at 13:21): claymonkey (May 18 2025 at 13:21):import IGES or STEP
error！！！
Sean (May 19 2025 at 04:07):@claymonkey iges import is tricky as you have to know and specify the type, and even then it can have problems if the data is not clean -- there are lots of iges exporters that export junk.
with step import, the most common cause is trying to import something that is not ap203e1 -- that's all that's presently supported. some like ap214 or e2 are also common.
claymonkey (May 27 2025 at 13:43):I tried to use the reading method of OpenCaseCAD to parse IGEs. However, it was very troublesome to convert all faces into NURBSface+NURBScurve logic. Especially when I wanted to translate the type into other BREPS models, the speed was very unsatisfactory. This reminded me of the BREPS structure in the current software, but errors frequently occurred when I tried to import it.
Sean (May 30 2025 at 18:25):@claymonkey what is your use case, end goal?
claymonkey (Jun 01 2025 at 02:17):(deleted)
claymonkey (Jun 01 2025 at 02:17):Try to parse the CAD file by yourself and convert it into a creatable BREP type.
Sean (Jun 01 2025 at 04:22):@claymonkey so just for the technical challenge? or some other purpose? parsing and converting from iges/step to some brep in-memory structure is not exactly an end-use case..
If you're working with BRL-CAD, the 3dm-g is by far the best brep import method that imports faithfully & natively using OpenNURBS. Next best is step-g if it's an ap203e1 file. The iges-g importer hasn't been tested or used in production use for nearly a decade, but it has extensive code for multiple import methods and encoding types (including automatic re-encoding of bspline to NURBS) but also less reliable if there are any errors in the geometry.
claymonkey (Jun 01 2025 at 08:35):Because I found that the Brep type of openNurbs is quite similar to that of opencascad, when some programs do not support certain operations, I thought of using the underlying feedback information to create corresponding ones, hoping that other open-source methods can handle them more precisely.
Sean (Jun 01 2025 at 13:58):It is indeed similar, but not 1-1 identical if memory serves.
Sean (Jun 01 2025 at 13:59):so are you looking to bridge geometry from some application built on opencascade into brl-cad, to some operation that brl-cad handles better, and then convert it back?
claymonkey (Jun 01 2025 at 14:03):Yes, if multiple software functions are combined, then only common cad types can be used for conversion. After all, brep will not be exactly the same
Sean (Jun 01 2025 at 14:04):that would certainly be feasible for brep and/or polygonal types I'd think
Sean (Jun 01 2025 at 14:07):problematic encodings are typically: implicits, csg booleans, volumetric/voxel data, level sets, subdivision surfaces, t-splines, medial axis, signed distance fields, and parametric ops like sweep/loft/extrude
Sean (Jun 01 2025 at 14:09):brep is more amenable, includes triangles, polygons, bezier patches, b-spline patches, and nurbs surfaces
claymonkey (Jun 01 2025 at 14:12):Perhaps FACE can be parsed as a combination of the basic NurbsSurface and CurvesToTrimed
. Then perhaps in any logic, there will be corresponding creation methods.
starseeker (Jun 01 2025 at 23:54):There was some work done a while back on opennurbs -> opencascade, IIRC - I think it was this? https://www.cnblogs.com/opencascade/p/opennurbs2opencascade.html
starseeker (Jun 01 2025 at 23:55):I recall hunting around a while back because going to/from opennurbs and opencascade data types would be a keystone of a converter of .g geometry to/from FreeCAD
starseeker (Jun 01 2025 at 23:56):It would be really awesome if we had two way communication with FreeCAD, but my recollection is that the problem is fairly involved - NURBS BRep objects have a LOT of subtypes, and there are subtleties that need to be taken into account.
Last updated: Jun 27 2025 at 00:56 UTC