что такое процедурная анимация

OpenSceneGraph: Процедурная анимация геометрии и атрибутов состояния

Введение

Говоря о приемах программирования, специфичных для OSG в прошлый раз мы говорили о механизме обратных вызовов (Callback) и его реализации в движке. Настало время посмотреть на то, какие возможности дает нам применение этого механизма для управления содержимым трехмерной сцены.

Если говорить об анимации объектов, то OSG предоставляет разработчику две возможности её реализации:

1. Процедурная морфинг-анимация

При обходе графа сцены OSG выполняет передачу данных в конвейер OpenGL, который выполняется в отдельном потоке. Этот поток должен быть синхронизирован с другими потоками обработки в каждом кадре. Невыполнение этого требования может привести к тому, что метод frame() завершится раньше обработки данных геометрии. Это приведет к непредсказуемому поведению программы и сбоям. OSG предлагает решение этой проблемы в виде метода setDataVariance() класса osg::Object, являющегося базовым для вех объектов сцены. Можно установить три режима обработки объектов

Общепринятой является практика модификации геометрии «на лету», то есть изменение координат вершин, нормалей цветов и текстур динамически в каждом кадре, получая видоизменяемую геометрию. Такой прием называется морфинг-анимацией. В данном случае решающим является порядок обработки геометрии — все её изменения должны быть пересчитаны до того, как начнется отрисовка. Для иллюстрации этого приема немного изменим пример с цветным квадратом, заставив одну из его вершин вращаться вокруг оси X.

main.h

main.cpp

Создание квадрата вынесем в отдельную функцию

описание которой, в принципе не требуется, так как подобные действия мы проделывали многократно. Для модификации вершин этого квадрата пишем класс DynamicQuadCallback, наследуя его от osg::Drawable::UpdateCallback

переопределяя в нем метод update()

Здесь мы получаем указатель на объект геометрии

читаем из геометрии список вершин (вернее указатель на него)

Для получения последнего элемента (последней вершины) в массиве класс osg::Array предоставляем метод back(). Для выполнения поворота вершины относительно оси X вводим кватернион

то есть мы задали кватернион, реализующий поворот вокруг оси X на угол 0.01 * Pi. Поворачиваем вершину умножением кватерниона на вектор, задающий координаты вершины

Последние два вызова пересчитывают дисплейный список и габаритный параллелепипед для видоизмененной геометрии

В теле функции main() мы создаем квадрат, устанавливаем для него динамический режим отрисовки и добавляем обратный вызов, модифицирующий геометрию

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

А теперь попробуйте убрать (комментировать) вызов setDataVariance(). Возможно мы и не увидим ничего криминального в этом случае — по-умолчанию OSG пытается автоматически определить когда следует обновлять данные о геометрии, пытаясь синхронизироваться с отрисовкой. Тогда попробуйте изменить режим с DYNAMIC на STATIC и будет видно, что изображение рендерится не плавно, с заметными рывками, в консоль сыпятся ошибки и предупреждения типа этого

Если не выполнить метод dirtyDisplayList(), то OpenGL проигнорирует все изменения геометрии и для отрисовки будет использовать дисплейный список, созданный в самом начале, при создании квадрата. Удалите этот вызов, и увидите, что никакой анимации нет.

Без вызова метода dirtyBound() не будет произведен пересчет ограничивающего параллелепипеда и OSG будет неверно выполнять отсечение невидимых граней.

2. Понятие об интерполяции движения

Предположим, что некий поезд, идущий от станции A к станции B затрачивает на это перемещение 15 минут. Как можно смоделировать эту ситуацию, изменяя положение поезда в обратном вызове? Самый простой способ — соотнести положение станции A с моментом времени 0, а станции B — с моментом 15 минут и равномерно перемещать поезд между этими моментами времени. Такой простейший подход называется линейной интерполяцией. При линейной интерполяции вектор, задающий положение промежуточной точки описывается формулой

где p0 — начальная точка; p1 — конечная точка; t — параметр, изменяющийся равномерно от 0 до 1. Однако, движение поезда намного сложнее: выйдя со станции A он разгоняется, потом движется с постоянной скоростью, а затем замедляется, останавливаясь на станции B. Линейная интерполяция такой процесс уже не в состоянии описать и выглядит неестественно.

OSG предоставляет разработчику библиотеку osgAnimation, содержащую ряд стандартный алгоритмов интерполяции, применяемых для плавной анимации перемещения объектов сцены. Каждая из этих функций имеет обычно два аргумента: начальное значение параметра (обычно 0) и конечное значение параметра (обычно 1). Эти функции могут быть применены к начальному участку движения (InMotion), к конечному участку (OutMotion) или к начальному и конечному участку движения (InOutMotion)

Для создания линейной интерполяции движения объекта пишем такой код

3. Анимация узлов трансформации

Анимация движения по траектории — наиболее распространенный вид анимации в графических приложениях. Этот прием может быть использован при анимировании движения автомобиля, полета самолета или движения камеры. Траектория задается предварительно, со всеми положениями, поворотами и изменениями масштаба в ключевые моменты времени. При запуске цикла симуляции состояние объекта пересчитывается в каждом кадре, с применением линейной интерполяции для положения и масштабирования и сферической линейной интерполяции для кватернионов вращения. Для этого используется внутренний метод slerp() класса osg::Quat.

OSG предоставляет класс osg::AnimationPath для описания изменяющейся во времени траектории. Для добавления в траекторию контрольных точек, соответствующих определенным моментам времени используется метод этого класса insert(). Контрольная точка описывается классом osg::AnimationPath::ControlPoint, конструктор которого принимает в качестве параметров позицию, и, опционально, параметры поворота объекта и масштабирование. Например

Здесь t1, t2 — моменты времени в секундах; rot1 — параметр поворота в момент времени t1, описываемый кватернионом osg::Quat.

Возможно управление зацикливанием анимации через метод setLoopMode(). По-умолчанию включен режим LOOP — анимация будет непрерывно повторятся. Другие возможные значения: NO_LOOPING — проигрывание анимации один раз и SWING — циклическое проигрывание движения в прямом и обратном направлениях.

После выполнения всех инициализации мы присоединяем объект osg::AnimationPath к встроенному объекту osg::AnimationPathCallback, являющемуся производным от класса osg::NodeCallback.

4. Пример анимации движения по траектории

Теперь заставим нашу цессну двигаться по окружности с центром в точке (0,0,0). Положение самолета на траектории будет рассчитываться путем линейной интерполяции положения и ориентации между ключевыми кадрами.

main.h

main.cpp

Начинаем с создания траектории самолета, вынося этот код в отдельную функцию

В качестве параметров функция принимает радиус окружности, по которой движется самолет и время, за которое он совершит один оборот. Внутри функции создаем объект траектории и включаем режим циклического повторения анимации

вычисляет параметры аппроксимации траектории. Мы разбиваем всю траекторию на numSamples прямолинейных участков, и вычисляем изменение угла поворота самолета вокруг вертикальной оси (рыскания) delta_yaw и изменение времени delta_time при переходит от участка к учаcтку. Теперь создаем необходимые контрольные точки

В цикле перебираются все участки траектории от первого до последнего. Каждая контрольная точка характеризуется углом рыскания

положением центра масс самолета в пространстве

Поворот самолета на требуемый угол рыскания (относительно вертикальной оси) задаем кватернионом

а затем добавляем рассчитанные параметры в список контрольных точек траектории

В основной программа обращаем внимание на нюанс в указании имени файла модели самолета при загрузке

– к имени файла добавился некий суффикс «.0,0,90.rot». Механизм загрузки геометрии из файла, используемый в OSG позволяет таким образом указать начальное положение и ориентацию модели после загрузки. В данном случае мы хотим, чтобы загрузившись, модель была повернута на 90 градусов вокруг оси Z.

Далее создается корневой узел, являющийся узлом трансформации, и объект модели добавляется к нему в качестве дочернего узла

Теперь создаем обратный вызов анимации траектории, добавляя в него путь, создаваемый функцией createAnimationPath()

Прикрепляем этот callback к узлу трансформации

Инициализация и запуск вьювера производится как обычно

Получаем анимацию движения самолета

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

Секрет в том, что эту работу выполняет специальный класс osg::AnimationPathCallback. В соответствии с текущим положением объекта на траектории он вычисляет матрицу трансформации и автоматически применяет её к тому узлу трансформации, к которому он прикреплен, избавляя разработчика от кучи рутинных операций.

Тут следует отметить, что прикрепление osg::AnimationPathCallback к другим типам узлов, не только не даст эффекта, но и может привести к неопределенному поведению программы. Важно помнить, что данный обратный вызов воздействует исключительно на узлы трансформации.

5. Программное управление анимацией

Класс osg::AnimationPathCallback предоставляет методы для управления анимацией в процессе выполнения программы

а для начала анимации с четвертой секунды после запуска программы с двухкратным ускорением, такой код

6. Порядок рендеринга примитивов в OpenGL

OpenGL хранит данные вершин и примитивов в различных буферах, таких как буфер цвета (color buffer), буфер глубины (depth buffer), буфер трафарета (stencil buffer) и так далее. Кроме того, он не перезаписывает вершины и треугольные грани уже отправленные в его конвейер. Это означает, что OpenGL создает новую геометрию вне зависимости от того, каким образом создавалась уже существующая геометрия. Это означает, что порядок в котором примитивы посылаются в конвейер рендеринга существенно влияет на конечный результат, который мы видим на экране.

Опираясь на данные буфера глубины OpenGL правильно отрисует непрозрачные объекты, сортируя пиксели по степени их удаленности от наблюдателя. Тем не менее, при использования техники смешивания цветов, например при реализации прозрачных и полупрозрачных объектов, будет выполнятся специальная операция обновления буфера цвета. Новые и старые пиксели изображения смешиваются, с учетом значения альфа-канала (четвертый компонент цвета). Это приводит к тому, что порядок рендеринга полупрозрачных (translucent) и непрозрачных (opaque) граней влияет на конечный результат

на рисунке, в ситуации слева в конвейер были отправлены сначала непрозрачные, а потом прозрачные объекты, что привело к корректному смещению в буфере цвета и корректному отображению граней. В правой ситуации сначала были отрисованы прозрачные объекты, а затем непрозрачные, что привело к неверному отображению.

Метод setRenderingHint() класса osg::StateSet указывает OSG требуемый порядок рендеринга узлов и геометрических объектов, если это необходимо выполнить явно. Этот метод просто указывает, следует или не следует учитывать полупрозрачные грани при рендеринге, тем самым гарантируя, что в случае наличия в сцене полупрозрачных граней сначала будут отрисованы непрозрачные, а затем прозрачные грани, с учетом удаленности граней от наблюдателя. Чтобы сообщать движку, что данный узел непрозрачный используем такой код

или содержит прозрачные грани

7. Пример реализации полупрозрачных объектов

Попробуем проиллюстрировать всё вышеописанное теоретическое введение конкретным примером реализации полупрозрачного объекта.

main.h

main.cpp

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

– значение альфа-канала равно 0.5, что в смешении с цветами текстуры должно дать эффект полупрозрачного объекта. Кроме того, для обработки прозрачности следует задать функцию смешивания цветов

передав её машине состояний OpenGL

При компиляции и запуске этой программы мы получим следующий результат

Стоп! А где же прозрачность? Всё дело в том, что мы забыли указать движку, что следует обрабатывать прозрачные грани, что решается легко вызовом

после чего мы получим нужный нам результат – крыло дельтаплана просвечивается через полупрозрачный текстурированный квадрат

Параметры функции смешивания GL_SRC_ALPHA и GL_ONE_MINUS_SRC_ALPHA означают, что результирующий пиксель экрана при отрисовке полупрозрачной грани будет иметь компоненты цвета, рассчитываемые по формуле

где [srcR, srcG, srcB] — компоненты цвета текстуры квадрата; [dstR, dstG, dstB] — компоненты цвета каждого пикселя того участка на который накладывается полупрозрачная грань, полученные с учетом того, что на этом месте уже отрисован фон и непрозрачные грани крыла дельтаплана. Под srcA понимаю альфа-компоненту цвета квадрата.

Метод seRenderingHint() отлично упорядочивает отрисовку примитивов, но использовать его не слишком эффективно, так как сортировка прозрачных объектов по глубине при рендеринге кадра довольно ресурсоемкая операция. Поэтому разработчик должен позаботится о порядке отрисовки граней самостоятельно, если это возможно на предварительных этапах подготовки сцены.

8. Анимация атрибутов состояния

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

Классы стандартных интерполяций так же мотут быть использованы для задания функции изменения параметров атрибутов.

У нас уже имеется опыт создания полупрозрачных объектов. Мы знаем, что если альфа-компонента цвета равна нулю, мы получаем полностью прозрачный объект, при значении 1 — полностью непрозрачный. Ясно, что варьируя этот параметр от 0 до 1 во времени можно получить эффект постепенного появления или исчезания объекта. Проиллюстрируем это на конкретном примере

main.h

main.cpp

Начинаем с создания обратного вызова-обработчика изменения значения альфа-канала во времени

Защищенный параметр _motion будет определять ту функцию, по которой будет изменятся значение альфы во времени. Для данного примера выберем аппроксимацию кубическим сплайном, задавая её сразу же, в конструкторе класса

Эта зависимость может быть проиллюстрирована вот такой кривой

В конструкторе объекта InOutCubicMotion определяем пределы изменения аппроксимируемой величины от 0 до 1. Далее переопределяем operator() для данного класса таким образом

Получаем указатель на материал

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

Читаем значение аппроксимирующей функции

и присваиваем материалу новое значение диффузного цвета

Теперь сформируем сцену в функции main(). Я думаю вы уже устали каждый раз строить квадрат по вершинам, поэтому упростим задачу — генерируем квадратный полигон стандартной функцией OSG

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

Мы указываем параметры цвета материала. Ambient color — это параметр, характеризующий цвет материала в затененной области, недоступной для источников цвета. Diffuse color — собственный цвет материала, характеризующий способность поверхности рассеивать падающий на неё цвет, то есть то, что мы привыкли называть цветом в быту. Параметр FRONT_AND_BACK указывает, что данный атрибут цвета присваивается как лицевой, так и обратной стороне граней геометрии.

Назначаем материалу созданный нами ранее обработчик

Назначаем созданный материал квадрату

и задаем другие атрибуты — функцию смешивания цветов и указываем, что данный объект имеет прозрачные грани

Завершаем формирование сцены и запускаем вьювер

Получаем результат в виде плавно появляющегося в сцене квадрата

Вместо заключения: небольшая ремарка о зависимостях

Наверняка ваш пример не компилируется, выдавая ошибку на этапе компоновки. Это не случайно – обратите внимание на строчку в заголовочном файле main.h

Каталог заголовков OSG, из которого берется заголовочный файл, обычно указывает на ту библиотеку, в которой содержится реализация функций и классов, описанных в заголовке. Поэтому появление каталога osgAnimation/ должно наводить на мысль о том, что в список линковки сценария сборки проекта следует добавить одноименную библиотеку, примерно так (с учетом путей к библиотекам и версии сборки)

Источник

Процедурная анимация

Из Википедии — свободной энциклопедии

Процедурная анимация (англ. procedural animation ) — вид компьютерной анимации, который автоматически генерирует анимацию в режиме реального времени согласно установленным правилам, законам и ограничениям. В отличие от предопределённой анимации, когда аниматор вручную определяет каждый кадр и все параметры создаваемой анимации, при процедурной анимации результат может быть в некоторой мере непредсказуем и при каждом запуске может генерировать разнообразную анимацию.

Процедурная анимация используется для создания и моделирования системы частиц (дым, огонь, вода [1] [2] ), ткани и одежды, динамики твёрдых тел, динамики волос и меха, а также для анимации гуманоидных и негуманоидных персонажей.

В компьютерных играх процедурная анимация часто используется для таких простых вещей, как поворачивание головы персонажа, когда игрок озирается по сторонам (например, в игре Quake III Arena).

Физика Ragdoll (рус. физика «тряпичной куклы» ) может считаться видом процедурной анимации. Физика Ragdoll использует физический движок для создания анимации смерти персонажа и его реалистичного падения на поверхность. При использовании физики Ragdoll персонаж состоит из последовательности связанных твёрдых тел (руки, ноги, торс, голова и т. д.), которые запрограммированы с использованием ньютоновой физики, действующей на них. Благодаря физике Ragdoll могут быть созданы очень реалистические анимации, которые очень сложно создать, используя традиционную предопределённую анимацию. Например, с использованием физики Ragdoll тела персонажей могут катиться или скользить по наклонным поверхностям, переворачиваться, кувыркаться и т. д., причём каждый раз анимация будет другой.

Процедурная анимация интенсивно используется в компьютерной игре Spore, в которой созданные игроком существа автоматически анимируются для всех действий, которые должно делать созданное существо: ходьба, бег, плавание, подбирание вещей и т. д.

Ещё одним явным примером процедурной анимации является технология «Dynamic Motion Synthesis» (рус. синтез динамических движений ), которая разработана NaturalMotion и используется в продуктах euphoria и endorphin. «Dynamic Motion Synthesis» (DMS) основан на моделировании биомеханики и моторной нервной системы в режиме реального времени. Также DMS использует элементы из биологии и теории управления роботами. DMS позволяет создавать модели полностью интерактивных трехмерных персонажей, которые не используют заранее просчитанную анимацию. «euphoria» использует DMS для генерации анимации «на лету» в режиме реального времени в компьютерных играх или других интерактивных приложениях. Технология «euphoria» используется в играх Star Wars: The Force Unleashed, Indiana Jones and the Staff of Kings, Max Payne 3, Grand Theft Auto IV и его аддонах, Grand Theft Auto V, а также в симуляторе американского футбола Backbreaker.

Источник

Введение в процедурную анимацию: инверсная кинематика

Часть 4. Введение в градиентный спуск

Эта часть представляет собой теоретическое введение в инверсную кинематику и содержит программное решение, основанное на градиентном спуске (gradient descent). Эта статья не будет всеобъемлющим руководством по этой теме, это всего лишь общее введение. В следующей части мы покажем настоящую реализацию этого алгоритма на C# в Unity.

Серия состоит из следующих частей (части 1-3 представлены в предыдущем посте):

Введение

Если у нас есть конкретная точка в пространстве, которой мы хотим достичь, то можно использовать ForwardKinematics для оценки близости к ней манипулятора с учётом текущей конфигурации соединений. Расстояние от цели — это функция, которую можно реализовать следующим образом:

Градиентный спуск — это алгоритм оптимизации. Его можно использовать для всех проблем, не имеющих точного уравнения. Это не наш случай, ведь мы уже вывели уравнение прямой кинематики в части «Математика прямой кинематики»:

Расстояние от целевой точки задаётся как:

где — это евклидова норма вектора .

Аналитическое решение этой проблемы можно найти минимизацией , которая является функцией .

Есть и другие, более структурированные подходы к решению проблемы инверсной кинематики. Для начала стоит взглянуть на матрицы Денавита-Хартенберга (Wikipedia).

Градиентный спуск

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

На графике ниже показан стандартный случай, в котором градиентный спуск будет успешным. В этом простейшем примере у нас есть функция. Она получает один параметр (ось X) и возвращает значение ошибки (ось Y). Мы начинаем со случайной точки на оси X (синяя и зелёная точки). Градиентный спуск должен заставить нас двигаться в направлении минимума (синяя и зелёная стрелки).

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

Чтобы градиентный спуск был эффективным, минимизируемая нами функция должна удовлетворять определённым требованиям. Если рельеф функции относительно плавный, то вероятность успешного применения градиентного спуска выше. Если у функции есть разрывы или множество максимумов, то это особенно сложно, потому что для достижения дна долины потребуется гораздо более долгое путешествие.

Вот как может выглядеть рельеф для робота-манипулятора с двумя соединениями (управляемыми и ):

Оценка градиента

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

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

Понятия градиента и произвольной тесно связаны.

Градиент или косая производная функции — это вектор, указывающий в направлении наискорейшего подъёма. В случае одномерных функций (как на наших графиках) градиент равен или , если функция идёт вверх, или , если функция идёт вниз. Если функция определена через две переменные (например, робот-манипулятор с двумя соединениями), то градиент является «стрелкой» (единичным вектором) двух элементов, направленным в сторону наискорейшего подъёма.

Производная функции, в отличие от градиента — это просто число, определяющее скорость подъёма функции при движении в направлении градиента.

В этой статье мы не будем стремиться вычислить настоящий градиент функции. Вместо этого мы создадим оценку. Наш приблизительный градиент — это вектор, который, как мы надеемся, указывает в направлении наискорейшего подъёма. Как мы увидим, это необязательно будет единичный вектор.

Оно очень важно. Выборка близлежащих точек требует оценки функции на определённом расстоянии от текущего положения. Это расстояние критически важно.

Посмотрите на график:

Это расстояние выборки, использованное для оценки градиента, слишком велико. Градиентный спуск ошибочно «предполагает», что правая сторона выше, чем левая. В результате алгоритм будет двигаться в неправильном направлении.

Снижение расстояния выборки позволяет уменьшить эту проблему, но избавиться от неё никогда не удастся. Более того, меньшее расстояние выборки приводит ко всё более медленному приближению к решению.

Эту проблему можно решить с помощью более сложных вариаций градиентных спусков.

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

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

Все эти проблемы тоже можно решить с помощью усложнённых вариаций градиентного спуска.

Математика

Теперь, когда у нас есть общее понимание графической работы градиентного спуска, давайте посмотрим, как перевести его на язык математики. Первый этап — вычисление градиента нашей функции ошибок в конкретной точке . Нам требуется найти направление, в котором растёт функция. Градиент функции тесно связан с её производной. Поэтому неплохо бы начать создание нашей оценки с изучения того, как вычисляется производная.

С математической точки зрения производная функции называется . Её значение в точке равно , и оно показывает, насколько быстро растёт функция. Согласно ей:

На графике ниже показано, что это значит:

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

Подведём итог. Для вычисления истинной производной функции необходимо использовать предел. Наш градиент является приблизительной оценкой производной, созданной с помощью достаточно небольшого расстояния выборки:

В следующем разделе мы увидим, чем эти два понятия отличаются при нескольких переменных.

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

Константу часто называют learning rate. Она определяет, как быстро мы будем двигаться по градиенту. Чем больше значения, тем быстрее найдётся решение, но тем больше вероятность пропустить его.

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

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

Несколько переменных

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

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

Мы можем ввести понятие частных производных, которые, в сущности, являются «традиционными» производными, вычисляемыми для каждой из переменных:

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

Для нашего градиентного спуска мы будем в качестве градиента использовать вектор, содержащий в себе все три результата:

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

Хотя это и может выглядеть как насилие над математикой (а возможно, так оно и есть!), но при этом оно не обязательно станет проблемой для нашего алгоритма. Нам нужен вектор, указывающий в направлении наискорейшего подъёма. Использование приблизительных значений частных производных в качестве элементов такого вектора удовлетворяет нашим ограничениям. Если нам нужно, чтобы это был единичный вектор, то можно просто нормализовать его, поделив на его длину.

Использование единичного вектора даёт нам преимущество определения максимальной скорости, с которой мы движемся по поверхности. Эта скорость является learning rate . Использование ненормализованного вектора означает, что мы будем быстрее или медленнее, в зависимости от наклона . Это не хорошо и не плохо, это просто ещё один подход к решению нашей проблемы.

Часть 5. Инверсная кинематика для робота-манипулятора

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

Введение

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

Для этого мы сначала вычислим градиент функции при текущем . Градиент — это вектор, показывающий направление наискорейшего подъёма. Проще говоря, это стрелка, указывающая нам направление, в котором растёт функция. Каждый элемент градиента — это приблизительное значение частной производной .

Например, если у робота-манипулятора есть три сочленения, то у нас будет функция , получающая три параметра: , и . Тогда наш градиент задаётся как:

а , и — достаточно малые значения.

Мы получили приблизительный градиент . Если мы хотим минимизировать , то необходимо двигаться в противоположном направлении. Это означает обновление , и следующим образом:

где — это learning rate, положительный параметр, управляющий скоростью удаления от поднимающегося градиента.

Реализация

При вызове этой функции она возвращает одно число, определяющее, как изменяется расстояние от цели как функция от поворота сочленения.

Нам нужно обработать в цикле все сочленения, вычисляя их влияние на градиент.

Многократный вызов InverseKinematics перемещает робот-манипулятор ближе к целевой точке.

Преждевременное завершение

Одна из основных проблем инверсной кинематики, реализованной этим наивным подходом — малая вероятность окончательного схождения градиента. В зависимости от выбранных для LearningRate и SamplingDistance значений очень возможно, что манипулятор будет «качаться» рядом с истинным решением.

Так происходит потому, что мы обновляем углы слишком часто, и это приводит к «перелёту» через истинную точку. Правильным решением этой проблемы будет использование адаптивного learning rate, изменяющегося в зависимости от близости к решению. Более дешёвая альтернатива — останавливать алгоритм оптимизации, если мы ближе, чем определённое пороговое значение:

Если мы будем повторять эту проверку после каждого поворота сочленения, мы выполним минимальное количество требуемых движений.

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

Ограничения

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

Решение достаточно очевидно. Мы добавим в класс RobotJoint минимальные и максимальные углы:

затем нужно убедиться, что мы ограничиваем углы нужным диапазоном:

Проблемы

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

Посмотрите на анимацию:

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

Часть 6. Инверсная кинематика щупалец

Введение

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

У некоторых существ есть части тела, имеющие несколько степеней свободы. Примером могут служить хобот слона и щупальце осьминога. Моделирование таких частей тела — особо сложная задача, потому что приведённые выше традиционные техники не смогут создать реалистичных результатов.

Мы начнём с примера из предыдущей части и постепенно придём к поведению, которое для наших целей окажется достаточно реалистичным.

Риггинг щупальца

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

Компонент Unity, позволяющий реализовать эту функцию, называется Skinned Mesh Renderer:

К сожалению, Unity не предоставляет возможности создания рендерера сеток со скиннингом в редакторе. Необходим редактор 3D-моделей, например, Blender. На изображении ниже показана модель щупальца, которое мы будем использовать в этой части. Внутри видно несколько костей, соединённых друг с другом. Это объекты, позволяющие нам изгибать модель.

В этом туториале мы не будем изучать добавление костей к моделям, также называемое риггингом. Хорошее введение в предмет можно прочитать в статье Blender 3D: Noob to Pro/Bones.

Кости и сочленения

У обычного осьминога каждое сочленение может свободно поворачиваться по всем трём осям. К сожалению, код написанный для робота-манипулятора, позволяет вращать сочленения только по одной оси. Если попытаться изменить это, то мы добавим нашему коду новый уровень сложности. Вместо этого мы можем циклично менять ось сочленений, чтобы сочленение 0 поворачивалось по X, сочленение 1 — по Y, сочленение 2 — по Z, и так далее. Это может привести к неестественному поведению, но такая проблема у вас может никогда не возникнуть, если кости достаточно малы.

В скачиваемом проекте Unity, продаваемом с этим туториалом, скрипт SetRobotJointWeights автоматически инициализирует параметры всех сочленений щупальца. Вы можете делать это вручную, чтобы иметь более точный контроль над движением каждой кости.

Функция комфорта

На представленной ниже анимации показано два щупальца. Щупальце слева тянется к красной сфере с помощью алгоритма из «Инверсной кинематики для робота-манипулятора». Правое щупальце добавляет совершенно новый уровень реализма, закручиваясь спирально, в более органическом стиле. Этого примера должно быть достаточно, чтобы понять, почему для щупалец нужен свой собственный туториал.

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

Такое приведение к соответствию с локальным поворотом не всегда подходит. В зависимости от ситуации можно выравнивать щупальце иначе.

Эти три ограничения приводят к более реалистичному способу движения щупалец. Более сложная версия может обеспечить колебания, даже когда условия удовлетворяют всем остальным ограничениям.

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

В идеале их нужно нормализовать между и . После этого можно будет использовать коэффициенты для указания их относительной важности:

Традиционную проблему прямой кинематики можно смоделировать аналитически. Это значит, что мы можем вывести уравнение, которое её решает. Мы уже упоминали о существовании аналитических методов решения двойственной проблемы инверсной кинематики.

На данный момент у нас есть функция, которую, возможно, не получится описать аналитически. Если бы мы выбрали традиционный, аналитический подход к решению инверсной кинематики, то нам не удалось бы добавить такие нюансы поведения щупальца. Использование градиентного спуска означает, что теперь мы можем минимизировать (почти!) любую произвольную функцию, есть у неё уравнение или нет.

Усовершенствования

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

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

[Готовый проект Unity со скриптами и 3D-моделями можно приобрести за 10 долларов на странице Patreon автора оригинала статьи.]

К сожалению, оказалось, что седьмая часть про поведение паучьих лап у автора ещё не готова. В связи с этим добавил опрос:

Источник