Изобретатель NURBS: о прошлом, настоящем и будущем САПР

Я считаю, что главным недостатком современных моделлеров сегодня является тот факт, что они не уделяют достаточного внимания реальности, в которой мы все живем. Сегодня проектирование — это мир многих приложений, это мир многих САПР, так что, рано или поздно, данные, возникшие на основе какого-то одного ядра, потребуется перенести на другое ядро и работать с ними уже там. Проблемы, при этом возникающие, связаны, например, с использованием в вычислениях разных допусков, с неявными последствиями незадокументированного выбора форматов данных, с разными алгоритмическими подходами даже к стандартным геометрическим вычислениям. Например, одной из самых критических вычислительных проблем, да, пожалуй — самой критической, является вычисление пересечения поверхностей.

Другие недостатки, конечно, включают вопросы производительности и точности. Точность становится критическим фактором во всех тех случаях, когда геометрические вычисления на 3D-модели выполняются менее точно, чем это потребуется в алгоритмах, которые оперируют с данной моделью на следующих этапах процесса проектирования. Подходы к моделированию допусков относятся к ключевым аспектам 3D-ядер.

Некоторые ядра хранят такое пересечение как кривую в трехмерном пространстве, другие — как кривые в двумерных параметрических пространствах каждой из двух поверхностей. Переход от одной из этих трактовок к другой создает проблемы. В таких условиях, разработчики легко скатываются к решениям своих собственных задач по совершенствованию математических или программных деталей — и уделяют меньшее внимание тому, где и как будет использоваться создаваемая ими программа.

Скорость работы алгоритма пересечения поверхностей часто является критической для суммарной производительности моделлера. Тем более, что эти вычисления многократно повторяются из-за того, что нынешние наиболее популярные САПР-приложения основаны на истории построения.

Лично мне больше нравится вариант хранения кривой пересечения в параметрическом виде. Могу ли я это обосновать? Нет, сделать это практически невозможно. Впрочем, по крайней мере, на основе 2D-параметрической кривой вы легко можете породить точки на 3D-кривой, но не наоборот.

В числе свежих проблем могу назвать две: потребность в более локальных операциях и в дополнительной поддержке облаков точек. По мере того, как мы наблюдаем в мире САПР растущий акцент на прямое моделирование и расширение круга соответствующих приложений, таких как, скажем, избавление модели от излишних или мелких деталей/элементов, несущественных при выполнении САЕ-расчетов, растет и значимость для ядер так называемых локальных операций. Мы также наблюдаем востребованность внедрения в традиционные геометрические модели данных в виде облака точек. Эта растущая потребность диктуется приложениями 3D-печати, индустрией игр, некоторые алгоритмы которых заимствуются отраслью САПР. Кроме того, надо учесть растущий во всех продуктовых сферах акцент на эстетику форм.

Не думаю, что прямое моделирование (ПМ) заменит моделирование, основанное на истории построения. Конечно, в ряде случаев, таких как обмен данными, у ПМ есть значительные преимущества. По-моему, функции ПМ больше подходят небольшим компаниям. Крупные игроки рынка работаю в условиях весьма формализованных процессов, предпочитая контролировать каждое изменение в модели. Наоборот, ПМ весьма полезно паре инженеров, которые работают над одним проектом. Однако, ПМ могло бы оказаться гораздо более привлекательным для всех, если бы оно позволило использовать параметры и ограничения (constraints): ведь параметрические возможности — это именно то, что особенно нравится пользователям в подходе на основе истории построения.

Мне нравится то, что в Siemens сделали в области синхронной технологии — особенно, я ценю их результаты с технической точки зрения. Но у них есть трудности с объяснением этой технологии потенциальным клиентам.

Мои вера и надежда состоят в том, что технологии, применяемые в инженерном и художественном проектировании, когда-нибудь интегрируются в единое решение, где оба представления работают вместе. Т-сплайны — один шаг в этом направлении. Однако, хочу подчеркнуть: все эти подходы останутся недостаточно успешными и недостаточно устойчивыми до тех пор, пока пользователей программных систем геометрического моделирования обязывают быть экспертами в математике. Ответственностью разработчика геометрического ПО должно стать не только разработка сложных математических алгоритмов, но и экранирование этой сложности от использующих эти алгоритмы приложений, и от их пользователей. Слишком часто мы сталкиваемся с программными интерфейсами геометрических моделлеров, которые требуют от пользователей знания всех тонкостей математической подоплеки.

Ясно, что трансляторы между облаками точек и традиционными САПР-данными потребуются в любом случае. Это чрезвычайно важная вещь. Но при упомянутой вами интеграции облаков точек в САПР могут возникнуть весьма интересные возможности. Одна из основных компаний, которые мы имеем в виду, говоря о технологиях, связанных с обработкой облаков точек, это — Geomagic.

Вообще, область облаков точек выглядит весьма интригующе: она очень интенсивно развивается в рамках САПР. Такое развитие можно сравнить с историей компьютерной графики (КГ) . Изначально компьютерная графика была разделом САПР, но затем начала развиваться гораздо быстрее, чем породившшая ее технология, и сегодня рынок графики во много раз больше рынка САПР. Между прочим, сегодня компьютерная графика, в некотором смысле, возвращается к своим истокам, образуя все больше связей с САПР. Подобное может произойти и с облаками точек.

К этому моменту нашей беседы должна быть совершенно ясна моя позиция: пользователи не являются математиками. Во всяком случае, коммерческие разработчики инженерного ПО осведомлены о том, что их клиенты — это инженеры, но никак не математики. А инженеры обсуждают свои проекты в терминах того, что мы именуем features (конструктивными элементами) — такими как сопряжения. отверстия и т.п. В свое время я аплодировал РТС за их реализацию такого инженерного подхода, который в рамках появления Pro/ENGINEER выразился в революционном создании интерфейса, основанного как раз на конструктивных элементах.

Я всегда рассматривал NURBS как средство описания форм. Если какое-то приложение может извлечь пользу от применения такого инструмента, то почему бы ему не использовать NURBS. Однако, я не трачу много времени в поисках новых классов задач, которые могли бы решаться с помощью NURBS. Сегодня фокус моей деятельности в том, чтобы способствовать продвижению инженерного сообщества на его пути к широкому применению технологий моделирования и совместной разработки. NURBS — только небольшая часть этих технологий.

Именно об этой проблеме я чаще всего слышу от пользователей, сталкивающихся с ней в своей повседневной работе. Не часто случается, чтобы продукты проектировались и строились одной компанией. Сейчас большинство продуктов основано на глобальном разделении труда. Нельзя рассчитывать на то, что участники распределенного проекта будут использовать один и тот же САПР или даже — одно и то же геометрическое ядро. Некоторые самые крупные компании попытались ввести единообразие, однако, во многих случаях, эти попытки уперлись в ограничение возможностей и потерю оперативности решений на динамичном рынке.

На пути достижения более качественной трансляции данных есть как технические, так и бизнес-препятствия. Встречаются случаи, когда вендор сознательно затрудняет обмен данных между своим продуктом и продуктами конкурентов. Для искоренения подобных ситуаций потребуется время и давление со стороны пользователей. Я уже упоминал некоторые технические проблемы, влияющие на трансляцию данных, такие как проблемы точности и скрытых форматов данных. Еще одна проблема связана с постоянным развитием САПРов, которое нередко затрагивает структуры данных. Отсюда следует, что самое совершенное сегодняшнее решение в области трансляции данных завтра может стать неработающим.

Да, проблема конверсии данных с помощью независимых форматов все еще существует, однако, я не назвал бы ее серьезной. Мое мнение подтверждается несколькими фактами. Во-первых, сегодня, помимо STEP, появилось еще несколько конкурирующих «стандартов». Формат JT от Siemens PLM Software стал стандартом ISO. Хотя и не ставший форматом ISO, вполне популярен 3D PDF от Adobe. Так что от STEP больше не требуют решения всех проблем.

Мне кажется, STEP сам добавил себе проблем. Это формат со всеми положительными и отрицательными чертами, присущими каждому формату данных. Какие-либо расширения STEP настолько трудны и требуют так много времени, что многие даже и не пытаются поставить такие задачи.

Стараясь не быть скептиком, все же признаюсь: я не верю, что проблема трансляции данных когда-нибудь будет решена полностью. Ведь каждый вендор, которому удалось утвердиться на рынке за счет каких-то собственных технологических средств, безусловно, захочет сохранить и защитить свои преимущества. Одно из средств такой защиты связано с использованием собственных структур и форматов данных.

STEP — громоздок. В нем можно доходить до такой детализации, что многие хранимые данные реально не будут необходимыми. Нередко обмен данными между поставщиком и клиентами должен проходить оперативно и часто, и здесь STEP может оказаться не лучшим вариантом.

JT уже серьезно используется в автомобильной промышленности, а 3D PDF — в тех компаниях, в которых уже активно использовались текстовые PDF-файлы, так что сотрудники с ними знакомы.

Я признаю преимущества единого для всех формата для обменов данными. И все-таки считаю, что конкуренция — это нечто, стимулирующее совершенствование всех существующих форматов. По-моему , оптимально иметь не десятки, а 2-3 формата для обмена.

Нарастанию сложности моделей способствуют несколько факторов. В наше время самый серьезный из них — программное обеспечение для встраиваемых электрических приборов. Управление изменениями всегда было самой большой заботой пользователей, но сегодня дело даже не в том, что некоторое физическое изменение компоненты А влияет на физическое состояние компоненты В. Сегодня изменения в программах могут потребовать изменений в этих компонентах

Вендоры в области САПР постоянно развивают свои решения этой сложной проблемы. Они делают это, комбинируя технологию обработки данных, которая содержится в системах PLM, и внедряя в приложения способность обнаруживать и фиксировать изменения в модели с помощью добавления в них элементов, их редактирования и удаления. Часто сложность нарастает из-за того, что продукты разрабатываются в нескольких конфигурациях. Управление всеми этими факторами относительно полной цепочки производства и поставок привносит дополнительные проблемы, включая необходимость иметь дело с различными PDM и САПР или учитывать факт, что некоторые внутренние изменения в поставляемой смежником компоненте могут не влиять на другие компоненты, а другие влиять могут.

Обсуждение того, какие вендоры лучше справляются с указанными проблемами, было бы слишком продолжительным и слишком сложным. Каждая компания, производящая продукты, характерна своими требованиями и, если быть честными, эффективность решения сложных проблемам у компаний существенно разный.

Мне довелось обсуждать подобные проблемы с компаниями, такими как John Deere — производящими трактора для ферм. Им необходимо встраивать в трактора все разновидности приборов — так же, как в автомобили. Например, трактор должен быть оснащен DVD-плейером и средствами интеллектуальной автоматизации, такими как GPS, постепенно превращающими трактор в робота.

Программное обеспечение и электроника развиваются с нарастающей скоростью. В прежние времена производящая компания могла иметь, скажем, 1000 инженеров в сфере механики, 100 — в сфере электротехники и 20 программистов. Сегодня в этой же компании мы увидим 100 механиков, 500 электриков и 1000 программистов. В наши дни самая востребованная профессия — инженер-системщик. «Системщик» означает знание всех трех сфер: механики, электроники и софтвера.

Вся моя карьера стимулировалась потребностью увидеть, как мой вклад в технологию реально используется на рынке. Ведь мы знаем слишком много примеров выдающихся технологий, которые так и не нашли практического применения. Именно желание увидеть свои результаты примененными подвигло меня на переход от изучения чистой математики в колледже к вычислительным наукам в аспирантуре. Я жаждал увидеть применение математики, а применение компьютеров в инженерном дело в те времена только зарождалось. Часто я рассказываю реальный забавный эпизод из моей жизни: на одном из занятий — накануне моего выпуска из колледжа со степенью бакалавра — преподаватель вошел в аудиторию со словами: «Сегодня мы займемся доказательством того, что доказательство может быть доказано». Услышая это, я уронил голову на стол и подумал: «Я обязательно должен заняться чем-то другим!».

В университете, благодаря профессору Стивену А. Кунсу, я узнал о существовании САПР и, в частности, о проблемах конструирования сложных больших компонентов поверхностей. Тут вся мозаика моих пожеланий сложилась в цельную картину: математика, компьютеры, графика и инженерные приложения. Работа по теме NURBS была весьма приятной благодаря комбинации моей любви к математике, контактам с выдающимися коллегами и программной реализации моих результатов. Программная реализация была университетским требованием к моей исследовательской аспирантской работе по теме NURBS, и я реально реализовал свои программы на компьютере, имеющем новую на то время технологию обновления изображения на экране.

Однако, попав затем в Computervision и проведя в этой фирме первые несколько лет в должности старшего программиста отдела разработок, я приобрел совершенно новый опыт. Мне пришлось встречаться с пользователями и обсуждать с ними их проблемы и их оценки написанным мной программам. Мне повезло работать в компании в быстро растущей отрасли и ставшей в то время поставщиком номер 1. Все это было очень волнующим, особенно — внедрение на широкий рынок новых концепций и функций.

Сегодня я занимаюсь консалтингом потому, что, на мой взгляд, таким образом я могу влиять на всю индустрию в большей степени, чем, если бы был ограничен работой на какого-то одного вендора.

Уверен, что вам известно: это — не легенда, этот эпизод описан моим другом Эваном Яресом в его блоге. Да, так оно и было, и об этом я рассказал Эвану за бокалом красного вина на одной из промышленных конференций. Чтобы полностью оценить происшедшее, вам надо знать, что в тот время я работал над архитектурой геометрической системы, используемой в Computervision. Я спроектировал ее на основе модульного подхода, состоящего в том, что каждому геометрическому объекту сопоставлялась, во-первых, своя структура данных в базе данных, и, во-вторых, — некоторые вычислительные функции, которые могли вызываться с надлежащими точками входа и выдавали указатель на объект.

Я обеспечил возможность размещения четырех координат для каждой вершины многоугольника так, что в базе данных было место для гомогенных координат, необходимых механизму NURBS, и, при этом, для Безье гомогенный элемент по умолчанию полагался равным единице. Затем я реализовал для вычислительных процедур возможность справляться с гомогенными координатами и рациональными функциями, но, поскольку на его вход поступали только данные Безье, мой модуль именно их и тестировал. Не надо забывать, что в те времена со сложными поверхностями в САПР была связано лишь ограниченная функциональность — гораздо более простая, чем сегодня.

Рассказав все это, я выражаю свою безусловную уверенность в том, что программистам не следует разрешать делать то, что им заблагорассудится. В моем случае, я реализовал все, что требовалось, не нарушив ни требования по ресурсам, ни по графику работ. Просто в своей реализации я оставил возможности для последующих расширений решения, которые я предвидел. Я не реализовал ничего чуждого разрабатываемой системе. Понимаете, в моей карьере, работая в качестве программиста, софтверного архитектора и менеджера, я осознал принципиальную разницу между очень хорошим программистом и софтверным архитектором. Архитектор предвидит, что потребуется усовершенствовать на протяжении жизненного цикла программного продукта, а хороший программист это предвидеть не обязан.

Я испытал подлинное наслаждение от тесного сотрудничества со Стивом Кунсом, Сэмом Гейзбергом, конечно — с Биллом Гордоном (помните, поверхности Гордона?) и Робином Форрестом. Как и все остальные люди, они были очень разными — каждый со своими особенностями. Но если бы мне пришлось дать им общую характеристику, я назвал бы интенсивность творческой деятельности.

Я очень ценю время, проведенное со Стивом Кунсом. Из всех людей, которых я встретил и сотрудничал, он больше всех заслуживает характеристики «гений». Однажды на моем последнем курсе, где Стив преподавал, он начал вступительную лекцию с рассказа о консалтинговом проекте, который он выполнял в отпускное летнее время, стараясь решить проблему, которая многие годы стояла перед его клиентом из промышленности. Стив написал нам на доске соответствующее моделирующее инженерное уравнение, затем занял место среди нас — студентов и, глядя на доску, спросил: «Красиво выглядит?». Он всегда был переполнен любовью к красоте математики. На доске мы видели матричное уравнение. Стив вскочил, подбежал к доске и в центре изобразил единичную матрицу. Затем он обернулся к аудитории и сказал: «Может быть, это не единичная матрица». Мы сразу увидели все последствия написанного на доске и искомое решение.

Сэм Гейзберг был совершенно другим человеком. В начале моей карьеры в Computervision, мы с Сэмом работали в одном офисе. Я помогал ему получить американское гражданство. У Сэма был блестящий ум, но я не назвал бы его лучшим программистом. Им управляли идеи. Одной из причин его ухода из Computervision стало то, что он не нашел технических аргументов, чтобы убедить меня в том, как следует реализовывать сложные поверхности произвольного вида. Он верил в то, что я называю 2.5D, где сочетание поверхностей можно задать только кривыми в параллельных плоскостях. Я предпочел полную трехмерность, а Сэм проигрывать не любил. Интересно, что некоторые элементы отстаиваемого им подхода, впоследствии я усмотрел в первых релизах созданного Сэмом Pro/ENGINEER.

Мы близкие друзья с Брэдом Хольцем, основателем COFES, и я много раз участвовал в этих конгрессах, проходящих в США. Брэд обратился ко мне с предложением о консалтинговом проекте в России, которому соответствует моя компетенция. Вам будет интересно узнать, что мой начальный комментарий, который я сделал российскому клиенту, включал слова о том, что я рад тому, что российские математики и программисты начали более агрессивно продвигаться на глобальный рынок. В Computervision в отделах разработки математического софтвера работало много эмигрантов из России, и я понимал их большие способности. Сегодня, я наблюдаю, как эти способности проявились в решениях многих САПР-вендоров.

Безусловно, я надеюсь, что, посещение COFES Россия и контакты, которые завяжутся на этом мероприятии, помогут мне расширить консалтинговую деятельность в России.