Идеи и предложения, высказанные в недавно опубликованной статье Николая
Снытникова «Эволюционное и революционное будущее геометрических 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 под боком, да и есть известные САПР-энтузиасты, вроде Романа Лыгина.
Вам срочно нужен кредит для оплаты счетов или на другие цели? Вам ранее отказывали в кредите в финансовых учреждениях или дома? Тогда у вас есть уникальная возможность получить кредит в нашей компании. Trustbridge Financial Service — это авторитетный и легальный кредитор, предоставляющий кредиты физическим и юридическим лицам по низкой процентной ставке 3%. Свяжитесь с нами сегодня по электронной почте (trustbridgefinancialservice943@yahoo.com), и мы поможем вам с получением финансовой помощи.
ОтветитьУдалить
Пожалуйста, заполните заявку на кредит, чтобы мы могли как можно скорее начать оформление вашей кредитной операции.
Мы предлагаем следующие виды кредитов:
a) Потребительский кредит, кредит на расширение бизнеса,
b) Кредит на открытие бизнеса, кредит на образование,
c) Кредит на консолидацию долгов, кредит на ремонт дома,
d) Кредиты под залог недвижимости, инвестиционные кредиты,
e) Кредит на подготовку к Рождеству.
Заполните информацию ниже для начала процедуры.
ФИО:
Адрес:
Страна:
Необходимая сумма кредита:
Срок кредита:
Цель кредита:
Номер телефона:
Для получения дополнительной информации свяжитесь с нами через WhatsApp: +2349124847559.
Спасибо
Администрация
Финансовые услуги Trust Bridge