C3D Kernel Test Application: How to Use the Configuration File

We hosted the C3D Converter master class at the C3D Days 2022 Conference to show how to generate a twin of the model file for easier export error handling. The proposed approach requires rebuilding the test application to activate and configure the debug feature. It is no big deal for the developer, but the end users not involved in software development may find it challenging.

Even we, the C3D kernel developers, are not always happy with editing the test applications to meet some specific user requests. We decided to make it easier by changing some settings to avoid rebuilding the application and to remove the numerous dialog windows that may get annoying at some point.

For example, we’ve already made it easier to enter the activation key: you do not have to do it every time as was the case. We applied a similar approach to handle other routine procedures: the test application settings are stored in a configuration file loaded at startup. The configuration file name is c3d_test.config. It should be in the user's home directory.

The settings of the plugins which read the formats not directly supported by the C3D kernel were a real challenge so they were the first to go to the configuration file. The third-party plugins are not in the kernel's scope of delivery, so their settings should not be incorporated in the source code of the test (demo) application. To run a plugin, we need to know at least the path to it and its specific settings. Now let us talk about the configuration file format.

Configuration File Structure

As opposed to the activation key file, the number of settings varies widely, so the simple two-line file structure is inappropriate. On the other hand, the de-facto standard formats like json or xml require some effort to handle. We made a compromise: the file is a list of key=value strings, where the key part meets some rules to identify which setting it represents and correctly interpret the value part.

For example, for a plugin setting, the keys may look like this:

As you can see, every key begins with converter.plugin. It makes the configuration file readable and editable, and it is not too hard to handle the keys programmatically: these are string constants listed in the test_variables.h header file. There are two types of settings: fixed values (no dot at the end: converter.plugin.FULL_PATH), and configurable values (a dot at the end: converter.plugin.settings.) In this example, C3D_PLUGIN_DECORATOR_TWIN_SAVE_TO is a specific setting of the plugin_decorator plugin. Only this library knows how to properly use it, if at all.

Other Settings

Debug settings

In the master class, we mentioned the special structure C3DConverterDebugSettingsused to pass the debug settings to the converters and demonstrated how to use to save a twin of a model file. Now you can do it with the converter.settings.debug.saveModelTwin key and the conversion log is saved with converter.settings.debug.enableCERRout.

Debug Rendering

As we have an ability to pass a path to the model, opened at startup, to the test application as a command line argument, it unexpectedly become an inconvenience, at least for the converters. The point is that the test application supports a debug rendering feature. It is not needed when reading the c3d format but is intensively used for importing models from other formats. This auxiliary functionality is enabled by default to meet the requirements of the C3D Modeler component developers where reading c3d file formats is a must while visualizing the debug data is only needed for some geometric modeling operations. It is the other way around for the C3D Converter component developers: the model reading is the most challenging operation, and any debug rendering inevitably harms the performance and complicates the debugging. Therefore, to read models in formats other than c3d, the app.debug.draw=false setting is usually used.

Multithreading

The multithreading functionality is similar. By default app.multithreading_mode=31, but in special cases, another value is set.

Import Settings

When importing models, the dialog windows with the import settings may or may not be invoked depending on the configuration. It is a compromise. On the one hand, the developers can access the most common import settings, and, on the other hand, it is relatively easy to suppress these windows if the default settings are applied.

For example, face stitching and joining settings have also been moved to the configuration file. To activate face stitching, set converter.settings.stitch_on=true and converter.settings.join_similar_faces=false.

The image shows how faces are stitched and joined.

Back to The Old Way

All the settings (except for the converter debug settings) in the configuration file can still be changed in the application menu or dialogs. If you need to use the default application settings, you don't need to delete or rename the configuration file.

For example, if you need to manually control the face joining in a specific session, you can return the dialog box. To do this, just add a hash symbol at the beginning of the line:

#converter.settings.join_similar_faces=true

The test application will ignore the entire string and will not look for the non-existent option.

Conclusion

We, the developers, find some of the kernel features so familiar and obvious that some questions from the users baffle us, just like the solutions we offer sometimes do not match some specific workflows.

The configuration file minimizes the number of dialog boxes standing between the user and the result. Besides, with the configuration file, our users will not have to memorize which values and in which fields they enter (especially if they use a different interface language).

Author:
Alexander Spivakov
Data Exchange Module Development Manager