Hi there !
My name is Roman Lygin, and I am the founder and CEO of CADEX. Welcome to our technical blog. We value our customers’ and prospects’ time so I will try to make this blog relevant, interesting and worth your time. So please do let me know your thoughts on it, what can be added (or avoided) as we move on.
I think this blog will likely be most useful for software developers who need to solve challenges related to CAD data exchange, visualization, modeling, measurements and other similar issues, i.e. those for who CAD Exchanger could be a fit. The purpose of this blog is to complement technical documentation, to share some relevant details on how CAD Exchanger works under the hood, to offer various hints and insights – anything that could help you use it more efficiently in your projects.
With that let me start with a general introduction of CAD Exchanger SDK, which is at core of all of our products.
Target use cases
CAD Exchanger SDK (Software Development Kit) is a set of software libraries that can be integrated into user’s applications which need to provide any of the following:
- Read and/or write 3D files in various formats (IGES, STEP, STL, JT, ACIS .sat, Parasolid .x_t, etc. The full list as of time of this writing is below and the up-to-date version can be found here.
- Create 3D models (precise geometry and polygonal; parts and assemblies)
- View (display) models in 3D views (OpenGL, WebGL, DirectX)
- Perform various measurements (lengths, areas, volumes, bounding boxes, etc)
- Generate 2D or 3D meshes
That’s not an exhaustive list but it does reflect the primary use cases.
SDK itself is written in C++ (with intensive use of C++11) and also offers binding with C# and Java. The SDK is really cross-platform and is supported on Windows, Linux, MacOS, Android and iOS; 4 Visual C++ compilers, 2 gcc compilers and clang; 32 and 64 bit architecture (here is the up-to-date list). This diversity is often a nightmare for our development and infrastructure teams but we try to keep the list broad enough so that our proactive and conservative customers could use SDK wherever they prefer.
Libraries and dependencies
The following diagram demonstrates the key SDK components, entry libraries and their dependencies:
CAD Exchanger SDK libraries
Language wrappers add extra libraries which are clearly aligned with the underling C++ libraries. For instance, C# support adds *Net.dll counterpart for each C++ library, e.g. CadExJTNet.dll for CadExJT.dll, CadExCoreNet.dll for CadExCore.dll and so on.
CadExCore contains common components used by all other libraries. Each format is contained in its specific library following clear naming schema (CadExIGES for IGES, CadExJT for JT and so on). Computational meshers are packaged in CadExMesh. Visualization component (which implementation is underway) is located in CadExView.
All public API is located in the cadex namespace and follows simple naming conventions to shorten learning curve.
Single data model
CAD Exchanger SDK encapsulates 3D model contents into an object of the class cadex::ModelData_Model. That is, any reading workflow end up with creation of (or addition to) such an object. Likewise, any writing workflow uses such as an object as a starting data. Thus, to get data access to any 3D model, a user’s application essentially may communicate with these objects only.
Once the required workflow (e.g. reading and exploring data contents) has been implemented in the user’s application adding support of any new format (for reading or writing) essentially requires a zero effort. Here is how this really works in a user’s application:
void DoSpecificStuff (/*const*/ cadex::ModelData_Model& theModel);
void ImportAndProcessFile (cadex::Base_Reader& theReader,
const cadex::Base_UTF16String& theFileName)
{
cadex::ModelData_Model aModel;
if (aReader.ReadFile (theFileName) && aReader.Transfer (aModel)) {
DoSpecificStuff (aModel);
}
}
//select a reader depending on a file to be read
cadex::STEP_Reader aReader;
ImportAndProcessFile (aReader, “myfile.stp”);All general-purpose algorithms (such as exploring assembly structure, retrieval of surface parameters or triangle coordinates, performing measurements and so on) are format agnostic and thus can be applied on an instance of ModelData_Model imported from any file format.
Having a single data model truly helps to reduce user’s code required to implement desired functionality in his/her app.
In the next post we will dive into some more in-depth details on what’s happening in key SDK workflows.
To be continued…