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

14 сент€бр€ 2020

C3D Converter: ускорение экспорта в формат JT

јлександр —пиваков, руководитель разработки C3D Converter

—пиваков

ќригинал в блоге C3D Labs


–аботу по поддержке формата JT команда C3D Labs начала в 2016 году. Ёто формат международного стандарта ISO, и, в принципе, при наличии документации написать код, который обеспечивает импорт и экспорт, Ч дело техники. “о есть научитьс€ читать и записывать данные согласно схемам со стрелочками. ќднако поддержка формата не тождественна реализации чтени€ и записи согласно документации.

¬о-первых, прочитанные данные нужно интерпретировать правильным образом; в случае с JT это означает, что нужно преобразовать геометрическую модель из представлени€ C3D в представление JT и обратно.

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

Ќаиболее очевидное отличие формата JT от других форматов, поддерживаемых €дром C3D, заключаетс€ в том, что он предоставл€ет средства дл€ передачи формы изделий в двух представлени€х Ч граничном и полигональном (второе, строго говор€, тоже описывает границу, но не позвол€ет передавать информацию о гладкости поверхностей).

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

Ёкспорт в формат JT

–абоча€ модель

«десь следует сказать, что полигональное представление в JT и в C3D устроены немного по-разному. ¬ обоих случа€х треугольники группируютс€ так, что получаютс€ аналоги граней, но в случае C3D кажда€ группа ссылаетс€ на свой набор точек. Ќапротив, в JT набор точек един дл€ всего тела. “аким образом, перед нами встала задача научитьс€ формировать этот единый набор.

 онечно, можно было облегчить себе работу на первом этапе; стандарт JT это позвол€л. ƒопустим, экспортировать каждую грань как отдельную сетку и не иметь проблем с поиском одинаковых точек на смежных гран€х. ќднако подобное упрощение, как минимум, лишало нас ценных сведений о том, какие задачи придЄтс€ решать, когда потребуетс€ экспортировать сетки целиком. ¬ конце концов, у нас была возможность вернутьс€ к простому варианту, если более правильный не удастс€ реализовать в отведЄнный срок.

Ёкспорт в формат JT

ћного граней

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

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

Ёкспорт в формат JT

—амокасание в точке и крупный план

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

ѕадение производительности отчасти удалось преодолеть за счЄт того, что проверке точек на совпадение стали подвергатьс€ только граничные точки. Ёто лучше, чем ничего, но замедление всЄ равно было существенным, и в какой-то момент нам пришлось отказатьс€ от экспорта тел целиком. ’уже всего, что код становилс€ трудноуправл€емым и не обеспечивал как диагностики процесса преобразовани€, так и контрол€ исходных данных. Ќесмотр€ на то что текущие практические задачи решались, было пон€тно, что дл€ дальнейшего развити€ нужна серьЄзна€ переработка кода.

Ёкспорт в формат JT

≈щЄ больше граней

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

 од, который готовил исходные данные дл€ сетки JT, был полностью переработан. ѕо€вились специальные классы, которые заменили собой ранее примен€вшиес€ шаблонные конструкции €зыка C++. “ем самым они обеспечивали не только основную функциональность, но и удобную отладку.  огда закончилс€ этап доводки нового алгоритма на простых модел€х, эти средства отладки пригодились, чтобы пон€ть, почему некоторые модели не экспортировались, хот€ по всем признакам должны были.

 ак оказалось, причина неудачного преобразовани€ скрывалась в тех функци€х, надЄжность которых до этого момента считалась несомненной: например, построение граничных полигонов. ¬ результате доводок по€вилась возможность детектировать дефекты сетки и в некоторых случа€х их устран€ть, чтобы обеспечить экспорт тел целиком в JT.

Ёкспорт в формат JT

«десь диагностированы дефекты

¬се эти при€тности по части читаемости кода и удобной диагностики стали важным дополнением к решению основной задачи: преобразование сетки к формату JT действительно удалось многократно ускорить по сравнению с базовым вариантом. √лавный фактор, который губительно сказывалс€ на быстродействии, Ч линейный поиск Ч не исчез, но его вли€ние на врем€ экспорта было существенно ограничено.


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


¬акансии:

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

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

ƒавид Ћевин
ƒавид Ћевин
ќт редактора: √лавное отличие человека от животного в том, что он хочет знать
ѕроект ЂЌародное —јѕ–-интервьюї

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

isicad Top 10

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

   ‘орумы isicad:

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

ќ проекте

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

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

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

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


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

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