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

Эту четырёхминутную короткометражку сделал студент из Нью-Йорка

Анимационные фильмы, созданные при помощи шлема VR, не являются особой новинкой. Но большинство из них – это отдельные сцены, зацикленные в повторяющуюся петлю типа анимированного GIF. Возможно, там двигается камера, выхватывает какие-то детали, но как таковой истории там нет. Но мультфильм Wired – это дело другое. Это один из первых анимационных фильмов, созданных в VR, содержащий несколько сцен и выраженную историю. Эта прекрасная короткометражка показывает жизнь мальчика, изучающего мир без беспроводных технологий. Он падает с кабеля, натянутого над огромными небоскрёбами, что заставляет местных жителей взглянуть вверх и насладиться небом.

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

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

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

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

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

Здравствуйте.

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



Для отрисовки я использовал javascript и canvas. Для каждого примера дана ссылка, где вы можете всё внимательно посмотреть. Можно заглядывать в исходный код, можно копировать себе — я не буду возражать. Материал вполне может пригодиться на занятиях и факультативах по физике, математике или информатике.

Итак, поехали.

NVIDIA PhysX, самый популярный в мире движок физической симуляции, отправляется в опенсорс.

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

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

Когда-то давно я получил высшее образование по физике. Позже еще самостоятельно выучился на веб-программиста. С тех пор я преимущественно работаю программистом, но продолжаю уделять время и физике, и технике (что-нибудь рассчитываю или конструирую), и науке в целом. Подобное «раздвоение» приносит интересные результаты. Оказалось, что некоторые факты в физике можно хорошо объяснить с помощью программирования.

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

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

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

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


Вот полная версия страницы.

Небольшая, но на мой взгляд очень полезная и интересная статья)

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



Микро-подталкивание — это своевременная небольшая анимация, которая побуждает пользователя выполнять «маленькую» задачу, которую они, возможно, забыли или не заметили.

Интерактивность помогает сделать пользовательские интерфейсы выразительными и простыми в использовании. Несмотря на большой потенциал, интерактивность, пожалуй, наименее понятно из всех дисциплин дизайна. Это может быть связано с тем, что интерактивность является одним из новых членов семейства пользовательских интерфейсов. Визуальный дизайн и дизайн взаимодействия восходят к ранним графическим интерфейсам, но интерактивный дизайн должен был дождаться более современного оборудования для плавного рендера анимации. Наслаивание интерактивности пользовательского интерфейса на традиционную анимацию вносит свою лепту недопонимания. Целую жизнь можно потратить на освоение 12 основных принципов Диснея, означает ли это, что интерактивность пользовательского интерфейса также сложно? Люди часто говорят мне, что проектировать интерактивность сложно или что выбор правильных значений неоднозначен. Я утверждаю, что в областях, наиболее важных для пользовательского интерфейса, интерактивный дизайн может и должен быть простым.

Предлагаю вашему вниманию перевод очень крутой статьи по анимации интерфейса.
The ultimate guide to proper use of animation in UX автора Taras Skytskyi.



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

Слева направо: оригинал, оснащённое поле (frame field) и окончательный результат. На базе зашумлённого растрового изображение в оттенках серого вычисляется оснащённое поле, выровненное по линиям картинки. На острые углы типа X- и T-пересечений накладываются векторы по обоим направлениям. Затем из этого поля извлекается топология чертежа — и производится окончательная генерация векторных кривых

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

Первые алгоритмы векторизации изображений появились в начале 1990-х годов и
использовались в инструментах для редактирования векторной графики, таких как Adobe Illustrator (Live Trace), CorelDRAW (PowerTRACE) и Inkscape. Несмотря на их широкое внедрение в промышленности, эти алгоритмы до сих пор страдают от серьёзных недостатков и находятся в активной разработке. В нескольких индустриях, где векторизация крайне необходима, включая традиционную анимацию и инженерное проектирование, она часто выполняется вручную. Дизайнеры кропотливо обводят отсканированное изображение с помощью инструментов рисования.

Визуально персонажи 3D-игр имитируются с помощью использования моделей, текстур и анимаций.

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

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

Возможность многократного применения анимаций позволяет использовать анимации из Asset store и с таких вебсайтов, как mixamo.com, для ваших собственных персонажей. Это экономит кучу времени!

В этом туториале вы узнаете, как подготовить гуманоидную модель в Blender и как перенести её в Unity. В частности, вы научитесь следующему:

• Создавать арматуру (скелет) персонажа и выполнять её риггинг (привязку скелета к мешу)
• Модифицировать персонаж добавлением аксессуаров и объектов
• Экспортировать модель в FBX
• Импортировать модели Blender
• Создавать и настраивать гуманоидный аватар
• Прикреплять к персонажу объекты
• Анимировать гуманоида в Unity

У меня есть ветка pbrt, которую я использую для проверки новых идей, реализации интересных мыслей из научных статей и в целом для исследования всего того, что в результате обычно оказывается в новой редакции книги Physically Based Rendering. В отличие от pbrt-v3, который мы стремимся сохранять как можно ближе к описанной в книге системе, в этой ветке мы можем менять что угодно. Сегодня мы увидим, как более радикальные изменения системы позволят значительно снизить использование памяти в сцене с островом из диснеевского мультфильма «Моана».

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

При рендеринге последней островной сцены из «Моаны» для хранения описания сцены pbrt-v3 использовал 81 ГБ ОЗУ. На текущий момент pbrt-next использует 41 ГБ — примерно в два раза меньше. Для получения такого результата достаточно было небольших изменений, вылившихся в несколько сотен строк кода.

Сегодня мы рассмотрим ещё два места, в которых pbrt тратит много времени при парсинге сцены из диснеевского мультфильма «Моана». Посмотрим, удастся ли и здесь улучшить производительность. На этом мы закончим с тем, что разумно делать в pbrt-v3. Ещё в одном посте я буду разбираться с тем, насколько далеко мы можем зайти, если откажемся от запрета на внесение изменений. При этом исходный код будет слишком отличаться от системы, описанной в книге Physically Based Rendering.

Оптимизация самого парсера

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

Я наконец-то собрался с силами и реализовал написанный вручную токенизатор и парсер для сцен pbrt. Формат файлов сцен pbrt парсить довольно просто: если не учитывать закавыченных строк, токены разделяются пробелами, а грамматика очень прямолинейна (никогда не возникает потребности заглядывать вперёд дальше, чем на один токен), но собственный парсер — это всё равно тысяча строк кода, которые нужно написать и отладить. Мне помогло то, что его можно было протестировать на множестве сцен; после исправления очевидных сбоев я продолжал работу, пока мне не удалось отрендерить в точности те же изображения, что и раньше: не должно возникать никаких различий в пикселях по причине замены парсера. На этом этапе я был абсолютно уверен, что всё сделано верно.

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

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

Память
BVH-дерево 9,01 ГиБ
Кривые 1,44 ГиБ
MIP-текстуры 2,00 ГиБ
Меши треугольников 11,02 ГиБ

Что касается времени выполнения, то встроенная статистика оказалась краткой и выдала отчёт только о выделении памяти под известные объекты размером в 24 ГБ. top сообщил, что на самом деле использовано около 70 ГБ памяти, то есть в статистике не учтено 45 ГБ. Небольшие отклонения вполне объяснимы: распределителям динамической памяти требуется дополнительное место для регистрации использования ресурсов, часть теряется из-за фрагментации, и так далее. Но 45 ГБ? Здесь определённо скрывается что-то нехорошее.

Walt Disney Animation Studios (WDAS) недавно сделала сообществу исследователей рендеринга неоценимый подарок, выпустив полное описание сцены для острова из мультфильма «Моана». Геометрия и текстуры для одного кадра занимают на диске более 70 ГБ. Это потрясающий пример той степени сложности, с которой сегодня приходится иметь дело системам рендеринга; никогда ранее исследователи и разработчики, занимающиеся рендерингом вне киностудий, не могли поработать с подобными реалистичными сценами.

Вот, как выглядит результат рендеринга сцены с помощью современного pbrt:


Остров из «Моаны», отрендеренный pbrt-v3 в разрешении 2048x858 с 256 сэмплами на пиксель. Общее время рендеринга на 12-ядерном/24-поточном инстансе Google Compute Engine с частотой 2 ГГц с последней версией pbrt-v3 составило 1 ч 44 мин 45 с.

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

Одна из самых сложных проблем современной 3D-анимации до сих пор заключается в такой, на первый взгляд, простой вещи, как отрисовка волос. На самом деле создание прически — это одна из наиболее сложных и трудоемких операций, которую можно себе вообразить. Анимационные и игровые студии уже достаточно давно научились использовать реальных актеров для снятия их движений и придания реалистичности действиям персонажей. То же касается и животного мира, когда речь идет о «звериных» анимационных фильмах, даже если персонажей делают антропоморфными (как, например, в «Зверополисе»). Но если анимация шерсти или коротких «полубокс» стрижек еще кое-как дается художникам, то с длинными женскими прическами все крайне и крайне неоднозначно. По этой причине многим студиям и проектам приходится отказываться от реализма в своих работах и использовать более простую, «мультяшную» рисовку.


Фото: Disney Research

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

Можно сказать, что девиз почти всех инди-разработчиков — это «Большие мечты при ограниченных ресурсах». Когда я начал работать над первой игрой Motion Twin для Steam Dead Cells, эта фраза стала и моим девизом.

Меня зовут Тома Вассёр, в течение целого года я был единственным художником Dead Cells. Я занимался дизайном и анимациями каждого аспекта игры. В одиночку мне пришлось создавать графический стиль, персонажей, монстров, анимации, спецэффекты (FX) и большинство фонов Dead Cells… Пока, к счастью, мне на помощь не пришёл мой злой брат-близнец Генель Массе. Количество художников Dead Cells удвоилось.

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

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

Неестественная анимация

Анимация — неотъемлемая часть современных веб-интерфейсов. От того, насколько она уместна, привлекательна и производительна, зависит немалая доля впечатлений пользователя от работы с сайтом или веб-приложением. Сегодня, в переводе тринадцатой части серии материалов, посвящённых особенностям JavaScript и связанных с ним технологий, мы поговорим об анимации, выполняемой средствами CSS и JS, а также обсудим подходы к её оптимизации.