вторник, 5 ноября 2013 г.

ЛЕДАС: ускоряем геометрические ядра

Идеи и предложения, высказанные в недавно опубликованной статье Николая Снытникова «Эволюционное и революционное будущее геометрических 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 и т.п. 
Публикация достигнутых в последнее время результатов ожидается в ноябре. 


6 комментариев:

  1. Давид, спасибо за развернутую картину - в совокупе с деталями, раскрытыми Николаем в его статье, становится более понятной новая инициатива ЛЕДАСа.
    Аднака, тут же возникают вопросы. Скажем, сравнение геометрии - явление весьма широкое, и напрашивается такой вот вопрос : а существует ли на настоящий момнет социальный запрос на расширение функционала, уже объявленного ЛЕДАСом и раскрытое в какой-то степени Николаем в его статье, для решения более специальных задач сравнения геометрии? У меня не вызывает сомнений что с точки зрения имплементации LGC - совершенно открытый продукт, и добавлениее самых разных add-ins к существующему сервису - дело техники. И тогда возникает даже не вопрос, а просьба - а нельзя ли редакции isicad давать тут периодическую инфу не только о появлении любых add-ins к существующему проекту, но также и инфу о динамике запросов на любые раширения данного продукта. И еще - если уже LGC является работающим сервисом, то интересно было бы знать также и о динамике спроса на уже существующий облачный сервис (если конечно раскрытие такой инфы не противоречит коммерческим интересам ЛЕДАСа). Ну и совсем интересно было бы услышать - а что, может у ЛЕДАСа уже сейчас есть конкретные идеи (или даже план действий) по расширению функционала LGC в рамках инициативных разработок, упреждая актуальный запрос рынка?
    Спасибо.

    ОтветитьУдалить
    Ответы
    1. Михаил, добрый день!

      Действительно, есть разные функциональные требования к сравнению геометрии. Их можно пытаться реализовать с помощью набора add-in или с помощью разных версий и опций.
      Список фунциональных требований, полученных от пользователей, включает в себя такие пункты как
      - сравнение сборок (а не только part-ов)
      - поддержка тех или иных входных форматов данных (пример - SolidWorks)
      - поддержка тех или иных выходных форматов данных (пример - 3D PDF)
      - сравнение моделей, которые были сдвинуты/повернуты относительно друг друга
      - сравнение моделей, которые были масштабированы друг относительно друга
      - реализации веб-сервиса сравнения геометрии
      - обработка в пакетном режиме
      и т.п., вообще идей разных очень много.

      Буду рад услышать твое мнение о сравнительной полезности перечисленного выше (или не перечисленного). На основе суммированного фидбэка мы и будем принимать конкретные решения.

      Алексей Ершов,
      ЛЕДАС.

      Удалить
  2. Даа, круто! Если уже сегодня такие вопросы поднимают, можно представить шо будет дальше...
    Навскидку трудно что-либо сказать, думать надо.

    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 чего стоит...

    Спасибо.

    ОтветитьУдалить
  3. Михаил,

    Спасибо за столь подробный комментарий!

    1) Про 3D принтеры - очень интересно. Правильно ли я понимаю, что между STL и g-code нет никакого промежуточного представления типа воксельного? Если бы такое представление было, то можно было бы сравнивать STL и воксели без необходимости анализировать все возможные виды g-code (он ведь не стандартизирован?)

    2) Пока речь идет о сравнении только геометрии. Constraints, по нашему представлению, не являются еще достаточно хорошо стандартизированными, и при сравнении двух разных форматов данных (или сравнении двух STEP, полученных конвертацией из разных форматов) из-за них могут возникать ошибки. Так что разобраться бы чисто с геометрическим сравнением деревьев компонент в сборке - уже было бы здорово, а constraints можно рассматривать в качестве плана на более отдаленное будущее.

    3) Это очень объемный проект, в котором сравнение геометрий будет малым кирпичиком по сравнению с процедурой векторизации растра, фильтрации, анализа и пр.
    Нужен партнер размером не меньше Google :)

    ОтветитьУдалить
  4. Алексей, пробую урочнить (возможно шо мое мнение в данном случае будет неверным...):

    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. Михаил,

      1) Получается двуфазная схема: сначала генерация облака точек по g-code, а потом сравнение облака точек с STL-моделью. Нам технологически ближе вторая фаза, так как ее можно считать уже сравнением геометрии. Там тоже не все так просто: несложно проверить попадание точки на STL модель с нужной точностью, но сложнее проверить, что вся STL модель полностью покрывается точками из облака. Хотя, конечно, все равно проще, чем образы распознавать.

      2) C constraints непонятно, когда именно и что конкретно станет востребованным. Лет 10 назад я думал, что вот через пару лет все проснутся, все стандартизуют и упорядочат, но это до сих пор не произошло :)

      3) Найти заказчика или партнера для такой разработки, пожалуй, самое важное. Если с тем же Intel будет получатся что-то конкретное - замечательно, тем более что тут у нас в Новосибирске офис разработки Intel под боком, да и есть известные САПР-энтузиасты, вроде Романа Лыгина.

      Удалить



Подпишитесь на RSS, чтобы получать обновления моего блога