Особенности использования файла конфигурации тестового приложения ядра C3D

В ходе мастер-класса по возможностям модуля C3D Converter, прошедшего в рамках конференции C3Days 2022, было продемонстрировано, как сформировать двойник модельного документа для того, чтобы упростить работу по ошибкам экспорта. Предложенный подход требует пересборки тестового приложения для активации и настройки отладочной функциональности. Для программистов это, но конечным пользователям, которые не связаны с разработкой, может создать немалые трудности.

Даже нам, разработчикам ядра C3D, не всегда удобно заниматься внесением правок в тестовые приложения, когда к нам приходят специфичные запросы. Поэтому мы решили облегчить работу с приложением, изменив некоторые его настройки так, чтобы они не требовали пересборки приложения и реализации многочисленных диалогов, которые в какой-то момент начинают досаждать пользователям.

Пример ввода данных, необходимых регулярно, уже реализован в приложении — это ввод ключа активации. Подобным образом мы решили подойти и к решению ежедневных задач, а именно — реализовать хранение настроек в конфигурационном файле тестового приложения, который мог бы загружаться при запуске. Тестовое приложение в качестве такого файла рассматривает c3d_test.config, размещённый в домашнем каталоге пользователя.

Первым блоком настроек, ввод которых создавал наибольшую проблему, стали опции плагинов для чтения, не поддерживаемых ядром C3D форматов. Эта функциональность зависит от поставщика плагинов и не входит в комплект поставки, поэтому в исходных кодах тестового (демонстрационного) приложения ей явно не было места. Для работы плагина необходимо знать, как минимум, путь к нему и специфичные для него настройки. И здесь будет уместно сказать о формате конфигурационного файла.

Как устроен файл конфигурации

В отличие от файла с ключом активации перечень настроек может варьироваться в широких пределах, поэтому форма файла из двух строк, каждая из которых имеет своё назначение, явно является неподходящей. В то же время стандартные де-факто форматы — json или xml, требуют некоторых усилий по внедрению. Поэтому было выбрано компромиссное решение: файл представляет собой набор строк вида ключ=значение, где подстрока ключ формируется по специальным правилам, чтобы можно было однозначно идентифицировать, какой настройке она отвечает, и выбрать правильный способ распознавания подстроки значение.

Например, в случае с настройками плагина ключи имеют следующий вид:

Итак, все ключи начинаются с converter.plugin. . С одной стороны это облегчает чтение и правку конфигурационного файла человеком, а с другой — не слишком обременительно в плане интерпретации ключа в коде, т.к. это фиксированные строки, которые перечислены в заголовочном файле test_variables.h. Среди этих настроек есть как фиксированное значение (нет точки в конце) converter.plugin.FULL_PATH, так и настраиваемое (оканчивается точкой) converter.plugin.settings. . В приведённом примере C3D_PLUGIN_DECORATOR_TWIN_SAVE_TO — настройка, специфичная для плагина plugin_decorator.dll, и только эта библиотека знает, как правильно её применять, если применять вообще.

Какие ещё есть настройки

Отладочные настройки

На мастер-классе упоминалось, что для передачи отладочных настроек в конвертеры сформирована специальная структура C3DConverterDebugSettings, а также продемонстрирована работа с ней на примере записи двойника модельного документа. Активировать запись модельного документа теперь можно с помощью ключа converter.settings.debug.saveModelTwin, а запись журнала трансляции — с помощью ключа converter.settings.debug.enableCERRout.

Отладочная отрисовка

Возможность передачи тестовому приложению в качестве аргумента пути к модели, которую нужно открыть при старте, неожиданно стала источником неудобств, по крайней мере, при работе конвертеров. Дело в том, что у тестового приложения есть отладочная отрисовка, к которой нет обращений при чтении формата c3d, однако она активно задействуется при импорте. Исторически эта вспомогательная функциональность включена по умолчанию, что отвечает требованиям разработчиков компонента C3D Modeler, в котором чтение файла формата c3d считается само собой разумеющимся, а визуализация отладочных данных нужна только при выполнении операций моделирования. У разработчиков компонента C3D Converter, наоборот, самые интересные события происходят именно в процессе чтения, и отладочная отрисовка гарантированно снижает производительность, поскольку, работая неизбирательно, усложняет процесс отладки. Поэтому для чтения моделей из форматов, отличных от c3d, как правило, выставляется настройка app.debug.draw=false.

Многопоточность

Схожая ситуация имеет место и с многопоточностью. По умолчанию app.multithreading_mode=31, но в особых случаях задаётся требуемое значение.

Настройки импорта

При импорте моделей в зависимости от конфигурации диалоги, уточняющие настройки импорта, могут как вызываться, так и не вызываться. Это решение является компромиссным, поскольку, с одной стороны, предоставляет наиболее часто используемые настройки импорта разработчикам, а с другой — сохраняется возможность сравнительно легко избавиться от необходимости на них реагировать в случае применения настроек по умолчанию.

Теперь управление сшивкой и объединение подобных граней также перенесено в конфигурационый файл. Для выключения сшивки и объединения подобных граней нужно задать converter.settings.stitch_on=true и converter.settings.join_similar_faces=false.

На иллюстрации виден результат работы алгоритмов сшивки и объединения подобных граней.

Как вернуть привычный режим работы

Все настройки (за исключением отладочных настроек конвертеров), которые задаются через файл конфигурации, по-прежнему можно изменять в меню пользовательского приложения или в диалогах. Если для решения какой-то задачи нужно работать с настройками приложения по умолчанию, необязательно удалять или переименовывать сам файл.

Например, если в одном сеансе работы нужно управлять объединением подобных граней, можно вернуть диалоговое окно. Для этого достаточно в начале строки, где задаётся опция, поставить решётку:

#converter.settings.join_similar_faces=true

Таким образом тестовое приложение проигнорирует строку целиком и не будет пытаться найти несуществующую опцию.

Заключение

Нам, как разработчикам, некоторые операции при работе с ядром кажутся настолько привычными и очевидными, что некоторые вопросы пользователей ставят в тупик точно так же, как порой предлагаемые нами решения не учитывают особенности наших рабочих мест.

Использование файла конфигурации позволит минимизировать количество диалогов — препятствий на пути к получению результата. Кроме того, хранимые таким образом настройки избавят наших пользователей от необходимости объяснять, какие значения они вводили и в какие поля, особенно если языки интерфейсов будут отличаться.

Автор:
Александр Спиваков
Руководитель отдела разработки модуля обмена данными