¬аше окно в мир —јѕ–
 
Ќовости —татьи јвторы —обыти€ ¬акансии Ёнциклопеди€ –екламодател€м
—татьи

26 €нвар€ 2017

„ерез тернии к облакам: создание облачного сервиса дл€ 3D проектировани€ и дизайна помещений на базе €дра C3D и WebGL

–оман  олесников

–оман  олесников

ќт редакции isicad.ru: ¬ €нваре 2013 года геометрическое €дро C3D компании ј— ќЌ было лицензировано разработчиком мебельных —јѕ– Ч фирмой Ѕазис-÷ентр. ќдним из последствий этого событи€ стала публикаци€ в августе 2015 года статьи Ђядерные технологии в CADї, написанной –оманом  олесниковым, разработчиком в компании ЂЅазис-÷ентрї, который с 2005 года занимаетс€ трехмерным моделированием и визуализацией.

¬ новой статье, предлагаемой сегодн€ вашему вниманию, –оман представл€ет проект, цель которого достаточно €сна из названи€ статьи. ѕри этом, как и в публикации 2015 года, автор демонстрирует весьма ценную склонность и способность к обоснованию своих решений, что придаЄт его стать€м дополнительно полезный обзорно-справочный характер.

Ќынче в интернетах только и говор€т об облаках, как они бесконечны и прекрасныЕ о серверах, которые они там виделиЕ ј ты? ¬от и € решил поделитьс€ с читател€ми своим опытом разработки онлайн сервиса проектировани€ помещений и интерьеров в 3D. «десь € постараюсь рассказать об архитектуре проекта в целом и о детал€х реализации.

„то такое облачна€ система 3D проектировани€? ѕоскольку в последнее врем€ термин Ђоблачные вычислени€ї очень попул€рен и используетс€ к месту и не к месту, € начну с определени€. ќблачное 3D проектирование в моем понимании и моей реализации Ц это така€ архитектура программного обеспечени€, при которой все данные о 3D модели и действи€ по еЄ обработке расположены на удаленных серверах (т.е. в облаках), а клиентские устройства запрашивают ту или иную часть данных или результатов расчетов по сети интернет. ƒругими словами, подобные системы отличаютс€ от классических систем проектировани€ тем, что производ€т большинство расчетных операци€х на серверах, а не на клиентских устройствах и передают только небольшую часть данных дл€ визуализации модели и ее параметров клиенту. јрхитектура подобных систем оказываетс€ разделЄнной на тесно взаимодействующие, но удаленно расположенные, серверную и клиентскую части, что требует особого подхода дл€ обеспечени€ их взаимодействи€ незаметно дл€ пользовател€ продукта.

—ледующий вопрос: какие преимущества имеет подобна€ архитектура? Ќесомненно, облачна€ архитектура сложнее классической, в которой пользователь, его данные и их обработка наход€тс€ и производ€тс€ в одном месте. “ем не менее, дл€ моего проекта облачна€ архитектура имеет р€д неоспоримых преимуществ как с точки зрени€ разработки, так и с точки зрени€ использовани€, дела€ подобное усложнение архитектуры приложени€ целесообразным. ѕопробую их сформулировать:

  1.  лиентским приложением €вл€етс€ веб-браузер. ¬ наше врем€ это означает кроссплатформенность приложени€ и возможность пользоватьс€ сервисом с любого устройства.
  2. Ѕыстрый старт приложени€ без установки снижает порог входа дл€ будущих пользователей.
  3. Ќет необходимости сохран€ть документы и перемещать их между устройствами, поскольку все данные одновременно доступны со всех устройств.
  4. ¬озможность одновременного редактировани€ или просмотра отдельных документов и целых проектов несколькими пользовател€ми и удобна€ коммуникаци€ создают единое рабочее пространство между удаленно расположенными клиентами.
  5. ќрганизаци€ непрерывного процесса разработки и мгновенной доставки обновлений, что позвол€ет клиентам использовать последнюю версию ѕќ и способствует активному использованию техник экстремального программировани€ при разработке.
–азумеетс€, подобный подход имеет и свои недостатки. »з них € выдел€ю следующие:
  1. Ќеобходимость иметь хороший интернет-канал дл€ комфортной работы с приложением.
  2. ”сложнение программного обеспечени€ и, как следствие, увеличение времени и стоимости разработки.
  3. Ќеобходимость развертывани€ и последующей поддержки сетевой инфраструктуры, необходимой дл€ работы ѕќ.
 олесников через тернии

јрхитектура проекта

ѕри выборе архитектуры € старалс€ учесть возможность масштабировани€ в будущем и разделил проект на части таким образом, чтобы было легко распараллелить самые нагруженные части. ѕри расчете € использовал следующие предположени€, основанные на имеющемс€ опыте по разработке CAD и уточненные при создании прототипа:
  1. ƒл€ загрузки среднестатистической квартиры с мебелью мне потребуетс€ примерно 25 ћб несжатых геометрических данных и дополнительных атрибутов (5 ћб сжатых) + 10ћб текстур. ¬рем€ генерации данных от 0.2 сек. до 5 сек. (в самых сложных случа€х). я планирую ограничить объем модели на уровне 3-5 млн треугольников.
  2. ¬о врем€ работы по проектированию плана и расстановке различных изделий пользователем, на одну операцию (вставка и редактирование изделий, регенераци€ плана) приходитс€ в среднем 100 - 500  б исход€щего трафика. ¬рем€ выполнени€ каждой операции на сервере в среднем составл€ет 0,1-0.5 сек.
  3. јктивность пользователей находитс€ на уровне открыти€ одной модели в минуту или выполнени€ 5 - 10 операций редактировани€ в минуту.
»сход€ из этого, стало пон€тно, что удержать на одном сервере больше сотни активных пользователей будет проблематично, поэтому нужно будет обеспечить обработку геометрических запросов на разных серверах, и каким-то образом распредел€ть 3D модели между ними.

¬ выборе средств разработки € изначально был св€зан несколькими ограничени€ми. ¬о-первых, использование в качестве геометрического €дра C3D и высокие требовани€ по скорости геометрических расчетов при работе с моделью предопределило использование —++ на стороне сервера. ¬о-вторых, запуск клиентской части на браузере также сузило выбор €зыков до тех, что поддерживают компил€цию в JavaScript.

¬ результате на данном этапе проект состоит из четырех независимых частей: два внутренних (backend) сервиса и два внешних Web приложени€. √лавный внутренний сервис отвечает за геометрическое моделирование и расчеты. ќн написан на —++ с использованием библиотек C3D и Qt Core. ¬спомогательный сервис отвечает за управлением файлами, каталогами пользователей и обработкой текстур. ќн написан на ASP.NET Core. ¬еб приложени€ разделены аналогично. ќдно отвечает непосредственно за моделирование и написано на TypeScript + WebGL, а второе предоставл€ет интерфейс пользовател€ дл€ управлением проектами и каталогами пользовател€ и написано на св€зке Angular 2 + TypeScript. ¬заимодействие между клиентской и серверной част€ми идЄт с помощью простых HTTP запросов. ¬ части, отвечающей за интерактивное моделирование помещений, используютс€ WebSocket соединени€, по которым передаютс€ сжатые бинарные данные. ¬о избежание дублировани€ кода между серверными сервисами они также обмениваютс€ необходимой информацией по HTTP протоколу.

 олесников через тернии

—ерверна€ часть

Ђ—емь часов утра Ц разгон облаков, установление хорошей погоды...ї (Ђ“от самый ћюнхгаузенї).


“акже, как и ћюнхгаузену, дл€ отзывчивой работы облачного сервиса необходимо разогнать облака по максимуму! ѕоэтому главна€ изюминка проекта Ц это комбинаци€ серверной и клиентской части, отвечающа€ за геометрическое моделирование, визуализацию и сохранение истории редактировани€ моделей.   этой части проекта предъ€вл€етс€ высокие требовани€ по производительности, потреблению оперативной пам€ти, распараллеливанию и масштабируемости, т.к. геометрическое моделирование само по себе достаточно затратна€ вычислительна€ задача, а выполнение запросов построени€ моделей от множества активных пользователей усложн€ет еЄ еще больше. ¬ качестве Ђсердцаї системы дл€ выполнени€ задач геометрического моделировани€ на сервере было выбрано €дро C3D от компании C3D Labs, причины выбора которого описаны в моей предыдущей статье Ђядерные технологии в CADї. ƒл€ реализации функционала по управлению комплексными 3D проектами была разработана собственна€ система хранени€ данных 3D модели, в основу которой вз€та иерархическа€ ECS (Entity Component System), попул€ризированна€ разработчиками игр. ќна представл€ет собой древовидную структуру модели, состо€щую из разных элементов(сущностей), где у каждого элемента есть разные наборы данных (компоненты), такие как геометрические параметры, BREP оболочки, треугольные сетки, пользовательские данные и т.п.

ƒл€ того чтобы система отвечала необходимым требовани€м, еЄ реализаци€ имеет целый р€д отличительных особенностей:

  1. ѕри загрузке модели загружаетс€ лишь еЄ структура, а все еЄ данные (компоненты) хран€тс€ в NoSQL базе данных и автоматически подгружаютс€ в оперативную пам€ть при обращени€м к компонентам, а также автоматически выгружаютс€ из пам€ти по мере необходимости. Ёто позвол€ет работать на сервере с тыс€чами одновременно открытых моделей при небольших затратах оперативной пам€ти.
  2. ¬нутри компонентов хран€тс€ св€зи на компоненты в других сущност€х в виде пары ЂID сущности - “»ѕ компонентаї. ѕри операци€х копировани€ элементов модели все элементы получают новые ID из старого ID и случайного кода операции с помощью симметричной хеш-функции, поэтому в сущност€х вместо подмены всех измененных ID внутри компонентов запоминаетс€ код преобразовани€ старых ID в новые. Ёто позвол€ет копировать данные компонентов простым и быстрым побайтным копированием, не тер€€ ссылочной целостности в структуре модели. ¬ результате можно копировать огромные модели без чтени€ структуры их компонентов, что, в свою, очередь обеспечивает мгновенное копирование больших сборок внутри проектируемого помещени€.
  3. Ѕлагодар€ предыдущему механизму реализован специальный компонент-транзакци€, в котором автоматически сохран€етс€ истори€ изменени€ структуры модели во врем€ того, как различные команды редактируют еЄ содержимое. –азделение сущности на относительно небольшие компоненты позволило поставить Ђслушательї на обращение к каждому компоненту, и отслеживать, тем самым, его изменение автоматически. Ёто позвол€ет хранить всю историю изменений модели и возвращатьс€ к любому моменту еЄ создани€, даже сделанному много мес€цев назад (т.к. вс€ истори€ хранитс€ также в компонентах, которые без необходимости не загружаютс€ в оперативную пам€ть). — точки зрени€ разработчика это означает наличие у геометрической модели аналога транзакций, аналогичных существующим в —”Ѕƒ.
  4. ¬ерсионность каждого элемента и компонента модели обеспечивает быстрое формирование специальных файлов-патчей, в которых содержитс€ информаци€ о том, какие сущности и компоненты нужно скорректировать на клиентской модели, чтобы синхронизировать еЄ с версией на сервере. ¬купе с использованием бинарной версии протокола WebSocket это обеспечивает эффективную синхронизацию данных модели на всех подключенных клиентах в реальном времени.
Ќа практике подобна€ система работает достаточно быстро, обеспечива€ врем€ обработки большинства запросов к модели в пределах 5-50 мс. ќднако у системы образовалось узкое место: открытие модели требует передачи всех данных дл€ еЄ визуализации, что в случае массивных моделей требует множества обращений к Ѕƒ дл€ извлечени€ данных компонентов, привод€ к значительным задержкам, достигающим нескольких секунд на модел€х из дес€тков тыс€ч элементов. ѕобороть эту проблему позволило кэширование файлов-патчей в Redis. ѕоскольку патчи не тер€ют своей актуальности (патчи с версии 0 до версии сто + патч с версии 100 до версии 200 эквиваленты единственному патчу с версии 0 до версии 200), это легко решает проблему инвалидации кэша: его можно обновл€ть в фоновом режиме, не забот€сь о потери актуальности данных.

 лиентска€ часть

ѕроектирование клиентской части началось с выбора движка дл€ визуализации. Ѕыли перепробованы почти все попул€рные WebGL движки, однако остановитьс€ ни на одном из них не удалось по следующим причинам:
  1. 1. —лаба€ поддержка CAD режимов визуализации, таких как удаление невидимых линий и обрисовка силуэтов криволинейных поверхностей.
  2. —лабое развитие инструментов дл€ качественного вывода текста небольших размеров в 3D режиме в сочетании с рисованием линий произвольной толщины (эта комбинаци€ нужна дл€ прорисовки планов на 3D модели)
  3. ќтсутствие эффективной техники batching. ћодели зачастую состо€т из дес€тков тыс€ч небольших элементов с разными материалами, и пользователь может изменить любой объект в любой момент времени, поэтому необходимы эффективные техники по динамическому склеиванию маленьких объектов в большие вершинные буферы в видеопам€ти дл€ достижени€ приемлемого уровн€ производительности.
  4. Ќеобходимость написани€ специфичных компонентов управлени€ камерой, наложени€ материалов и анимации, т.к. предлагаемые Ђкоробочныеї варианты не подход€т под нужды системы проектировани€.
¬ результате анализа пришло понимание того, что написать свой УвелосипедФ будет и быстрее, и лучше, и значительно легче в поддержке. «а основу была выбрана великолепна€ библиотека https://twgljs.org .

—ледующим вопросом был выбор €зыка программировани€ и платформы в целом. ” мен€ уже был опыт разработки JavaScript приложени€ размером пор€дка 10 тыс€ч строк. »сход€ из этого опыта, иде€ разработки на JavaScript нечто большего лично мне внушала благоговейный ужас. ќчередной релиз TypeScript и тот факт, что за ним стоит јндерс ’ейлсберг, предопределило выбор €зыка. ¬ыбор платформы дл€ Web пал на Angular 2 ( который теперь уже 4): мне и так предсто€ло собрать проект из немалого количества разношерстных библиотек, а собирать свой комбайн дл€ Web-приложени€ не было ни малейшего желани€. ’отелось иметь именно framework, в котором Ђвсе включеної. –азвитые возможности отложенной загрузки модулей системы, эффективна€ кодогенераци€ (AOT) и возможности интернационализации только укрепили мой выбор. ≈динственное, что мен€ все еще смущает на данный момент Ч это отсутствие локализации сообщений в исходных файлах, но € искренно надеюсь, что уж к четвертой версии они реализуют эту функциональность .

–еализаци€ замыслов

ѕроект началс€ с реализации на —++ прототипа структуры будущей модели и экспериментальной визуализации на OpenGL. ѕосле нескольких мес€цев отладки € зан€лс€ переводом приложени€ на клиент-серверную модель. ѕервоначально € сделал это следующим образом: написал совмещенный REST+WebSocket сервер на C# и подключил геометрический сервис, как динамическую библиотеку с C-интерфейсом дл€ работы с модел€ми, котора€ будет вызыватьс€ дл€ геометрических запросов.  райнее неудобство отладки такого гибридного приложени€ и ненужные накладки при копировании данных из C++ в —, а затем и в C# вынудили мен€ искать альтернативные решени€. ¬ конце концов € включил WebSocket сервер внутрь —++ части и маршрутизировал все запросы к нему через прокси-сервер. ѕри этом дл€ аутентификации клиентов геометрический сервис делает внутренние запросы к основному REST-сервису.

—ледующим этапом стала реализаци€ алгоритма синхронизации модели, измен€емой на сервере, с моделью, отображаемой на клиенте. ѕервоначальные идеи слежени€ сервером за состо€нием клиента, либо отправки клиентом своего текущего состо€ни€ на сервер перед синхронизацией пришлось отмести, как не очень надежные и сложные в реализации. ќстановилс€ € на следующей реализации: в каждом компоненте хранитс€ целочисленна€ верси€ компонента. “аким образом, верси€ модели в целом определ€етс€ максимальной версией среди всех еЄ компонентов и компонентов дочерних сущностей. ѕри синхронизации клиент отправл€ет на сервер запрос, содержащий версию его модели, в ответ на который сервер отправл€ет данные всех компонентов, верси€ которых старше клиентской версии. Ёто обеспечило синхронизацию древовидной модели между клиентами и сервером с минимально возможным трафиком (запрос синхронизации - одно число, а в ответе содержатс€ лишь измененные компоненты).

ѕосле написани€ прототипов клиентской и серверной частей € зан€лс€ поиском оптимального формата данных дл€ передачи геометрической модели между клиентом и сервером. ¬ этом формате € хотел иметь следующие возможности:

  1. ”добство записи и чтени€ формата как из C++, так и из TypeScript кода
  2. ѕоддержка схемы данных
  3. ћинимально возможное врем€ упаковки и распаковки данных
  4. ѕередача чисел с плавающей точкой без потери точности
  5. Ёффективность работы при среднем размере пакета данных в диапазоне 100 б - 10ћб
  6. ¬ерсионность формата дл€ возможности поэтапного обновлени€ разных частей системы
»спользованный в экспериментах JSON пришлось отмести сразу, а дальше был выбор между MessagePack, Google Protocol Buffers, Apache Thrift, BSON и аналогичных им библиотек. ћой выбор остановилс€ на Google Protocol Buffers по причине лучшей производительности, хорошего сжати€ и удобного кодогенератора. ¬ажным фактором также стала распространенность библиотеки и надежда, что она не будет заброшена в долгосрочной перспективе. ¬ результате € использую родной protobuf на —++, protobufjs - дл€ чтени€ и записи на клиенте, proto2typescript - дл€ использовани€ единой схемы между C++ и TypeScript.  роме того, данные дополнительно сжимаютс€ zlib при передачи через WebSockets. Ёто схема позволила очень комфортно и быстро передавать все необходимые данные по модели. PS: Ќе так давно наткнулс€ на библиотеку FlatBuffers от того же разработчика, и у мен€ по€вилась мысль, что этот вариант будет еще лучше, однако времени попробовать эту библиотеку совершенно не хватает, кроме того, поддержка TypeScript пока отсутствует в основной ветке.

ѕосле устаканивани€ формата данных и первых экспериментов над каждой частью системы стало приблизительно пон€тно, как будет функционировать сервис в целом. ѕомимо этого были оценены узкие места и сделаны наброски вариантов масштабировани€ в будущем. «атем были созданы первые варианты программы, показывающие работу св€зки Ђдействие пользовател€ Ч запрос к серверу моделировани€ - визуализаци€ действи€ пользовател€ї. Ќа этом этапе наступило первое разочарование: така€ схема работы обеспечивает обновление данных в стиле Ђпот€нул за маркер, отпустил мышку, объект перестроилс€ї. Ёто было слишком медленно дл€ интерактивного отображени€ действий пользовател€ при перемещении курсора.

ƒанный результат потребовал переосмыслить границу между серверной и клиентской частью и сделать клиент более обширным, а также продублировать функционал между сервером и клиентом таким образом, чтобы клиент проводил предварительные расчеты дл€ интерактивной полигональной визуализации, а сервер производил финальные действи€ над BREP моделью и синхронизировал всех клиентов между собой. Ёто заставило мен€ глубоко задуматьс€ о проекте WebAssembly, который теоретически позволил бы иметь единую кодовую базу дл€ клиентской и серверной части и оперативно управл€ть выполнением расчетов между клиентом и сервером, перераспредел€€ нагрузку по мере необходимости. Ќо пока это всЄ мечты...

—ледующим этапом стала реализаци€ полноценного WebGL рендера. ѕока его возможности достаточно скромные, однако и над ними пришлось изр€дно попотеть.

ѕеречислю основные момента реализации:

  1. Ќа текущем этапе дл€ отрисовки использую классический Forward-rendering и несколько проходов. Ќа перспективу планирую реализовать затенение на основе Screen Space Ambient Occlusion или Scalable Ambient Obscurance.
  2. ƒл€ достижени€ приемлемой производительности склеиваю мелкие объекты в большие буферы вершин в глобальной системе координат и отправл€ю в видеокарту. ѕри изменении объектов все необходимые буферы оп€ть пересчитываютс€ на процессоре. Ёто может выгл€деть диковато, но отправл€ть матрицу объекта в дополнительных атрибутах еще накладнее.
  3. ќтрисовка в 3D линий толщиной отличной от 1 пиксел€ крайне в WebGL нетривиальна. –еализовал еЄ через отрисовку двух треугольников, все вершины которых лежат на одной линии, а толщина хранитс€ в атрибутах - тангенсных векторах.  онечные вершины треугольников рассчитываютс€ в вершинном шейдере путем перевода точек в систему координат экрана (дл€ учета соотношени€ ширины и высоты экрана), прибавки необходимой толщины линий и перевода в нормализованные координаты. —глаживание линий реализуетс€ через альфа-канал во фрагментном шейдере.
  4. ќтрисовка текста сделана через технику SDF, опубликованной компанией Valve. ƒл€ подготовки шрифтов использовалась утилита Hiero от libgdx. ѕолученный мной результат - удовлетворительный: при размере шрифта 14-16 пикселов текст выгл€дит неплохо, если же размер меньше, и текст расположен под острым углом к плоскости экрана, то он практически нечитаемый. ¬озможно, € просто не умею готовить SDF, но потер€в много времени, кардинального улучшени€ результатов получить не удалось. ¬ перспективе планирую попробовать эту технику: http://wdobbie.com/post/gpu-text-rendering-with-vector-textures/.
 олесников через тернии

’очу также отметить, что поддержка WebGL в современных браузерах отлична€ по сравнению с OpenGL под Windows))) Ёто, видимо, благодар€ проекту Angle, эмулирующему вызовы WebGL через DirectX.  од без костылей отлично работает даже под IE 11. — другой стороны, в приложении, оперирующим большими объемами данных со сложными структурами, остро стоит проблема утечек пам€ти, с которыми боротьс€ очень непросто.

Ёпилог

—ледующим шагом в разработке стала реализаци€ предметной области программы Ч моделирование зданий, планировка помещений и различных конструктивных элементов, расстановка предметов интерьера и создание каталогов пользовател€.  онечно же, требуют внимани€ и времени множество сопутствующих веб-сервису вещей в виде авторизации и аутентификации, обеспечени€ резервного копировани€, масштабировани€ различных частей, непрерывной интеграции всего процесса разработки. ¬ этих направлени€х впереди немалый фронт работы, прежде чем проект можно будет открыть дл€ публичного пользовани€. Ќесмотр€ на это, проведенна€ работа позволила мне приобрести огромный опыт. Ќадеюсь, мои измышлени€ будут полезными кому-то из читателей. ≈сли кто-то имеет опыт и готов, в свою очередь, поделитьс€ советами по реализации веб-сервиса, мне будет очень интересно их услышать. ѕишите в личку, или оставл€йте комментарии здесь.


„итайте также:


¬акансии:

јктуальное обсуждение

RSS-лента комментариев

ƒавид Ћевин
ƒавид Ћевин
ќт редактора: Ќе CAD, а HAD?
ѕроект ЂЌародное —јѕ–-интервьюї

—лучайна€ стать€:

isicad Top 10

—амые попул€рные материалы

   ‘орумы isicad:

isicad-2010 isicad-2008
isicad-2006 isicad-2004

ќ проекте

ѕриглашаем публиковать на сайте isicad.ru новости и пресс-релизы о новых решени€х и продуктах, о проводимых меропри€ти€х и другую информацию. јдрес дл€ корреспонденции - info@isicad.ru

ѕроект isicad нацелен на

  • укрепление контактов между разработчиками, поставщиками и потребител€ми промышленных решений в област€х PLM и ERP...
ѕодробнее

»нформаци€ дл€ рекламодателей


¬се права защищены. © 2004-2017 √руппа компаний «Ћ≈ƒј—»

ѕерепечатка материалов сайта допускаетс€ с согласи€ редакции, ссылка на isicad.ru об€зательна.
¬ы можете обратитьс€ к нам по адресу info@isicad.ru.