Идеи и предложения, высказанные в недавно опубликованной статье Николая
Снытникова «Эволюционное и революционное будущее геометрических 3D-ядер» и в ее переводе «Evolution and Revolution in Geometric Kernels», уже привлекли большое внимание специалистов. В отличие от тщательно взвешенной идейно-технологической
статьи Николая, моя заметка задумана как несколько упрощенное, но зато
радикально представленное направление мыслей и замыслов ЛЕДАСа.
На основе своего широкого и глубокого опыта, специалисты ЛЕДАСа пришли к выводу, что, по
отношению к неуклонно развивающимся возможностям аппаратуры, к появлению новых сервисных
схем и к новым требованиям приложений, все существующие 3D-ядра фактически исчерпали лимит своего
внутреннего развития. Этот диагноз не является неожиданным и оскорбительным: любой полноценный 3D-моделлер – исходно чрезвычайно
сложная программа, которая не становится проще за десятилетия далеко не всегда архитектурно
предусмотренного развития и тонкой настройки на часто плохо совместимые требования
многих тысяч приложений. Вместе с тем, именно
потому, что от каждого промышленного ядра зависят тысячи и миллионы приложений (включая как уже работающие, иногда – крайне
ответственные, так и разрабатываемые новые), существующие ядра еще долго будут
жить на рынке.
Отсюда возникает мысль о том, что 3D-ядерную индустрию целесообразно
развивать параллельно по двум направлениям.
1. Создание промышленного модуля-акселератора (plug-in), который регулярным образом продлит
достойную жизнь ядер-ветеранов
- ориентируясь на современные и перспективные аппаратные
вычислительные архитектуры
- не пытаясь просочиться во все поры давно
сложившейся и сопротивляющейся архитектуры ядер, но
- максимально эффективно поддерживая выполнение
наиболее тяжелых ядерных операций в вычислительной кооперации с ускоряемым ядром.
2. Проектирование совершенно нового ядра, изначально и в
полной мере имея в виду современные возможности аппаратуры, облачные схемы
работы приложений, дисциплины совместной разработки, растущую роль и рыночную долю мобильности и т.д.
Эти два направления представлены в статье Николая
Снытникова – с разной степенью подробности и без характеристики некоторых методов,
уже разработанных в ЛЕДАСе.При этом излагается в некоторой степени проработанная
гипотеза о том, что совершенно новое ядро может базироваться на модификации так
называемого воксельного представления, изначально дающего возможности
масштабируемого параллельного выполнения
геометрических операций ядра и являющемуся альтернативой классическому B-rep
представлению.
Несколько слов о том, как в эту схему вкладывается ядро RGK, в создании которого команде
ЛЕДАСа посчастливилось принять активное участие. У RGK есть два
фундаментальных преимущества перед остальными «серьезными» ядрами:
- в нем изначально заложены многие архитектурные
решения, существенно облегчающие регулярную адаптацию к новым возможностям
аппаратуры и схемам эксплуатации, так что сторонний акселератор вряд ли ему понадобится в
ближайшем будущем,
- у него пока нет многочисленных зависимостей от
использующих его приложений.
С другой стороны, развитие и даже начало использования RGK полностью зависит от
решений государственных инстанций, а им такие решения даются нелегко…
Кратко представленные в статье Н.Снытникова идеи лежат в
основе второго проекта LEDAS Labs, который трактуется в основном, как исследовательский. Вместе с
тем, мы в ЛЕДАСе уверены
в том, что наша компетенция, практический опыт реализации трудных промышленных
проектов в релевантной области и уже полученные новые результаты, открывают перспективу
успеха – по крайней мере, на одном из двух направлений проекта. А кооперация с квалифицированными и заинтересованными партнерами и заказчиками, на наш взгляд, превращают перспективу
в гарантию.
***
Упомянув выше «LEDAS Labs» и «второй проект», напомню, что означают эти слова.
После двух лет пребывания в статусе чисто сервисной компании,
ЛЕДАС затосковал по свободному
творчеству и летом этого года возвратился к созданию собственных новых технологий и продуктов. Этот шаг воплотился в создании подразделения LEDAS Labs и
в его рамках – в организацию первого проекта: построения облачной системы сравнения 3D-моделей.
Эта система обнаруживает и визуализирует
все различия между геометрическими моделями, она также способна отслеживать
модификации, которым подвергается модель в течение ее жизненного цикла.
Технически проект называется LGC (LEDAS Geometric
Comparison), что апеллирует к разработанной ЛЕДАСом серии геометрических процессоров LGS, однако для рыночной жизни будущего продукта могут быть выбраны
более мнемоничные названия: diff3D, 3DCompare и т.п.
Публикация достигнутых в последнее время результатов
ожидается в ноябре.
Давид, спасибо за развернутую картину - в совокупе с деталями, раскрытыми Николаем в его статье, становится более понятной новая инициатива ЛЕДАСа.
ОтветитьУдалитьАднака, тут же возникают вопросы. Скажем, сравнение геометрии - явление весьма широкое, и напрашивается такой вот вопрос : а существует ли на настоящий момнет социальный запрос на расширение функционала, уже объявленного ЛЕДАСом и раскрытое в какой-то степени Николаем в его статье, для решения более специальных задач сравнения геометрии? У меня не вызывает сомнений что с точки зрения имплементации LGC - совершенно открытый продукт, и добавлениее самых разных add-ins к существующему сервису - дело техники. И тогда возникает даже не вопрос, а просьба - а нельзя ли редакции isicad давать тут периодическую инфу не только о появлении любых add-ins к существующему проекту, но также и инфу о динамике запросов на любые раширения данного продукта. И еще - если уже LGC является работающим сервисом, то интересно было бы знать также и о динамике спроса на уже существующий облачный сервис (если конечно раскрытие такой инфы не противоречит коммерческим интересам ЛЕДАСа). Ну и совсем интересно было бы услышать - а что, может у ЛЕДАСа уже сейчас есть конкретные идеи (или даже план действий) по расширению функционала LGC в рамках инициативных разработок, упреждая актуальный запрос рынка?
Спасибо.
Михаил, добрый день!
УдалитьДействительно, есть разные функциональные требования к сравнению геометрии. Их можно пытаться реализовать с помощью набора add-in или с помощью разных версий и опций.
Список фунциональных требований, полученных от пользователей, включает в себя такие пункты как
- сравнение сборок (а не только part-ов)
- поддержка тех или иных входных форматов данных (пример - SolidWorks)
- поддержка тех или иных выходных форматов данных (пример - 3D PDF)
- сравнение моделей, которые были сдвинуты/повернуты относительно друг друга
- сравнение моделей, которые были масштабированы друг относительно друга
- реализации веб-сервиса сравнения геометрии
- обработка в пакетном режиме
и т.п., вообще идей разных очень много.
Буду рад услышать твое мнение о сравнительной полезности перечисленного выше (или не перечисленного). На основе суммированного фидбэка мы и будем принимать конкретные решения.
Алексей Ершов,
ЛЕДАС.
Даа, круто! Если уже сегодня такие вопросы поднимают, можно представить шо будет дальше...
ОтветитьУдалитьНавскидку трудно что-либо сказать, думать надо.
1) Тем не менее, уже сейчас хотелось бы сказать пару слов на предмет очень специальных случаев когда надо сравнить результат симуляции обработки CAM (NC machining) компоненты с исходной геометрией. Более конкретный пример из области low-level primitive product for low-level primitive people : из жизни 3D принтеров :
вот есть STL исходная модель, которую некий slicer не самого высокого качетва кода режет по слоям и генерит g-code, который собственно держит ту геометрию шо реально будет сделана на 3D принтере. И если slicer нагло врт, то юзер-лузер не всегда может обратить внимание на детали, которые могут быть важны. Тогда задача ставится так - надо смоделировать отработку g-code (, ну наверное лишь его геометрических команд), воссоздать 3D геометрию и сравнить с ишодной - если проблемы лишь в точности (т.е. slicer нагло не ломал геометрию) - то все в порядке, toolerance можно ведь вааще заранее подобрать под параметры 3D принтера.
В свете постоянно и экспоненциально растущего рынка 3D принтеров потребительского (самого низкого) качества (ну, самая грубая резолюция - 0.1мм по X/Y и 0.2/0.3мм по Z) возможен большой спрос на такой сервис.
2) А сравнение сборок - это как - геометрия + constraints?
3) И уж совсем дикая идея - возможен сторонний эффект от гигантского рынка, никакого отношения к миру CAD не имеющего :
Если реальна имплементация из списка :
- сравнение моделей, которые были сдвинуты/повернуты относительно друг друга
- сравнение моделей, которые были масштабированы друг относительно друга
то уж решение такой же задачи в 2D должно быть не токмо проще, но и куда эффективнее в производительности. Теперь вообразим шо в задаче распознования окружающей среды с одной моно-камеры в реальном времени классические алгоритмы возни с битмэпами быстро исчерпывают свои возможности и для решения задач классификации надо а) конвертировать растр в вектора; б) выделять замкнутые/открытые контура и в) анализировать их эволюцию на нескольких соседних фреймах (или 2/3 десятках соседних фреймов). Тогда рискну предполозить шо тут как раз с весьма грубой точностью происходит как раз изменение масштаба и поворот контуров. И где же рынок? Пример совсем нового рынка - smart hardware SoC в сборке с мини-камерой сажаются на дужку очков, чел с почти убитым зрением тем не менее ходя по улице, может получать результат анализа надписей (номера транспорта, вывески магазинов и пр. текстуальные сущности) куда более достоверный нежели всякие расширения классических OCR. Насколько мне известно, Intel актвно работает над подобным проектом.
Куда более объемный рынок - встроенные системы в автомобили где с моно-камеры идет классификация окружающего мира. Ведь не токмо паранойя Google-car имеет место - мировой автопром начинает шодить с ума ибо к 2015г там какие-то законы принимают о повышенной безопасности, а фирм, умеющих делать классификацию в IP не так уж и много. Ну и собственно паранойя self-driving car уже охватила то что вместо мозгов у ведущих OEM мирового автопрома как по обе стороны Атлантики, так и на Дальнем Востоке.
Ну и возможно самый перспективный рынок таких систем начинает реально развиваться - автономные роботы. Вот, к примеру, объявление Intel про проект Jimmy чего стоит...
Спасибо.
Михаил,
ОтветитьУдалитьСпасибо за столь подробный комментарий!
1) Про 3D принтеры - очень интересно. Правильно ли я понимаю, что между STL и g-code нет никакого промежуточного представления типа воксельного? Если бы такое представление было, то можно было бы сравнивать STL и воксели без необходимости анализировать все возможные виды g-code (он ведь не стандартизирован?)
2) Пока речь идет о сравнении только геометрии. Constraints, по нашему представлению, не являются еще достаточно хорошо стандартизированными, и при сравнении двух разных форматов данных (или сравнении двух STEP, полученных конвертацией из разных форматов) из-за них могут возникать ошибки. Так что разобраться бы чисто с геометрическим сравнением деревьев компонент в сборке - уже было бы здорово, а constraints можно рассматривать в качестве плана на более отдаленное будущее.
3) Это очень объемный проект, в котором сравнение геометрий будет малым кирпичиком по сравнению с процедурой векторизации растра, фильтрации, анализа и пр.
Нужен партнер размером не меньше Google :)
Алексей, пробую урочнить (возможно шо мое мнение в данном случае будет неверным...):
ОтветитьУдалить1) Насколько мне известно, между STL и g-code нет ничего в промежутке - slicer-то как взял на вход STL - так и выдал g-code для 3D принтера. Так что вполне так себе воксельную геометрию надо генерить из g-code - потенциально сие не должно быть трудным - все по модели гениального романа В. Ерофеева "Москва-Петушки" - "слеза комсомолки" -> "поцелуй тети Клавы" -> "сучий потрох" - а именно - как в g-code найдена команда на пускание из extruder слезы пластика, так надо если нулевой слой то плодить вертексы на каждый шаг в рамках tolerance, если следующий слой - убирать те вертексы шо совместились с предыдущим в рамках tolerance, остальные - добавлять. В результате получим облако точек актуальной поверхности, которую должен породить принтер. Его и сравнивать с STL моделью.
Насчет стандартизации g-code - мне кажется шо все производители 3D принтеров давно работают с одним и тем же подмножеством, ибо если уж бесноватые из MS объявляют о драйвере для 3D принтеров под Windows 8 - то скорее всего стандартизовано. Еще мне кажется шо все производители берут для управляющего компа (там вроде простенькие Ардуино используются) один и тот же код из Open Source, как впрочем и весь desktop код под Виндой для 3D принтеров тоже берется из Open Source - тогда со стандартом все в порядке.
2) Мне кажется (хотя скорее всего я ошибаюсь) что уже в ближайшие год-два в индустрии начнется дикий вой по поводу сравнения constraints сборок скажем перекочевавших из одной системы в другую. И одной из причин будет все более активное использование variational design большими и толстыми - вот когда они (большие и толстые) начнут сливать суб-подрядчикам такие модели, то все завопят - "а где же constraints?". Другое дело, как вытаскивать constraints из сегодняшних моделей, построенных на истории, и как сие изменится с variational design - тяжелый вопрос, даже такие опытные в parametric data exchange парни как ITI-Proficiency мне так и не дали ответа как сие надо делать. Хотя у них-то как раз решение для моделей, построенных на истории, как раз имеется - в рамках их формата UPR).
3) Не совсем согласен со оценкой сложности, ибо тут надо все разложить на отдельные компоненты - скажем, векторизация растра - есть полным-полно разного кода в Open Source, там вполне может оказаться и вполне качетвенное решение. Далее, фильтрация скорее всего должна работать еще на уровне растра, вот один мой приятель сидит себе дома и стругает библиотеки на C++ всяко-там HMM, фильтры Кальмана и др. и вполне так успешно продвигается - даже на уровне героев-одиночек какие-то решения достижимы. Ну а главное - анализ, классификация и пр. - как раз и может быть построено на основе сравнения геометрии контуров. Если говорить о возможном бизнес-партнерстве хотя бы бы на уровне (постепенно сходящего с ума) автопрома - то тут возможно партнерство с Tier-1 suppliers бортовой электроники или даже IT divisions некоторых OEM, чьих амбиций хватает на такие проекты (может, Бош или кто-то такого уровня - как раз подходящие ребята).
Если же бормотать о будушем рынке роботов, то тут для начала надо разобраться - а шо на самом деле Intel хотят сбацать в рамках проекта Jimmy - может оказаться шо даже тут есть ниша - вот мой племянник шо в местном Intel трудится, скоро в Штаты поедет в один из их центров - может что-то узнает про сей проект. Хотя куда смешнее было бы затянуть в такие разработки самих производителей 3D принтеров:)
Михаил,
Удалить1) Получается двуфазная схема: сначала генерация облака точек по g-code, а потом сравнение облака точек с STL-моделью. Нам технологически ближе вторая фаза, так как ее можно считать уже сравнением геометрии. Там тоже не все так просто: несложно проверить попадание точки на STL модель с нужной точностью, но сложнее проверить, что вся STL модель полностью покрывается точками из облака. Хотя, конечно, все равно проще, чем образы распознавать.
2) C constraints непонятно, когда именно и что конкретно станет востребованным. Лет 10 назад я думал, что вот через пару лет все проснутся, все стандартизуют и упорядочат, но это до сих пор не произошло :)
3) Найти заказчика или партнера для такой разработки, пожалуй, самое важное. Если с тем же Intel будет получатся что-то конкретное - замечательно, тем более что тут у нас в Новосибирске офис разработки Intel под боком, да и есть известные САПР-энтузиасты, вроде Романа Лыгина.