To niesamowite, że po takim czasie odkąd prowadzę bloga, jeszcze nic nie napisałem na temat pracy z constraint w Autodesk Maya.
A temat jest bardzo ważny, bo znajomość tych narzędzi jest NIEZBĘDNA w codziennej pracy animatora. Dodatkowo ułatwia sporo rzeczy oraz przyspiesza nasz codzienny workflow.
No to co? Szybko nadrabiamy!
Constraints? Ale co to?
Tak, zacznijmy od podstaw. Constraints to zestaw narzędzi pozwalających na przekazanie (wymuszenie) translacji, rotacji, skali z jednego obiektu na drugi. Są one niezbędną częścią każdego riga z którym animator na co dzień pracuje. Między innymi dzięki constrainom kontrolki poruszają kośćmi.
Jednak to są sprawy typowo rigerskie. Zapytasz się – „ale panu animatoru, po co mi constrainy? Przecież ja nie riguję!” – a ja odpowiem: „ależ rigujesz!”.
Znajomość constrainów ułatwia nam (animatorom) codzienną pracę. Dzięki nim łatwo przypinamy pióro do dłoni albo czapkę do głowy.
Ok! To rozumiem! A jak ich używać?
Och! Bajecznie prosto!
Najpierw zaznaczamy obiekt, którym będziemy poruszać, wciskamy Shift i zaznaczamy obiekt, który będzie poruszany.
Zawsze podczas tej czynności w głowie mówię do siebie „TO będzie poruszać TYM„. Polecam!
Następnie z menu Constrain (dostępny w pasku animacji – F4) wybieramy Create -> I typ constrainta.
A jest trochę typów! Kanały w Channel box podświetlą się na niebiesko, gdy obiekt będzie miał aktywny (wpięty) constraint.
Ok, żeby się w tym wszystkim nie pogubić to krótko omówię jaki constraint do czego służy:
Parent Constraint
To najczęściej stosowany typ constrainta. Relatywnie przekazuje on translacje i rotacje. Przykład widoczny o scroll wyżej. Zupełnie jakbyśmy w hierarchii podpięli jeden obiekt do drugiego. Czyli też… „parentowanie”.
Tutaj na chwilę przycupnijmy i rozróżnijmy te dwie kwestie.
Parent constraint na twardo przekazuje atrybuty do kanałów translacji i rotacji (widoczne w channel box). Te wartości definiują położenie obiektu w world space. Po polsku: Majka wpisuje translate i rotate tak, aby obiekt zachowywał się jak „jeden duży obiekt” – czy też hierarchia obiektów.
Parent to po prostu właśnie ta wyżej wspomniana hierarchia. Poruszamy „rodzicem, a dzieci automatycznie idą za nim”. Bez modyfikowania atrybutów dzieci.
A uzyskamy to w podobny sposób. Znowu zaznaczamy obiekty i po prostu wciskamy P. Żeby „odparentować” obiekt to wciskamy Shift + P.
Zobaczcie na przykładzie.
Po lewej zwykła hierarchia. Położenie Cube jest definiowane przez rotacje na Sphere. Po prawej to samo, ale z informacją o położeniu Cube w world space.
Efekt mamy dokładnie taki sam! ALE!
W przypadku zwykłego Parent wszystko dzieje się pod maską. Cube nie otrzymuje żadnych wartości w translacjach i rotacjach. Channel editor jest wolny! Można poruszać Cube! Jednak cały czas będzie on zależny od rodzica – Sphere. Nie możemy poruszyć Sphere bez ruszania Cube.
W przypadku Parent Constraint nie możemy już w ogóle poruszyć Cube. Jest on przylutowany na stałe. No też na chłopski rozum – dziedziczy on informacje od Sphere, a my chcemy mu jeszcze dopychać wartości z kluczy animacyjnych? Kaman! No trochę za dużo.
Skoro działają (prawie!) tak samo, to gdzie jest haczyk? – zapytacie. No cóż.
Parent Constraint ma taką przewagę, że można go „odpiąć” w każdym momencie. Wystarczy przełączyć atrybut z nazwą obiektu sterującego z 1 na 0. Można też kliknąć prawym i postawić klucz. Wtedy możemy odpiąć lub podpiąć obiekt w dowolnym momencie. Np. odkładanie długopisu lub podnoszenie kulki. I właśnie do takich rzeczy najczęściej użyjemy parent constraint.
Point, Orient, Scale Constraint
Trzy typy – translacja, rotacja, skala – wrzuciłem do jednego wora. Przekazują wartości do wybranych kanałów bez zachowania niby relacji rodzic-dziecko. Wszystko dzieje się w object space – lokalnie.
Żeby łatwo rozróżnić – z lewej strony stworzyłem Parent Constraint. Tłumaczyłem wyżej. Z prawej zaś stworzyłem point, a potem orient constraint. Niby rezultat powinien być taki sam? Sprawdźmy:
Niezła jazda, nie? To jest właśnie różnica pomiędzy parent-child, a object space.
Maya po prostu „przepisuje” wartości z translate, rotate i scale (trochę olałem ten constraint powyżej). 1:1 odwzorowuje ruch.
Aim Constraint
Celowanie na obiekt. Dokładnie tyle. Najczęściej używamy przy kontrolkach oczu – gałki oczne „celują” w kontrolkę. Rzadko używam przy animacji. Najczęściej przy animacji kamery, gdy w ferworze walki nagle trzeba robić camera aim i przy tym nie tracić już ustalonego kadru. Takie przypadki raczej mogę na palcach policzyć.
Niemniej jednak dobrze jest o tym typie constrainta pamiętać. Nigdy nie wiadomo kiedy może się przydać.
Nie constraintuj tak szybko!
Zanim przypniesz jeden obiekt do drugiego poczekaj chwilę. Przemyśl to! Może warto wykonać jeden ekstra krok?
Stwórz mały rig. Zwykły nurbs Circle posłuży nam za kontrolkę. Dodajmy także grupę offsetową (do której będziemy podpinać coinstraint) oraz jeszcze jedną – dla porządku – trzymającą geometrię.
W ten sposób cały nasz animacyjny syf powstaje na kontrolce, a geometria pozostaje nieruszona… eee no w sensie atrybutów.
Dodatkowo możemy pod grupę SphereGeoGroup podpiąć np. scale constraint albo też coś animować. Kolejna warstwa chroni geometrię!
Że już nie wspomnę, że nie powinniśmy animować na geometrii!
Tutaj to tylko zaczepienie tematu. Stworzę oddzielny wpis poświęcony rigowaniu, a raczej tle co animator powinien wiedzieć.
Podsumowując
Pamiętam uczucie, gdy pierwszy raz odkryłem constrainty. Przestałem wreszcie „ręcznie” wciskać przedmiot w łapę postaci albo dłubać w hierarchii riga.
To tak niesamowicie ułatwiło życie! Teraz się z tego śmieję, bo to podstawa podstawowych podstaw!
Najważniejszą lekcją z tego wpisu niech będzie umiejętne techniczne zaplanowanie naszej pracy. Jak rozgryziemy problem? Jaki constraint wybierzemy? A co jeżeli przyjdą poprawki i będzie trzeba zmienić to i owo? Dalej będzie ok?
Warto znać constrainty i wiedzieć kiedy mogą nam przyjść z pomocą.