4 PyDrivers и Constraints (Управляющие объекты и Ограничения)333

Перевод: S.Lavik, Striver

Проектируя сложные объекты с подвижными частями, мы хотели бы управлять перемещением этих частей относительно друг друга. Иногда, для достижения цели мы можем использовать физические движки, например, такие как Bullet physics, но часто этого не достаточно для точного воспроизведения анимации, физический движок не всегда предоставляет необходимый контроль над сценой. Большую часть времени умное использование многократных ограничений будет вполне достаточным, но иногда взаимосвязи между объектами (другими словами хорошая анимация) не могут быть выражены с точки зрения простых ограничений и ключевой анимации. В таких случаях мы можем расширить возможности Блендера, определив собственные ограничения или отношения между анимируемыми объектами, используя Питон.

В этой главе мы увидим, как можно связать встроенные ограничения с объектами Блендера и как определить сложные отношения между анимированными объектами используя так называемые pydrivers. Мы также определим новые сложные ограничения, которые могут использоваться точно так же, как и встроенные ограничения. Мы пока не будем изучать такие определения, как ключевые кадры (key frames), поскольку мы столкнемся с ними в более поздних главах.

В этой главе мы узнаем:

• Как управлять одним IPO из другого в выражениях Питона

• Как работать с некоторыми ограничениями, присущими pydrivers

• Как управлять движением объектов и костей, добавляя ограничения

• Как написать ограничение в Питоне, которое привяжет один объект к ближайшей к нему вершине на другом объекте

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


Акцентируем внимание на свойствах анимации

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


IPO

В Блендере почти любой объект может быть анимирован. Обычно это делается, с помощью фиксации некоторых параметров, таких как положение в пространстве некоего объекта в определенных ключевых кадрах и интерполяция этих параметров для остальных промежуточных кадров. В Блендере группы объектов, задействованные в анимации собираются в так называемые кривые IPO. Например, все пространственные параметры, такие как местоположение, вращение, и масштаб сгруппированы как тип объекта IPO и могут быть связаны со многими объектами Блендера: мешем, камерой, или лампой. Большинство свойств материалов в Блендере также могут быть сгруппированы в соответствующем IPO. Получается, что ''Материальный'' тип IPO может быть связан с любым объектом, которому присвоен материал. Аналогично, тип IPO Лампы должен быть связан с объектом Лампы.

IPO это аббревиатура, но что она обозначает кажется немного неясным. Wiki Блендера заявляет, что она происходит от слова InterPOlation, то есть от математической функции (почитайте Wiki там есть интересная информация на этот счет - прим. пер), но в Блендере мы столкнемся с интерполяцией как с объектом. И большую часть времени будем использовать IPO как существительное, однако, это обсуждение становится немного академическим.

Каждый IPO может быть связан с более чем одним объектом. Например, возможно анимировать вращение нескольких объектов, объединив их с одним объектом IPO. В Блендер API кривые IPO представлены объектами IPO. Объект IPO может быть связан с другим объектом посредством метода setIpo(). Следующая таблица дает краткий обзор типов IPO, IPO-каналов, и список объектов с которыми они могут взаимодействовать. Обратитесь к API документации о модуле Blender.IPO за подробной информацией.

(http://www.blender.org/documentation/249PythonDoc/index.html).


Тип IPO

Object

IPO каналы (некоторые примеры, см. полный список в API документации)

LocX, LocY, LocZ (перемещение)

RotX, RotY, RotZ (вращение)

ScaleX, ScaleY, ScaleZ (маштаб)

Соответствующие объекты в Блендере

Все объекты Блендера, которые можно перемещать: Меш, Лампа, Камера и др.


Тип IPO

Pose

IPO каналы (некоторые примеры, см. полный список в API документации)

RotX, RotY, RotZ (вращение)

Соответствующие объекты в Блендере

Кости (Bone)


Тип IPO

Material

IPO каналы (некоторые примеры, см. полный список в API документации)

R,G,B (рассеянный цвет)

Соответствующие объекты в Блендере

Любые объекты, использующие материалы


Тип IPO

Texture

IPO каналы (некоторые примеры, см. полный список в API документации)

Contrast (контрастность)

Соответствующие объекты в Блендере

Любые объекты, использующие текстуры, например: Меш, Лампа, Мир и др.


Тип IPO

Curve

IPO каналы (некоторые примеры, см. полный список в API документации)

Speed (скорость)

Соответствующие объекты в Блендере

Кривые (Curve)


Тип IPO

Lamp

IPO каналы (некоторые примеры, см. полный список в API документации)

Energ (энергия)

R,G,B (цвет)

Соответствующие объекты в Блендере

Лампы


Тип IPO

World

IPO каналы (некоторые примеры, см. полный список в API документации)

HorR,HorG,HorB (цвет горизонта)

Соответствующие объекты в Блендере

Мир (World)


Тип IPO

Constraint

IPO каналы (некоторые примеры, см. полный список в API документации)

Inf (влияние)

Соответствующие объекты в Блендере

Ограничения


Тип IPO

Sequence

IPO каналы (некоторые примеры, см. полный список в API документации)

Fac (фактор, например громкость звуковой дорожки) Обратитесь к API документации для Blender.IPO module за подробной информацией

Соответствующие объекты в Блендере

Последовательности


IPO-каналы и IPO-кривые

Кривые IPO, перечисленные в таблице, содержат целую коллекцию связанных между собой анимационных параметров. Каждый из этих параметров упоминается как канал. Примером канала IPO-объекта является 

LocX
(x-компонент местоположения) и 
RotY
(вращение вокруг оси Y). Каждый канал представлен объектом 
IPOCurve
, который реализует необходимую функциональность для возвращения значений, интерполированных между ключевыми кадрами анимации.

Примером канала в IPO материала (Material) является 

SpecB
– синий компонент зеркального цвета (specular color).

IPOCurve-объекты доступны как атрибуты приведенных в таблице IPO, например, 

myipo.LocX
обратится к 
LocX IPOCurve
, если 
myipo
будет IPO - объектом.

Чтобы проиллюстрировать эти понятия предположим, что мы хотим анимировать движение простого куба вдоль оси X. Мы начнем движение с 1 кадра и закончим его в кадре номер 25. В Блендере выполним следующие шаги:

1. Добавьте простой Куб, выбрав в меню Add | Mesh | Cube и удостоверьтесь, что Вы находитесь в объектном режиме (object mode).

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




3. Добавьте ключевой кадр, выбрав Object | Insert keyframe | Loc. В окне редактора IPO добавленный ключевой кадр расположения нашего куба в пространстве обнаружится как IPO типа Object (см. скриншот).




Текущий кадр отображается в виде зеленой вертикальной линии. Расположение IPO зафиксировано тремя каналами (для положения куба вдоль оси X - 

LocX
, вдоль осей Y и Z - 
LocY
и 
LocZ
соответственно). Каналы представлены в виде графиков различных цветов (они могут перекрывать друг на друга). Этими линиями можно управлять прямо в редакторе IPO Кривых, но пока мы только добавим второй ключевой кадр.

1. В окне Timeline выберите 25 кадр.

2. Выберите Куб и переместите его вправо вдоль оси X.

3. Добавьте второй ключевой кадр, выбрав Object | Insert keyframe | Loc (или просто нажав I - прим. пер.). Теперь мы видим что каждый из графов, представляющих три IPO-канала (направления по осям X, Y, Z) получили вторые точки-пересечения с зеленой линией. Поскольку мы изменили местоположение куба только вдоль оси X, графы других каналов остались плоскими, но линия канала 

LocX
изменилась вслед с изменением положения куба по оси X.




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


Ограничения

Ограничения в Блендере связаны с объектами Блендера верхнего уровня или Bone-объектами и представлены в виде объекта 

Constraint
. У Объектов Блендера и Bone-объектов есть атрибут 
constraint
, с помощью которого осуществляется последовательность ограничений. Также выше перечисленные объекты имеют методы, для добавления, удаления, и изменения ограничений в этой последовательности.

Когда ограничение связано с объектом, результатом будет объединение параметров ограничений и расчетных параметров объекта. Атрибут 

influence
(влияние) определяет, насколько сильно параметры ограничения будут влиять на объект анимации.


Различия между управляющими объектами (drivers) и ограничениями

Управляющие объекты и ограничения похожи тем, что они влияют на изменение свойств пути (речь идет о параметрах анимации — прим. пер.), но в тоже время они очень разные: ограничения действуют непосредственно на объекты, в то время как управляющие объекты определяют то, как IPO-кривая будет изменяться относительно изменений других IPO-кривых в процессе анимации. Ограничения влияют только на пространственные свойства объекта, такие как положение, масштаб или вращение, а с помощью управляющих объектов любой кривой IPO можно управлять с помощью другой кривой IPO. Это означает, что даже параметры материалов, такие как цвет, или параметр лампы, такой как энергия, может управляться другим IPO. Однако есть ограничение: IPO-кривые, управляющие другими IPO-кривыми должны в настоящее время обладать специальными свойствами объекта, таким образом, Вы можете управлять цветом материала, вращая некоторый объект, но Вы не можете изменить цвет объекта энергией лампы. Кроме того, факт, что ограничения могут затронуть только пространственные свойства, означают, что нет никакого способа, которым Вы можете ограничить, например, рассеянный цвет (diffuse color) материала. Следующая таблица показывает некоторые ограничения и их соответствующее атрибуты. Обратитесь к документации API по модулю 

Blender.Constraint
за подробной информацией.


Типы Ограничений

TrackTo

Стандартные атрибуты

Target (target object)

Track (axis to track)


Типы Ограничений

Floor

Стандартные атрибуты

Target (target object)


Типы Ограничений

StretchTo

Стандартные атрибуты

Target (target object)


Типы Ограничений

CopyLocation

Стандартные атрибуты

Copy (выбор компонента(тов) для копирования )


Заметьте, что возможно анимировать влияние ограничения (параметр influence), когда с Объектом связано IPO типа constraint.


Программирование ограничений

Блендер имеет много ограничений, которые Вы можете применить к объекту. Некоторые из них похожи на управляющие объекты (drivers), в том смысле, что они не ограничивают движение объекта, но могут копировать некоторые параметры, такие как вращение или расположение (location). С точки зрения разработчика, каждому объекту Блендера присущ атрибут 

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


Метод

append(type)

Действие

Добавляет новое ограничение к объекту и возвращает ограничение

Пример

ob.constraints.append( Constraint.Type.TRACKTO)


Метод

remove(constraint)

Действие

Удаляет ограничение с объекта

Пример

ob.constraints.remove( ob.constraints[0])


Метод

moveUp(constraint)

moveDown(constraint)

Действие

Изменят позицию ограничения в списке ограничений

Пример

ob.constraints.moveDown( ob.constraints[0])


Метод

[]

Действие

Доступ к атрибутам ограничений

Пример

Con = ob.constraints[0]

Con[Constraint.Settings. TARGET] = other


Новые Ограничения не становятся экземплярами объектов посредством конструктора, но посредством вызова метода 

append()
атрибута 
constraints
вместе с переданным ему типом ограничения. на выходе 
append()
мы получаем новое Ограничение, параметры настроек которого уже можно изменять.


Программирование кривых IPO

IPO-каналы управляются из скриптов так же, как и ограничения, но они по своей сути более разнообразны, чем ограничения, поскольку существует много различных типов IPO-каналов, и некоторые из них, особенно текстурные каналы и ключи формы, нуждаются в специальной обработке. Про них существует отдельная глава (Глава 6: Ключи формы, IPO, и Позы), но различные варианты использования Питона для IPO - каналов будут показаны ниже.


Управляющие объекты (PyDrivers)

Есть много случаев, где мы хотели бы изменять некоторые свойства, относительно других свойств анимируемых объектов, но не всегда возможно зафиксировать эти «взаимоотношения», управляя одним IPO-каналом через другой. Так происходит потому, что такое отношение не всегда оказывается простой линейной зависимостью, например, движение поршня управляется круговым движением. Другой случай когда отношение не постоянно, например, свет, включающийся только тогда, когда выключатель находится в определенном положении.

В этих случаях отношения между объектами могут быть определены Питон-выражением или так называемым 

pydriver
. Управляющий объект принимает IPO-канал другого объекта как входной параметр и возвращает результат, управляющий IPO-каналом на текущем объекте. Поскольку эти выражения на Питоне имеют доступ к полному API Блендера, взаимоотношения могут быть действительно очень сложными.


Ограничения на Питоне (PyConstraints)

Там, где управляющие объекты могут использоваться, чтобы обходить пределы встроенных возможностей Блендера по управлению IPO-каналами, PyConstraints позволяют нам преодолеть трудности в ситуациях, где встроенные ограничения не достаточны. Например, невозможно ограничить положение одного объекта на поверхности другого, если в нем есть отверстия. Встроенные ограничения предлагают способы ограничивать расположение объекта не ниже чем расположен другой объект (ограничение 

floor
). Но если мы хотели бы, чтобы была возможность изменять позицию объекта ниже поверхности другого объекта в местах, где есть отверстия, мы должны запрограммировать такое ограничение самостоятельно. Как мы увидим, PyConstraints позволяют нам сделать точно это.

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


Установка времени - один управляет всеми

Как использовать часы, если невозможно установить время удобным способом? Вместо перемещения каждой стрелки часов отдельно, мы хотели бы поворачивать единственную кнопку, чтобы перемещать обе стрелки — большую (минутную) и маленькую (часовую), причем (очевидно) часовая стрелка должна перемещаться в двенадцать раз медленнее минутной.

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

Чтобы настроить ведомые каналы, выполним шаги:

1. В окне 3D View, выберите объект 

bighand
(большая стрелка).

2. В окне редактора IPO-Кривых удостоверьтесь что выбран тип IPO – object. Справа вы увидите список IPO-каналов. Выберите RotZ, щелкнув на нем левой кнопкой мышки.




3. Выберите Curve | Transform Properties. В появившемся окне нажмите на кнопку Add Driver.




4. Не закрывая Transform Properties, выберите Curve | Insert 1:1 mapping и затем щелкните по Default one-to-one mapping. В редакторе IPO появится прямая светло-голубая линия.




5. В окне Transform Properties, нажмите на изображение светло-зеленого питона. Изображение станет темно-зеленым, и теперь возможно редактировать выражение pydriver в смежной текстовой области. Введите туда следующий код:

ob('Knob').RotZ*(360/(2*m.pi))/10

Вот и все! Теперь, если вращать кнопку вокруг оси Z, большая стрелка следует примеру. Все же pydriver-выражение действительно нуждается в некотором разъяснении. Выделенная часть является движком (driver) - канал объекта (object channel), обеспечивающий входные данные для управления IPO-каналом. 

ob('Knob')
является укороченной записью (стенографией), позволенной в pydriver-выражениях для Блендера. 
Object.Get('Knob')
и атрибут 
RotZ
дают нам вращение вокруг оси Z. Это вращение задано в радианах, тогда как результат pydriver-выражения для канала вращения (RotZ) должен быть в градусах, поэтому мы умножаем на 360 и делим на удвоенное число пи (m.pi = 3.14). Наконец, мы делим полученное число в градусах на десять, потому что по некоторой неясной причине, Блендер не принимает градусы, не поделенные на 10! (Заметьте, что это "делить на десять" действительно нужно только для каналов вращения по осям, но не для любого из других каналов!)

1-on-1 mappings

Вы можете задаться вопросом, почему мы должны были сначала вставить кривую 1:1. Отношение между ведомым каналом и его управляющим объектом содержит еще один слой и это - кривая, транслирующая значение на выходе управляющего объекта (pydriver) в финальное значение. Эту кривую можно изменять вручную, но обычно мы делаем всю точною настройку в нашем pydriver и просто вставляем кривую 1-к-1. Такой вариант работы настолько распространен, что Блендер обеспечивает специальный интерфейс для этой ситуации, так как весьма утомительно создавать необходимые кривые снова и снова для каждого управляемого канала.


Конечно, мы, возможно, достигли бы того же самого результата, ведя вращение напрямую через канал вращения объекта 

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

Часовая стрелка из примера, - вот где использование pydriver действительно является правильным решением. (Хотя, изменяя непосредственно IPO-кривую, мы могли бы изменить темп изменения управляющего канала, но это было бы не столь же ясно, как простое выражение, и почти невозможно для более сложных отношений между объектами). Мы повторяем список действий, показанных ранее, но теперь для маленькой (часовой) стрелки и введем следующее pydriver-выражение:

ob('Knob').RotZ*(360/(2*m.pi))/10/12

Поскольку часовая стрелка в двенадцать раз медленней, чем минутная, мы используем то же самое pydriver-выражение что и для минутной стрелки, но разделим результат на двенадцать. Теперь, когда мы вращаем объект 

knob
(кнопку) по ее оси Z, минутная стрелка будет следовать как и раньше, а часовая соответственно в 12 раз медленнее. Вместо того, чтобы вручную вращать кнопку, также возможно анимировать вращение кнопки, для анимации обеих стрелок часов. Полный результат доступен как 
clock-pydriver.blend
, изображение часов с кнопкой, показано на следующем скриншоте:




Сокращения

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

ob('')
— это обращение к объектам Блендера по имени, аналогично, возможно получить доступ к Меш-объектам и материалам посредством 
me('')
и 
ma('')
соответственно. Кроме того, модуль 
blender
доступен как 
b
, модуль 
Blender.Noise
как 
n
, и модуль Питона 
math
как 
m
. Он позволяет выражениям использовать тригонометрические функции, такие как синус, например. Этих возможностей достаточно, чтобы покрыть много проблем, но их все равно не хватит если мы захотим, например, импортировать внешние модули. Есть путь избежать этих трудностей, мы его увидим в следующем абзаце.


Преодоление ограничений: pydrivers.py

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

math
и к некоторым из модулей Блендера, с помощью сокращённых выражений, предоставленного места достаточно мало. Кроме того, поскольку pydrivers должны быть выражениями Питона, весьма трудно отлаживать их (например, потому что Вы не можете вставить функцию print) или добавить нечто похожее на функциональность 
if/then
. Последний пример до некоторой степени может быть преодолен хитрыми уловками, основанными на том факте, что Истина (
True
) и Ложь (
False
) в Питоне преобразуются в, соответственно, 1 и 0 внутри числового выражения, таким образом утверждение:

if a>b: 

   c=14 

else: 

   c=109

эквивалентно: 

c = (a>b)*14 + (a<=b)*109

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

pydrivers.py
. Если такой текстовый блок присутствует, его содержание доступно в виде модуля с именем p. Так, например, если мы определяем функцию 
clamp()
(зажим) в 
pydrivers.py
таким образом:

def clamp(a,low,high):

   if a

   if a>high: a=high

   return a

Мы можем вызвать эту функцию в нашем pydriver-выражении как 

p.clamp (a, 14,109).

Мы будем использовать 

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


Внутреннее сгорание — корреляция сложных изменений

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

Чтобы увидеть отношения между частями двигателя, будет полезно взглянуть на следующую иллюстрацию. На скриншоте перечислены названия, которые мы будем использовать, когда обратимся к различным частям мотора. (Я не автомобильный инженер и не механик, таким образом названия, возможно, не точны, но по крайней мере мы будем говорить об одних вещах. За дополнительной информацией Вы можете обратиться сюда http://en.wikipedia.org/wiki/Four-stroke_cycle.)




camshaft – распределительный вал

outlet valve – выпускной клапан

inlet valve – впускной клапан

cylinder – цилиндр

piston – поршень

connecting rod – шатун

drive shaft – ведущий или коленчатый вал


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

Ведущий вал просто будет следовать за вращением махового колеса, как более медленный механизм (это можно осуществить с помощью ограничения copy rotation объекта, но здесь мы всё хотим осуществить через pydrivers). Соответствующий pydrivers для канала 

RotX
будет похож на это:

ob('Flywheel').RotX/(2*m.pi)*36

Это может выглядеть неуклюжим, но необходимо помнить - вращения сохраняются в радианах, в то время как pydriver-выражения должны возвращать вращение в градусах, поделенных на 10.

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

m.degrees(ob('Flywheel').RotX*-0.5)/10.0

Чтобы проиллюстрировать, как получить доступ к функциям в математическом модуле Питона 

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

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

ob('DriveShaftPart').RotX/(2*m.pi)*18+9




Выражение для распределительного вала на выходе почти идентично за исключением времени запаздывания (здесь 24, но настройка этого двигателя не совсем соответствует реальной механике):

ob('DriveShaftPart').RotX/(2*m.pi)*18+24


Движение поршня ограничено только по вертикали, но его точное движение более сложно для вычисления. Нас интересует длина отрезка Q — смотрите предыдущий рисунок — и расстояние между центром ведущего вала и точкой, где шатун (L на диаграмме) соединяется с поршнем. Поскольку длина шатуна постоянна, изменение Q будет функцией от угла поворота α ведущего вала. Расстояние от центра ведущего вала, до точки, где шатун связан с ведущим валом, фиксировано. Мы назовем это расстояние R. Теперь у нас есть треугольник со сторонами Q, L, и R и известен угол α. Поскольку три из этих данных (L, R, и α) известны, мы можем вычислить Q, при использовании теоремы косинусов (http://ru.wikipedia.org/wiki/Теорема_косинусов). Поэтому мы определяем функцию 

q()
в файле 
pydrivers.py
, которая возвращает длину Q, при заданных L, R, и α:

 def q(l,r,a): return r*cos(a)+sqrt(l**2-(r*sin(a))**2)

Выражение для канала поршня 

LocZ
просто обращается к этой функции с соответствующими значениями аргументов:

p.q(1.542,0.655,ob('DriveShaftPart').RotX)

Точные значения для L и R были взяты из меша, используя координаты соответствующих вершин шатуна и ведущего вала в окне 

Transform Properties
. (кнопка N в окне 3D-вида)

Для самого шатуна можно использовать то же выражение для 

LocZ
-канала, но нужно так тщательно сделать соединение поршня и шатуна, чтобы они точно совпадали.

Однако, движение шатуна не ограничено только перемещением по оси Z, так как он вращается вокруг оси X с центром в точке, соединяющей шатун с поршнем. Угол вращения (γ на диаграмме) можно вывести из значений L, R, и α:

def topa(l,r,a):

   Q=q(l,r,a)

   ac=acos((Q**2+l**2-r**2)/(2*Q*l))

   if a%(2*pi)>pi : ac = -ac

   return -ac

Pydriver выражение для RotX будет выглядеть вот так:

m.degrees(p.topa(1.542,0.655,ob('DriveShaftPart').RotX))/1 0.0

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




Наконец, в 

pydrivers.py
мы определяем функцию 
spike()
, которая принимает угол поворота распределительного вала как аргумент и возвращает значение между 
0.0
и 
1.0
которое резко возрастает в районе нулевого угла:

def spike(angle):

   t = (cos(angle)+1.0)/2.0

   return t**4

Сейчас клапан движется линейно, но линия, по которой он следует, наклонена на 10 градусов (вперед для впускного клапана, назад для выпускного клапана), теперь нам придется управлять двумя каналами, LocZ и LocY, каждый нужно умножить на правильное значение для создания наклонного движения. Поэтому мы определим две функции в 

pydrivers.py
:

def valveZ(angle,tilt,travel,offset):

   return cos(radians(tilt))*spike(angle)*travel+offset

def valveY(angle,tilt,travel,offset):

   return sin(radians(tilt))*spike(angle)*travel+offset

Обе функции возвращают расстояние в зависимости от угла поворота управляющего объекта. 

Tilt
(наклон) - наклон клапана (в градусах), 
travel
— максимальная длина пути, по которому проходит клапан вдоль наклонной линии, а 
offset
(компенсация) - значение, которое позволяет регулировать позицию клапана. Соответствующие pydriver-выражения для 
LocZ
и 
LocY
-каналов впускного клапана:

p.valveZ(ob('CamInlet').RotX+m.pi,-10.0,-0.1,6.55)

и

p.valveY(ob('CamInlet').RotX+m.pi,-10.0,-0.1,-0.03)

(Выражения для выпускного клапана аналогичны, но с положительным углом 

tilt.
)

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

pydrivers.py
мы для начала определим вспомогательную функцию 
topi()
, которая, в качестве аргументов, кроме угла вращения движущегося объекта принимает угол 
h
(в радианах) и интенсивность 
i. topi()
возвращает эту интенсивность, если угол двигающегося объекта находится между 
0
и 
h
, и ноль, если угол выйдет за пределы этого ряда. Поскольку угол на входе функции, возможно больше, чем 2*pi (когда двигающийся объект пройдет больше чем полный круг), мы исправляем это выделенной операцией деления по модулю:

def topi(a,h,i): 

   m = a%(2*pi) 

   r=0.0 

   if m

   return r

pydriver-выражение для канала энергии (называемый "Energ" в редакторе Кривых IPO), может быть выражено следующим образом:

   p.topi(ob('DriveShaftPart').RotX/2+m.pi,0.3,0.5)

Как видно, это выражение запустит «огонь» в свече зажигания при первых 17 градусах (0.3 радиан), установив энергию для этого цикла в 0.5 .


Больше мощности — комбинирование нескольких цилиндров в двигателе

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

Но есть препятствие. Если мы используем Shift + D, вместо Alt + D мы получим одинаковые копии мешей объектов, вместо того чтобы просто воспользоваться ссылкой на первый объект. К тому же, мы ожидаем, что скопировали и остальные атрибуты объекта, такие как материалы, текстуры и IPO. Блендер, по-умолчанию, не дублирует вышеперечисленные категории, копируя только сам объект. Это получится неуклюже, так как изменение IPO первого поршня, к примеру, затронуло бы все остальные.

Мы могли бы сделать остальные копии уникальными впоследствии (нажав на поле количества пользователей этих кривых IPO, например, и подтвердив своё согласие со всплывающим вопросом make single user?), но было бы слишком утомительным повторять это для каждой копии отдельно.




Лучшим способом будет изменить настройки копирования объектов (Duplicate with object) в панели Edit Methods, как показано на скриншоте выше. Таким образом, кривые IPO, связанные с объектом, будут превращены в уникальные копии при дублировании объекта.

Результат нашей работы, четырехцилиндровый двигатель, передающий движение от ведущего вала к поршням доступен как engine001.blend. Изображение анимации доступной по адресу http://vimeo.com/7170769, показано на следующем скриншоте.




Добавление простых ограничений

Ограничения (Constraints) могут быть применены к объектам и костям. В обоих случаях ограничение добавляется вызовом метода 

append()
атрибута constraints. Наш следующий пример покажет, как мы можем ограничить движение стрелок часов из rigged clock (Глава 3, Группы вершин и материалы) для вращения вокруг оси 
Z
. Код, определяющий функции для достижения поставленной задачи начинается с двух определений 
import
, которые уменьшат длину кода:

from Blender.Constraint import Type 

from Blender.Constraint import Settings

Функция принимает два аргумента: 

obbones
, ссылка на объект Блендера, данные которого являются арматурой (то есть, не объект арматуры непосредственно) и 
bone
, название кости, которую мы будем ограничивать. Важно понимать, что ограничение, которое мы связываем с костью, является не свойством арматуры, а позой объекта, содержащего арматуру. Множество объектов могут обращаться к одной и той же арматуре, и все позы будут связаны с объектами, таким образом различные объекты, обращающиеся к той же самой арматуре, смогут принимать различные позы.

Итак, стартуя, функция сначала получает позу, а затем ссылку на кость, которую мы хотим ограничить. Выделенная строка показывает, как привязать ограничение (это аналогично тому, как если бы мы связывали ограничение с объектом Блендера вместо кости):

def zrotonly(obbones,bone):

   poseob = obbones.getPose()

   bigarmpose = poseob.bones[bone]

   c=bigarmpose.constraints.append(Type.LIMITROT)

   c[Settings.LIMIT]=Settings.LIMIT_XROT|

              Settings.LIMIT_YROT

   c[Settings.XMIN]=0.0

   c[Settings.XMAX]=0.0

   c[Settings.YMIN]=0.0

   c[Settings.YMAX]=0.0

   poseob.update()

Вновь присоединенное ограничение сохраняется в переменную 

c
и в последующих строках видно, что различные атрибуты ограничения, становятся доступны подобно словарю. Сначала мы настраиваем атрибут 
LIMIT
(это битовая маска), для ограничения вращения по осям 
X
и 
Y
. Далее, мы устанавливаем минимальное и максимальное значение вращения вокруг этих осей равным 
0.0
, таким образом мы останавливаем любое движение. Например, в риггинге реалистичного скелета животного этими значениями можно задать пределы величин вращения к значениям, сопоставимыми с реальными соединениями между костями. И в конце, чтобы сделать изменения pose (позы) видимыми, мы обращаемся к методу 
update()
.


Определяем сложные ограничения

Там, где pydrivers предоставляют нам возможность управлять изменением одной IPO-кривой посредством изменения другой, PyConstraints (питон-ограничения) предоставляют нам способы задавать пределы изменения свойств объекта.

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

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

#BPYCONSTRAINT

Ограничение на Питоне должно содержать три функции с именами 

doConstraint()
, 
doTarget()
, и 
getSettings()
. Первые двe вызываются в любое время, когда мы двигаем или цель, или ограничиваемый объект, а последняя функция вызывается тогда, когда пользователь щелкает по кнопке Options, которая появляется, как только пользователь выбрал pyconstraint. Следующий скриншот показывает окно Ограничений, как только был выбран pyconstraint.




Самый легкий путь понять, что эти функции делают — посмотреть встроенный шаблон ограничения, который мы можем использовать в качестве основы, чтобы написать наши собственные ограничения. Он доступен в текстовом редакторе по меню Text | Script Templates | Script Constraint. При выборе этого меню будет создан новый текстовый блок, который можно выбрать в выпадающем списке внизу окна текстового редактора.


Шаблон ограничения в Блендере

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

getSettings()
здесь будет почти пуст. Как показано, функции будут осуществлять функциональное ограничение, однако, ничего фактически не будет ограничено. Расположение, вращение, и масштаб ограничиваемого объекта останутся без изменений. 

def doConstraint(obmatrix, targetmatrices, idprop): 

   # Выделить компоненты преобразования для быстрого

   # доступа. 

   obloc = obmatrix.translationPart() # перемещение 

   obrot = obmatrix.toEuler()     # вращение 

   obsca = obmatrix.scalePart()    # масштабирование

   # код, который реально меняет положение, вращение и 

   # масштабирование, расположен здесь  

   # Конвертация обратно в матрицы положения, вращения,

   # масштаба, 

   mtxloc = Mathutils.TranslationMatrix(obloc) 

   mtxrot = obrot.toMatrix().resize4x4() 

   mtxsca = Mathutils.Matrix([obsca[0],0,0,0], 

[0,obsca[1],0,0],

        [0,0,obsca[2],0], [0,0,0,1]) 

   # Рекомбинация отдельных элементов в матрицу

   # преобразования.

   outputmatrix = mtxsca * mtxrot * mtxloc 

   # Возвращаем новую матрицу. 

   return outputmatrix

В функцию 

doConstraint()
передаётся матрица преобразований ограничиваемого объекта и список матриц преобразования для каждого целевого объекта. Она также получает словарь свойств ограничения, к которым можно получить доступ по имени.

Первая вещь, которую мы делаем, - выделяем отдельные компоненты матрицы преобразования — перемещение, вращение, и масштаб ограничиваемого объекта. Частью перемещения будет вектор положения 

x, y, z
, частью масштаба будет вектор масштабирующих коэффициентов вдоль осей 
x, y, z
. Часть вращения будет представлена вектором Эйлера с вращением вокруг трех основных осей. (углы Эйлера очень упрощают работу с вращениями в трехмерном пространстве, но по началу являются довольно трудными для понимания. В википедии есть материал на эту тему http://ru.wikipedia.org/wiki/Углы_Эйлера, но пока что легче думать о углах Эйлера как о вращении вокруг осей 
x, y, z
. Углы Эйлера трудны? Вот от кватернионов реально мозг взрывается! - возмущение пер.) Мы можем разделить любую матрицу преобразования целевого объекта так, как нам нужно, и затем изменить компоненты матрицы преобразования ограничиваемого объекта по своему усмотрению.

Функция, показанная здесь, не делает ничего, но преобразует различные компоненты преобразования обратно в матрицы, используя методы API (где это доступно), и затем рекомбинирует их, используя матричное умножение в единственную матрицу, которая впоследствии возвращается.

Функция 

doTarget()
вызывается до вызова 
doConstraint()
и даёт нам возможность манипулировать целевой матрицей прежде, чем она будет передана в 
doConstraint()
. Аргументы - целевой объект, под-цель (или Кость или группа вершин для целевой арматуры или меша соответственно), целевая матрица, и свойства ограничения. В следующем разделе мы используем эту возможность для сохранения ссылки на целевой объект в свойствах, чтобы 
doConstraint()
могла иметь доступ к этой информации. Если мы не хотим ничего изменять, то достаточно возвратить целевую матрицу, как показано в следующем коде:

def doTarget(target_object, subtarget_bone, target_matrix,

       id_properties_of_constraint): 

   return target_matrix

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

getSettings()
, может иметь просто оператор 
return
(возврат). Если мы хотим показать всплывающее меню, 
getSettings()
- то место, где это нужно сделать. Мы также увидим такой пример в следующем разделе. Следующий код будет корректной реализацией "ничегонеделания":

def getSettings(idprop): 

   return


Вы тоже находите меня притягательным?

Когда Луна и Земля вращаются вокруг друг друга, каждая из них чувствует гравитационное притяжение другой. На земле это приводит к приливам и отливам, но твердые тела Земли и Луны также исказятся, хотя этот эффект небольшой. Теперь известно намного больше о приливах и отливах, чем только притяжение (http://ru.wikipedia.org/wiki/Прилив_и_отлив), но мы можем показать гравитационные искажения в гипертрофированном виде с применением ограничений.

Один из способов сделать это - использовать ограничение 

TrackTo
, чтобы ориентировать ось нашего ограничиваемого объекта к притягивающему объекту и добавить второе ограничение, которое масштабирует ограничиваемый объект вдоль этой оси. Величина масштаба будет обратно зависима от расстояния между ограничиваемым объектом и целевым объектом. Эффект проиллюстрирован на следующем скриншоте, где эффект ограничения 
TrackTo
объединен со скриптовым ограничением 
moon_constraint.py
.




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

doTarget()
и 
getSettings()
как есть, но мы должны написать подходящую 
doConstraint()
(полный код доступен как 
moon_constraint.py
):

def doConstraint(obmatrix, targetmatrices, idprop): 

   obloc = obmatrix.translationPart() # Положение 

   obrot = obmatrix.toEuler()     # Вращение 

   obsca = obmatrix.scalePart()    # Масштаб


   tloc = targetmatrices[0].translationPart() 

   d = abs((obloc-tloc).length) 

   d = max(0.01,d) 

   f = 1.0+1.0/d 

   obsca[1]*=f 


   mtxloc = Mathutils.TranslationMatrix(obloc) 

   mtxrot = obrot.toMatrix().resize4x4() 

   mtxsca = Mathutils.Matrix([obsca[0],0,0,0], 

       [0,obsca[1],0,0],[0,0,obsca[2],0], [0,0,0,1]) 

   outputmatrix = mtxsca * mtxrot * mtxloc 

   return outputmatrix

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

В первой строке получаем позицию нашей цели. Затем мы вычисляем расстояние между ограничиваемым объектом и целью и определяем предел его минимума (чуть-чуть больше нуля), чтобы предотвратить деление на нуль в следующей выделенной строке. Используемая здесь формула отнюдь не является аппроксимацией какого-либо гравитационного влияния, но ведет себя достаточно хорошо для наших целей; коэффициент масштабирования будет близок к 1.0, если 

d
очень большое, и гладко возрастает при уменьшении расстояния 
d
. Последняя выделенная строка показывает, что мы изменяем масштаб только по оси y, то есть по оси, которую мы ориентируем на целевой объект с помощью ограничения 
TrackTo
.

Циклическая зависимость:

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

TrackTo
и 
moon_constraint.py
к обоим объектам, чтобы видеть эффект воздействия их друг на друга, но, к несчастью, это не будет работать, поскольку это создаст циклическую зависимость, и Блендер запротестует.


Привязка к вершинам меша

Это похоже на режим "snap to vertex" (привязка к вершине), который доступен в Блендере из меню Object | Transform | Snap (информацию о привязках смотрите тут: http://wiki.blender.org/index.php/Doc:Manual/Modelling/Meshes/Snap_to_ Mesh), за исключением того, что эффект не постоянный (объект вернётся в свою изначальную позицию, как только ограничение будет удалено) и силу ограничения можно регулировать (даже анимировать), изменяя движок Influence (Влияние).

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

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

Путь в обход этого препятствия - аргумент 

idprop
, который передаётся в 
doConstraint()
. Перед тем, как вызвать 
doConstraint()
, Блендер сначала вызывает 
doTarget()
для каждого целевого объекта. Эта функция передаётся в виде ссылки на целевой объект и в свойства ограничения. Это позволяет нам включать ссылку на целевой объект в эти свойства, и поскольку эти свойства передаются в 
doConstraint()
, это обеспечивает нас средствами для передачи необходимой информации в 
doConstraint()
для получения Меш-данных. Есть мелочь, которую мы всё-же рассмотрим здесь: свойствами в Блендере могут быть только числа или строки, так что мы не можем на самом деле хранить ссылку на объект, но должны удовольствоваться его именем. Поскольку имя является уникальным, и функция Блендера 
Object.Get()
предоставляет способ извлекать объект по имени, это - не проблема.

Код для функций 

doConstraint()
и 
doTarget()
будет выглядеть так (полный код находится в 
zoning_constraint.py
):

def doConstraint(obmatrix, targetmatrices, idprop): 

   obloc = obmatrix.translationPart().resize3D() 

   obrot = obmatrix.toEuler() 

   obsca = obmatrix.scalePart() 

   # Получаем целевой меш 

   to = Blender.Object.Get(idprop['target_object']) 

   me = to.getData(mesh=1) 

   # получаем местоположение целевого объекта

   tloc = targetmatrices[0].translationPart().resize3D() 


   # ищем ближайшую вершину на целевом объекте 

   smallest = 1000000.0 

   delta_ob=tloc-obloc 

   for v in me.verts: 

     d = (v.co+delta_ob).length 

     if d < smallest: 

       smallest=d 

       sv=v 

   obloc = sv.co + tloc 

   # восстанавливаем матрицу объекта

   mtxrot = obrot.toMatrix().resize4x4() 

   mtxloc = Mathutils.TranslationMatrix(obloc) 

   mtxsca = Mathutils.Matrix([obsca[0],0,0,0],

                [0,obsca[1],0,0], 

                [0,0,obsca[2],0],

                [0,0,0,1]) 

   outputmatrix = mtxsca * mtxrot * mtxloc 

   return outputmatrix 

def doTarget(target_object, subtarget_bone, target_matrix,

       id_prop_of_constr): 

  id_props_of_constr['target_object']=target_object.name 

  return target_matrix

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

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


Выравнивание вдоль вершинной нормали

Теперь, когда мы смогли привязать объект к ближайшей вершине в целевом меше, мы можем видеть, что что-то пропустили: объект не сориентирован в правильном направлении. Это не всегда является проблемой, например, деревья обычно направлены вверх, но во многих ситуациях было бы неплохо, если бы мы смогли сориентировать ограничиваемый объект перпендикулярно поверхности. Это делается также для всех практических целей, как ориентация ограничиваемого объекта вдоль вершинной нормали той вершины, к которой мы сделали привязку.

Следовательно, после обнаружения ближайшей вершины, мы определяем угол между вершинной нормалью и осью z (то есть, мы произвольно определяем направление Z как 'вверх'), затем вращаем ограничиваемый объект на тот же самый угол вокруг оси, перпендикулярной как вершинной нормали, так и оси z. Это сориентирует ограничиваемый объект вдоль этой вершинной нормали. Если ограничиваемый объект был вручную повёрнут до добавления ограничения, эти предыдущие вращения будут потеряны. Если это - не то, что нам нужно, мы можем применить все вращения перед добавлением ограничения.

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

zoning_constraint.py
уже содержит эти изменения): 
doConstraint()
должно вычислять поворотную часть матрицы преобразования. Мы должны вычислить угол вращения, ось вращения, и затем новую матрицу вращения. Выделенная часть следующего кода показывает, что основные инструменты для этих вычислений уже предусмотрены модулем 
Mathutils
:

vnormal = sv.no 

if idprop['NormalAlign'] : 

   zunit=Mathutils.Vector(0,0,1) 

   a=Mathutils.AngleBetweenVecs(vnormal,zunit) 

   rotaxis=zunit.cross(vnormal) 

   rotmatrix=Mathutils.RotationMatrix(a,4,"r",rotaxis) 

   mtxrot = rotmatrix 

else: 

   mtxrot = obrot.toMatrix().resize4x4()

В предыдущем коде мы можем видеть, что мы сделали выравнивание зависимым от свойства 

NormalAlign
. Только если оно задано, мы вычисляем необходимое преобразование. Следовательно, нам нужно адаптировать также функцию 
getSettings()
, поскольку пользователю нужен способ выбирать, нужно ему выравнивание или нет:

def getSettings(idprop): 

   if not idprop.has_key('NormalAlign'):

    idprop['NormalAlign'] = True


   align = Draw.Create(idprop['NormalAlign'])


   block = [] 

   block.append("Additional restrictions: ") 

   block.append(("Alignment: ",align,

          "Align along vertex normal")) 

   retval = Draw.PupBlock("Zoning Constraint", block) 

   if (retval): 

     idprop['NormalAlign']= align.val

Как показано, свойство 

NormalAlign
по умолчанию будет установлено в 
True
(Истина). Опция затем будет представлена как простое выпадающее меню с кнопкой-переключателем. Если пользователь щелкает за пределами меню или нажимает клавишу Esc, 
PupBlock()
вернёт значение None, мы не будем изменять свойство 
NormalAlign
. В противном случае, оно будет установлено в соответствии со значением кнопки-переключателя.

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




Если мы включим свойство 

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




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




Привязка к вершинам в вершинной группе

Что, если мы хотим определить конкретно те вершины, к которым мы можем привязать объект? Это можно достигнуть, определив группу вершин, и, затем, рассматривая только вершины из этой группы в качестве кандидатов, к которым можно привязывать. Код необходимый для этого, увеличится всего на несколько строк, и важная часть 

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

# получаем целевой меш 

to = Blender.Object.Get(idprop['target_object']) 

me = to.getData(mesh=1) 

# получаем положение целевого меша 

tloc = targetmatrices[0].translationPart().resize3D() 

# ищем ближайшую вершину в целевом объекте

smallest = 1000000.0 

delta_ob=tloc-obloc 

try: 

   verts = me.getVertsFromGroup(idprop['VertexGroup']) 

   for vi in verts: 

     d = (me.verts[vi].co+delta_ob).length 

     if d < smallest : 

       smallest = d 

       si = vi 

     obloc = me.verts[si].co+tloc 

     vnormal = me.verts[si].no 

except AttributeError: 

   for v in me.verts: 

     d = (v.co+delta_ob).length 

     if d < smallest: 

       smallest=d 

       sv=v 

   obloc = sv.co + tloc 

   vnormal = sv.no


Автор здесь нарушил одно из важнейших правил качественного программирования, которое гласит «Нет дублированию кода!» Текст после try желательно переписать, например, так:

try: 

   verts = me.getVertsFromGroup(idprop['VertexGroup']) 

except AttributeError: 

   verts = range(len(me.verts))

for vi in verts: 

   d = (me.verts[vi].co+delta_ob).length 

   if d < smallest : 

     smallest = d 

     si = vi 

   obloc = me.verts[si].co+tloc 

   vnormal = me.verts[si].no

–

Примечание занудного и наглого переводчика Striver'а


Конструкция 

try/except
гарантирует, что если свойство 
VertexGroup
ссылается на несуществующую группу вершин, мы получим шанс проверить все вершины. Конечно, нам теперь нужен способ для пользователя, позволяющий выбирать группу вершин, так что функцию 
getSettings()
нужно тоже адаптировать. Мы довольствуемся простым полем ввода строки, где можно набрать имя группы вершин. Нет проверки на существование группы, и если мы не хотим ограничиваться привязкой к группе вершин, тогда мы можем или оставить это поле ввода пустым, или занести имя несуществующей группы. Не слишком изящно, но это работает (дополнительные строки выделены):

def getSettings(idprop): 

   if not idprop.has_key('VertexGroup'):

    idprop['VertexGroup'] = 'Zone' 

   if not idprop.has_key('NormalAlign'):

    idprop['NormalAlign'] = True 

   vgroup = Draw.Create(idprop['VertexGroup']) 

   align = Draw.Create(idprop['NormalAlign']) 

   block = [] 

   block.append("Additional restrictions: ") 

   block.append(("Vertex Group: ",vgroup,0,30,"Vertex

          Group to restrict location to")) 

   block.append(("Alignment: ",align,

          "Align along vertex normal")) 

   retval = Draw.PupBlock("Zoning Constraint", block)


   if (retval): 

     idprop['VertexGroup']= vgroup.val 

     idprop['NormalAlign']= align.val

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



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

doConstraint()
, будет усреднённой позицией вершин в вершинной группе.


Итог

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

• Управлять одним IPO из другого посредством выражения на Питоне

• Обходить некоторые ограничения, присущие управляющим объектам

• Ограничивать движение объектов и костей, добавляя ограничения (constraints)

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

Затем мы взглянем на то, как выполнять некоторое действие всякий раз, когда мы передвигаемся по кадрам в нашей анимации.


ТЕЛЕГРАМ

Канал с обзорами, анонсами новинок и книжными подборками

Книжный Вестник

Бот для удобного поиска книг (если не нашлось на сайте)

Поиск книг

Персональные книжные рекомендации

Что почитать?

Свежие любовные романы в удобных форматах

Любовные романы

Детективы и триллеры, все новинки

Детективы

Фантастика и фэнтези, все новинки

Фантастика

Отборные классические книги

Классика
ВКОНТАКТЕ

Цитаты, афоризмы, стихи, книжные подборки, обсуждения и многое другое

Книжный Вестник
БИБЛИОТЕКИ

Библиотека с любовными романами, которая наверняка придётся по вкусу женской части аудитории

Любовные романы

Библиотека с фантастикой и фэнтези, а также смежных жанров

Фантастика

Самые популярные книги в формате фб2

Топ фб2 книги