[idea] Creating plugins for other commercial CAD software to import FreeCAD files

[foadsf]

If I understand foadsf right it's not a question of reading the binary format. To go from SolidWorks to FreeCAD it's rather creating a FreeCAD file in SolidWorks using VisualBasic, or generate python code using VisualBasic which creates the model tree.
The other way, to go from FreeCAD to SolidWorks would again not create the model file, but rather VisualBasic code which generates the model in Solid works.

I think it's a good idea and should be rather stable even if the binary format doesn't change. I would guess that SolidWorks, Catia and others may well change their internal format, but try to keep the API stable.

Let's say we want to import/export from FreeCAD/software-X to/from software-x/FreeCAD in binary/script format. There are 2^3 (8) possibilities.

1. plugin for software-x:
   1. Import/export from/to FreeCAD binary files: this should be possible by replicating or wrap that part of OCCT which is responsible for parsing/writing binary data into design tree (or vice-versa), in the macro language of the software-x (in the case of SolidWorks VB, but Autodesk software like fusion 360 also have Python AFIK).
   2. import/export FreeCAD's Python scripts: this actually should be easier. Using regular expressions one should be able to parse Python scripts, in for example VB, and then extract the data/expressions and convert them to software-x macro language API.
2. plugin for FreeCAD:
   1. Import/export from/to software-x: binary format: This is actually a huge challenge requiring years of try and error reverse engineering, assuming the beneficiary company does not change the internal guts of their binary files, which I assume they do quite often. Unless they use a fixed and open standard like DWG/DXF/OLE2... I don't see this happening any time soon.
   2. Importing/exporting from/to software-x macros: This is actually again very much possible. I see there are already some Python projects to parse Visual Basic and the other way around, parsing Python scripts in visual Basic, is also feasible. In fact, a lot of companies who distribute the CAD models of their Off-the-shelf parts for SW, use VB macros. The main reason I think is that they have one script which generates the CAD models programmatically instead of having thousands of different CAD models just with small dimensional differences.

So I would say except 2.1 the rest of the options seem possible. It is a matter of dividing it into smaller steps and actually implementing them. 2.2 seems the "easiest" considering there are already some Visual Basic parser libraries for Python. If this done then theoretically FC users should be able to import the infinite number of off-the-shelf CAD models on the internet.

[chrisb]

Are there any specific reasons why FreeCAD/OpenCASCADE store data in binary format

It may look like, but it doesn't. A FreeCAD document is a zip container containing ascii XML files.

Besides binary files for open source programs are no problem, as long as their structure is well documented.

[foadsf]

It may look like, but it doesn't. A FreeCAD document is a zip container containing ascii XML files.

Awsome. I had no idea about this. According to Wikipedia:

FreeCAD's own main file format is FreeCAD Standard file format (.FCStd). It is a standard zip file that holds files in a certain structure. Document.xml file has all geometric and parametric objects definitions. GuiDocument.xml then has visual representation details of objects. Other files include brep-files for objects and thumbnail of drawing.

And when I open the .FCStd file with 7zip, I indeed see two XML documents GuiDocument.xml and Document.xml. there is an SVG file, lots of DiffuseColor, LineColorArray, PointColorArray, and PartShape*.brp files. Any idea what these are? Should I be able to reproduce the CAD model just with the XML file?

besides, binary files for open source programs are no problem, as long as their structure is well documented.

Very much true. Even if that was the case, given the parser is open-source, one should be able to wrap it in any other language or replicate it.

[ickby]

XML Files are the document structure, objects and properties etc. The brep files are the actual shapes in binary format. So technical you don't need them, as freecad could recalculate all shapes from the information in the XML files. But we do not do that as loading would take ages die to recalculation, and it would also not be guaranteed to be the exact same shape as freecad and occt version or setting may be different

[ickby]

The reason for the binary format is space efficiency and read write times, which are way faster for binary

[foadsf]

XML Files are the document structure, objects and properties etc. The brep files are the actual shapes in binary format. So technical you don't need them, as freecad could recalculate all shapes from the information in the XML files.

I tried this and did not succeed. More info here.

The reason for the binary format is space efficiency and read write times, which are way faster for binary

using an archive file would definitely help with space efficiency and cleanness. But I would argue if it would improve read-write speed.

[wmayer]

However, the founder Roman Lygin, has been a serious contributor to OCCT

AFAIK he once was an OCCT developer.

1. The CAD data in FreeCAD files is most of the time stored in binary format (depends on FreeCAD settings).

The FCStd itself is binary (it's a zip archive) but the stored BRep data usually are in ASCII. There is a user setting SaveBinaryBrep to force to write BRep in binary but by default this is off.

You would need a part of OCCT to read and interpret it. This means any importer needs to be a own software, with occt included, either as library or executable... so it is not easily implemented in visual basics etc.

For parametric features it's theoretically possible to not export the BRep files because they can be restored by doing a recompute. For non-parametric objects the BRep must be exported, of course.

Are there any specific reasons why FreeCAD/OpenCASCADE store data in binary format? I'm no expert but this seems like a bad idea.

As said by default the output is ASCII. The binary format once was implemented for FreeCAD's AutoRecovery function where every few minutes the changes since the last time are stored to disk. The binary format there was chosen because it's way faster than ASCII.

I'm not sure how OCCT stores data, but it should be something like storing the design steps in chronological order or categorizing the geometries in different categories (point, line, plane, cube, cylinder, sketch, extrude....).

The BRep format is OCCT's proprietary format but like STEP or IGES it is still a dump format since it doesn't contain any information about the modelling history. That information is part of FreeCAD's Document.xml which is inside every .FCStd project.

Should I be able to reproduce the CAD model just with the XML file?

Theoretically, for fully parametric features the Document.xml file alone should sufficient to restore the model. But practically the more complex your model is the less likely it will be restored as expected if the BRep files are missing. This is mainly because of the topological-naming problem.

[sgrogan]

AFAIK he once was an OCCT developer.

Yes, this is my mistake, I edited my previous post.