KOMPAS-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 stationary PCs. Large engineering programs, especially CAD, for mobile OS is extremely small. A few years ago, ASCON had a free KOMPAS application: 24 for viewing KOMPAS-3D documents (parts, assemblies, drawings, specifications, etc.) on Android devices.
Model "KAMAZ of the Future", author 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 having the source code of the main product (although attempts were made both on our own and by third-party developers).
Data is serialized in binary form, each class does it on its own, taking into account the file version. KOMPAS-3D from the fifth version was developed only for Windows, but users have long been asked to implement at least viewing files from other operating systems. It was decided to create a separate KOMPAS product: 24 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, and not write it all over again. Somewhat reduced the amount of work that part of the system (geometric core) was already independent of 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 in OpenGL. In reality, it turned out that not the resulting bodies are saved in the file, but only the construction history. It was necessary to organize reading of all available objects, including drawing / fragment objects, which are used in the sketch. Adding work, it allowed 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 rebuilding the included parts with the transfer of data through a record in memory, similar to storing on disk. In addition to reading the file, I also had to implement the write 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 one. The modules responsible for the user interface and build processes were excluded. At first, there was a difficulty with the unwilling to link the mathematical core. The problem arose due to the too long command line passed to the linker. To resolve the situation without major rework of the project, we had to bring the kernel assembly to a virtual machine with Linux. Fortunately, in the next version of Android NDK, the problem has been fixed, and now there are no such difficulties.
It was not a significant problem, but debugging required strong nerves. Making changes to 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 was rendered into separate modules. This allowed us to significantly limit the place of continuous rewriting. Here the difficulties added to the line. Depending on the file version, the string may be either 1-byte windows-1251, or 2-byte wchar_t. For Android NDK, the native encoding is utf-8 and 4-byte wchar_t is allowed. And the lines are compared to more / less and from them are hashes. The only way to deal with this zoo is long-term debugging and a close look at the code.
Significantly increased development time for a large number of legacy code. The project is really old. There is a code written 15 years ago under Visual Studio 6 / Borland C ++ Builder. Taking into account how quietly the Microsoft compiler relates to a violation of the C ++ standard (and sometimes even encourages), we had to frequently rewrite platform-independent, at first glance, code fragments.
I mentioned the specifics of serialization at the beginning. Data is serialized in binary form, and each class does it on its own, taking into account the file version. Built-in types of windows are serialized, incl. VARIANT. 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. In new releases, there is support for new versions of KOMPAS-3D files and minor improvements.
The project includes more than 2000 cpp-files from KOMPAS-3D and about 20 files, characteristic only for KOMPAS: 24. In the code there are about 4000 plots with different implementations for KOMPAS-3D and KOMPAS: 24.
The opportunity to open any model, assembly or drawing for which the RAM of the mobile device is enough is achieved. In practice, not all files are opened, but it is a matter of fixing individual bugs.
A code is received that is relatively easy to maintain for all platforms. There are experimental builds of KOMPAS: 24 for Linux and Windows.
Application of the dynamic section to the turbo coupling model
In the development process confirmed the possibility of the existence of KOMPAS-3D for Android. When you open assemblies, a full rebuild occurs. Mobile applications have made a huge leap from simple games and notebooks to serious projects. In addition, the performance of modern phones have overtaken the PC a decade ago, and the size and resolution of the tablets allow you to place on the screen a sufficient amount of information.
KOMPAS: 24 became a testing ground for decisions, some of which were later transferred to KOMPAS-3D. For example, in KOMPAS: 24, for the first time, a dynamic section of 3D models appeared, fast rendering with caching of triangulation, and quick opening of assemblies from the cache without rebuilding.
Alexander Poluektov, Lead Programmer
Model "KAMAZ of the Future", author Dmitry Kotlyar.
One of the KOMPAS developers tells about how porting a large Windows application to Android was implemented: 24 Alexander Poluektov.
Baseline conditions
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 having the source code of the main product (although attempts were made both on our own and by third-party developers).
Data is serialized in binary form, each class does it on its own, taking into account the file version. KOMPAS-3D from the fifth version was developed only for Windows, but users have long been asked to implement at least viewing files from other operating systems. It was decided to create a separate KOMPAS product: 24 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, and not write it all over again. Somewhat reduced the amount of work that part of the system (geometric core) was already independent of the GUI and adapted for Linux-systems.
C3D Kernel Test Application for Linux
Difficulties, pitfalls and solutions
Initially, the task was to read 3D models from files and draw them, i.e., get bodies, count triangulation and dump in OpenGL. In reality, it turned out that not the resulting bodies are saved in the file, but only the construction history. It was necessary to organize reading of all available objects, including drawing / fragment objects, which are used in the sketch. Adding work, it allowed 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 rebuilding the included parts with the transfer of data through a record in memory, similar to storing on disk. In addition to reading the file, I also had to implement the write 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 one. The modules responsible for the user interface and build processes were excluded. At first, there was a difficulty with the unwilling to link the mathematical core. The problem arose due to the too long command line passed to the linker. To resolve the situation without major rework of the project, we had to bring the kernel assembly to a virtual machine with Linux. Fortunately, in the next version of Android NDK, the problem has been fixed, and now there are no such difficulties.
It was not a significant problem, but debugging required strong nerves. Making changes to 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 was rendered into separate modules. This allowed us to significantly limit the place of continuous rewriting. Here the difficulties added to the line. Depending on the file version, the string may be either 1-byte windows-1251, or 2-byte wchar_t. For Android NDK, the native encoding is utf-8 and 4-byte wchar_t is allowed. And the lines are compared to more / less and from them are hashes. The only way to deal with this zoo is long-term debugging and a close look at the code.
Significantly increased development time for a large number of legacy code. The project is really old. There is a code written 15 years ago under Visual Studio 6 / Borland C ++ Builder. Taking into account how quietly the Microsoft compiler relates to a violation of the C ++ standard (and sometimes even encourages), we had to frequently rewrite platform-independent, at first glance, code fragments.
I mentioned the specifics of serialization at the beginning. Data is serialized in binary form, and each class does it on its own, taking into account the file version. Built-in types of windows are serialized, incl. VARIANT. 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. In new releases, there is support for new versions of KOMPAS-3D files and minor improvements.
The project includes more than 2000 cpp-files from KOMPAS-3D and about 20 files, characteristic only for KOMPAS: 24. In the code there are about 4000 plots with different implementations for KOMPAS-3D and KOMPAS: 24.
The opportunity to open any model, assembly or drawing for which the RAM of the mobile device is enough is achieved. In practice, not all files are opened, but it is a matter of fixing individual bugs.
A code is received that is relatively easy to maintain for all platforms. There are experimental builds of KOMPAS: 24 for Linux and Windows.
Application of the dynamic section to the turbo coupling model
In the development process confirmed the possibility of the existence of KOMPAS-3D for Android. When you open assemblies, a full rebuild occurs. Mobile applications have made a huge leap from simple games and notebooks to serious projects. In addition, the performance of modern phones have overtaken the PC a decade ago, and the size and resolution of the tablets allow you to place on the screen a sufficient amount of information.
KOMPAS: 24 became a testing ground for decisions, some of which were later transferred to KOMPAS-3D. For example, in KOMPAS: 24, for the first time, a dynamic section of 3D models appeared, fast rendering with caching of triangulation, and quick opening of assemblies from the cache without rebuilding.
Alexander Poluektov, Lead ProgrammerSource: https://habr.com/ru/post/336300/
All Articles