Визуализация в САПР: зачем мы написали еще один 3D-движок и как он работает

    Команда C3D Labs с 1995 года делает геометрическое ядро, ключевой технологический компонент для создания систем автоматизированного проектирования (САПР). Два года назад мы выпустили собственный модуль визуализации C3D Vision. Зачем понадобился еще один 3D-движок?

    image

    Рендеринг для разработчика САПР всегда сопряжен с определенными сложностями. Если брать готовые коммерческие или опенсорсные визуализаторы, то большинство из них изначально создавались для игровой индустрии и не отвечают специфике инженерных CAD/CAM/CAE-приложений.

    Игровые движки работают с текстурами, спрайтами, анимациями. А инженерным приложениям в первую очередь нужны инструменты работы с геометрией:

    • локаторы – конвертируют экранные координаты курсора в текущий геометрический объект
    • привязки (snap) – вычисляют точные координаты геометрического объекта
    • буксировщики-манипуляторы – позволяют интерактивным способом взаимодействовать с моделью, которая будет строиться.

    Мы назвали три важных для САПР инструмента, которые отсутствуют в игровых движках, но их гораздо больше.

    Писать собственный движок не всем разработчикам под силу. Дорого, долго и отвлекает от основного продукта. Так появился естественный запрос на специализированные движки для САПР. В мире такие есть, например Hoops, Redway, но они достаточно дорогостоящие, кроме того, требуют интеграции с уже разработанными геометрическими ядрами. Потому что лучший визуализатор – тот, который работает вместе с используемым математическим ядром как единое целое.

    До 2016 года у нас не было своего движка. Мы предлагали разработчикам ядро
    геометрического моделирования («мозг» для САПР), решатель геометрических ограничений и модуль обмена данными. А вопросы о визуализации нам задавали регулярно. Заказчики хотели получить движок вместе с ядром, а не заниматься интеграцией стороннего компонента. Так родилось решение написать свой движок, тем более что на тот момент ни одна компания не поставляла полный набор компонентов для создания САПР. И сейчас мы остаемся единственными, кто разрабатывает все четыре компонента: ядро, решатель, конвертер и визуализатор. При этом наш 3D-движок можно использовать и как самостоятельный модуль с компонентами от других разработчиков.

    Почему не OpenGL?


    Действительно, спецификация OpenGL используется для визуализации во многих САПР, но у нее есть серьезные минусы. При всех своих возможностях она не имеет структурного API для описания сцены, а ее интерфейс предоставляет лишь базовые средства для трехмерного рендеринга. Это весьма затрудняет применение разработчиками API OpenGL без использования вспомогательного кода, который обычно реализуется собственными силами и требует много времени и ресурсов. Мы предложили инструмент более высокого уровня, который обеспечивает разработчиков определенными средствами структурного описания сцены визуализации, а также обладает набором необходимых инструментов для интерактивного взаимодействия со сценой.

    Мы учли, что стандарт OpenGL не связан с оконной системой и широко распространен в открытых системах. Спецификация OpenGL использует расширение GLX, которое принадлежит протоколу ядра X Window System и обеспечивает взаимодействие OpenGL и X Window. Данное расширение организует прямой рендеринг в обход X-сервера, что позволяет реализовывать эффективные приложения, работающие в распределенной X-среде. Все эти возможности использованы в нашем визуализаторе.

    Визуализация данных в C3D Vision


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

    Графические приложения, созданные на базе C3D Vision, работают с геометрическими представлениями сцены, а именно с отрезками, поверхностями, ребрами и прочими объектами, которые отрисовываются в активном окне. Непосредственное взаимодействие пользователя с графическим приложением имеет некое представление отображения сцены. В случае если представление не имеет иерархической структуры, а, предположим, представлено простым линейным массивом объектов, то это затрудняет применение эффективных методов, например отсечения невидимых объектов или поиска объектов сцены.

    Применение представления сцены с иерархической структурой дает ряд преимуществ. В этом случае функциональные возможности объектов сцены очень похожи и их можно выделить в отдельные группы, которые объединяются в группы более высокого уровня. В свою очередь, применение иерархических принципов неизбежно приводит к известному графическому стандарту PHIGS (Programmer's Hierarchical Interactive Graphics System).


    Обобщённая схема представления сцены в C3D Vision (картинка кликабельна)

    Именно иерархические принципы были применены при разработке 3D-движка, поэтому описание сцены в нем представлено в виде графа, имеющего терминальные узлы или группы узлов в качестве объектов. Поскольку при таком представлении сцены в качестве узлов в графе выступают сегменты, мы ввели определение «сегментация сцены». Сегмент, не имеющий родителя, называется корневым (от англ. — root). Сегменты могут группироваться по свойствам: материалам, формам и т.д. Кроме того, имеется возможность создавать набор сегментов, в частности шаблонных групп, время жизни которых определяет пользователь. Это может быть набор манипуляторов, заранее созданных для редактирования определенных сегментов, или что-то еще.

    Граф сцены принадлежит контейнеру, имеющему ряд необходимых функций для работы с графом, а также отрисовочный канал. Но, пожалуй, одной из самых важных характеристик C3D Vision является то, что пользователь никак не ограничен в создании множества подобных контейнеров. Он может сформировать несколько независимых друг от друга графов, отличающихся по целому перечню значимых критериев.
    Такой подход гарантирует высокую гибкость в работе визуализатора и дает возможность детально настраивать его для обеспечения максимальной производительности рендеринга.

    Применение сегментации сцены обусловлено не только удобством работы с разделенными на составляющие объектами, но также необходимостью реализации других задач, в том числе:

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


    Сегментация сцены


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


    Представление сцены в виде направленного ациклического графа (картинка кликабельна)

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

    Каждый сегмент графа сцены имеет собственную систему координат, при этом матрица сегмента трансформирует полигональные модели, которые заданы в системах координат подсегментов, в собственную систему координат рассматриваемого сегмента. Поскольку произведение всех матриц от текущего сегмента до root-сегмента графа сцены образует матрицу преобразования из локальной системы координат текущего сегмента в мировую систему координат, то в рассматриваемом случае глобальная система координат будет связана с root-сегментом. В качестве примера сегментации сцены покажем отрисовку 3D-модели экскаватора с поворотной башней и подъемным ротором.

    image
    Модель роторного экскаватора с поворотной башней и подъемным рабочим органом: 1 — гусеничная платформа; 2 — опорно-поворотный механизм; 3 — поворотная платформа; 4 — противовес; 5 — башня; 6 — кабина; 7 — роторный рабочий орган

    На основе модели экскаватора воспроизводим граф сцены. Берем только крупные механизмы 1-3-4-5, то есть произведем сегментацию сцены по ключевым фрагментам.


    Сегментация сцены роторного экскаватора (картинка кликабельна)

    Видно, что сегмент гусеничной платформы наследуется от root-сегмента и содержит матрицу перемещения. При трансформации перемещения изменение этой матрицы будет влиять на все подсегменты, поэтому экскаватор будет перемещаться по ходу движения. Соответственно, трансформация по матрице поворотной платформы будет поворачивать всю группу, включающую подсегменты. Группу сегментов, образующих подграф всего графа сцены, можно рассматривать как отдельный объект, состоящий из множества входящих объектов. Например, автомобиль с креслами может быть представлен неделимым объектом, хотя на самом деле состоит из множества геометрических объектов.

    С помощью такого подхода можно решить ряд полезных задач по управлению местоположением объектов внутри сцены. Достаточно преобразовать матрицу одного промежуточного сегмента, чтобы изменилось местоположение в сцене сразу у всех входящих сегментов, а следовательно, у всей геометрии. Если решается задача перемещения автомобиля, то всё содержимое в нем — кресла, руль, педали, водитель с пассажирами — тоже перемещается без организации каких-либо препятствий для выполнения иных локальных задач. Здесь необходимо подчеркнуть, что любые действия над сегментом в основном распространяются на его подсегменты.

    Остановимся подробнее на ссылочной геометрии. Граф сцены обычно включает большое количество подграфов, а те, в свою очередь, несколько потомков, образующих дочерние подграфы. Наконец, последние могут иметь собственную геометрию. Если рассмотреть множество всех существующих моделей, то становится очевидным, что большинство из них не отличается по геометрии. Тот же самый автомобиль имеет четыре колеса одинаковой формы и размеров, поэтому рационально хранить такую геометрию в одном экземпляре, а для определения различий в местоположении колес использовать индивидуальные матрицы. В C3D Vision мы реализовали возможность присвоения ссылок на геометрию тому или иному сегменту графа сцены.



    Сегментация сцены с применением ссылочной геометрии (картинка кликабельна)

    Одно из наиболее важных свойств графа сцены — это хранение состояния отображения каждого сегмента. В данном случае речь идет о подготовке OpenGL перед отрисовкой по иным свойствам сегмента, таким как текстуры, шейдеры и материалы. Задание ряда свойств сегмента распространяется и на подсегменты, то есть на весь подграф.

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

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

    С помощью графа сцены можно легко находить такие объекты. Для этого в каждом сегменте вычисляются ограниченный прямоугольник или сфера. Далее к нему добавляются все дочерние подграфы и сегменты, и уже непосредственно перед отрисовкой сцены вычисляется пересечение ограничивающей сферы сегмента сцены с так называемой пирамидой видимости. В результате строится сортированный список всех видимых сегментов графа сцены. Данный механизм отсечения незначительных элементов сцены характерен для режима оптимизации Frustum Culling.

    Оценивая преимущества, предоставляемые пользователю базовым функционалом сегментации сцены, отметим следующее:

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

    Освещение сцены


    Реализация света в C3D Vision выполняет ту же роль, что и реальные источники света, поскольку она делает объекты видимыми. Именно источники освещения определяют, какая часть модели будет участвовать в проекции сцены на плоскость, будь то экран компьютера или дисплей мобильного телефона. Самих источников освещения может быть несколько, а соответствующие им объекты C3D Vision способны имитировать различные эффекты освещения. Все объекты смоделированы на основе поведения реальных источников света. Важная особенность — сцена должна иметь хотя бы один источник света, чтобы объекты виртуальной сцены стали видимыми.

    На сегодняшний день в C3D Vision реализовано несколько типов источников освещения:

    • Point Light — реализует освещение сцены, аналогичное ближнему источнику света, при этом источник освещения занимает определенное местоположение и испускает свет из этого положения (функция SetPosition). Объекты на сцене также освещаются в зависимости от их положения и расстояния относительно источника света. Можно не только задать параметры затухания, определяющие интенсивность ослабления источника света в зависимости от расстояния, но и установить значение константы или линейной/квадратичной интерполяции для затухания источника света.
    • Direction Light — реализует освещение сцены, аналогичное удаленному источнику света. Направление источника света, как и в случае с ближним источником света, определяется с помощью функции SetPosition, но уже без указания конкретного местоположения.
    • Spot Light — имеет местоположение и направление и реализует освещение сцены, подобное источнику Point Light. В данном случае свет проецируется в конусообразную область (функция SetSpotCutoffAngle), а ее значение устанавливается в радианах.


    Виртуальная камера


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

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

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

    Что еще умеет C3D Vision?


    Важная особенность C3D Vision – возможность масштабирования программного кода, создание пользователем собственных объектов и интерактивных процессов, позволяющих расширить инструментальные возможности исходной библиотеки. Визуализатор базируется на нашем геометрическом ядре C3D Modeler. Это означает, что при использовании в проекте математической части из набора компонентов C3D Toolkit ее сопряжение с объектами C3D Vision поддерживается напрямую, что существенно облегчает разработчикам создание собственных приложений.

    Мы не рассмотрели подробно поддержку шейдеров, выбор объектов сцены и их детализацию с применением технологии LOD, поддержку полупрозрачных объектов, pixel culling – все это наш модуль визуализации тоже умеет делать.
    Сейчас мы работаем над его второй версией. В ней появятся новые инструменты и возможности, ориентированные на системы автоматизированного проектирования.

    Заинтересованные разработчики могут протестировать C3D Vision. Модуль предоставляется бесплатно на три месяца, по заявке на нашем сайте.

    Эдуард Максименко, к.т.н., руководитель разработки C3D Vision
    АСКОН 129,11
    Крупнейший российский разработчик инженерного ПО
    Поделиться публикацией
    Комментарии 11
      0
      А есть ли у Компас API которое позволяет создавать модели и работать с ними посностью на языке программирования? И на каком языке это API?
        0
        Конечно, в КОМПАСе есть API, на хабре даже уже есть небольшой цикл статей по описанию работы с API на C++ habr.com/company/ascon/blog/350516
        А так можно на Delphi, на C#, на Python писать. SDK есть в папке с программой.
        0
        Я правильно понимаю, что если не OpenGL и DirectX, то вы написали свою математику и сделали работу с ней на видеокарте напрямую (без указанных выше библиотек)?

        Или всё же сделали обертку (движок), которая просто позволяет оперировать описанной вами иерархической структурой?

        p.s.: хочу гордиться коллегами, хочу больше технических деталей, ибо первое сложно, а вот второе не очень.
          +1
          Отвечает Эдуард Максименко:

          «Нет, свою математику мы не писали, т.к. решение OpenGL является стандартом практически для всех ОС и смысла в этом нет.
          Обертка — слово неподходящее, это все же движок, со своим функционалом, оптимизацией, а также инструментарием. Что такое “Обертка”? Если говорить простым языком, в большинстве случаев это промежуточный слой между прикладной программой и другой библиотекой или интерфейсом другого API, цель обертки — упростить и сделать более удобной работу конечного пользователя, но есть и др. цели. Тут разработан именно движок, а обертка над стандартной библиотекой OpenGL занимает объем не более 3-6% от всего кода. Поверьте, что и тут достаточно работы, чтобы сделать ориентированный визуализатор в данной области. И самое главное — разработать необходимый набор функционала, которого не ни в OpenGL, ни в DirectX, и вряд ли когда появится.

          Для ясности привожу примеры: как и в большинстве движков, разработано представление сцены в виде графа, который не имеет отношение к OpenGL и DirectX. Также много механизмов оптимизации LOD, Frustum culling, …, которые не связаны с этими библиотеками, ну а про привязки, локаторы, манипуляторы и, как следствие, собственную событийную модель или поддержку физических устройств я уже говорить не буду. Тем не менее в данной библиотеке присутствует всего лишь два класса, которые выполняют роль оболочки и реализовывают перевызов нескольких функций из OpenGL. Хочу также отметить, что на создание подобных движков уходят годы работы не одного человека, а целой группы. Короче, все зависит от потребности, если вам не обходимо визуализировать кубик — это одно, если мы говорим о библиотеке с большим множеством решений — это совершенно другой расклад. Спасибо за ваше внимание, мы всегда готовы дать максимально развернутый ответ на ваши вопросы».
          0
          Как будете жить с миром Apple который переходит на свой Metal?
            +1
            Отвечает Эдуард Максименко:

            C3D Vision — достаточно молодой компонент в линейке C3D Toolkit. Пока реализована поддержка Windows и Linux. Я думаю, это даже к счастью, что мы еще не реализовали поддержку iOS (с Metal), что позволит нам проанализировать некоторые подходы для дальнейшей его поддержки. В любом случае, нас это не пугает, т.к. C3D Vision имеет модульную основу, что позволяет разработать отдельный плагин для поддержки того или иного отрисовщика, в том числе и Metal, не модифицируя остальные модули движка.
            Как я отмечал в ответе на предыдущий комментарий, реализация плагина отрисовщика занимает незначительную часть по отношению ко всему движку, но, естественно, будет необходим потратить определенное время на изучение Metal, т.к. мы с ним не работали, тут никуда не денешься.
            0
            Вот хотелось бы узнать перспективы по использованию, с виду смотрится красиво.
            Но вот я хочу использовать его к примеру в своем приложении. Где собственно сейчас крутится свой вариант на OpenGL. Приложение не продается и когда будет продаваться неизвестно, и будет ли вообще.
            Это я к тому — во сколько обойдется использование вашего движка в данном случае? Не будет ли в будущем какого-нибудь отказа в стиле — мы решили сделать движок закрытым или поднять на него цены до уровня конкурентов.
            Насколько удобно будет его использовать с Delphi к примеру.
              +1
              Вопрос цены мы обсуждаем индивидуально. В том числе учитываем, на каком этапе разработки находится продукт заказчика, по какой модели будет продаваться.
              Закрывать движок в наши планы не входит. Смысл нашей работы и состоит в том, чтобы дать разработчикам САПР удобный и полезный инструмент.
                0
                Хорошо, а если продукт вообще продаваться не будет? :-)
                Сейчас я его использую больше для обучения студентов, чем для чего-то практического в плане бизнеса.
                  +1
                  Для образовательных задач предоставляется академическая лицензия на все компоненты C3D Toolkit. Подробнее здесь c3dlabs.com/ru/info/education
                  Если такое сотрудничество интересно, напишите на info@c3dlabs.com.
                    0
                    Благодарю за информацию, попробую написать.

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

            Самое читаемое