August 25, 2017 at 13:17KOMPAS-3D Viewer for Android: the experience of porting a large Windows application
Despite the total "mobilization" of the average user, most engineers continue to work on desktop PCs. There are very few large engineering programs, primarily CAD, for mobile OS. A few years ago, ASCON launched the free KOMPAS: 24 application for viewing KOMPAS-3D documents (parts, assemblies, drawings, specifications, etc.) on Android devices.
Model "KAMAZ of the Future", by Dmitry Kotlyar.
One of the KOMPAS developers tells about how porting a large Windows application to Android was implemented: 24 Alexander Poluektov.
The specificity of the KOMPAS-3D file format is such that there is no description of the internal structure of the document and it is impossible to read the file without the source code of the main product (although attempts were made both on its own and by third-party developers).
Data is serialized in binary form, each class does it on its own, taking into account the version of the file. KOMPAS-3D with the fifth version was developed only for Windows, but users have long asked to implement at least viewing files from other OSs. It was decided to create a separate KOMPAS: 24 product for Android based on the existing KOMPAS-3D code.
The project is very large - several million lines in C ++. Since there is C ++, you can use NDK, rather than re-write everything. Somewhat reduced the amount of work that part of the system (geometric core) was already independent from the GUI and adapted for Linux-systems.
C3D kernel test application for Linux
Initially, the task was to read 3D models from files and draw them, i.e. get bodies, count triangulation and dump them in OpenGL. In reality, it turned out that the resulting bodies were not saved in the file, but only the construction history. It was necessary to organize the reading of all available objects, including drawing / fragment objects that are used in the sketch. By adding work, this made it possible to organize the opening of not only parts / assemblies, but also drawings / fragments. It turned out that the model changes made in the assembly require the rebuilding of the included parts with the transfer of data through writing to memory, similar to storing on disk. In addition to reading the file, I also had to implement a writing mechanism.
A large number of source texts, of course, need to be structured. In order not to reinvent the wheel, the project was divided into modules, similar to the original ones. The modules responsible for the user interface and construction processes were excluded. At first there was a difficulty with a mathematical core that did not want to link. The problem arose because the command line passed to the linker was too long. To resolve the situation without major alterations to the project, I had to bring the kernel assembly to a Linux virtual machine. Fortunately, in the next version of Android NDK, the problem was fixed, and now there are no such difficulties.
It was not a significant problem, but it required strong nerves to debug. Making changes in one line requires the assembly and restart of the project from three (at best) to 40 minutes.
Drawing display
Work with the file system, registry and user interface has been moved to separate modules. This allowed to significantly limit the place of continuous transcribing. Here's the difficulty of adding lines. Depending on the version of the file, the line may turn out to be either 1-byte windows-1251 or 2-byte wchar_t. Android NDK has native utf-8 encoding and 4-byte wchar_t is acceptable. And also lines are compared on more / less and with them hashes are totaled. The only way to deal with this zoo is through long debugging and a close look at the code.
Significantly increased development time a large amount of legacy code. The project is really old. There is code written 15 years ago under Visual Studio 6 / Borland C ++ Builder. Considering how calmly the Microsoft compiler treats the violation of the C ++ standard (and sometimes even encourages it), it was often necessary to rewrite platform-independent, at first glance, code fragments.
I mentioned the specifics of serialization at the beginning. The data is serialized in binary form, and each class does this on its own, taking into account the version of the file. The built-in windows types are serialized, including VARIANT. The hashes of strings are serialized, which are then compared with strings (remember about encodings).
The development of the first version of KOMPAS: 24 took about six months. New releases include support for the latest versions of KOMPAS-3D files and minor improvements.
The project includes more than 2000 cpp-files from KOMPAS-3D and about 20 files specific to KOMPAS-only: 24. The code contains about 4000 sections with different implementations for KOMPAS-3D and KOMPAS: 24.
The ability to open any model, assembly or drawing that has enough RAM for the mobile device has been achieved. In practice, not all files are opened, but it is a matter of fixing individual bugs.
Received code that is relatively easy to support for all platforms. There are experimental assemblies of KOMPAS: 24 for Linux and Windows.
Application of a dynamic section to a turbo coupling model
During the development process, the possibility of the existence of KOMPAS-3D for Android was confirmed. When you open assemblies, a complete rebuild occurs. Mobile applications have made a huge leap from simple games and notebooks to serious projects. In addition, the performance of modern phones overtook PCs a decade ago, and the size and resolution of the tablets allow you to place enough information on the screen.
KOMPAS: 24 became a testing ground for solutions, some of which were subsequently transferred to KOMPAS-3D. For example, in KOMPAS: 24, for the first time, a dynamic section of 3D models appeared, quick rendering with triangulation caching, and quick opening of assemblies from the cache without rebuilding.
Alexander Poluektov, lead programmer
Model "KAMAZ of the Future", by Dmitry Kotlyar.
One of the KOMPAS developers tells about how porting a large Windows application to Android was implemented: 24 Alexander Poluektov.
Baseline
The specificity of the KOMPAS-3D file format is such that there is no description of the internal structure of the document and it is impossible to read the file without the source code of the main product (although attempts were made both on its own and by third-party developers).
Data is serialized in binary form, each class does it on its own, taking into account the version of the file. KOMPAS-3D with the fifth version was developed only for Windows, but users have long asked to implement at least viewing files from other OSs. It was decided to create a separate KOMPAS: 24 product for Android based on the existing KOMPAS-3D code.
The project is very large - several million lines in C ++. Since there is C ++, you can use NDK, rather than re-write everything. Somewhat reduced the amount of work that part of the system (geometric core) was already independent from the GUI and adapted for Linux-systems.
C3D kernel test application for Linux
Challenges, Pitfalls, and Solutions
Initially, the task was to read 3D models from files and draw them, i.e. get bodies, count triangulation and dump them in OpenGL. In reality, it turned out that the resulting bodies were not saved in the file, but only the construction history. It was necessary to organize the reading of all available objects, including drawing / fragment objects that are used in the sketch. By adding work, this made it possible to organize the opening of not only parts / assemblies, but also drawings / fragments. It turned out that the model changes made in the assembly require the rebuilding of the included parts with the transfer of data through writing to memory, similar to storing on disk. In addition to reading the file, I also had to implement a writing mechanism.
A large number of source texts, of course, need to be structured. In order not to reinvent the wheel, the project was divided into modules, similar to the original ones. The modules responsible for the user interface and construction processes were excluded. At first there was a difficulty with a mathematical core that did not want to link. The problem arose because the command line passed to the linker was too long. To resolve the situation without major alterations to the project, I had to bring the kernel assembly to a Linux virtual machine. Fortunately, in the next version of Android NDK, the problem was fixed, and now there are no such difficulties.
It was not a significant problem, but it required strong nerves to debug. Making changes in one line requires the assembly and restart of the project from three (at best) to 40 minutes.
Drawing display
Work with the file system, registry and user interface has been moved to separate modules. This allowed to significantly limit the place of continuous transcribing. Here's the difficulty of adding lines. Depending on the version of the file, the line may turn out to be either 1-byte windows-1251 or 2-byte wchar_t. Android NDK has native utf-8 encoding and 4-byte wchar_t is acceptable. And also lines are compared on more / less and with them hashes are totaled. The only way to deal with this zoo is through long debugging and a close look at the code.
Significantly increased development time a large amount of legacy code. The project is really old. There is code written 15 years ago under Visual Studio 6 / Borland C ++ Builder. Considering how calmly the Microsoft compiler treats the violation of the C ++ standard (and sometimes even encourages it), it was often necessary to rewrite platform-independent, at first glance, code fragments.
I mentioned the specifics of serialization at the beginning. The data is serialized in binary form, and each class does this on its own, taking into account the version of the file. The built-in windows types are serialized, including VARIANT. The hashes of strings are serialized, which are then compared with strings (remember about encodings).
Development Results
The development of the first version of KOMPAS: 24 took about six months. New releases include support for the latest versions of KOMPAS-3D files and minor improvements.
The project includes more than 2000 cpp-files from KOMPAS-3D and about 20 files specific to KOMPAS-only: 24. The code contains about 4000 sections with different implementations for KOMPAS-3D and KOMPAS: 24.
The ability to open any model, assembly or drawing that has enough RAM for the mobile device has been achieved. In practice, not all files are opened, but it is a matter of fixing individual bugs.
Received code that is relatively easy to support for all platforms. There are experimental assemblies of KOMPAS: 24 for Linux and Windows.
Application of a dynamic section to a turbo coupling model
During the development process, the possibility of the existence of KOMPAS-3D for Android was confirmed. When you open assemblies, a complete rebuild occurs. Mobile applications have made a huge leap from simple games and notebooks to serious projects. In addition, the performance of modern phones overtook PCs a decade ago, and the size and resolution of the tablets allow you to place enough information on the screen.
KOMPAS: 24 became a testing ground for solutions, some of which were subsequently transferred to KOMPAS-3D. For example, in KOMPAS: 24, for the first time, a dynamic section of 3D models appeared, quick rendering with triangulation caching, and quick opening of assemblies from the cache without rebuilding.
Alexander Poluektov, lead programmer