Русский
Русский
English
Статистика
Реклама

Компьютерная анимация

MAD (otoMAD) безумие или искусство?

04.12.2020 08:08:46 | Автор: admin

Интервью c авторами "The Glorious Octagon of Destiny", восьмиминутного ролика, на создание которого ушло почти два года. В производстве видео принимало участие около тридцати человек. Ролик является качественным образчиком otoMAD-культуры, набирающей мировую популярность.

Привет! Расскажи, что такое otoMAD? Какие особенности отличают этот жанр видео?

MMaker: "Я думаю, otoMAD, вероятно, может быть классифицирован как "ремиксовый" жанр видео, но самое большое отличие otoMAD от остальных ремиксов в том, что большая часть исходного контента (аудио и видео) не делается с нуля, а берётся из уже существующего.
Идея состоит в том, чтобы увидеть, насколько можно использовать оригинальный материал, чтобы сделать из него что-то креативное. Существует масса разных стилей otoMAD, и у каждого автора свой вкус, но в конце концов все они, как правило, имеют некие общие паттерны."

SafNine: "По моему мнению, особенностью жанра otoMAD является то, насколько креативными могут быть авторы, редактируя источники, чтобы создать красивую, гармоничную музыку и анимацию. Поскольку мы делаем это исключительно из энтузиазма, а не за деньги, мы можем быть настолько креативными, насколько захотим. Полная свобода творчества!"

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

В чем разница между MAD, otoMAD, YTPMV?

MMaker: "Выбор стилистики и регион происхождения в первую очередь (YTPMV - западные, а MAD - восточные), но это может вызывать споры, поскольку одно и то же видео может быть определено разными людьми как относящееся как к YTPMV, так и к otoMAD.
В основном, различия сводятся к выбору исходников, otoMAD, как правило, более акцентирован на визуальное содержание, тогда как YTPMV делает фокус на создании кавера на песню с меньшим вниманием к графике.
Коллаборация "The Glorious Octagon of Destiny" рассматривается сообществом как гибрид между otoMAD и YTPMV, поскольку Octagon основан на западных источниках. Но, поскольку коллаборация испытала сильное японское влияние в стилистическом плане, то, по моему мнению, большинство участников считают, что они сделали otoMAD, а не YTPMV.
Отличие между MAD и otoMAD - в стилистике аудио. В MAD, как правило, звук никак не редактируется, а просто подбирается визуальный ряд под существующий трек. В otoMAD же музыка ремиксуется."

SafNine: "MAD известен на Западе как AMV. Это аниме-сцены, отредактированные под музыку. OtoMAD отличается от MAD большей динамичностью, большим использованием монтажа, спецэффектов, а также редактированием музыки. Жанр otoMAD наиболее популярен в Восточной Азии, особенно в Японии, где он и возник. Даже если автор otoMAD не из Японии, то, как правило, он будет использовать источники, которые были впервые использованы в Японии, такие, как, например, музыка из серии игр Touhou Project или "Gachimuchi рестлинг-видео (NSFW!)".
OtoMAD возник на NicoNicoDouga, а YTPMV - на YouTube. Эти жанры схожи между собой, но otoMAD характеризуется использованием японского контента, а также, на мой взгляд, более качественным исполнением видео и аудио. "

Marlon: "На мой взгляд, otoMAD и YTPMV это одно и то же, хотя со мной могут поспорить, сказав, что эти жанры отличаются своими стилями. Возможно, раньше так и было, но за годы оба этих жанра испытали сильное взаимовлияние, и теперь между ними сложно провести чёткую границу. Основное отличие в том, что один из них появился в Японии, а другой - на Западе."

Я попытался определить признаки, по которым можно узнать видео в стиле otoMAD:
- набор часто используемых треков и/или ремиксов (
RED ZONE, Evans, саундтреки из популярных в Японии игр/франшиз: Touhou Project, Mario, Kirby, Undertale, и т.д.);
- важна синхронизация визуального ряда с битом фоновой музыки;
- набор часто используемых видеоисточников (аниме, японская реклама, и т.д.)
Так ли это?

MMaker: "Да, всё верно. Частым приёмом является стилизация видео под оригинальный клип фоновой музыки. Если играет "Dance Robot Dance", видео будет стилизовано под клип этого трека, а также стилизация/пародирование аниме-опенингов. Авторы также часто делают шутки/стилизации на основе других видеороликов, например, когда играет Big Blue, в середине визуальный ряд переключается (NSFW!) на Inmu (NSFW!), или когда играет RED ZONE, во время "хоровой части" видео делится пополам, причём в одной половине "играет" соло, в другой - бас. Иногда мы также упоминаем конкретное видео с целью выразить уважение автору."

SafNine: "Часто используемыми источниками являются Gachimuchi, "Улица Сезам: Джек Блэк объясняет восьмиугольник", реклама Old Spice c Терри Крюсом, "Кухонный ствол" (скетч из Шоу Питера Серафиновича), и т.д."

Marlon: "Да, люди склонны использовать знакомые/известные материалы, это касается как видео, так и аудио. Часто песня связана с каким-либо спецэффектом. Сообществу нравится переиспользовать оригинальный монтаж, придавая ему собственный вид или используя другой источник, отдавая таким образом дань уважения автору.
Что-то похожее есть и с видео-исходниками, с которыми тоже связаны определённые шутки. Посмотрев достаточно видео, вы начнёте их узнавать. Особенно популярные исходные видео формируют собственные направления otoMAD, например, Gachimuchi, Cookie, Inmu.
Мы любим следовать определенным трендам, но, я думаю, otoMAD больше определяется стилем редактирования. Есть много видео, в которых используются непонятные видео- и аудиоматериалы, но, я думаю, они всё ещё могут быть классифицированы как otoMAD."

Какова история otoMAD? Как ты узнал об этом и начал делать ролики?

MMaker: "Жанр otoMAD имеет длинную историю, но большая проблема в том, что она на японском языке. И даже на нём она, как правило, передаётся из уст в уста, как и история YTPMV. Сейчас мало кто занимается переводом, раньше у NicoNicoDouga была английская версия, но они отказались от неё из-за отсутствия интереса.
Впервые я увидел перезалитые на YouTube MAD несколько лет назад, но не разбирался в них до тех пор, пока не посмотрел несколько видео MowtenDoo, который с Запада и считает себя автором otoMAD. После этого я стал делать видео в стиле YTPMV, но сейчас больше сместился в стиль otoMAD."

Marlon: "Я слабо знаком с историей otoMAD. Я увлёкся этим много лет назад, когда смотрел YouTube в 2007-2008 годах, и видел там ранние YTPMV и перезалитые с NicoNicoDouga otoMAD. Сначала я увлекался YTP, но затем переключился на YTPMV.
Своё первое видео я смонтировал ещё в 2009 году , когда мне было 12 лет, и я совершенно не понимал, что делаю.
Но я продолжал делать ролики, и постепенно они становились лучше и лучше, а также знакомился с сообществом. За это время мой стиль изменился, и я стал больше интересоваться otoMAD примерно с 2015 года, в основном из-за интереса к Gachimuchi в то время."

Расскажи подробнее о производстве ролика "The Glorious Octagon of Destiny". Сколько времени это заняло, сколько человек участвовало? Насколько сложно сделать такое видео? Какое программное обеспечение использовалось?

MMaker: "Изначально мы планировали сделать это видео за 6 месяцев, но в итоге производство заняло 2 года. Так как мы занимаемся этим в свободное время, сроки премьеры могут откладываться.
Участвовало около трёх десятков человек, участники выбираются из тех, кого мы знаем, что они хороши в своём деле, талантливы, креативны, знакомы с исходником и т.д. Почти все участники знают друг друга годами. У нас не было какой-то "формы подачи заявки на участие" или типа того. Если вы монтируете ролики, вы, как правило, заводите связи с другими авторами, и таким образом попадаете в подобные коллаборации.
Софт может сильно различаться, но в основном мы используем REAPER для аудио и Adobe After Effects для визуальных эффектов. Многие создатели YTPMV используют Vegas как для аудио, так и для видео, а японцы обычно пользуются REAPER для аудио и AviUtl для визуальных эффектов.
Видео разбито на отрезки, на каждый назначается своя команда, обычно это два человека - один работает с видео, другой с аудио. Мы много общаемся, что гарантирует то, что конечный результат будет выглядеть органично и отрывки будут плавно переходить от одного к другому. А затем отрывки сводятся вместе. Этим я и занимался в том числе. Также я был главным организатором проекта."

SafNine: "Я работал над визуальной частью одного из отрывков. С момента, когда меня пригласили в 2018 году, и премьеры видео в 2019, я работал около года. Но, разумеется, это не был год непрерывной работы, поэтому у меня было время попробовать новый софт и идеи. Но наша коллаборация - особенный случай, так как это последнее видео в серии, обычно это не занимает столько времени."

Marlon: "Основная часть работы была сделана в последние несколько месяцев.
Сделать видео такого уровня довольно сложно, но большинство участников уже имели такой опыт.
Вот краткое описание производственного процесса:
- руководители проекта составляют список треков, на которые они хотят сделать видео;
- в сообществе ищутся добровольцы для участия;
- делается саундтрек (в нашем проекте его сделал NOMA);
- каждому назначаются роли (редактирование видео/аудио или всего вместе);
- убеждаемся в том, что у каждого есть план работы и помогаем друг другу, если необходимо;
- производство аудио сопровождается производством видео;
- затем всё собирается вместе.
Это большой труд, отнимающий много времени. Я был одним из руководителей проекта, помогал с такими вещами, как выбор музыки и назначение участников, а также немного помогал им, ещё редактировал несколько отрывков видео и аудио."

Что посоветуешь для начала ознакомления с otoMAD? Желательно что-то понятное для западного/европейского менталитета. SFW, конечно.

SafNine: "Для новичков я бы советовал сборники otoMAD, поскольку они содержат большое разнообразие, так как много участников создают для них визуальные и звуковые эффекты. Я бы порекомендовал эти, поскольку они хорошо сделаны и не содержат исходников NSFW:
- The Glorious Octagon of Destiny;
- Muscular Wonders - Terry Crews' Greatest Hits;
- Kitchen Gun - 3 Shots Of Derek Bum;
-CollaborationGabe Newell Birthday Extravaganza.
Начните с этих, а дальше всё сделают алгоритмы YouTube. Нужна хорошая акустика или наушники, иначе вы не оцените уровень качества обработки звука."

Что тебя вдохновляет при создании роликов?

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

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

MajorMilk: "Я художник, и рассматриваю видео как ещё один способ самовыражения."

Твоя работа связана с видео? Как ты этому научился?

MMaker: "Нет, моя работа с этим не связана, я сам учился редактировать. Я не проходил какого-то специального обучения".

SafNine: "Создание анимированной графики для меня - просто хобби. На создание своих otoMAD меня сподвигли другие видео в Интернете, поэтому я изучил Adobe After Effects.
Освоить софт проще, чем развить хорошее чувство стиля. Я думаю, что это верно как для создания видео, так и для аудио.
Изучая работы других людей и получая отзывы о своей работе, вы разовьете навыки, чтобы ваши визуальные и звуковые эффекты выглядели хорошо. Важно быть частью сообщества otoMAD/YTPMV, оно поможет."

Можно ли считать otoMAD видом искусства?

MMaker: "Я бы сказал, да, это ещё одна форма ремиксов, которые являются искусством. Но пока это скорее локальный японский феномен, где он пользуется наибольшей популярностью."

SafNine: "Да. Однажды я показал несколько otoMAD-видео другу и он назвал их постмодернистским искусством."

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

Нужно ли знать японский язык, чтобы понимать юмор/мемы в надписях/фразах?

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

MajorMilk: "Желательно иметь базовые знания. Например, уметь читать катакану/хирагану. Это улучшает восприятие, и, я думаю, это важно. Как смотреть фильм. Обычно у этих видео есть какой-то сюжет, связанный со способом создания звука, много предложений "пропевается" под музыку."

Есть ли примеры "русского otoMAD" или otoMAD с русскоязычными исходниками?

SafNine: "Есть авторы otoMAD из России, но они, как правило, пользуются общепринятыми (японскими) исходниками. А видео с исходниками на русском языке я почти не встречал, кроме что разве этого(на самом деле, украинское - прим. ред.) хотя, например, музыка из "Тетриса" является довольно популярной, в некоторых сборниках встречаются визуальные отсылки к России".

Подробнее..

Перевод Motion Path введение в современные анимации

07.07.2020 00:22:55 | Автор: admin


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


Для того чтобы выполнить подобные пожелания, актуальные для современного мира веб-разработки, CSS-модуль Motion Path Module Level 1 дает возможность использовать абсолютно новый вид анимаций и позволяет перемещать HTML-элементы по заданной траектории.


Поддержка браузерами


Начнем с неприятных моментов. Придется огорчить поклонников Safari (OS X и iOS) и Internet Explorer (если таковые остались): свойства модуля Motion Path пока не поддерживаются всеми браузерами.


Однако на момент написания данной статьи около 75% посетителей вашего сайта имеют возможность насладиться этой современной технологией.


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

Data on support for the css-motion-paths feature across the major browsers from caniuse.com

Свойства модуля Motion Path


При реализации анимаций задействуются три механизма:


  • определение траектории движения элемента (за это отвечает свойство offset-path),
  • определение положения элемента на траектории (свойство offset-distance)
  • и ориентация элемента во время движения (свойство offset-rotate).

offset-path


Это наиболее значимое свойство из перечисленных. Оно может принимать несколько значений: path(), ray(), url(), circle(), polygon(), inset(), и none.


На сегодняшний день большинство браузеров поддерживают только одно значение path(), поэтому в данной статье внимание будет сосредоточено именно на нем.

Синтаксис значений offset-path заимствован из языка разметки SVG. Поэтому чтобы освоить анимации, рассматриваемые в данной статье, нужны базовые знания SVG или опыт работы с редакторами векторной графики.


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


Вот пример квадратной траектории, по которой будет двигаться div.


div {  offset-path: path('M10 10 H 180 V 180 H 10 Z'); /* квадратная траектория */}   

Цель данной статьи не изучение SVG, а чтобы подробнее узнать об используемом здесь синтаксисе можно прочитать замечательный перевод статьи с СSS-Tricks на сайте la Cascade (перевод на русский прим. пер.) или подробное руководство на MDN.

offset-distance


Что касается свойства offset-distance, оно определяет положение элемента на заданной траектории. Его значение может быть выражено в любых стандартных единицах (пикселях, rem, процентах и т.д.). Свойство представляет особый интерес, когда требуется реализовать анимацию движения объекта по определенному пути.


div {  animation: move 1s; /* анимация "move" будет длиться 1s */}@keyframes move {  0% {     offset-distance: 0%; /* стартуем в начале траектории */  }  100% {     offset-distance: 100%; /* и прекращаем движение в конце траектории */  }}

Смотрите демо на CodePen:





offset-rotate


И наконец, третье свойство модуля, offset-rotate, определяющее ориентацию объекта на изогнутых участках пути.


Принимаемые значения:


  • auto (значение по умолчанию): ориентация объекта совпадает с направлением участка траектории, на котором он находится. Чаще всего требуется именно это значение.
  • reverse: объект также будет менять ориентацию в зависимости от направления, но при этом будет развернут на 180 вокруг своей оси, то есть все время будет двигаться задом наперед.
  • auto Xdeg (или reverse Xdeg): ориентация объекта будет отклоняться от кривой движения на угол X.

Смотрите демо:





Визуализация траектории


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


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


path() или пропал


Вспомним квадратную траекторию, по которой движется div:


div {  offset-path: path('M10 10 H 180 V 180 H 10 Z'); /* квадратная траектория */}

Наша задача в точности воспроизвести этот же путь в SVG, потому что только так он станет видимым.


В языке разметки SVG путь можно отрисовать с помощью элемента svg со вложенным path, который в свою очередь имеет атрибут d


Таким образом, в SVG у нас получается следующий код:


<svg ...>    <path d="M10 10 H 180 V 180 H 10 Z" fill="none" stroke="gray" /></svg>

Обратите внимание, что большинство значений атрибутов SVG меняются с помощью CSS, так что можно сократить код:


<svg class="svg-path" width="200" height="200" xmlns="http://personeltest.ru/away/www.w3.org/2000/svg">  <path d="M10 10 H 180 V 180 H 10 Z"></svg>

А в таблице стилей будет следующее:


.svg-path {  stroke: gray;  stroke-width: 4;  fill: none;}

Накладываем видимый путь на траекторию


На втором этапе необходимо спозиционировать относительно друг друга все необходимые элементы. А именно нам понадобится:


  • немного CSS-кода, чтобы отобразить путь с помощью path (это мы уже сделали),
  • объект, перемещающийся по своей траектории с помощью свойства offset-path (это тоже готово),
  • контейнер-обертка, относительно которого можно спозиционировать элементы с position: absolute.

А если конкретно, нам нужен следующий код:


<div class="motion-container">  <svg class="svg-path">    <path>  </svg>  <div class="motion-object"></div></div>

И, соответственно, такой CSS:


/* обертка для .svg-path */.motion-container {  position: relative;}.svg-path {  position: absolute;  left: 0;  top: 0;}




Усложняем анимации


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


Единственное, что вас может в этом ограничить, это ваше воображение. Ну и, конечно, желание рисовать SVG. C последним вам помогут различные SVG-редакторы. Например, значительно облегчить жизнь могут Sketch или Inkscape.


Также с этой задачей отлично справится онлайн SVG-редактор Method Draw.


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



Смотрите демо на CodePen:





И немного к вопросу о доступности веб-контента


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


Рассмотрим существующие подходы к данному вопросу.


  1. Согласно одному из стандартов RGAA 4 длительность анимации не должна превышать пяти секунд, либо необходимо предоставить возможность включить анимацию и поставить ее на паузу или развернуть/свернуть блок с контентом. В ином случае контент должен быть неподвижным. (По поводу стандартов WC3 по обеспечению доступности веб-контента см. следующий обзор и его перевод. Прим.пер.)
  2. Медиа-запрос prefers-reduce-motion позволяет учитывать предпочтения пользователей в вопросе анимаций, принимая в расчет индивидуальные настройки.

Несколько демо и заключение


Чтобы вызвать у вас желание поэкспериментировать с модулем Motion Path, я подготовил на CodePen подборку демо, которые у меня получились лучше всего:



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


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

Подробнее..

Наш 2020-й в видеороликах итоги года от Alconost Video

29.12.2020 18:11:47 | Автор: admin

Мы в Alconost Video выпустили около сотни видеороликов в 2020-м и хотим рассказать вам о проектах, которыми нам запомнился уходящий год. Заваривайте чай и давайте посмотрим ролики!

Итак, начнём с больших клиентов. В этом году мы сделали серию обучающих видео для одного из крупнейших Интернет-магазинов России Ozon. В ней мы рассказывали партнёрам платформы об основных её функциях и объясняли, как ими пользоваться. Вот для примера один из туториалов серии: Как начать продавать товар со своего склада.

Продолжаем делать ролики и для Kaspersky. Посмотрите, какой видеообзор мы сделали о продукте Kaspersky Small Office Security, защищающем каждый аспект цифровой жизни пользователя.

Трейлеры о приложениях и сервисах

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

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

Серия роликов-тизеров

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

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

Больше роликов об играх

Ролик об игре Story of Alcana: Match 3 длится всего 20 секунд, но за это время мы успели показать множество уровней на красочных локациях, сказочных персонажей и, конечно, сам геймплей.

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

А в красочном трейлере о Religion inc. показали, как преображается мир, когда люди творят чудеса.

Более подробный обзор роликов об играх за 2020-й в этой статье.

Больше видеопрезентаций

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

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

Или как в ролике о платформе Debexpert, предназначенной для ведения сделок по покупке и продаже долгов. Кстати, это видео мы ещё и локализовали на испанский.

Обновление роликов

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

В этом году у нас было несколько проектов такого типа. В видеопрезентации, посвящённой удалённому управлению устройствами SecureDrive BT и SecureUSB BT, мы продемонстрировали новый UI веб-портала.

А в ролике о плагине HelpDesk for Jira мы показали, каким информативным и наглядным стало отображение сроков работы над каждым запросом, отправленным в службу поддержки.

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

Короткие рекламные видео

Для продвижения в рекламных и социальных сетях иногда нужны простые ролики длительностью 5-15 секунд. В 2020-м мы сделали несколько коротких прероллов для наших собственных сервисов: отдела локализации Alconost и онлайн-службы профессионального перевода Nitro.

А для компании Cargo Air Chartering, которая занимается доставкой грузов по воздуху, сделали анимированный 3D-логотип.

Как делаются видеоролики: закулисье и лайфхаки

В этом году мы решили почаще делиться с вами опытом создания видео. У нас вышла дюжина лонгридов на эту тему.

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

Надеемся, что ролик о вашем приложении, сервисе или бренде попадёт в нашу статью с итогами за 2021-й :-) Обращайтесь, если надумаете сделать видео: будем рады помочь!

Об авторе

Статья написана вAlconost. Мы уже 8 лет создаём видеоролики: рекламные и обучающие, для игр и приложений, продуктов и компаний. Ещё мы занимаемсялокализацией приложений, игр и сервисов на 70+ языков.

Подробнее..

Разбор зачем нужны анимации на сайтах 7 полезных инструментов и библиотек для их создания

14.09.2020 20:08:14 | Автор: admin


Источник: Dribbble

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

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


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

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



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



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

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

Slides: фреймворк для создания анимаций без кода




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

  • панели
  • слайдеры
  • диалоговые окна
  • сайдбары
  • выпадающие меню
  • контактные формы
  • навигационные элементы
  • поп-апы
  • кнопки

Фреймворк позволяет создавать анимации с помощью HTML, CSS и JS вам нужно будет лишь скопировать сгенерированный код и внедрить его на сайт.

Express Animate: создание видео-анимаций




Этот инструмент позволяет генерировать анимации и специальные эффекты для видео. Затем эти видео можно встраивать на веб-страницы. Проекты можно экспортировать в формате HTML5, flash или GIF. С помощью этого инструмента можно создавать специальные элементы

Koolmoves: создание анимаций и перекодирование flash


Этот инструмент позволяет создавать HTML5-анимации для наложения эффектов на изображение, анимирования элементов навигации, создания слайд-шоу и т.п. Конечный результат можно экспортировать в HTML5, GIF, MP4/AVI. Также Koolmoves позволяет конвертировать flash-анимации в более современные форматы.

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

image

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

WAIT! Animate: создание пауз в CSS-анимациях




Этот инструмент решает конкретную задачу расчет идеальной паузы между завершением анимации и ее повторным стартом. CSS не дает простых способов сделать такую паузу, поэтому WAIT! Animate оказывается неожиданно полезным инструментом.

Granim.js: работа с градиентами в анимациях


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



iTyped: анимация текстов


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



Заключение


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

Знаете какие-то еще полезные инструменты для работы с анимациями в вебе? Оставляйте ссылки в комментариях.
Подробнее..

Из песочницы Разжимаем древний формат сжатия анимаций

13.07.2020 14:10:08 | Автор: admin
image

В один день я просматривал различные видео на YouTube, связанные с персонажами программы Vocaloid (не совсем точное описание, но дальше буду называть просто вокалоидами). Одним из таких видео было так называемое PV из игры Hatsune Miku: Project DIVA 2nd. А именно песня relations из The Idolmaster, которую исполняли вокалоиды Megurine Luka и Kagamine Rin. Оба персонажа от Crypton Future Media. Порыскав по сети я понял, что никто так и не смог сконвертировать анимации из этой игры? Но почему? Об этом под катом.

Сама игра использует Alchemy Engine, который разработала Intrinsic Graphics, а позже купила Vicarious Visions. Это можно увидеть по файлам, имеющим расширение ".igb" (далее IGB), а также соответствующим строкам в них. Сами файлы бинарные. Погуглив немного я нашёл скрипт от тов. minmode для известной в определённых кругах программы Noesis. Запускаем её, с перекинутым в папку скриптом, пытаемся открыть файл анимаций и Получаем тыкву.

image

Как объяснил тов. minmode в своём посте на DeviantArt, этот скрипт не может прочитать анимацию, сжатую некоей Enbaya. В Google Patents я смог найти только подобное. Самим патентам уже лет 19-20, поэтому я и предполагаю, что сам алгоритм сжатия тоже древний. Да и сам сайт на это тоже намекает (доступен только через веб-архив). Поискав ещё немного я понял, что этот алгоритм был в составе некоего ProGATE от компании Enbaya. Но это ничего нам не даёт.

Вернёмся же к IGB. Переписав код для IGB, который я смог найти, а также воспользовавшись скриптом для Noesis, на C#, картина начала проясняться.

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

Уточнение *List массив из элементов *

igAnimationDatabase--igSkeletonList---igSkeleton - Скелет, который, возможно, будет использоваться нами----igSkeletonBoneInfoList-----igSkeletonBoneInfo - Нода скелета--igAnimationList---igAnimation - Наша анимация----igAnimationBindingList-----igAnimationBinding - Ссылается на igSkeleton. Служит для линковки скелета к анимации----igAnimationTrackList-----igAnimationTrack - Сам трек анимации------igEnbayaTransformSource-------igEnbayaAnimationSource--------igData - Тут уже хранятся сырые данные EnbayaigData - Нода с данными, которые уже не являются нодами.

Таким образом я смог достать сырые данные для дальнейшего изучения. С помощью PPSSPP, Ghidra и плагина для неё я начал изучать бинарник игры. Я уже не особо помню как именно нашёл нужные функции, но приведу конкретные функции из EBOOT.BIT из ULJM05681 (в данном случае это не первая, а вторая, так называемая Bargain Version или же Project Diva 2nd#):

0x08A08050 инициализация функции декомпрессии на основе заголовка из igData
0x08A0876C запрос данных по конкретному времени (да. Enbaya работает со временем, не кадрами).

Сам код декомпилирован и выложен на GitLab. Написан он на Си. Компилируется как в Visual Studio, так и в gcc. Работает как в x86, так и в x64.

Я не стану углубляться в сам алгоритм. За меня лучше расскажет мой код.

Но если кратко, то Enbaya использует дельту для данных о перемещении и кватернионах. Дельту оно применяет, просто прибавляя/отнимая её к/от предыдущим/текущих данных. Перемещение остаётся как есть, а кватернион нормализуется для дальнейшего использования. Алгоритм позволяет вернуться назад во времени, не перезагружая файл. При этом он оперирует не частотой кадров, а семплами в секунду. Для этого он в памяти хранит два состояния предыдущий семпл и следующий, а движок сам интерполирует значение между ними. Однако в следствии того, что у нас данные в файле везде в целочисленном виде, мы должны их на что-то делить (точнее умножить. например на 0.0002), чтобы получить дробное число. Это число указывается в заголовке. Из-за этого деления (на самом деле умножения, но не суть) с каждым сложением и вычитанием точность немного уплывает.

А на этом всё. Честно говоря, мне было весело реверсить всё это. Надеюсь, что мои труды не прошли даром.

P.S. Используя данные igSkeleton мы уже можем получить готовую анимацию и экспортировать её, например в Maya. Через тот же Noesis.

Подробнее..

Перевод Javis v0.3 и анимация рядов Фурье

17.12.2020 22:12:36 | Автор: admin


Прошло уже достаточно времени с релиза Javis v0.2, что обсуждалось в соответствующем посте. Там я дал представление о потенциальном будущем этого графического пакета. Мы наконец-то выпустили v0.3, и будущее стало стандартом по умолчанию.


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


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


Этот блог в основном предназначен для читателей, которые интересуются Javis и Julia, поэтому я начну с изменений, которые появились в v0.3.


Изменения в v0.3


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



Что-то, к сожалению, не попало в v0.3, как например объединение объектов в слои, но работа идет полным ходом. Есть уже концептуальный план, осталось найти время, чтобы все закодить, попутно внося возможные изменения.
Еще было обещано поменять имена некоторых ключевых функций, так что надеюсь, что вы либо не использовали Javis v0.2, либо что вы адаптируетесь и довольны изменениями, которые мы провели.


Давайте просто перечислим некоторые из них:


Action и SubAction теперь называются соответственно Object и Action.
Это связано с тем, что Action раньше больше описывал сам объект и мог фактически перемещать его. Мы решили убрать такую возможность чтобы упростить кодовую базу и сделать различие гораздо более четким.


Далее мы упростили BackgroundAction до Background. Больше никаких комментариев по этому поводу


Наконец, мы удалили Translation, Rotation и Scaling и ввели anim_translate, anim_rotate/anim_rotate_around, а также anim_scale, потому что работа с функциями вместо структур кажется более естественной, и название указывает, что мы попутно делаем анимацию, а не статический перевод.


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


Теперь просто определяем видео, объекты и действия строка за строкой и, в конце концов, визуализируем видео:


using Javisfunction ground(args...)    background("black")    sethue("white")endvideo = Video(800, 400)Background(1:100, ground)ball = Object((args...)->circle(O, 100, :fill), Point(-500, 0))rolling = Action(anim_translate(Point(1000, 0)))act!(ball, rolling)render(video; pathname="rolling_ball.gif")


Думаю, код предельно прозрачен, кроме, может быть, нескольких причуд ...


Функция circle принимает центральную точку и радиус, а также действие (здесь :fill). Почему я определяю центр в центре? Я мог бы определить его в Point(-500, 0), но мне нравится думать о том, что объекты центрируются, а затем, перемещаются вокруг оси. Мне кажется, что здесь есть преимущество: объект легко и правильно масштабируется, а также это облегчает вращение.


На самом деле невозможно увидеть вращение круга (в настоящее время мы его не вращаем). Как насчет того, чтобы добавить что-то к кругу, чтобы мы могли различать вращается ли он?


using Javisfunction ground(args...)    background("black")    sethue("white")endfunction my_circle(args...)    circle(O, 100, :fill)    sethue("black")    line(O, Point(100, 0), :stroke)endvideo = Video(800, 400)Background(1:100, ground)ball = Object(my_circle, Point(-500, 0))translating = Action(anim_translate(Point(1000, 0)))rotating = Action(anim_rotate(0.0, 2*2))act!(ball, [translating, rotating])render(video; pathname="rolling_ball_2.gif")


Таки катится. Ладно, возможно, я немного отвлекся, но позже нам это пригодится.


Думаю, в v0.2 было бы довольно трудно сделать линию внутри круга с длиной зависящей от времени. На самом деле, это было возможно с v0.2.2, но я еще не писал об этом, так что это время перемен


using Javisfunction ground(args...)    background("black")    sethue("white")endfunction my_circle(args...; line_length=0)    circle(O, 100, :fill)    sethue("black")    setline(2)    line(O, Point(line_length, 0), :stroke)endvideo = Video(800, 400)Background(1:100, ground)ball = Object(my_circle, Point(-500, 0))translating = Action(anim_translate(Point(1000, 0)))rotating = Action(anim_rotate(0.0, 2*2))changing_len = Action(change(:line_length, 0 => 100))act!(ball, [translating, rotating, changing_len])render(video; pathname="rolling_ball_3.gif")


Теперь, наконец, можно просто изменять значения непосредственно анимированным способом. Вот мы вроде как и собрали строительные блоки для Фурье


Ряды Фурье


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


Как насчет ступенчатой функции?



Код
using Javis, Colorsfunction ground(args...)    background("black")    sethue("white")    translate(-args[1].width/2+50, 0)    scale(700, 150)endfunction wave(xs, ys, opacity, color)    setline(1.5)    setopacity(opacity)    sethue(color)    points = Vector{Point}(undef, length(xs))    for (x, y, i) in zip(xs, ys, 1:length(xs))        points[i] = Point(x, y)    end    prettypoly(points, :stroke, ()->())endfunction term(x, i)    return 4/ * sin.(2*(2i-1)*x)/(2i-1)endfunction sum_term(x, k)    k == 0 && return zeros(length(x))    return sum(term(x, i) for i in 1:k)endnframes = 300frames_per_wave = 40video = Video(800, 600)Background(1:nframes, ground)x = 0.0:0.001:1.0k = 6colors = [RGB(0.0, 1.0, 0.4), RGB(0, 1.0, 1.0), RGB(1.0, 0.25, 0.25), RGB(1.0, 1.0, 0.0), RGB(1.0, 0.5, 1.0), RGB(0.75, 0.75, 1.0)]waves = Object[]for i = 1:k    frames = frames_per_wave*(i-1)+1:nframes    push!(waves, Object(frames, (args...; y=term(x,i)) -> wave(x, y, 0.5, colors[i])))    act!(waves[end], Action(5:frames_per_wave,                    change(:y, term(x,i) => sum_term(x, i))))endsum_wave = Object(1:nframes, (args...; y=zeros(length(x)))->wave(x, y, 1.0, "white"))for i = 1:k    act!(sum_wave, Action(frames_per_wave*(i-1)+1:frames_per_wave*i,                         change(:y, sum_term(x, i-1) => sum_term(x, i))))endrender(video; pathname="images/fourier_1D.gif")

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


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


А теперь, бегом в 2D


На самом деле, хочется нарисовать что-то в 2D это гораздо интереснее. Кстати, вся эта идея использования Javis для визуализации рядов Фурье пришла от Риккардо Чиоффи, которого я люблю называть первым пользователем Javis. Он сам реализовал идею, без нашего ведома, пока мы не увидели его пост об этом на JuliaLang-дискурсе. Посмотрите, пожалуйста!


Имплементация была на предыдущей версии Javis, поэтому код больше не работает. Я подожду здесь пару минут, пока вы будете наслаждаться его потрясающей визуализацией.


Давайте начнем с некоторых строительных блоков, которые имеют смысл для понимания рядов Фурье в 2D. Я начну с кругов и комплексных чисел.


В общем, я пройдусь по тому материалу, который Грант Сандерсон прекрасно объяснил на своем YouTube-канале 3blue1brown Что такое ряды Фурье?. В конце этого поста есть еще несколько ссылок


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


$ e^{2\pi i t} $


где t наша переменная в диапазоне от 0 до 1, а i мнимая единица.


Таким образом, эта формула дает комплексное число для некоторого t. Мы можем его визуализировать, просто откладывая действительную компоненту нашего комплексного числа на оси x и комплексную компоненту на оси y.


В этой визуализации круг рисуется до определенной точки в каждом кадре и завершает круг с t=1.00



Картинку нужно попридержать в уме до конца поста.


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


Я думаю, что это лучше всего объяснить визуально, поэтому я покажу вам, чего мы пытаемся достичь, а затем покажу, как этого достичь.


Что мы хотим воссоздать


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



Код
using Javis, FFTW, FFTViewsfunction ground(args...)    background("black")    sethue("white")endfunction circ(; r = 10, vec = O, action = :stroke, color = "white")    sethue(color)    circle(O, r, action)    my_arrow(O, vec)    return vecendfunction my_arrow(start_pos, end_pos)    start_pos  end_pos && return end_pos    arrow(        start_pos,        end_pos;        linewidth = distance(start_pos, end_pos) / 100,        arrowheadlength = 7,    )    return end_posendfunction draw_line(    p1 = O,    p2 = O;    color = "white",    action = :stroke,    edge = "solid",    linewidth = 3,)    sethue(color)    setdash(edge)    setline(linewidth)    line(p1, p2, action)endfunction draw_path!(path, pos, color)    sethue(color)    push!(path, pos)    draw_line.(path[2:end], path[1:(end - 1)]; color = color)endfunction get_points(npoints, options)    Drawing()    shape = poly([Point(-200, 0), Point(250, 70), Point(165, -210)]; close=true)    points = [Javis.get_polypoint_at(shape, i / (npoints-1)) for i in 0:(npoints-1)]    return pointsendfunction poly_color(points, action; color=nothing)    color !== nothing && sethue(color)    poly(points, action)endc2p(c::Complex) = Point(real(c), imag(c))remap_idx(i::Int) = (-1)^i * floor(Int, i / 2)remap_inv(n::Int) = 2n * sign(n) - 1 * (n > 0)function animate_fourier(options)    npoints = options.npoints    nplay_frames = options.nplay_frames    nruns = options.nruns    nframes = nplay_frames + options.nend_frames    points = get_points(npoints, options)    npoints = length(points)    println("#points: $npoints")    # optain the fft result and scale    x = [p.x for p in points]    y = [p.y for p in points]    fs = fft(complex.(x, y)) |> FFTView    # normalize the points as fft doesn't normalize    fs ./= npoints    npoints = length(fs)    video = Video(options.width, options.height)    Background(1:nframes, ground)    Object((args...)->poly_color(points, :stroke; color="green"))    circles = Object[]    npoints = 5    for i in 1:npoints        ridx = remap_idx(i)        push!(circles, Object((args...) -> circ(; r = abs(fs[ridx]), vec = c2p(fs[ridx]))))        if i > 1            # translate to the tip of the vector of the previous circle            act!(circles[i], Action(1:1, anim_translate(circles[i - 1])))        end        ridx = remap_idx(i)        act!(circles[i], Action(1:nplay_frames, anim_rotate(0.0, ridx * 2 * nruns)))    end    trace_points = Point[]    Object(1:nframes, (args...) -> draw_path!(trace_points, pos(circles[end]), "red"))    render(video, pathname = options.filename)endfunction main()    gif_options = (        npoints = 1000, # rough number of points for the shape => number of circles        nplay_frames = 400, # number of frames for the animation of fourier        nruns = 2, # how often it's drawn        nend_frames = 0,  # number of frames in the end        width = 800,        height = 500,        shape_scale = 0.8, # scale factor for the logo        tsp_quality_factor = 40,        filename = "images/fourier_tri_5.gif",    )    animate_fourier(gif_options)endmain()

Здесь мы попытаемся нарисовать зеленый треугольник, используя пять кругов. Они аппроксимируют треугольник, как вы можете видеть, красной фигурой. У каждого круга имеется прикрепленный к нему вектор. Начнем с внутренней неподвижной окружности, где вектор фиксирован.


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


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


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

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


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


Как это посчитать


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


$ \sum_{k=-n}^n c_k e^{k\cdot 2\pi i t} $


Мы уже видели $e^{2\pi i t}$ раньше, так что k это единственная новая вещь в экспоненциальной части. Из анимации круга выше видно, что k в основном, просто определяет скорость, а знак k направление вращения.


Это означает, что у нас есть невращающийся круг с k=0 и вращающиеся круги с $k \in \{-1, 1, -2, 2\}$. Единственное, что осталось, это $c_k$.


$c_k$ определяет радиус круга, например, 2.5 или 0.5. Кроме того, они задают начальное вращение круга. Это показывается с помощью внутреннего вектора. Мы уже немного посмотрели на комплексные числа, и при определении $c_k$ как комплексного числа у нас есть необходимые два компонента, заданные абсолютным значением и углом комплексного числа.


Такое объяснение отлично от того, что Вы можете найти на других сайтах, поскольку есть разные способы выражения данной концепции. Моя версия эквивалентна тому, как Грант Сандерсон объяснил это в своем видео Что такое ряды Фурье?.

Давайте посмотрим на компоненты для n=1:


$ c_{-1} e^{-2\pi i t} + c_{0} e^{0\cdot 2\pi i t} + c_{1} e^{2\pi i t} $


что может быть упрощено с помощью $e^0 = 1$:


$ c_{-1} e^{-2\pi i t} + c_{0} + c_{1} e^{2\pi i t} $


Что произойдет, если мы возьмем среднее значение этого показателя, когда позволим t перейти от 0 к 1 и нарисуем полные круги?


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


Если мы усредним положения окружности, то получим центр, который находится в точке (0,0) для всех из них. Поэтому усреднение по всем возможным t между 0 и 1 (или, по крайней мере, хорошее подмножество всех возможностей хорошо, скажем, несколько сотен значений вместо бесконечного множества)
мы получаем $c_0$. Чудненько, да?


Давайте повторим это еще раз: мы усредняем по слагаемым, и поскольку все слагаемые, кроме $c_0$, являются кругами, они усредняются до $(0, 0)$ и не имеют отношения к делу.


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


Ну подождите, а как мы получим $c_{-1}$ и все остальные константы $c_k$?


На самом деле мы делаем точно то же самое и просто умножаем все уравнение на $e^{1\cdot 2\pi i t}$, чтобы получить сдвинутую версию. Помните, что $e^x \cdot e^y = e^{x+y}$ такое, что мы можем отменить показатель степени с помощью этого умножения. Умножая на $e^{1\cdot 2\pi i t}$, мы вычеркиваем компонент, который у нас есть для $k=-1$. Мы можем сделать то же самое для всех констант.


Давайте сделаем хорошую визуализацию для этого:



Немного сложно для восприятия, так что остановимся поподробней:


  1. Начнем с зеленого треугольника
  2. Выбираем 100 точек на этом треугольнике и усредняем его
  3. Создаем окружность с центром в начале координат и указываем на среднее значение с помощью вектора
  4. Умножаем треугольник на $e^{k \cdot 2\pi i t}$ с $k=-1$ и t зависящим от положения, в котором мы находимся на треугольнике.
  5. Создаем новые 100 точек и снова усредняем их
  6. Создаем новый круг
  7. Перемещаем вновь созданный круг на вершину предыдущего круга

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


Работать сподручней с пакетами


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


Есть два хороших пакета, которые я использовал в своей анимации треугольника Фурье показанном раньше:



Первый из них выполняет тяжелые вычисления, и делает это быстро, поэтому первая буква "F" в названии означает "быстрый".


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


FFTW создает вектор со всеми этими константами $c_k$, но FFTViews позволяет индексировать эту информацию более естественно, например так c[-3], даже несмотря на то, что Julia это язык, с индексацией начинающейся с единицы.


А потом вводится вектор точек как вектор комплексных чисел. Дополнительный шаг, который нужно выполнить, это усреднить результат, поскольку это не делается алгоритмом (вероятно, это будет один из способов сделать его быстрее )


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


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


The final animation




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


Короткая заметка:
Если вас интересует проблема коммивояжера или оптимизация в целом я настоятельно рекомендую проверить мои ранние посты:

Ладно вернемся к посту:


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


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


Выводы


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


  1. Основные изменения в Javis v0.3
  2. Рисование простых фигур и применение к ним действий
  3. Что можно сделать с рядами Фурье в 1D и 2D
  4. Формула и объяснение ряда Фурье
  5. Интуиция, как получить необходимые константы

Ссылки



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

Подробнее..

Лицевые анимации из двумерных видео

29.11.2020 04:09:36 | Автор: admin
КликбейтКликбейт

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

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

Введение

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

По моему маленьку расследованию, в настоящее время чуществуют следующие методы:

  • Создание маркеров на основе захвата движения по точкам или отметинам на лице исполнителя

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

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

    • Методы, использующие различные способы создания карты глубин, такие, как камеры Kinect или Intel Real Sense

  • Звуко-управляемые методы

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

  • Анимация по ключевым кадрам

    • Методы, использующие классический способ анимации, при котором различные части модели лица смещаются вручную

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

  1. Автоматизированность

  2. Отсутствие необходимости в использовании дорогостоящего оборудования

  3. Относительная точность передачи положения лица в пространства

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

Выборка

Чтобы собрать что-то дельное, необходимо составить математическую модель того, что мы собираемся делать. Ну или хотя бы понять, как вообще мы будем определять качество итогового результата? Поэтому

Благо лиц в интернете достаточно. Так что в качестве тестовых данных я выбрал четырёх популярных персонажей. Важное замечание: все видео сохранены в 2х различных форматах, имеют различные условия освещения.

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

Так выглядят три последовательных кадра и параметры, которые мы оцениваем на них. Данные собираются автоматически в процессе построения опорных точек. Основные параметры, которые я собрал включают в себя:

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

  • Ren - расстояние между правым глазом и носом, показывающее искажение правой скулы

  • Len - расстояние между левым глазом и носом, показывающее искажение левой скулы

  • Chin 1-8 - набор расстояний, состоящих из расстояний между левой и правой частью лица, показывающий общее искажение лица

Поговорим о том, что эти параметры собой представляют.

Параметр rele

Пусть (x,y,z) координаты центра левого и правого глаза вычисляются последовательно для каждого кадра по следующим формулам:

x = \frac{\sum_{i=m}^{n}{a_{i_0}+a} }{n+1}\\y = \frac{\sum_{i=m}^{n}{a_{i_1}+a} }{n+1}\\ z = \frac{\sum_{i=m}^{n}{a_{i_2}+a} }{n+1}

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

rele_i = \sqrt{(x_{left}-x_{right})^2+(y_{left}-y_{right})^2+(z_{left}-z_{right})^2}

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

rele = \frac{ \sum_{i=m}^{n}{\frac{rele_i}{rele_0}} }{a}

Значение rele показывает среднее изменение длины вектора AB - расстояния между центрами правого и левого глаза. Из чего можем провести следующую зависимость:

Чем меньше значение функции rele для видеофайла, тем меньше изменялись основные пропорции лица, а равно, тем (предположительно) лучше качество конечной анимации

Параметр len

Пусть (x,y,z) координаты центра левого глаза вычисляются последовательно для каждого кадра по следующим формулам:

x = \frac{\sum_{i=m}^{n}{a_{i_0}+a} }{n+1}\\y = \frac{\sum_{i=m}^{n}{a_{i_1}+a} }{n+1}\\ z = \frac{\sum_{i=m}^{n}{a_{i_2}+a} }{n+1}

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

len_i = \sqrt{(x_{left}-x_{nose})^2+(y_{left}-y_{nose})^2+(z_{left}-z_{nose})^2}

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

len = \frac{ \sum_{i=m}^{n}{\frac{len_i}{len_0}} }{a}

Значение len показывает среднее изменение длины вектора AB - расстояния между центром левого глаза и носом. Из чего можем провести следующую зависимость:

Чем меньше значение функции len для видеофайла, тем меньше изменялось расстояние между левым глазом и носом, а равно один из основных параметров лица, тем (предположительно) лучше качество конечной анимации

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

Список параметров chin0-chin7

Список параметров chin0 - chin7 показывает изменение длины вектора AB между каждыми двумя точками, относящимися к нижней дуги лица (точки 0-16).

Список значений chini хранит в себе длины векторов AB, где A-точка лежащая на левой полудуге, B-точка лежащая на правой полудуге соответственно, а равно, расстояние левой и правой стороной лица в точке i. Пусть каждое значение списка chini вычисляется по следующей формуле для каждого кадра:

chin_i = \sqrt{(x_{chin-left}-x_{chin-right})^2+(y_{chin-left}-y_{chin-right})^2+(z_{chin-left}-z_{chin-right})^2}

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

chin = \frac{ \sum_{i=m}^{n}{\frac{chin_i}{n}} }{a}

Значение chin показывает среднее изменение длины вектора AB - расстояния между двумя точками на левой и правой стороне нижней дуги лица. Из чего можем провести следующую зависимость:

Чем меньше значение функции chin{0-7} для видеофайла, тем меньше изменялось расстояние между двумя половинами лица, а равно один из основных параметров лица, тем (предположительно) лучше качество конечной анимации

Все эти метрики позволяют относительно точно отследить качество итоговой анимации не только по итогу, но ещё и покадрово как-то вот так:

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

Этапы формаирования косточек и анимацииЭтапы формаирования косточек и анимации

Результаты работы скрипта

Кошмар разКошмар раз
Кошмар дваКошмар два
Кошмар триКошмар триНормальная табличка сюда не влезла, наслаждайтесь 10/10 шакаловНормальная табличка сюда не влезла, наслаждайтесь 10/10 шакалов

Давайте подробнее рассмотрим "Кошмар три"

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

Ну и вот итог всего пути, который мы прошли. От точек в пространстве, до сносной анимации:

Подводим итоги

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

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

Подробнее..

Молекулярная биология и Houdini летом двадцатого

09.11.2020 14:21:24 | Автор: admin

Вот что получилось. А ниже история движения из точки А в точку B.

Ссылка на проект

1.


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

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

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


Мампап, а чего у вас в учебнике нет красивых фоток? Зачем эта бледность и уныние? Вы не можете увидеть красоту и не хотите, чтобы я её увидел? Ну ладно, я тогда пойду продавать машины или в архитекторы, они классные. Не буду учёным. Это скучно.
Мы считаем, что тебе достаточно текста и схем. И вот тебе ещё более точный текст и очень красивая схема.
Мампап, у вас немножко мир поменялся. Он теперь тоже весь в тексте и схемах.
Немедленно верни обратно! Немедленно!
Ладно. Схемы, тексты, а как это всё выглядит? Где фотки? Видосики?
Видишь ли, все эти атомы, вирусы, они настолько маленькие, что мы не можем их увидеть. Поэтому вот тебе схемы и текст.
Мампап, но ведь в кино все эти взрывы, бабахи и разбитые машины тоже нарисовано. Они же выглядят очень.
Да. Видишь ли, на это у нас есть бюджет.
А на меня?
Мороженое будешь?
Буду.

Грустная история. Правда? Мне грустно. Я считаю, что красивым, завораживающим можно сделать что угодно. А что это там такое красивое/загадочное/героичное/стильное/трогательное? Хочу подойти поближе и заниматься этим на всю жизнь.

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

Мой ответ да.

2.


И на этой волне летом 2020 года я в задумчивости рассматривал в своём любимом Houdini, как выглядят разные белки/протеины. Их я загрузил с сайта www.rcsb.org формат pdb, к моей радости, является нативным для Houdini.

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

1. Модели: Днк, шаперон и иммуноглобулин

И мне захотелось рассказать о них. Я не знал о них ничего. Никакого сценария у меня тоже не было.

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

А что рассказать, Алёха, ты же не молекулярный биолог? Да, я не молекулярный биолог. И я понял, что не хочу идти путём популяризатора науки, который своими словами рассказывает о чём-то, не имея образования в данной области. Я хочу быть научно достоверным. Точным. Что же делать?

Нужно найти консультанта по молекулярной биологии!

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

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

2. Второй релиз ролика. Три склеенных скриншота. Длительность аж целых 17 секунд...

И тут пришло понимание. Мы можем больше!

Антитело не само по себе существует. Это ответ иммунной системы на что-то. На что? Вирус! Иммуноглобулин же прикрепляется к вирусу! И тем самым мешает вирусу заразить клетку.

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

3. 4 релиз нашего ролика. ротавирус в окружении антител.

Вирус настоящий. Всамделишный. Называется ротавирус. Ротавирус, например, является частой Причиной диареи у детей. Вот, как он выглядит в базе. В его внешней оболочке порядка 6 000 000 атомов. И тут меня ждал неприятный сюрприз. Дело в том, что большие структуры хранятся в базе протеинов в другом формате - не pdb. Они хранятся в формате cif. Houdini не понимает этот формат. К счастью, он текстовый. Разобравшись в его логике я написал небольшой парсер, который вытаскивает из файла нужные мне данные. Размер файла модели ротавируса занимает порядка 600мб. Время на его сборку и отображение во вьпорте Houdini занимает две минуты.

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

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

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

4. 6 релиз нашего ролика. Зарождение эстетики.

Я раскрасил прилепившиеся антитела. И тут я увидел, что начинает появляться какая-то эстетика/стиль. Что микромир нужно рисовать красиво/вкусно, а не только научно достоверно. И что именно в этом месте возникает любопытство и желание изучать и заниматься молекулярной биологией. Из красивых схем и точных слов это желание не возникает. Особенно оно не возникает у школьника. Нужны именно красивые картинки. Плюс мы показываем вещи, как они выглядят. Такая возможность появилась очень недавно. И я говорю не о микроскопии, а о трёхмерном моделировании. Когда можно показать сам объект, но, что я считаю важнейшим взаимодействия объектов и показать событие из абсолютно любой точки для наблюдателя, хоть изнутри вируса, хоть из Солнца.

Думаю, что между точно и красиво нужны компромиссы. И двигаться можно, как в одну, так и в другую сторону.

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

Можно сделать разные диаметры у атомов, Основные элементы, из которых собран наш иммуноглобулин углерод, сера, водород, кислород и азот. Диаметры элементов различаются приблизительно в 4 раза. Это можно показать в одном месте, как факт, что атомы различаются. И мы это сделали в части ролика, где показывали иммуноглобулин без вируса. Но это же можно сделать и для всего ролика. Это будет честно. Но нужно ли? Или можно упростить?

Еще можно добавить цвета.Блики. Размытое отражение. Прозрачность. HDRI. Подповерхностное рассеивание света. Прямой свет. Тени. Затенение. Фактуру на сами атомы, типа царапин или сколов краски. Глубину резкости и моушн блюр. Вот так, пожалуй, выглядит список всех возможностей.

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

Оставил затенение. Это мягкий рассеянный свет. Как в пасмурную погоду. Он есть и на фотографиях клеток.

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

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

А вот от всего остального отказался. В силу своей малости атомы не могут быть в царапках или потёртостях. HDRI мы не увидим т. к. объекты чёрно-белые. Разные размеры атомов мы показали, на примере иммуноглобулина в начале ролика. После этого все шарики имели более-менее один диаметр. Прямой свет и тень возможен только на крупных структурах. Колониях бактерий, клетках. В случае с антителами и вирусами нет. Кстати, сама модель атома шарик тоже гм не совсем честна. Ведь, по сути, элемент ядро с облаком электронов на орбиталях. И на сферу это совсем непохоже.

Теперь, когда стало понятно, какие средства я могу использовать в работе, а от каких пришлось отказаться, я поработал ещё с материалами вируса и остановился вот на таком решении.

5. 10 релиз нашего ролика. Красные прикрепившиеся антитела. Голубые нет.

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

6. Ротавирус близко-близко. Видны атомы.

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

Я нахожу структуры белков/протеинов/вирусов/клеток очень красивыми вблизи. Когда они огромные, тогда их вещественность становится ощутимой. А что, если подойти поближе, а не пытаться увидеть всю структуру/иммуноглобулин целиком?

7. Фрагмент тяжёлых и лёгких цепей иммуноглобулина.

Мне нравится!

А теперь совместим ближний и дальний план с помощью полиэкрана. И оп!

8. Иммуноглобулин. Аминокислоты. Цвета рандомные.

Да! Теперь есть мелкие структуры, на которые мы можем полюбоваться вблизи и, одновременно, виден весь иммуноглобулин целиком. Такое решение я и оставил в ролике.

Пора было высаживать наш вирус на клетку. Но какую? Нам нужна была клетка, которую заражает именно наш вирус. И это клетка эпителия. На картинке серое море внизу поверхность клетки мембрана. Все модели в сцене в масштабе. Вирус приблизительно в 100-1000 раз меньше клетки.

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

9. Два вируса. Один прилепился к клетке эпителия. Второй, облепленный антителами, менее удачен.

Размытые голубые пятна антитела. Я добавил на рендере моушн блюр и глубину резкости. Рендер сделан в Mantra. Её неспешность мне хоть как-то позволили нивелировать 16 ядер от AMD.

И, когда осталось посчитать весь ролик, я очень сильно сомневался, что смогу за приемлемое время отрендерить 1920x1080. Поэтому я склонялся в пользу формата 1280х720. Но нет, тесты показали, что можно посчитать и 2к. В итоге время рендера кадра 2-20 минут. С честной глубиной резкости и моушн блюром. Отсчитать 1200 кадров заняло неделю.

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

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

IgA. IgD. IgE. IgM. Фагоциты. Агглютинация. Комплемент. Преципитация. Лизис. Аллергия. Апоптоз. Натуральные киллеры. Вакцина. В-лимфоциты. Аутоиммунное заболевание. Т-хелперы. Т-лимфоциты. Лимфоцит. Инфицированные клетки. Макрофаг. Т-клетки памяти. B-клетки памяти. Перфорация клеточной мембраны. Гуморальный иммунитет. Клеточный иммунитет. Нейтрофилы. Клетка. Эозинофилы. Базофилы. РНК. ДНК. Иммунные привилегии. Электронные орбитали. Фолдинг. Цитопатическое действие.

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

И самое главное. У нас нет звука. Да. Мы настолько сосредоточились на визуальном и на самой возможности сделать всё самим, что мысль о звуке нас даже не посещала. Уже сильно позже мы поняли, что звук, а, точнее, голос за кадром, очень и очень важен для понимания/упрощения, происходящего на экране.

Ссылка на проект

P.S.

Я отправил ролик двум разным учёным, мнение которых очень важно для меня. И в ответах каждого я увидел слово красота.

3.


Что дальше?

Нам нравится, что у нас получилось. Удалённая работа показала свою состоятельность при увлечённости и мотивации. И то, что мы с Валерией не знакомы очно, никогда друг-друга не видели, общались только в чате watsapp и живём в разных часовых поясах - не мешало нам работать. Наверное, очень большим причиной нашей радости и удовольствия от проекта было отсутствие ожиданий. У нас не было дедлайна, заказчика (им был я), сложных шотов. Рисовали мы ролик один месяц и к началу августа завершили. И я очень признателен Валерии Архиповой и тем людям, которые помогали с работой, консультировали меня по Houdini, высказывали своё мнение: Лёха Бумбурум, Дима Новосельцев, Игорь Харитонов, Саша Соколов, Дима Староверов, Стас Рыхликов, Константин Северинов, Йоха Колудар.

Я увидел, что мы можем делать достойнейшие ролики обладающие эстетической ценностью и научной достоверностью. И сейчас мы работаем над версией ролика со звуком. Я никогда раньше этого не делал.

И ещё мы делаем ролик по CRISPR-Cas9. В этом году за разработку метода редактирования генома Нобелевскую премию по Химии присуждена Дненифер Даудна и Эмманюэль Шарпантье. А это и есть CRISPR-Cas9. И вот вам скриншот из аниматика, над которым мы работаем.

10. Скриншот из аниматика по CRISPR-Cas9. Бактериофаг.
Подробнее..

Перевод Рендеринг острова из Моаны менее чем за 10 000 строк кода на Swift

18.01.2021 14:21:57 | Автор: admin
Остров из Моаны (2048 858 пикселей, 64 spp), отрендеренный при помощи Gonzales в хранилище Google Cloud с 8 виртуальными ЦП и 64 ГБ памяти примерно за 26 часов. Остров из Моаны (2048 858 пикселей, 64 spp), отрендеренный при помощи Gonzales в хранилище Google Cloud с 8 виртуальными ЦП и 64 ГБ памяти примерно за 26 часов. В памяти он занимает около 60 ГБ. Удаление шума при помощи OpenImageDenoise.Остров из Моаны (2048 858 пикселей, 64 spp), отрендеренный при помощи Gonzales в хранилище Google Cloud с 8 виртуальными ЦП и 64 ГБ памяти примерно за 26 часов. Остров из Моаны (2048 858 пикселей, 64 spp), отрендеренный при помощи Gonzales в хранилище Google Cloud с 8 виртуальными ЦП и 64 ГБ памяти примерно за 26 часов. В памяти он занимает около 60 ГБ. Удаление шума при помощи OpenImageDenoise.

После того, как Walt Disney Animation Studios выложила в сеть описание сцены острова из Моаны, много кто пытался его отрендерить своими силами, исключающими оригинальный Hyperion. Это лишь малая часть списка таких движков:

Андреас Вендледер из Бабельсбергского киноуниверситета представил другой, написанный им рендерер Gonzales. Он в значительной степени вдохновлен PBRT, написан на Swift (с несколькими строками кода на C ++ для вызова OpenEXR и Ptex) и оптимизирован для проведения рендеринга в (сравнительно) разумные сроки на бесплатном хранилище Google Cloud (8 виртуальных ЦП, 64 ГБ RAM). Насколько автору известно, это единственный рендерер, написанный не на C/C++, способный на рендеринг этой сцены. Написан он с помощью vi и командной строки Swift в Ubuntu Linux и Xcode на macOS, так что скомпилировать его на этих платформах не должно составить труда.

Так почему именно Swift?

Как пишет Вендледер, ему всегда было неудобно работать с заголовочными файлами и препроцессором на C и C++. Однажды объявив и определив что-либо (переменную, функцию), нет нужды делать это повторно. Кроме того, текстовое включение заголовочных файлов приносит с собой множество проблем, таких как необходимость добавления деталей реализации в эти самые файлы (на ум приходят, например, шаблоны) или медленное время компиляции ввиду многократного включения заголовков и вытекающего отсюда комбинаторного взрыва. Когда он начинал работать на C++, модули там еще не были доступны, поэтому он перепробовал написание кода на Python (слишком медленный), Go (слишком похож на C) и некоторых других языках программирования, но в конце концов остановился Rust и Swift. В результате предпочтение отдал Swift из-за его удобочитаемости (просто не нравились fn main и impl trait). Тем более, тот факт, что он был написан разработчиками LLVM и Clang, вселил уверенность, что он а) не будет заброшен в будущем и б) будет соответствовать поставленным целям по производительности. Короче говоря, был нужен скомпилированный язык без указателей, модулей, концепций, диапазонов, читаемых шаблонов, и нужен он был прямо сейчас. Кроме того, компиляторы были изобретены, чтобы облегчить жизнь программистам, сделав программы более читабельными, и порой, смотря на код, основанный на шаблонах, у автора складывалось ощущение, что мы движемся назад во времени. Все любят, когда их код легко читается.

Кое-какие заметки

Парсинг пережил несколько воплощений. Сначала то была простая строка (file.availableData, кодировка: .utf8), но она оказалась слишком велика, чтобы поместиться в памяти. Данные здесь не использовались по аналогичным причинам. В то же время еще и Scanner переехал из Foundation. В конце концов Вендледер остановился на чтении InputStream в 64-КБ массиве UnsafeMutablePointer <UInt8>.

Массивы всё. Короче говоря, никогда не используйте их при срочной необходимости. То есть, вообще не создавайте их. Это должно было быть ясно с самого начала, но урок был извлечен быстро, поскольку они всегда появлялись в верхней части анализа, выполненного с помощью perf. Для массивов фиксированного размера это можно преодолеть с помощью кортежей или внутреннего FixedArray в Swift. Даже если используется только массив, геттеры индекса, как правило, появляются в начале выполнения perf.

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

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

  • Valgrind Memcheck: показывает, куда пропала память. Например, анализ с помощью этого инструмента говорит о том, почему структура ускорения отделена от билдера этой структуры: память, потраченная на построение ограничивающей иерархии, просто никогда не освобождалась. Приятно не иметь указателей в Swift: никаких malloc или new и даже sharedpointers, но все же необходимо подумать о том, как используется память.

  • Профилирование с Xcode: в основном здесь использовались Time Profiler, Leaks и Allocations, которые дают примерно ту же информацию, что и Perf и Valgrind, но с другой точки зрения. Порой бывает полезно взглянуть на одно и то же с двух разных ракурсов. Это напоминает старые добрые времена, когда мы загружали наше ПО в три разных компилятора (Visual Studio, GCC и один из IRIX, как там его? MIPSPro?).

Хотя Swift позволяет легко писать читаемый и компактный код, вам все равно придется задуматься о низкоуровневых операциях, таких как выделение памяти и тому подобное. Сам автор часто переключался между структурами и классами, чтобы посмотреть, как это повлияет на память и производительность. Отсутствие указателей, new и shared_pointers приятно тем, что большую часть времени можно просто переключаться между уже упомянутыми структурами и классами, не меняя ничего в системе.

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

О программировании на основе протоколов: текущая версия Gonzales показывает 23 протокола, 57 структур, 47 заключительных классов и 2 незавершенных класса. Наследование здесь почти не используется. Два оставшихся незавершенных класса это TrowbridgeReitzDistribution и Texture: оба они самому Вендледеру не нравятся, и он думает о том, как изменить их в будущем. В целом программирование на основе протоколов приводит к хорошему коду: например, раньше в Gonzalez был класс Primitive, такой как в PBRT, но вскоре он изменился на протокол, унаследованный от таких протоколов, как Boundable, Intersectable, Emitting (его уже нет) и других. Теперь и его тоже нет: BoundingHierarchyBuild просто зависит от экзистенциального типа Boundable и возвращает иерархию Intersectables, которую использует BoundingHierarchy. Все примитивы теперь хранятся как массив экзистенциальных типов, состоящий из композиции протоколов Boundable и Intersectable (var primitives = Boundable&Intersectable).

С другой стороны, примитивы в BoundingHierarchy хранятся как [AnyObject&Intersectable]. На это есть две причины:

1. Тут требуются только пересечения;

2. AnyObject заставляет хранимые объекты быть ссылочными типами (или классами), что экономит память, поскольку макет протоколов как для структур, так и для классов (OpaqueExistentialContainer) использует 40 байтов ведь Swift пытается хранить встроенные структуры, тогда как протоколы только для классов (ClassExistentialContainer) используют всего 16 байт, ведь там должен храниться только указатель, как это можно увидеть в документации Swift или проверить здесь. Стоит подчеркнуть, что это не только академическое обсуждение: автор столкнулся с этим лично, ведь оно обнаружилось во время его работы в верхней части запуска проверки памяти.

Одна из причин, по которой вы можете отрендерить этот остров менее чем за 10 000 строк возможность писать компактный код на Swift. Один из таких примеров списки параметров. В PBRT вы можете прикреплять произвольные параметры к объектам, что приводит к примерно 1000 строкам кода в paramset.[h|cpp]. В Swift вы можете добиться того же примерно за три строчки:

protocol Parameter {}

extension Array: Parameter {}

typealias ParameterDictionary = Dictionary<String, Parameter>

На самом деле, это, конечно, не совсем так, но вы поняли суть. (Кроме того, скорее всего, это изменилось бы в PBRT-v4.)

О взаимодействии C ++ для поддержки Ptex и OpenEXR: Интегрирование с C ++ для Swift уже на подходе, но оно было недоступно, когда автор только начинал со всем этим заниматься, и все еще не доступно на данный момент. Поскольку он использует OpenEXR и Ptex только для чтения текстур и записи изображений, он прибег еще к extern "C". Одна карта модулей и несколько строк кода на C ++ (100 для Ptex, 82 для OpenEXR) и вас уже есть поддержка чтения и записи изображений OpenEXR и текстур Ptex.

Этот код публикуется сейчас потому, что получилось добиться его работы на Google Compute Engine с 8 виртуальными ЦП и 64 ГБ памяти, бесплатной в течение трех месяцев, поэтому, пожалуйста, загрузите код и получите учетную запись, чтобы запустить его. Тем не менее, предстоит еще многое сделать, поскольку сейчас он оптимизирован только для получения одного изображения. Ниже приводится большой список задач, отсортированный от легко реализуемых до крупных проектов, за которые автор мог бы или не мог бы взяться в будущем.

Список дел

  • Дифференциалы лучей прямого освещения. Это должно быть относительно просто. Посмотреть, как это делает PBRT-v3, реализовать дифференциальную генерацию в камере, прокачать ее через систему и использовать в вызове Ptex. Там все это обрабатывается автоматически.

  • Лучшие иерархии: в Gonzalez реализована только простейшая ограничивающая иерархия, что приятно, поскольку она занимает всего 177 строк кода, но в то же время это приводит к не оптимальному времени рендеринга. Оптимизированные иерархии SAH должны быть намного лучше в этом плане. Их также не должно быть сложно реализовать.

  • Ускоренный парсинг: нужно встроить быстрый синтаксический анализатор pbrt Инго Вальда, который анализировал бы Моану за секунды, а не за полчаса. Или даже лучше: написать самому парсер для формата pbf на Swift.

  • Ускоренное создание иерархии: сейчас оно происходит медленнее, чем хотелось бы. Что с этим можно сделать?

  • Идея об ускоренном парсинге, генерации иерархии и форматах сцены. LLVM имеет три различных формата битового кода: in-memory, machine readable (двоичный) и human readable, и он может без потерь преобразовывать их между собой. Может ли у нас происходить то же самое? Подобно PBRT (читаемому человеком), PBF или USD (машиночитаемому) и BHF (формату двоичной иерархии), где ограничивающие иерархии уже созданы и могут быть просто отображены в памяти.

  • Задачка начального уровня: сам автор пытался отрендерить только Моану, но должно оказаться довольно легко улучшить Gonzales так, чтобы он мог рендерить другие сцены, добавляя функции или исправляя ошибки. Существует множество сцен, на которых можно потренироваться. Также есть много экспортеров для PBRT, которые должны работать и для Gonzales.

  • Bump mapping: должно оказаться довольно просто.

  • Displacement mapping: не так просто.

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

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

  • Шумоподавление: сейчас используется OpenImageDenoise, но, конечно, было бы неплохо иметь встроенный шумоподавитель в Swift. Кроме того, beauty, albedo и normal image сейчас пишутся отдельно, и это нужно переделать.

  • USD: написать парсер для Universal Scene Description Pixar.

  • Лучший сэмплинг: использовать discrepany-based sampling или multi-jittered sampling.

  • Трассировка пути: изучить PxrUnified и реализовать управляемую трассировку пути (автор уже смотрел ее, но выглядит она запутанно) и Manifold Next Event Estimation. Кажется, где-то была такая реализация, но уже забыл, где. (Эх, если бы только Weta последовала примеру Диснея и опубликовала голову Гэндальфа из той статьи!)

  • Подповерхностное рассеяние. Уже в PBRT.

  • Ускоренный рендеринг: у Embree есть трассировщик пути. Изучить его внимательно и постараться сделать Gonzales быстрее.

  • Рендеринг на ГП: достаточно объемная задача, и PBRT-v4, очевидно, делает это так же, как некоторые из упомянутых выше рендереров. Возможно, стоит просто сделать так же, как они, и использовать Optix для рендеринга на видеокарте, но лучше бы найти решение, не использующее закрытый исходный код. Это означало бы, что вам нужно реализовать свой собственный Optix. Но если посмотреть на то, как развиваются ГП и ЦП, в далеком будущем вполне возможно использовать один и тот же (Swift) код на них обоих; у вас могут быть экземпляры с 448 ЦП в облаке, а новейшие графические процессоры имеют несколько тысяч микро-ЦП, и они выглядят все более и более одинаково. Интересно, понадобится ли программирование для AVX в будущем, поскольку сейчас оно кажется все менее необходимым, ведь вы можете просто добавить больше ядер для решения проблемы. В то же время память становится все больше и больше похожей на NUMA, так что расположение ваших данных рядом с ALU становится все более важным. Может быть, однажды у нас появятся узлы рендеринга в облаке, каждый из которых будет отвечать за свою часть сцены: геометрически разбивать эту сцену и отправлять только части ее в ЦП. Затем возвращенные пересечения можно было бы просто отсортировать по значению t луча, что напоминает архитектуры сортировки по первому/среднему/последнему, такие как Chromium.

На этом пока все. Автор был бы очень рад получить комментарии о том, что можно было бы сделать лучше или более элегантно, отчеты об ошибках или даже пулл-реквесты. Также спасибо Мэтту Фарру и PBRT наиболее ценному ресурсу в известной вселенной (по крайней мере, касательно рендеринга)

Подробнее..

Программа для physics-based анимации персонажей Cascadeur вышла в ранний доступ

14.04.2021 20:10:55 | Автор: admin


Спустя 10 лет разработки и 2 года бета-тестирования Cascadeur, программа для создания физически корректной персонажной анимации, вышел в ранний доступ! Пользователям доступны 4 варианта подписки, один из которых совершенно бесплатный.

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


Данный релиз является итогом двухлетнего бета-тестирования, в котором приняли участие более 70.000 человек из индустрии по созданию компьютерной графики и визуальных эффектов. Однако на этом разработка Cascadeur не заканчивается.

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



Скачать программу можно на официальном сайте проекта cascadeur.com/ru. Здесь же вы найдете все необходимые материалы для того, чтобы начать анимировать прямо сейчас.

Узнать о Cascadeur больше:

Вложенность нейросетей инструмента автопозинга в Cascadeur
Почему 12 принципов Диснея недостаточно
Cascadeur: будущее игровой анимации
Подробнее..

Молекулярная биология. Houdini. NVIDIA 3080. Коронавирус vs иммуноглобулины

01.05.2021 14:19:19 | Автор: admin

Ссылка на наш ролик

Это мой второй текст на Хабре. Он плавно вырос из первой статьи Молекулярная биология и Houdini летом двадцатого.

Мы закончили наш новый (второй) ролик 12 апреля 2021 года, в День космонавтики. Дата получилась случайной я очень хотел закончить работу в понедельник. Но это оказалось идеальное совпадение.

Поехали!

Вот приблизительный диалог, который состоялся у нас с Валерией (молекулярный биолог) на старте проекта:

А давайте сделаем английскую озвучку к нашему ролику про иммуноглобулин?

А давайте.

И заменим ротавирус на коронавирус. Они же очень похожи.

Да.

Часть сцен нам даже не нужно будет переделывать.

Да.

И перейдём с CPU-рендера на GPU. Откажемся от Blender в пользу DaVinci Resolve. Тайминг у нас останется тот же одна минута. Звук и вирус. Думаю, за пару месяцев мы всё закончим.

Ага, наверное.

Мы делали ролик 5 (пять) месяцев. Я мог работать по 2 часа в день с 12 до 2 ночи и не каждый день. Длительность ролика увеличилась в 3.5 раза. Увеличение сложности проекта (по сравнению с первым нашим роликом) моим внутренним ОщущаторомСложности оценивается, как шестикратная.

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

За разных людей у нас был я.

Какие это фрагменты? Сториборд. Переход с Mantra (внутренний CPU-рендер Houdini) на RedShift (GPU-рендер, приобретается отдельно). Решение задачек средствами Houdini (обожаю эту часть). Рендер. Цветовое решение. Озвучка. Музыка и звуки. Монтаж в Resolve (к счастью, есть free-версия).

Я разобью повествование на разрозненные части. Хотя это, на самом деле, конечно, суп где всё влияет на всё. И мы постоянно перемещались от одного к другому, постепенно меняясь.

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

Раскадровка (сториборд)

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

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

Сториборд. Вирус прикрепляется к клеточному рецептору АСЕ2.Сториборд. Вирус прикрепляется к клеточному рецептору АСЕ2.Сториборд. Серые круги клетки. Чёрные вирусы. Белые иммуноглобулины или антитела.Сториборд. Серые круги клетки. Чёрные вирусы. Белые иммуноглобулины или антитела.

Работа

Я за лёгкость. За юмор. За улыбку. Поэтому мне очень симпатичны Фейнман, Сапольски и Северинов. Одновременно с этим я понимаю, что я не могу с хохотом заниматься молекулярной биологией потому что я некомпетентен в этом (в молекулярной биологии). Для этого я делегирую ответственность в принятии решений молекулярному биологу. Я также не компетентен в английском. Тогда появляется переводчик. И каждый из них принимает решение в своей зоне ответственности. Я лишь собираю из этого всего пазл. Не вмешиваясь. В моей вселенной командная работа движется в сторону, где роль руководителя стремится к 0.

Мы хотим делать и научно достоверные и красивые работы. Чтобы школьнику, студентке, взрослому было интересно. Поэтому за научную достоверность у нас молекулярный биолог Валерия Архипова. И большинство частей вируса и клеток это всамделишные атомарные запчасти, полученные с сайта www.rcsb.org.

Мы пошли по пути создания релиза целого ролика и постепенного (слой за слоем) его улучшения. Всего было сделано 5 релизов и 6 финальный. Первый имел длину полторы минуты. Последний три с половиной.

Вот, как выглядит одна и та же сцена в разных релизах:

Одна сцена в разных релизах.Одна сцена в разных релизах.

Первый релиз сделан на демоверсии RedShift. Это видно по ватермаркам. Увидев достоинства от перехода на GPU-рендер, я купил лицензию.

Но постойте! А как, почему длительность ролика увеличилась с одной минуты до трёх с половиной?! Был же сториборд. Где все ключевые сцены утверждены.

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

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

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

RedShift

Считать картинки можно на процессоре, как это делал я в первом ролике. А можно на видеокарте. По тестам разница в скорости 5-10 раз не в пользу процессора. Какие очевидные плюсы и минусы от перехода на GPU-рендер? Ну, думал я, из очевидных плюсов, во-первых, скорость. Во-вторых, скорость. Из минусов? Память. У видеокарты её сильно меньше, чем общей памяти. Но ведь у меня очень простые сцены! Даже текстур нет.

И я попробовал.

На моей новёхонькой 3080 в демоверсии RedShift кадр в 2к с драфтовыми настройками считался секунд 5. Это было удивительно! Mantra, славящаяся своей неторопливостью, справляется секунд за 30 (на 16 ядрах, между прочим). Конечно, я тут же перешёл на этот рендер! И с самого начала проекта второй ролик делался уже в RedShift.

Почему Redshift? Выбор был между Octane, Vray и Arnold. От Vray я отказался сразу. Я работал с этим рендером в 3dsmax и мне не нравится обилие настроек и хаотичность результата. Arnold в тестах показывал результаты сравнимые с Мантрой и меня отпугнул факт, что этот рендер выкупила компания Autodesk. Octane показался мне очень сырым. RedShift самый часто используемый рендер в моушн графике. По нему много туторов и развито сообщество. Наконец, сама компания Maxon, которая приобрела RedShift, мне очень симпатична.

Я, к сожалению, не вёл дневник в процессе работы, как это делал, например, Фёдор Овчинников, когда создавал книжные магазины, а потом придумал сделать Додо-пиццу. Поэтому могу вспомнить только ретроспективно.

У RedShift свои материалы, свет. И свои алгоритмы работы с instance и частицами. Со всеми граблями и айсбергами я знакомился в процессе работы.

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

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

RedShift. Шейдер одинаковый. Слева частицы. Справа сферы. WTF?RedShift. Шейдер одинаковый. Слева частицы. Справа сферы. WTF?

Эээ но подождите! Почему они разных цветов?! И что это за чёрные швы в местах, где сферы пересекаются? Для швов я нашёл решение. Они убираются за счёт операции булеан. Оп! Через две минуты boolean посчитался и чёрные швы исчезли. Можно рендерить! Секундочку! Но ведь весь рендер занимает 5 секунд. А булеан 2 минуты. Да. Но ведь работает. Нет. Спасибо, но нет.

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

Очень часто в сцене используются одинаковые части. Скажем, шипы у вируса. Это же, по сути, один шип, который рандомно развёрнут и расставлен по сферической мембране. И если мы так сделаем, то в этом случае мы получаем экономию по памяти на рендере и шустрый вьюпорт. Для этого у нас есть instance-объекты. Правильно? Логично?

Я тоже так думал. И у меня ушёл ещё один месяц на злость, смирение, слёзы и принятие другой реальности.

В RedShift (у меня) инстансные объекты из частиц/сфер рендерятся вот так:

RedShift. Слева без инстанс объектов. Справа с instance-объектами (сферы или частицы).RedShift. Слева без инстанс объектов. Справа с instance-объектами (сферы или частицы).

Видите? Свет. Слева он ровный и заполняющий. А справа он у каждого объекта свой и рандомно повёрнут. Хотя условия освещения в сцене одинаковые. Я не смог решить эту проблему. Кроме как отказаться от instance-объектов и упаковки. А учитывая, что атомов в сцене миллионы, то от сфер пришлось отказаться в пользу частиц. Памяти видеокарты (10Гб) не хватало. К слову, оперативной (64Гб) при таком подходе не хватало тоже.

NVIDIA 3080 и RedShift. В умелых руках и 10Гб мало. Не instance-геометрия крашит рендер.NVIDIA 3080 и RedShift. В умелых руках и 10Гб мало. Не instance-геометрия крашит рендер.

Уже после проекта мы обсудили эту особенность со Стасом Рыхликовым и он предположил, что дело в нежности объектов, которые мы копируем. О чём речь? Нужно убрать все ноды трансформаций и все другие ноды и тогда, возможно, всё будет хорошо.

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

При рендере на видеокарте так не получится. Рендер крашится. Или замедляется. Что, если подумать, логично. Но неприятно, да.

У меня не было цветового решения объектов. Я выкрашивал вирус в цвет окисленной меди (бирюзовый) и смотрел. Красиво? Красиво. А остальные объекты в какой цвет красить будем? И нужна цветовая гармония, настроение. Я остановился вот на такой палитре.

Цветовая палитра ролика.Цветовая палитра ролика.

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

Ниже финальные рендеры из проекта. В оригинале рендеры в 2к. Для уменьшения трафика размер картинок уменьшен до 1к.

NVIDIA 3080. Redshift. Финальный рендер 2к. Атомарная модель коронавируса. Время рендера до 3 минут.NVIDIA 3080. Redshift. Финальный рендер 2к. Атомарная модель коронавируса. Время рендера до 3 минут.NVIDIA 3080. Redshift. Финальный рендер 2к. Атомарная модель коронавируса. Время рендера до 4х минут.NVIDIA 3080. Redshift. Финальный рендер 2к. Атомарная модель коронавируса. Время рендера до 4х минут.NVIDIA 3080. Redshift. Финальный рендер 2к. Эпительная клетка облепленная экземплярами коронавируса(порядка.150 000). Время рендера до 2 минут.NVIDIA 3080. Redshift. Финальный рендер 2к. Эпительная клетка облепленная экземплярами коронавируса(порядка.150 000). Время рендера до 2 минут.NVIDIA 3080. Redshift. Финальный рендеры 2к. SSS + DOF + Motion Blur. 1-4 минуты на кадр. Виньетирование добавлено в постпродакшене.NVIDIA 3080. Redshift. Финальный рендеры 2к. SSS + DOF + Motion Blur. 1-4 минуты на кадр. Виньетирование добавлено в постпродакшене.

Я оценил мощь 3080 и RedShift, когда нужны были тесты, драфты, финальные рендеры и потом куча перерендеров. Дело не только в скорости. Фактически, финального качества ролик считался те же 7 дней. Только это уже был ролик не в одну минуту, а в три с половиной. Такая скорость позволяет перманентно находится внутри проекта. Не выпадать из него на время рендера. И это очень и очень ускоряет работу. Я сэкономил огромное количество времени на том, что тесты считались по 5 секунд кадр, а не 30. Кажется и то и то отлично. Только в первом случае для секвенции в 200 кадров (менее 10 секунд) я получал результат через 20 минут. А во втором почти через 2 часа. И в этом важнейшее отличие между процессором и видеокартой.

И не забываем о масштабируемости. У меня одна видеокарта. Если их будет больше, то скорость рендера падает линейно. А при подключении NVLink память у видеокарт (не более двух) становится общей это очень классный бонус!

Для меня возврат к рендеру на процессоре в схожих задачах он, ну, невозможен, наверное. Процессор апгрейдить уже некуда (16 ядер AMD 3950). А вот видеокарт мало не бывает.

Houdini

Я люблю Houdini. И люблю решать задачки. И технические задачи, в отличие от задач эстетических, могут решаться участниками одинаково. Скажем решение, уравнения вида x = 5 2 будет иметь одинаковый вид для любого участника процесса решения. Школьница, студент, мама и аспирант решат его одинаково. Более того, решение будет понятно и принято всеми.

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

Поэтому решение технических задач мне нравится. А пиксельхантинг нет.

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

Клеточная мембрана. Вот как она выглядит на картинке из Википедии.

Википедия. Клеточная мембрана.Википедия. Клеточная мембрана.

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

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

Эндоцитоз. Способ проникновения вируса в клетку.Эндоцитоз. Способ проникновения вируса в клетку.

Давайте представим, что мы шариком тычем в тонкий лист картона. Картон, как не особо эластичная поверхность, порвётся. Но клетка не рвётся. Значит она эластичная. Хорошо. Заменим лист картона на что-то тягучее. Жвачку. Или слайм. Теперь наш шарик прекрасно входит и ничего не рвётся. Но погодите-ка. Ведь жвачка и слайм тянутся и в месте натяжения толщина вещества истончается. И, во-вторых, не происходит окутывания шарика. Эээ значит мембрана по свойству не плотное вещество, но и не тянется. И тут я словил инсайт. Мембрана жидкость! Именно этим объясняется её одинаковая плотность и не растяжимость. И теперь, если это жидкость, значит всегда и везде расстояние между фосполипидами одинаково. Жидкость не сжимаема.

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

К этому прибавляется проблема свойственная 3d-анимаций фликинг или мерцание кадров. Это явление возникает, если у нас низкие настройки сглаживания рендера или меняется численность объектов. На статичной картинке этого эффекта, конечно, не видно.

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

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

Озвучка

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

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

Я сделал четвертую версию ролика. Мы написали текст на английском для озвучки. Затем пригласили в команду переводчика - Александру.

Дальше молекулярный биолог и переводчик вместе работали над текстом. Я никак не участвовал и не вмешивался. Забрав конечный результат я отдал его на озвучку женщине-роботу. Параллельно я отправил запрос на озвучку живым нативным диктором. И ждал ответа по стоимости работ.

Когда женщина-робот озвучила текст я сел за монтаж. Видео и звук. О нет! Эти ребята совсем не хотели дружить. Даже мои возможности примирить их ускорением или замедлением секвенций не особо помогали. В озвученных предложениях появились многозначительные паузы или предложения наступали друг другу на ноги. Нужно всё перемонтировать. Я очень расстроился.

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

Было решено оставить голос робота-женщины. И я приступил к новой версии монтажа.

DaVinchi Resolve

Монтаж и звук для первого ролика сделан в Blender. После этого опыта я возжелал сменить коня. А какие есть варианты? Чтобы под Windows. При этом композитинг и монтаж это разный софт.

  1. After Effects + Premiere Pro.

  2. Sony Vegas + ?

  3. Davinci Resolve + Fusion.

  4. Nuke + ?

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

DaVinci Resolve. Вот, как выглядит четвёртая версия ролика. Проект мы закончили на шестой.DaVinci Resolve. Вот, как выглядит четвёртая версия ролика. Проект мы закончили на шестой.

Resolve прекрасно работает с exr. Очень быстро рендерит секвенции на таймлайне.

Вот пример раскрашенного рендера. Помните, я в части про RedShift рассказывал, что почти все рендеры чёрно-белые?

DaVinci Resolve. Коронавирус. Раскрашенный чёрно-белый рендер.DaVinci Resolve. Коронавирус. Раскрашенный чёрно-белый рендер.DaVinci Resolve. Коронавирус и поверхность клетки. Вирус прикрепляется к АСЕ2 рецептору.DaVinci Resolve. Коронавирус и поверхность клетки. Вирус прикрепляется к АСЕ2 рецептору.DaVinci Resolve. Эндоцитоз. Коронавирус попадает в клетку.DaVinci Resolve. Эндоцитоз. Коронавирус попадает в клетку.DaVinci Resolve. Иммуноглобулин IgG.DaVinci Resolve. Иммуноглобулин IgG.DaVinci Resolve. Иммуноглобулин IgG.DaVinci Resolve. Иммуноглобулин IgG.

Что дальше?

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

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

Я хотел добавить в название статьи фрактальность. Причём же здесь фрактальность? Ролик же про коронавирус и иммуноглобулин. Ну да. Но сколько можно?

Когда я решаю какую-либо задачу, то создаю некую модель реальности. Скажем мембрана клетки. Достаточно ли изобразить её ровной поверхностью, которую мы гнём? Достаточно. Но давайте приблизимся. И уже нужны фосфолипиды. Хорошо. А если мы захотим сделать сечение? Тогда нужно показать бислойность мембраны. А если добавить эндоцитоз? Тогда нужно сделать жидкую мембрану.

И вот это бесконечное погружение внутрь. Фрактальность. На следующем уровне абстракции понадобится подключение динамики Houdini. Чтобы фосфолипиды учитывали положение соседей и не протыкали друг друга. Погрузившись ещё глубже нам понадобится сторонний софт, занимающийся молекулярной динамикой: GROMACS, CHARMM, NAMD и другие. Копнув еще глубже, мы увидим, что атомы это, оказывается, совсем не шарики.

Мы очень сильно выросли на этом проекте. И видим куда расти дальше. И хотим этого.

P.S.

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

Пока я работал над статьёй закончился конкурс на Биомолекула. Мы участвовали с нашим первым роликом. И выиграл приз годовую подписку на OctaneRender.

Подробнее..

О создании UI-анимаций в играх и почему они так важны

13.08.2020 18:07:06 | Автор: admin


Привет! Я старший UI-дизайнер Pixonic, Алексей Морев. И в этой статье речь пойдет UI-анимациях, которые каждый из нас может увидеть в играх.

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

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

Итак, начнем!


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

Если упрощенно, анимация это последовательность кадров, которая оживляет изображение. Она делится на полную (full animation) и упрощенную (limited animation). Примером полной анимации является любой полнометражный анимационный фильм: диснеевские Аладдин, Книга джунглей, Русалочка и пр. Примеры упрощенной анимации большинство мультсериалов, таких как Рик и Морти, Гравити Фолз, Крайний космос и пр.

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


Полная и упрощенная анимация на примере мультфильма Симпсоны

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

Что такое анимация, разобрались. Теперь логично перейти к следующим вопросам: какой тип анимации использовать в UI? И нужна ли она вообще?

Сперва отвечу на второй. Нужна ли нам анимация? Вроде бы все понятно: окно открылось, приз получен, кнопка нажалась. Не так уж и важно при этом использовать какую-либо анимацию, верно?

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

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

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

Давайте на примерах одного и того же попапа посмотрим, как он выглядит с полной, упрощенной и минимальной анимацией.


Полная анимация


Упрощенная анимация


Минимальная анимация

Кто создает UI-анимацию и как устроен процесс разработки


Обычно в разработке анимации участвует три человека:

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

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

Создание анимации можно условно разделить на три этапа: продумывание, создание референса и реализация.

Первый этап: идея


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

Давайте поэтапно разберем процесс создания анимации на примере анимации попапа, которая показана выше.

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

В качестве примера возьмем следующий попап и разберем на нем всю последовательность создания анимации.



Тезисно опишем идею:

  • Появление попапа после долго отсутствия игрока в игре;
  • Сделать плавную, но достаточно быструю анимацию;
  • Использовать Full frame анимацию;
  • Анимировать каждый элемент;
  • Анимировать пушку динозавру;
  • Добавить анимированное свечение под динозавром.

Когда цель становится ясна и понятно сформулирована, можно приступить ко второму этапу.

Второй этап: создание референса


Создаем собственный анимационный референс, который в дальнейшем будет демонстрироваться, дорабатываться и изменяться.

Для этого подойдут такие программы, как Adobe Animate, After Effects, Spine и т.д. На данном этапе для нас не имеет значения, в какой программе анимировать (исключение может составлять Spine, т.к. у этого редактора есть экспорт анимации во многие движки), поэтому выбираем, что для нас окажется удобнее и быстрее. Можно даже покадрово проанимировать элемент в Photoshop, но это уже экзотика. Я предпочитаю работать в After Effects, поскольку это наиболее гибкий редактор в плане анимаций: в нем можно реализовать практически любую идею, которая придет в голову.



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

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


Третий этап: реализация


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


Пример оптимизированной нарезки

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

Почему нельзя сразу сделать все на движке? Ответ не очевиден, но довольно прост: когда вы создаете анимацию, к примеру, в After Effects, у вас есть только программа анимации и ее функционал. Не нужно настраивать камеры в игре, чтобы они верно отображались в UI. Не нужно оптимизировать графику и делить все на составляющие: вы легко можете заменить любой элемент, а то и вовсе переосмыслить анимацию, полностью ее переиначив. Если же сразу все создавать на игровом движке, вы потеряете много времени на оптимизацию файлов, будете зажаты в техническом плане и потратите много времени на нарезку графики для анимации на начальном этапе, хотя в конечном итоге она может оказаться совсем другой.

Заключение


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

Если вам понравилась эта статья, следующий материал планируется про то, как можно использовать принципы Disney-анимации в UI. Узнать подробнее о самих принципах можно здесь.
Подробнее..

Перевод Полируем UI в Android StateListAnimator

08.09.2020 18:17:15 | Автор: admin
Привет, хабр! В преддверии старта курса Android Developer. Professional мы подготовили для вас перевод еще одного интересного материала.




Большую часть времени разработки нашего Android-приложения мы тратим отнюдь не на работу над пользовательским интерфейсом мы просто накидываем вьюх и начинаем писать код. Я заметил, что большинство из нас не особо заботится о пользовательском интерфейсе. И я считаю, что это в корне неправильно. Разработчики мобильных приложений должны заботиться также и о UI/UX. Я не говорю будьте экспертом в мобильном UI, но вы должны понимать язык дизайна и его концепции.

Ранее я написал статью о тенях в материальном дизайне и получил много хороших отзывов. Я хочу поблагодарить всех вас. Освоение теней в Android рассказывает о высоте (elevation) и тени (shadow) в Android. Там же я показал, как дополнял ими свою UI библиотеку с открытым исходным кодом. (Scaling Layout).

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

Содержание


В этой статье рассматриваются следующие темы:


Состояния Drawable


В Android есть 17 различных состояний для Drawable.



Возможно, мы даже никогда не встречали некоторые из них. Я не собираюсь углубляться в каждое состояние. В большинстве случаев мы используем pressed, enabled, windows focused, checked и т. д. Если мы не объявляем состояние для drawable, то подразумевается, что это состояние по умолчанию в Android.

Нам нужно понимать эти состояния, чтобы написать наш собственный StateListDrawable.

StateListDrawable


Это, по сути, список drawable элементов, где каждый элемент имеет свое собственное состояние. Для создания StateListDrawable нам нужно создать XML-файл в папке res/drawable.

<item android:drawable="@drawable/i" android:state_pressed="true"/>


Это элемент (item). Он имеет два свойства. Drawable и State.

<selector>   <item       android:drawable="@drawable/p"       android:state_pressed="true"/>   <item       android:drawable="@drawable/default"/></selector>


Это StateListDrawable. Если мы не объявляем состояние (state) для элемента, как я уже упоминал ранее, это означает, что это состояние по умолчанию.

Могу ли я использовать ShapeDrawable?


Да. Вместо использования android:drawable вы можете добавить к своему элементу произвольную форму. Вот элемент с ShapeDrawable.


StateListDrawable

Вы можете использовать StateListDrawable с уровня API 1. Таким образом, для StateListDrawable нет ограничений уровня API.

<View   android:layout_width="50dp"   android:layout_height="50dp"   android:foreground="@drawable/state_list_drawable"   android:clickable="true"/>


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

Но погодите секундочку. Clickable? Зачем мы добавили этот атрибут? Нам что, еще и его добавлять нужно? Да. Но только для пользовательских вью. Чтобы это выяснить, нужно время. Кнопки отлично работают без добавления clickable, потому что они по умолчанию clickable. Но если вы хотите использовать StateListDrawable для View, ImageView, Custom View и т. д., вам необходимо добавить атрибут clickable.



StateListDrawable

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

StateListAnimator


Помните, что когда вы нажимаете FloatingActionButton, его Z значение увеличивается из-за анимации. Это StateListAnimator так сказать за кадром. У некоторых виджетов материального дизайна есть собственный StateListAnimator внутри.

Давайте проясним это с помощью вопроса на StackOverflow.



(Как удалить границу/тень с кнопок lollipop).

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


(Lollipop имеет небольшую неприятную функцию, называемую stateListAnimator, которая обрабатывает высоту кнопок, производя тени.

Удалите stateListAnimator, чтобы избавиться от теней.

У вас есть несколько вариантов как сделать это:

В коде:

button.setStateListAnimator(null);)




Итак, а как мы можем создать его?

Чтобы понять StateListAnimator, нам нужно понять анимацию свойств объекта (property animation). Я не собираюсь углубляться в анимацию свойств в этой статье. Но по крайней мере, я хочу показать вам основы.

Анимация свойств


Вот самый простой пример свойства в объекте. X это свойство.

class MyObject{    private int x;    public int getX() {       return x;   }    public void setX(int x) {       this.x = x;   }}


Система property animation это надежный фреймворк, который позволяет анимировать практически все. Вы можете определить анимацию для изменения любого свойства объекта с течением времени, независимо от того, отображается ли он на экране или нет. Анимация свойства изменяет значение свойства (поля в объекте) в течение заданного периода времени.



X это свойство. Т время. Во время анимации свойство X обновляется в заданное время. В целом так работает анимация свойств. Вместо коробки может быть вью или любой объект.

ValueAnimator это базовый класс для анимации свойств. Вы можете настроить слушатель на обновления ValueAnimator и наблюдать за изменениями свойств.

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

  • У вас есть объект (любой класс с каким-нибудь свойством).
  • Вы не хотите наблюдать за слушателем ValueAnimator.
  • Вы хотите обновлять свойство объекта автоматически.


Итак, если у нас есть вью (которое является объектом), и мы хотим обновить свойство вью (координата x, координата y, rotation, translation или любое другое свойство, для которого у вью есть геттер/сеттер), мы можем использовать ObjectAnimator. Продолжим создание StateListAnimator.

<selector>    <item android:state_pressed="true">      <objectAnimator           android:duration="200"           android:propertyName="translationZ"           android:valueTo="6dp"           android:valueType="floatType" />   </item>    <item>      <objectAnimator           android:duration="200"           android:propertyName="translationZ"           android:valueTo="0dp"           android:valueType="floatType"/>   </item> </selector>



Кнопка FAB анимирует свое свойство translationZ при нажатии и разжатии.

Как я сказал ранее, мы можем использовать свойство объекта напрямую, не наблюдая за изменениями в аниматоре. Каждый View имеет свойство translationZ. Таким образом, мы можем напрямую анимировать translationZ с помощью ObjectAnimator.

Мы можем также объединить несколько <objectAnimator>-ов в <set>. Изменим еще одно свойство View. Scale X и Scale Y.

Вот результат! Теперь она также увеличивается при нажатии пользователем. А вот коммит.



Вы также можете определить другие свойства в своем animator.xml. Здесь вы можете найти больше информации об использовании ObjectAnimator.

Вот и все. Я планирую написать еще что-нибудь о ValueAnimator и ObjectAnimator. Это отличное API для анимации объекта.

Успешного вам кодинга!
Подробнее..

Ретроспектива создания своего мультфильма

20.06.2020 18:10:45 | Автор: admin
Мы живём в удивительное время. То, что раньше было невероятным, сегодня у нас буквально валяется под ногами. В наши дни любой человек может сделать свой собственный мультфильм. Анимационные программы упрощают и ускоряют этот процесс настолько, что даже один человек ну будучи аниматором, может сделать настоящий анимационный фильм.
С удовольствием поделюсь полученным мною опытом. Речь будет идти о 2D-анимации, но многие моменты равно применимы и к 3D. Кому будет интересно ссылка на сам мультфильм в конце поста.

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

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

Анимация это не самое важное. Анимация на втором месте. История важнее анимации. Она должна быть интересной, стоящей, поучительной. Анимация лишь раскрывает вашу историю.

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

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

Ускорение развития навыков. Чередуйте, банально переключайтесь между теорией (20%) и практикой (80%). Не впадайте ни в одну, ни в другую крайность. Понятно, если вы ограничитесь теорией, то вы ничего, никогда и не сделаете. Но часто многие ограничиваются практикой, силовым методом и это тоже снижает скорость развития. Из 5 часов 1 час изучайте, 4 делайте. По-моему опыту это заметно ускоряет.

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

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

Название мультфильма. Лучшее название для вашего фильма появится в самом конце. Вы сразу его узнаете. Мультфильм вы начинаете делать просто с рабочим названием.

Зритель видит по-другому. Рассказывать истории очень сложно. Имеет значение всё. Зритель не увидит так как хочешь ты, он увидит так как он видит. И отсюда сразу два урока:
Чётко управлять вниманием, фокусировать на важном (прежде всего движением, в т.ч. камеры, контраст, световой/цветовой, выбивание/отличие из ряда и т.д.).
Обязательно устраивать предпоказы узнаешь как видят твою историю другие люди (зритель не смотрит туда, куда нужно посмотреть, упускает нить повествования, внимание рассеивается, расфокусируется, и т.д.).

Развитие сцены. Сцена должна развиваться. Не выкладывайте зрителю все карты сразу. Сначала покажите лампу, потом, что она может светиться, потом, что можно регулировать яркость свечения, потом, что может мигать одинаковым тактом, потом неравномерным тактом (под музыку), потом, что может светиться разными цветами и т.д. Развивайте сцены.

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

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

Повышение производственной эффективности:
Банальное разбиение на сцены ускоряет работу, через вырезание/перемещение ключей, открытие проекта, пререндеринг).
Чистота структуры (легко и быстро читаемые прежде всего вам названия слоёв, объектов, кистей, темплейтов). Если вы задумались над элементом значит, название для него подобрано неудачное.
Простая система наименования сцен.
Качественное планирование (сценарий, сториборд, аниматик, Списки требуемых фонов, персонажей, пропсов, эффектов и т.д.). По умолчанию получается Анимация в воде слишком гладкая, нет динамики. Планирование в итоге просто сэкономит время, а поднимет анимацию на уровень выше.
Специализация. Делать работу по этапам (только фоны подряд или только риги или только пропсы). Без разницы в какой очерёдности.
Оптимизация количества локаций, фонов, количество персонажей не рисовать ненужное, несущественное, не значимое, не несущее ценной информации.
Стилизация картинки (упрощение) условные блики на стёклах, ограниченная цветовая схема на весь проект и т.д.
Скелетный подход. Накидать сцены в грубую, а потом дополишовывать (в итоге эффективнее, чем вылизывать каждую сцену до идеала).

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

Риггинг. Риги нужно конструировать, учитывая:
Характер, особенности персонажа (какой он, какие движения ему потребуются, в каких ракурсах он нужен в сценах, планируются ли диалоги). Если не спланируете риг заранее, это может значительно затянуть время производства мультфильма.
Персонажа рисовать прежде всего стоит в ракурсе 3/4, спереди. Самый важный ракурс персонажа. Он чаще всего будет использоваться. Если вы планируете делать диалоги, то хорошо разнообразят картину 3/4 сзади собеседников персонажа.
Максимально упрощайте своего персонажа (без лишних деталей, текстур) гораздо ценнее вложить время в качественную анимацию, что в красивые риги с плохими движениями.
Наименование слоёв для быстрого ориентирования (и здесь тоже).
Важность установки осей вращения (Pivot Point) в темплейте.
Требуемый стиль (реалистичность, резиновость), возможности и ограничения техники перекладки.

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

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

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

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

SVGator.com на практике

20.05.2021 18:13:57 | Автор: admin

Привет, мы дизайнеры экосистемы Своё для фермеров и банковских сервисов Россельхозбанка. Рассказываем, зачем нам понадобился SVGator.

Как мы пришли к SVGator.com

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

Наш путь начался с lottie, как с более популярного сервиса. Ключевой недостаток: встроенная api. Нам хотелось найти более прагматичное решение без интеграции, поэтому выбор пал на SVGator. В наши цели попадало закрытие микроанимаций элементов интерфейса, оформительские детали и т.п.

Что за зверь и какие задачи решает

SVGator.com это web-платформа для создания svg-анимаций, то есть svg-файлов со встроенными анимациями, которые без каких-либо проблем интегрируются в html. Можно задать последовательную обработку таких анимаций. Возможен экспорт как js, так и чистым CSS. Возможности js немного шире, но разница не существенная.

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

Небольшие функциональные элементы интерфейса. Например, интерактивные состояния компонентов и вытекающая микроанимация

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

Элементы дизайна. Например, иллюстрации

Интерфейс и функционал

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

Инструмент включает в себя следующие функции: работа с размером, положением, поворотом, наклоном, цветом, прозрачностью, а также богатый функционал для работы с обводкой. Помимо этого, поддерживается работа с масками и векторами движения. Этого достаточно для работы с классическими решениями анимации. Ещё один важный момент работа с easing, которые также встраиваются в svg-файл. Это упрощает работу на этапе front-end, и дизайнеру не приходится тревожить разработчика скоростью анимации.

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

Чем svg отличается от sequence, gif, video? А также основные конкуренты:
Lottie и Keyshape

Ключевые преимущества svg вес, отсутствие api и возможность давать плавную анимацию. Разберём каждую из альтернатив.

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

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

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

Lottie. Это один из ключевых конкурентов SVGator. Компания раньше вышла на рынок и имеет значительно больше почитателей. Плюс возможности анимации значительно больше, поскольку базовая анимация собирается в Аfter Еffects, а lottie является своего рода оболочкой для такой анимации. Но для работы с данным решением необходимо предустановить api на платформу, что не всегда хорошо для продакшена больших нагруженных систем.

Keyshape. Очень близкая по возможностям платформа, различия лишь в деталях. Текущий функционал Keyshape несколько выше и позволяет делать экспорт чистым svg + css. К недостаткам можно отнести её стационарность и возможность работать исключительно на macOS.

Вот поэтому и стоит обратить внимание на SVGator. Плавные анимации, реализованные кодом, кроссплатформенные, без каких-либо api и с нормальным весом.

SVGator в экосистеме Своё

На наших продуктах Своё Фермерство, Своё Жильё, Своё Родное, Монеты, Подбор персонала, Своё Село и т.д. уже присутствуют наработки в SVGator: лоадер, интерактивные состояния компонентов, логотипы, а также иллюстрации для оформления разделов. Мы планируем увеличивать их долю и продолжать экспериментировать.

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

Перспективы

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

Объёмные решения склонны к излишней нагрузке системы и могут стать камнем преткновения. Поэтому в наших планах использовать этот инструмент поступательно, небольшими шагами, анимируя поначалу небольшие элементы.

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

Подробнее..

Стартовал открытый бета-тест Cascadeur

28.07.2020 18:07:12 | Автор: admin


Со времени первого анонса Cascadeur в начале 2019 года уже более 18 000 пользователей приняли участие в закрытом бета-тестировании программы. У аниматоров, занимающихся разработкой игр и созданием фильмов, было более 12 месяцев, чтобы испытать в работе наш инструментарий.

Сегодня мы рады сообщить о запуске открытого бета-теста (ОБТ) своей анимационной программы для физически корректной анимации персонажей. Благодаря ОБТ протестировать и оценить ее возможности сможет более широкий круг пользователей.

Подход Cascadeur к анимации значительно облегчает достижение точной механики тела. Теперь я уверен, что инструменты для физически корректной анимации станут ожидаемым стандартом в индустрии, поделился мнением один из первых пользователей Cascadeur, анимационный директор Polyarc Ричард Лико, ранее работавший над Destiny 2.

Опрос, проведенный издателем Nekki в апреле 2020 года, показал, что 85% бета-пользователей Cascadeur считают его инструментом, который будет играть важную роль в их будущих проектах. В январе 2020 года Nekki и Cascadeur были номинированы на премию Pocket Gamer Mobile Games в номинациях Best Innovation и Best Tool Provider, что является редким достижением для еще неизданного продукта.





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

  • Новую архитектуру, которая делает Cascadeur намного быстрее и эффективнее

  • Улучшения рига, такие как способность перетаскивать или вращать центр масс без его фиксации и улучшенная интерполяция

  • Доработку инструментов создания рига

Новая архитектура Cascadeur значительно ускорит процесс разработки и оптимизации программы. Следующие шаги будут включать в себя:

  • Дальнейшее улучшение риггинга, с возможностью создания кастомных ригов

  • Поддержка Python для автоматизации процессов

  • Бета-версия инструмента Graph Editor






Чтобы сделать использование Cascadeur привлекательным для профессиональных аниматоров, Nekki разрешает бесплатное коммерческое использование бета-версии. Любая анимация, созданная в ОБТ-версии Cascadeur, может быть бесплатно использована в играх и фильмах без предварительного разрешения Nekki.

Мы хотим наглядно продемонстрировать вам основные особенности и инструменты Cascadeur в новом 5-минутном видео:



Получить более подробную информацию и скачать ОБТ-версию Cascadeur вы можете на cascadeur.com

Узнать о Cascadeur больше:

Вложенность нейросетей инструмента автопозинга в Cascadeur
Почему 12 принципов Диснея недостаточно
Cascadeur: задача о падающей кошке
Cascadeur: будущее игровой анимации
Подробнее..

Нейроэволюция киберкальмаров. Перезагрузка

23.10.2020 18:08:20 | Автор: admin


С интересом слежу за темой симуляции живого посредством компьютерных программ. Нейросети демонстрируют огромный прогресс переваривая гигабайты информации.
Обучение нейронных сетей, в части требуемых ресурсов, далеко ушло от среднего по мощности настольного компьютера. Поэтому всегда интересны "игрушечные" проекты с быстрой обратной связью в части обучения нейросетей. А лучше всего, чтобы нейросеть сама и обучалась без заметных усилий со стороны разработчика. Этой весной был приятно удивлен обнаружив статью Job Talle о нейроэволюции кальмаров.


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


Начнем с источников:

Оригинальная статья взятая за основу при программировании кальмаров(осьминогов)



Перевод вышеуказанной статью на Хабре.


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

или так:


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


Когда все уже готово, рассказано и показано, остается вопрос, а как эта программа работает на самом деле.
Поэтому решил переписать код изначально созданный под JavaScript на более близкий мне с++. Как всегда бывает с чужим кодом, сначала многое было непонятно. Чего стоит такой вот пассаж:




простыми словами автор программы включил в индекс нейрона и его тип, зачем этот прием из 80-х годов непонятно. Вроде сейчас памяти хватает в компьютерах.
Но в целом прототип заработал и стал выглядеть примерно так:



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



выглядит неплохо, но переход щупальца к телу хотелось увидеть более естественным, добавил более сильный отступ от центра щупальца:



в итоге остановился на таком варианте:



Но кальмары скорее всего не прозрачные, поэтому картинка больше про медуз:


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



или в движении:



и более мультипликационно:



Дело сделано в 2D, но 3D все еще мейнстрим, поэтому переходим к следующему этапу. Сначала понять как буду крепить щупальца:



Решил сначала физику переписать с нуля:




Видно, что опирается на щупальца, добавил коллизии щупалец и прочее из набора физического движка. Потянуло на проверенный временем Bullet Physics Library:



Но вскоре решил не трогать то, что работало изначально и просто добавил еще одно измерение в первоначальную физику:



получилось похоже на оригинал но в 3D. На видео видно баг, когда одна из щупалец ломается. Дело в том, что в 3D поиск нормали к вектору не совсем тривиальная задача. Местами симуляция движения щупальца ошибалась в выборе нормали. Поправил.


Конечный результат, что-то из фильма "Матрица":


Подробнее..

Перевод История создания Dragons Lair

07.11.2020 22:21:21 | Автор: admin

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


image


Dragon's Lair или Логово Дракона это история о рыцаре, который врывается в замок с ловушками, чтобы спасти прекрасную девушку от злого дракона. Да, здесь не особо оригинальная история и игра не превратилась в культовый франчайз, однако её появление стало одним из самых запоминающихся событий в истории видеоигр.


image


И по сей день ведущий разработчик Dragon's Lair Рик Дайер получает электронные письма от фанатов, которые рассказывают, какое влияние игра оказала на их жизнь. Десятки лет спустя эта игра всё ещё продается, и это одна из немногих видеоигр, когда-либо попавших в Смитсоновский институт (двумя другими являются Pong от Atari и Pac-Man от Namco). Это была видеоигра, созданная при помощью новейшей технологии лазер-дисков. Это было завораживающе. Игроки смотрели на неё с трепетом. Дайер объясняет это законом Кларка: Любая достаточно продвинутая технология неотличима от магии.


image


Гадкий утёнок


В течение двух лет компания Дайера Advanced Microcomputer Systems работала над созданием игры в мире фэнтези. Взяв пример с Adventure (выходила на Atari 2600 в 1980 году), Дайер хотел продвинуть концепцию дальше, сделав её более наглядной. Он экспериментировал с бумагой для кассовых аппаратов, визитницей Rolodex (вращающийся каталог с карточками), и даже с кассетной декой (профессиональная версия магнитолы). Ничего не работало. Все они использовали линейный доступ (linear access) и поэтому были слишком медленными. Ему требовался произвольный доступ (random access). Ему нужен был лазерный диск (Laser disc).


Дайер разработал версию в виде слайд-шоу на лазерном диске с мгновенным доступом (instant access), но этого было недостаточно. Игру надо было анимировать. Я пошёл на просмотр Секрет Н.И.М.Х (анимационный фильм 1982 года) и указал на экран, сказав: вот кто должен взяться за анимацию в моей игре вспоминает Дайер. Затем он встретился с создателями фильма, представив Дону Блуту и его продюсерской команде Гэри Голдману и Джону Померою идею анимации интерактивного развлечения с тематикой меча и магии (swords'n'sorcery game) на лазерном диске. Поскольку у команды Блута не было никаких проектов, а их фильм провалился в прокате, они согласились.


image
Секрет Крыс или Секрет Н.И.М.Х. анимационный фильм 1982 года по книге Роберта О'Брайана


В первые четыре недели разработки работа не складывалась. Дайер и Блут боролись за место руководителя проекта. Как вспоминает Блут: Рик пытался написать рассказ, а я говорил: "Давай пойдём другим путём". Он подключил нас к своему проекту, но не собирался рассказывать, как его анимировать Он сделал несколько набросков и рисунков, на которые я посмотрел. И по моим стандартам качества я сказал: ни за что.


В конечном счёте, Дайер отказался от контроля анимации в команде Блута, и всё же обе команды работали по-своему. Дайер запер свою группу из семи дизайнеров в комнате, заставил их рисовать и критиковать работы друг друга. Звучит сурово, но для него это был единственный способ утереть нос команде Блута из 300 аниматоров. Группе Блута тоже приходилось перерисовывать сцены, что надломило их дух. Оглядываясь назад, Дайер понимает, что в коллективе царила токсичная атмосфера, но у него не было выбора: Мы анимировали игру, история которой не была дописана. Причина заключалась в том, что мы участвовали в гонке на опережение хотели быть первыми, кто выйдет на рынок с подобным проектом. Мы знали, что если запоздаем, это будет провал.


Ловушки


Dragon's Lair состоит из множества ловушек. Осознайте надвигающуюся угрозу, правильно отреагируйте с помощью джойстика или кнопки, и увидите следующий фрагмент фильма. Но как понять, что нужно нажимать? События в Dragon's Lair происходили очень быстро. Игроки не успевали понять, что нужно делать. Поэтому, в момент угрозы требовались визуальные подсказки, в виде жёлтой вспышки, сообщающей, в какую сторону направить джойстик. Это не сильно помогало. У вас есть только восемь кадров или треть секунды, для реакции. Единственный способ победить запоминать игру.


image


За создание ловушек отвечал Дайер. Внешний вид, звук и персонажи лежали на плечах Блута. Мы хотели сделать Дирка не просто рыцарем, который пытается пройти через замок мы хотели придать ему индивидуальность. Чтобы он запомнился, говорит Блут. Это означает, что игроку предстоит проникнуть в голову главному герою. А язык его тела подскажет о том, что происходит в его голове. Используя Чарли Чаплина в качестве модели, Блут сделал Дирка чем-то вроде болвана: У него иллюзия своего величия. Он мнит о себе больше, чем он есть на самом деле. И это делает его забавным. Он возьмется за то, что кажется абсолютно невозможным, потому что не понимает, что это невозможно. Дафна, цель для Дирка и приз в конце игры, обязана своей красивой фигурой и откровенным позам пятилетней коллекции журналов Playboy Гэри Голдмана.


image


Блут не мог позволить нанять талантливого актёра озвучки, поэтому попросил своего редактора, от природы забавного парня, озвучить Дирка. Дирк не разговаривал (ещё одна отсылка к Чаплину) он издавал звуки, чтобы показать, что испытывает. Блут попросил другого сотрудника озвучить Дафну. И она уже разговаривала.


Вот это поворот!


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


Сцены смерти


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


image


Компания Advanced Microcomputer Systems протестировала игру на Гран-при Малибу в Эль-Монте, Калифорния. Когда Дайер посетил площадку мероприятия, он не мог поверить в то, что увидел: Там были сотни людей, все они стояли с открытыми ртами и вытаращенными глазами, просто глядя на нашу игру. Когда я подошёл к автомату слот для денег был забит монетами. Было так тесно, что нельзя было пошевелиться. Там было около 200 человек, и они не собирались уходить.


Через несколько минут Дайер побежал к телефону-автомату, чтобы позвонить президенту Cinematronix дистрибьютору Dragon's Lair. Тогда Cinematronix тестировала игру в Сан-Диего, Калифорния. Прежде чем Дайер успел сказать хоть слово, президент Cinematronix проговорил: Да, Рик, здесь происходит то же самое.


Успех


Хотя для Блута это был первый игровой опыт, он понимал, почему Dragon's Lair стала настолько успешной: Мне кажется, что проект вызвал такой фурор, потому что, на тот момент, не было ничего визуально схожего в развлечениях на игровых автоматах. Это были очень пиксельные проекты, с невыразительной графикой, которые не были особо сложными. Впервые игра выглядела как что-то из мира медиа-развлечений.


Окупаемость игры была под вопросом, поэтому Cinematronix пришлось установить цену в 50 центов вместо 25-ти. Один только проигрыватель лазерных дисков стоил 1000 долларов. Это был единственный способ, чтобы разместить наши автоматы в аркадных залах дать им возможность взимать с игроков 50 центов, говорит Дайер. В противном случае, никто не стал бы закупать эти автоматы. Конечно, как выяснилось позже, Dragon's Lair стала настолько успешной, что автомат окупался за одну-две недели, потому что занят он был круглосуточно.


image


Команда продолжила создание анимированных игр с технологией Laser Disc, это были Space Ace и Dragon's Lair 2. Но ни одна из этих аркад не была такой успешной, как первая. Эпоха лазерных дисков началась и закончилась с выходом Dragon's Lair. Мы просто технологически упёрлись в стену, вспоминает Дайер. Тем не менее, через 20 лет команда собралась снова, чтобы создать Dragon's Lair 3D (2002 год/ Playstation 2 и Nintendo Gamecube) видеоигру с компьютерной графикой, которая сохраняет ощущение рисованной анимации.


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




Это был перевод статьи из журнала Edge Special Retro 02/2003. Прикладываю скан оглавления со всем списком игр, которым был посвящён выпуск пишите в комментариях, что перевести дальше.


image


Также, советую ознакомиться с косплеем по Dragon's Lair (по персонажу Дафны).

Подробнее..

Перевод История Streets of Rage

08.11.2020 00:20:08 | Автор: admin

Сегодня в это трудно поверить, но в 80-е и 90-е двухмерные битемапы безраздельно властвовали, особенно в аркадных залах. С тех пор, как Ёсихиса Кишимото усовершенствовал формулу с помощью Renegade и Double Dragon, все разработчики стремились повторить успех, и многим это даже удалось.


image


Хотя к этому времени компания Sega уже представила несколько популярных проектов вроде Altered Beast, Golden Axe и Alien Storm, именно Capcom оседлала этот жанр спасибо таким хитам, как Dynasty Wars, Captain Commando и Final Fight. Подвиг Хаггара, Коди и Гая, расчищавших улицы Метро Сити от всякой шпаны, обернулся для Capcom большим успехом, и вскоре Final Fight была лицензирована для множества домашних компьютеров: от ZX Spectrum до 16-битной Амиги. Компания Nintendo быстро осознала популярность творения Capcom и сделала его своим консольным эксклюзивом для SNES.


Вырезанные кооператив и целый уровень (промышленная зона, если вам интересно) не помешали игре стать успешной, причём настолько, что были выпущены два эксклюзивных сиквела только для консоли Nintendo. Тем временем Sega была вынуждена просто наблюдать, как один из самых популярных аркадных проектов бьёт рекорды продаж на приставке её конкурента. Как показывает история, лучший порт Final Fight вышел именно на Sega Mega-CD, но до этого оставались ещё годы, а Sega не умела предсказывать будущее. Компании нужен был хит, который побьёт популярный эксклюзив Nintendo, и она нуждалась в нём прямо сейчас.


image


Поэтому перед Sega встала задача создать свою собственную игру, которая будет не хуже Final Fight и даже превзойдёт её. Этим проектом стала Streets of Rage, которая дебютировала на консоли Mega Drive в августе 1991 года, через девять месяцев после успешного выпуска Final Fight для SNES.


Мы взяли интервью у Ацуши Сеймии, расспросив его о работе над культовым битемапом. Во время создания Streets of Rage (или Bare Knuckle, как игру называли в Японии) он работал художником. Первый вопрос заключался в следующем: всегда ли Streets of Rage планировалась как ответ Sega на популярный эксклюзив для SNES?


Не могу этого отрицать, честно отвечает Ацуши. На самом деле мы купили аркадный автомат с оригинальной игрой и долго изучали её всей командой.


Внимательное изучение игры от Capcom окупилось. Streets of Rage предлагает множество преимуществ по сравнению с Final Fight на SNES. В первую очередь, можно играть с другом, а это куда веселее. Streets of Rage позволяет выбирать из трёх бойцов, у которых есть счёты с мистером Икс, контролирующим город и полицию. Как и в Final Fight, каждый герой уникален, у каждого есть свои сильные и слабые стороны. Адам Хантер основан на Хаггаре он более медленный, но при этом сильный герой, умеющий справляться с группами противников. Блейз Филдинг больше похожа на Гая она куда быстрее, но не способна выдерживать сильные удары. Последний герой Аксель Блейз, он обладает всеми способностями Коди, но не такой прыгучий, как его товарищи. Все трое являются бывшими полицейскими и поклялись передать мистера Икс в руки правосудия.


image


Нам было интересно узнать, за что отвечал Сеймия во время создания игры. Как художник, я работал над широким спектром задач: от проработки персонажей до ландшафта, объясняет он. Я впервые занимался главными героями, поэтому пришлось многократно переделывать свою работу. Возможно, для молодого художника это было боевым крещением, но переделки в итоге окупились. Многие уровни очень похожи на проект от Capcom например, городские улицы и промышленные районы. Но хватает и разнообразия за счёт прекрасных пляжных участков, увлекательной поездки на лифте и заключительного тяжёлого прохода по коридору, ведущему к пентхаусу мистера Икс, перед битвой с которым игроку предстоит сразиться с боссами из всех предыдущих уровней. Неудивительно, что внешне Streets of Rage был крайне не оригинальным проектом: Сеймия признал, что Sega просто давала игрокам то, чего они хотели: В Final Fight, Double Dragon и других аркадных играх того времени использовался реалистичный визуальный стиль, и я думаю, что это было просто в тренде, признаёт Сеймия.


Возможно, игра и выглядит очень похожей на некоторые из популярных битемапов того времени, но ей удаётся выделяться благодаря разнообразию локаций, интересному дизайну уровней, а также куче интересных врагов и боссов самых разных форм и размеров. В дополнение к простым уличным головорезам имеются ниндзя (как в Teenage Mutant Ninja Turtles), госпожи с хлыстами, сумасшедшие, жонглирующие топорами и факелами, а также мастера боевых искусств.


image


image


Боссы тоже очень разнообразны: от маньяков с когтями до борцов, похожих на Последнего воина (американский рестлер, известный под псевдонимом The Ultimate Warrior). Другие запоминающиеся главари это здоровый огнедышащий толстяк, а также Мона и Лиза две девушки, которых фактически сделали из Блейз путём смены палитры. В итоге Сеймия поработал над всеми персонажами в игре: Команда дизайнеров поручала мне создавать модели на основе историй персонажей, их размера в пикселях и других справочных материалов, вспоминает он. Я так и поступал, хотя и было довольно сложно анимировать персонажа с ограниченным количеством пикселей.


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


image


Несмотря на силы и размеры главарей в Streets of Rage, главные герои способны с ними справиться. Все трое имеют доступ к сериям ударов ногами и кулаками, а также умеют наносить удар в прыжке и применять захваты. В этом нет ничего революционного, но управление очень отзывчиво, поэтому игроки чувствуют полный контроль над своими героями в бою. Противники тоже не согласны работать грушами для битья: они могут схватить игрока и бросить его на землю. Но вы можете приземлиться на ноги своевременным нажатием кнопки прыжка и даже атаковать, когда вас берут в захват. Можно даже объединиться со своим товарищем, чтобы выполнять совместные приёмы, а при нажатии на кнопку A приезжает полицейская машина, и бывший коллега героев уничтожает всех врагов с помощью ракетницы. К сожалению, Сеймия не отвечал за боевую механику, но вот что думает по этому поводу: Мне очень нравится, как в игре реализовали совместные приёмы для двух игроков.


Еще одним аспектом игры, фанатом которого является Ацуши, стал прекрасный саундтрек. Музыка очень важна, поэтому мы позвали Юдзо Косиро, вспоминает он. До этого Косиро написал отличную музыку к игре The Revenge of Shinobi. А поскольку глава разработки Streets of Rage, Нориёси Охба, также руководил серией Shinobi, договориться о совместной работе с композитором было нетрудно.


image


image


Сеймия считает, что именно режиссёрский стиль Охбы привёл к необычному для того времени множеству концовок в игре. Например, одна из них даёт игроку возможность объединиться с мистером Икс. Как мне кажется, это черта его стиля: добавить неожиданный поворот в сценарий, утверждает Ацуши. К слову, разработка Streets of Rage была завершена лишь с точки зрения игрового процесса. Релизная версия это то, что решила выпустить Sega, а сами авторы хотели добавить в игру куда больше контента. Много чего не попало в финальную версию, но геймплейные механики мы успели реализовать все до единой, говорит Сеймия.


Streets of Rage получила признание критиков и показала отличные продажи. Её успех на консоли Mega Drive привёл к тому, что в 1992 году появился урезанный порт для Game Gear, в котором нет Адама. А в 1993 году для PAL-региона вышла версия для Master System без режима кооперативной игры. Мы спросили, причастен ли Сеймия к этим портам низкого качества, и он ответил: Нет, я не работал над этими проектами.


image


image


Хотя оригинальная Streets of Rage снискала огромный успех, именно продолжение, выпущенное в 1992 году, заставило геймеров обратить внимание на серию. В сиквеле всё лучше: от музыки (написанной тем же Юдзо Косиро) до более детальных спрайтов и большего количества боевых приемов. Многие игроки до сих пор считают Streets of Rage 2 вершиной жанра. Сеймия работал над сиквелом в качестве художника фонов. Он также участвовал в создании Streets of Rage 3 1994 года, печально известной своим боксёрским кенгуру и большим количеством различий между западной и восточной версиями игры. Есть даже серия комиксов, но Сеймия тут уже точно ни при чём.


Несмотря на спорный триквел, серия Streets of Rage остаётся примером отличных битемапов и важным релизом в 16-битной битве между Sega и Nintendo. Недавно выпущенная четвёртая часть понравилась фанатам серии и поклонникам жанра: да, там нет запоминающегося саундтрека, но в остальном у Lizardcube и Guard Crush Games получилось создать достойное продолжение.


image




Это перевод статьи из 133-го номера журнала Retro Gamer. Ранее выкладывал материал на ресурсе Идеальный Пиксель сайт понравится всем фанатам ретро-игр и старых компьютеров.

Подробнее..

Игровые локации, или как сюжет раскрывается через окружение в современных играх

20.03.2021 00:14:27 | Автор: admin

Ребята, всем привет!!!

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

Интересно? Тогда заваривай чаек, бери на руки своего котана и погнали!!!

То, что мы видим, когда погружаемся в игровой мир новой стрелялки, "бродилки", "симммулятора", стратегии, "экшена" и или, во что вы там любите еще играть после работы, учебы, на работе на учебе ;)) и что притягивает наше первое внимание, так это окружение и тот мир куда мы попадаем - это и есть игровая локация.

Для начала оценим масштаб происходящий событий

Локации могут динамически появляться, как маленькие кусочки огромного мира постепенно открывая всю карту, так например сделано во множестве онлайн игр с открытым миром. Среди наиболее известных это различные вариации MMORPG, так как ArcheAge, Lost Ark, SkyForge, CrossOut, Dragon Knight 2, Rise of Angels, World Of Tanks.

Локации могут быть самыми разнообразными, но все они должны передавать дух игры и помогать "разворачивать" сюжетную линию игры (Фото: https://store.my.games, ArchAge)

Как бы ним была устроена локация, она должна максимально "погружать" пользователя в игровой мир и сделать "пребывание" в этом мире максимально комфортным, интересным и захватывающим (Фото: https://la.mail.ru, Lost Ark).

Окружение, помимо чисто эстетической цели, служит еще и определенным вектором при "прохождении" игры, оно направляет игрока по сюжетной линии, иногда помогая ему, а иногда и препятствуя, дабы усилить игровой момент и чувства преодоления препятствий. Этот эффект позволяет игроку понять, что будут как сложности так легкие участки, ну а по завершению его ждет желанная награда за успешно выполненные задания. (Фото: https://mmo13.ru, Justice).

Так же есть локации с фиксированным размером, это характерно для игр имеющих четкую сюжетную линию, ограниченное число уровней, и способов взаимодействия игрока с этим миром. Сюда можно отнести практически все игры, которые предназначены либо для индивидуального прохождения, либо для парного. Среди наиболее популярных можно назвать такие: CyberPunk 2077, Vangers: One of the Road, Warhammer: Dark Omen, Heroes 3 и т.д.

Локации всегда представляются чем-то масштабным, здесь задействована огромная работа художников по окружению, специалистов по моделированию, в основном hard surface, программистов, текстурщиков, специалистов по рендеру, свету, и многих других. Вся их работа направленно на то, чтобы на вашей "машине" игрушка взлетала на ура и не тормозила, и конечно же приятно радовала глаз (Фото: https://www.cyberpunk.net, CyberPunk).

Что же теперь перейдем к более детальной классификации, и рассмотрим какое-именно окружение бывает и какие цели должно преследовать. И так, локации условно делят на следующие виды:

Пустые и заселенные

На первом месте у нас значатся различные заброшенные здания, техника, заводы и целые города или жилые помещения и обитаемые местности, где присутствуют игровые персонажи или простые жители, а также представители животного и растительного мира. Среди наиболее известных игры в этом жанре "стоят" такие скалы игромира как: Stalker: Shadow Of Chernobyl, Silent Hill, Mist Survival, Necromunda

Локации подобного рода присутствуют в играх типа хоррора, ужастиков, артхаус, шутеры, выживания и многих других. Главная цель таких локаций создать ощущение покинутости пространства, ненужности, отрешенности, создать следы былой "кипучей" деятельности человека и предать окружению ореол мистики (Фото: https://technomode.ru)

Развалившиеся постройки, беспорядок, общий хаос и постоянное разрушение и гниение вот, что подчеркивает данные локации (Фото: https://www.kinonews.ru, Necromunda)

Опасные и безобидные

Если цель игрока выброс адреналина, можно выбрать локацию, где каждый персонаж желает вашей смерти по любым причинам и, напротив, может стать вашим спутником или напарником. Сюда также относятся различные "выживалки" и хорроры, типа Dead by Daylight, Days Gone, Rust.

Общая черта таких локаций, заключается в том, что пространство, не приветствует игрока в этом мире, оно ему враждебно, оно давит на него своей пустотой и мрачностью, стягиваясь вокруг него в плотный клубок безысходности, пустоты и непроглядной тьмы (Фото: https://news.xbox.com, Dead By DayLight)

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

Природные локации

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

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

Пространство этого окружения наполнено воздухом, движением и жизнью в целом. Среди игр, где эти черты наиболее удалось выразить это: Ведьмак 3 "Дикая охота", Assassins Creed, Ori and the Blind Forest, The Vanishing of Ethan Carter, Uncharted 4: A Thiefs End.

Максимально природные черты и фотореализм, горы, леса поля, буйство жизни, буйство красок все это подчеркивает природные локации (Фото: https://pluggedin.ru, Ведьмак 3).

Окружение может быть реально-существующим или выдуманным, но должно точно передавать ощущение действительности мира, в котором находится игрок. (Фото: https://pluggedin.ru, Assassins Creed).

Общий подход характерен не только для 3D игр, но и для 2D (Фото: https://pluggedin.ru, Ori and the Blind Forest).

Теперь давайте плавно перейдем к описанию различных вариаций игровых миров?

Мир апокалипсиса

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

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

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

Общий настрой таких локаций борьба за жизнь, существование в рамках одной персоны, небольшой коммуны или целого города. Среди классиков жанра можно выделить: Dead Rising 3, DayZ, State of Decay 2, Dying Light, Dead Frontier 2, Miscreated.

Мир в таких играх не всегда представляется чем-то враждебным, это всегда пост-результат деятельности человека, и когда человек уходит, природа начинает "забирать" себе территорию (Фото: https://www.playground.ru, DayZ).

Либо это совсем "невосстановимая" природа, уничтоженная под корень и не в состоянии прийти в нормальное русло в следствии множества факторов: ядерная зима, отравление токсичными отходами, радиоактивное загрязнение или изменение климата в целом в худшую сторону (Фото: https://overclockers.ru/, Metro 2033).

Античность и первобытность

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

Правильно, "нарубил мамонтов", принес в пещеру, женщину в охапку и в соседнее племя на дискотеку. Или быть мэром и править городами, создавать цивилизации и настраивать международные связи. Все это вы можете ощутить если поставите на свою "тачку" такие игрушки: Ceasar 4, Cleopatra, Far Cry Primal, Эсцилон.

Строительство городов, построение экономики, решение внешполитических и внутри-экономических вопросов все, здесь зависит от игрока, забота о городе, гражданах вот что здесь главное. Хочешь почувствовать себя мером или церем тогда тебе сюда. (Фото: https://store.steampowered.com, Ceasar 4).

Первобытные времена, борьба с природой и соплеменниками, мелкие войны, сражения с дикими животными, все это и многое другое предлагается для игрока. Цивилизация еще только зарождается, и ты ее начало. Дерзай!!! (Фото: https://mygamehunter.ru)

Мир киберпанка

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

Здесь приветствуются различные улучшения и модификации тела и отдельных его частей, много неона всех мастей и расцветок, бегущие надписи, строки, голограммы, необычные и футуристичные наряды, различные отсылки на азиатские страны: Япония, Сингапур, Китай, Малазия, которые ужа давно живут в 23 веке. Самым ярким представителем, на сегодняшний день, конечно же является CyberPunk 2077, за ним следует Deus Ex: Mankind Divided, Remember Me, Hard Reset, Observer, Watch Dogs 2.

Неоновые лампы, симбиоз человека и машины, бурное развитие технологий, ты уже в будущем дружище! (Фото: https://cubiq.ru, Hard Reset)

Открытые рынки азиатского типа, мелкая торговля, множество магазинчиков, пестрящих разноцветной рекламой, яркие, броские цвета, мегакорпорации, модификации всех цветов и расцветок. Добро пожаловать в мир киберпанка!!! (Фото: https://cubiq.ru, Deus Ex: Mankind Divided)

Мир стимпанка

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

Здесь все не так как у нас: необычная одежда, мебель, средства передвижения (наземные, воздушные, подводные). Здесь все подчиненно внутреннему состоянию прекрасного и даже немного эстетства. Вспомнить только: дамы в оригинальных шляпках, трости, старые винтовки, чертежи, механизмы вот прямо от слово механика, а не электроника и много чего еще, что находится на стыке будущего и прошлого, минуя настоящее. Благодаря этой идеи появилось множество чудесных игр: Warpstorm, Black Gold Online, Bioshock.

Шестеренки, старые заводские фонари, мебель, многочисленные трубы, вентиля, схемы и чертежи, и много других элементов должны отражать дух времени века, эдак, 17-18, но с переходом в будущее, как будто развитие технологий пошло по другому руслу. (Фото: https://grandgames.net, Warpstorm)

Корабли морские, переделанные под космические корабли, флаги, трюмы, мачты, различные старые машины, портовая атрибутика, старые кабаки и таверны - один из ярких примеров в стиле стимпанк. (Фото: Black Gold Online)

Мир фэнтези

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

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

Здесь, прям есть где разгуляться: Dragon Age: Origins, Gothic, Titan Quest, Middle-Earth: Shadow of Mordor, Neverwinter Nights, The Elder Scroll 5: Skyrim, World of Warcraft: Wrath of the Lich King и т.д.

Проселочные дороги, неровные каналы и мосты, покосившиеся заборы, горные селения все для того чтобы передать дух средневековья с частицей магии, которая пронизывает все. (Фото: https://onyxgame.com, Brothers: A Tale of Two Sons)

Замки джинов, магов, священные и тайные писания хранящиеся высоко в горах, заснеженные пики и изобилие запретных царств (восточных, азиатских), вот такое фэнтези и вызывает восторг у игрока (Фото: https://onyxgame.com, World of Warcraft)

Наш мир

Наконец, наш мир, его прототипом стали локации нашей планеты, пусть иногда эти места и не существуют на самом деле, но все же они максимально были приближены к реальности и создают ощущение у игрока что это происходит здесь и сейчас. Здесь можно выделить например GTA5, Jusсt Cause 3, Far Cry 3, Sleeping Dogs.

Все максимально реалистично, это наш мир, без малейшей тени на выдумку (Фото: https://gamingda.wordpress.com, Slepping Dogs)

Тоннели, мосты, метро, трафик, все взято из нашего мира, никаких сверх-способностей только умение взаимодействовать с этим миром (Фото: Watch Dogs)

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

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

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

Mail: anomalyimage@yandex.ru

Дзен

Телеграм

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru