Alexander Spivakov, head of the C3D Converter team, shares his experience in developing converters of proprietary and IFC formats and describes how it has affected the core functionality from the user and application perspective.
In my publications, I have rarely covered new features of our converters, and even less so, geometry definitions. I have mostly discussed new formats and settings. But this time, as an exception, I will focus on new geometry definitions. The primary reason for this shift is that a large portion of the C3D Converter team’s activities involves developing components for reading proprietary formats and the IFC format.
The image presents a timeline illustrating the evolution of our converters from their inception to their current state. The IFC and Creo converters are excellent examples of our focus on new geometry types and definitions. Equally noteworthy are our enhancements to the core functionality in the converter-to-user and converter-to-application processes.
Fig. 1. Retrospective
We started to extend the converter’s beyond-the-kernel capabilities in 2020. Back then, we worked on an integration with some software products. The geometry types available in most exchange formats (like STEP) were sufficient for us. In 2021, a plugin for Capvidia was released, and we integrated with it. In 2022, It was replaced with a plugin for CAD Exchanger. The approach we used proved to be versatile. We can create plugins for a new software system simply by copying binary files without rebuilding them. Concurrently, in 2022 we started working on proprietary solutions. Immediately we realized that our data exchange approach was insufficient for the new challenges and for the tech stack we had.
Let me explain: NX and SW are based on the Parasolid kernel, and we already had a converter for its native format. It was no longer necessary to convert the geometry on the plugin side or exchange it using the existing data exchange standard — our Parasolid converter could handle it. First, we implemented the support for Parasolid data streams. We did this in the last year’s release. We have taken a similar approach for the Inventor converter, which is currently in active development. Unlike Parasolid, it uses the SAB format. It is not just a binary version of the SAT format, but a dedicated Inventor branch. We added some improvements that were not too complex in terms of mathematics but still very difficult to implement.
It was designed to provide full support for the IFC and Creo formats. In contrast to the conventional boundary and partially polygonal representation, IFC intensively uses Boolean and sweeping operations, not on surfaces, but on bodies. Once again, we had to expand our API. Creo uses a proprietary kernel, and its file format has not been disclosed, even partially. To read such a format, we had to add support for geometric entities from scratch to follow Creo’s logic.
What does the IFC format contain? IFC is predominant in the BIM industry. The format is quite controversial. Initially, we had no intention of supporting it for objective reasons, but we decided to do so in response to customer requests.
The modeling operations are not too complicated, and even not very powerful modelers like ours can handle them. Still, we had to implement such operations. We had an advantage: the converter and modeler are in the same software module. Therefore, we could use the modeler’s capabilities. The modeling operations can range from relatively simple (e.g., three joined and explicitly defined arcs) to quite complex. For instance, the cross-section in a sweep operation is not explicitly defined but is a library element.
Fig. 2. Solids of extrusion and revolution
The image shows an I-beam cross-section with known width, height, and thickness. The plugin generates the explicit geometry for the sweeping operation. In the actual model, this geometry is used to generate the final shape that the user obtains.
Fig. 3. Boolean operations
Another issue is Boolean operations. They are commonly used to cut such openings as windows, doors, etc. In the image, both bodies are extruded solids. Both the wall and window opening are extruded.
Fig. 4. Mesh patching
The IFC format also contains meshes, and there are many of them, with the mesh quality often being poor. At least, such meshes immediately catch my eye when I look at the model. The image shows a mesh that needs patching, and C3D PolyShaper provides a solution. Here we have inconsistent, chaotic normals. To address this problem, we are extending the polygonal modeling and mesh patching capabilities. The patched geometry can be seen on the right.
Fig. 5. Industry metadata
A controversial issue in the IFC format is the industry metadata linked to components. The structure of the metadata can be extremely complicated. There is no way to “hardcode” the data structures needed to store the metadata in RAM and on disk. As a workaround, we have provided the plugin with an interface to exchange this data in a relatively standardized way. The image shows a model imported from the JSON format. The file is read in multiple streams: one for the design trees and the other for the metadata of each component. There is still a lot of work in this area; this is just the beginning of the journey.
The image also shows an example of metadata for one of the components in the design tree. Here, we are handling units of measurement. This is obviously a Tekla file. How to handle these data? It mostly depends on the specific application.
The Creo format is closer to the kernel format rather than to some new, exotic, modeler formats.
In a way, it is similar to old good mechanical CAD formats. What was the most interesting and exciting for us? Some geometry simply did not, and still does not, have counterparts in the C3D format. It’s not too complicated. It can be generated. We use the following strategy: the radius vector and derivatives are calculated by the native format converter, while we make a copy to work with.
Note that some surfaces are defined in a cylindrical coordinate system. The API also had to be enhanced to support such geometry.
Fig. 6. Surfaces in a cylindrical coordinate system
The image shows a model defined in this way. Probably, when building the original model, the use of such a coordinate system was beneficial for the designer in some way, but these subtleties are insignificant to the final result.
Now let us talk about the kernel improvements. One of the most notable changes is support for PMIs.
Fig. 7. PMI exchange via C3D
We have also worked with PMI in the STEP, and JT formats and passed them through objects not intended for read/write operations. They had a different prefix and were not designed to be read and written in the C3D format. The challenge we faced was to exchange PMIs as well. We used to exchange PMIs as very intricate, special-purpose objects. Now PMIs (dimensions, drawing annotation, numerical variables…) are just regular objects. We plan to get rid of the old annotation format to avoid duplication. To make this transition seamless, we have implemented public conversion functions between the old and new formats. Here is a pseudocode demonstrating how to convert objects during the transition period.
Fig. 8. Seamless plugin activation
Previously, to load a plugin and use it to read a file, you had to take many extra actions. You had to obtain an instance of the converter, load the plugin into it, and pass the settings as dedicated properties. For our plugin, a special key, or signature was used. Only then could you run a dedicated read function, and then release the memory for good.
Fig. 9. Seamless plugin activation
It was inconvenient. Now, when working with the native and IFC format converters, you simply call the ImportFromFile function, preceded by kernel activation. Now the activation key can contain the fields required for all the components it supports. To enable the plugin, place the libraries included in the installation package into the same folder as your application and the C3D kernel files. In this case, they are activated automatically for easier operation. Without coding, by just adding files, your applications based on the C3D kernel can now read Creo, NX, SolidWorks, and IFC file formats.
As for new formats to be supported, we are focusing on IFC geometry and metadata exchange. Our colleagues from SoftDev are working on converter components for other formats that will also support metadata.
We will continue to refine the Creo, Invertor, and other format converters. First and foremost, we implement improvements suggested by users. There is another challenge with the IFC format. There is a different approach, not using our standard file reading procedure. We know that some of our customers have proprietary solutions that extract metadata and build bodies. Constructing B-Rep bodies is one of the most demanding tasks. We intend to simplify it as much as possible and to fit the initial data to the IFC requirements. We are going to read the 3mf format out of the box and add support for the kernel’s polygonal objects.
Alexander Spivakov,
C3D Converter Team Leader,
C3D Labs
