что такое pbr в scrum
Уточнение Бэклога Продукта [Груминг Бэклога] (Product Backlog Refinement)
Уточнение Бэклога Продукта — это активность, которая проводится Владельцем Продукта при участии всех членов Скрам-команды. Включает добавление деталей, оценку и упорядочивание элементов в Бэклоге Продукта.
Не относится к официальным Мероприятиям Скрама, однако зачастую проходит в виде мероприятия (встречи).
В русском жаргоне адептов Скрама для этой практики прижилось название Груминг Бэклога (а также такие переводы слова Grooming как Уход за бэклогом и Причесывание бэклога). Это связано с тем, что в Scrum Guide до 2013 года использовался термин Grooming, а не Refinement.
В Скраме рекомендуется от 5 до 10 процентов времени каждого Спринта выделять на Уточнение Бэклога Продукта. Этот процесс включает:
Уточнение Бэклога Продукта проводится не для того, что уже взято в работу в текущем спринте, а для будущих спринтов. Хорошей практикой считается иметь в Бэклоге Продукта детально проработанные элементы как минимум на два Спринта вперёд. В этом случае Планирование Спринта существенно упрощается, поскольку Владелец Продукта и Скрам-Команда начинают планирование с понятным, прошедшим этап анализа и аккуратно оцененным набором пользовательских историй. Если же груминг Бэклога не был проведён (или был проведён недостаточно хорошо), Планирование Спринта растянется во времени, вызовет большое количество вопросов, потребует уточнений и/или выявит несоответствия.
Для пользовательских историй существует два критически важных этапа: «Готово к разработке» и «Сделано». Для них должны быть, соответственно, критерии готовности к разработке (Definition of Ready) и Критерии готовности (критерии завершения работы над историей, Definition of Done). И Уточнение Бэклога — это процесс или встреча, в ходе которого Владелец Продукта удостоверяется в том, что пользовательские истории «Готовы к разработке», то есть команда может немедленно взять их в работу и перевести их в «Сделано».
Одно из 5 Мероприятий Скрама. Эта встреча длится не более пятнадцати минут и проводится каждый рабочий день в одном и том же месте в одно и то же время. В нем принимают участие все разработчики. На нем озвучивается информация для оценки прогресса и отмечаются препятствия. В результате разработчики могут прийти к необходимости перепланирования работы внутри Спринта.
Одно из 5 Мероприятий Скрама. Проводится в конце Спринта, чтобы клиенты и заинтересованные лица провели инспекцию Инкремента и дали обратную связь по нему, а Скрам-команда, при необходимости, сделала адаптацию Бэклога Продукта. Для Спринта длиной в месяц Обзор Спринта длится не более 4 часов.
Одно из 5 Мероприятий Скрама. На этой встрече Скрам-команды происходит планирование работы на следующий Спринт. Для Спринта длиной в месяц встреча длится не более 8 часов. Она завершается созданием Бэклога Спринта и включает обсуждение 3-х тем:
Одно из 5 Мероприятий Скрама. Ретроспектива Спринта дает Скрам-команде возможность провести инспекцию своей работы и создать план улучшений на следующий Спринт. Ретроспектива проходит после Обзора Спринта, перед Планированием Спринта. Для Спринта длиной в месяц эта встреча ограничивается 3 часами.
Одно из 5 Мероприятий Скрама, которое является контейнером для других мероприятий. Спринты — это короткие регулярные циклы длиной не более четырех недель. Итерации работы должны быть достаточно короткими, чтобы команда не теряла концентрацию, и при этом достаточно длинными, чтобы поставлять значимый инкремент работы. Все остальные Мероприятия Скрама проводятся в рамках Спринта. Следующий Спринт начинается сразу же по окончании предыдущего.
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми
Что такое Уточнение Бэклога Продукта
Уточнение Бэклога Продукта — это встреча для прояснения будущих задач Команды Разработки. Владелец Продукта и Команда собираются, когда не до конца понимают, с какой стороны подступиться к задачам в следующем Спринте. После встречи они чётко представляют, что предстоит cделать, сколько сил затратить и к чему это приведёт.
Сам Бэклог Продукта — это список возможных улучшений. Записаны они бывают по-разному, например, одни улучшения полностью понятны Команде, другие — всего лишь хотелки без конкретики. И если сразу взяться за такие хотелки, есть риск не уложиться в Спринт или вовсе не выпустить Продукт. На встрече их конкретизируют.
Встреча Владельца Продукта и Команды Разработки
На уточнение приходят Владелец Продукта и Команда. Приглашают и клиентов с экспертами, если без их мнения нельзя обойтись. Скрам-мастер тоже может прийти, чтобы помочь провести встречу, сформулировать задачи или упорядочить Бэклог Продукта.
Собраться без Владельца Продукта нельзя — только он вносит изменения в Бэклог. А вот Команде собираться всем составом необязательно. Цель встречи известна заранее, и каждый сам определяет, будет ли он полезен и нужно ли ему вообще присутствовать на уточнении задач.
Студия пирсинга год работает по Скраму. Сейчас она планирует запустить новую услугу: купить оборудование, найти ещё одного мастера и дать рекламу в социальных сетях. Хочется также создать блог и открыть франшизу. Но если первые три задачи понятны, то что делать с блогом и франшизой — студия толком не знает.
Решили сначала разобраться с блогом. На встречу пришли Владелец Продукта, маркетолог и два мастера пирсинга. Маркетолог пришёл вместе с редактором.
Помогает детально проработать Бэклог Продукта
На встрече участники разбивают задачи на маленькие, объединяют в большие или меняют порядок Бэклога. Владелец Продукта и Команда Разработки проясняют задачи до готового к работе состояния, когда их можно сразу включить в план и реализовать к концу следующего Спринта.
Для доведения задач до ума участники встречи определяют, насколько ценна каждая задача, как она зависит от других и по каким критериям её принимать. Все задачи записывают максимально коротко, чтобы не превратить Бэклог Продукта в многостраничного монстра.
На встрече маркетолог рассказал, как раскрутить блог, что для этого потребуется и что в итоге получит студия. Мастера пирсинга поделились, чем интересуются клиенты, чего боятся и какие советы им нужны. Редактор объяснил, как организовать работу над статьями и сколько человек к этой работе привлечь.
Прямо во время встречи участники дополняли Бэклог Продукта. В итоге стало понятнее: не создать блог, а придумать дизайн, составить список тем и разработать стратегию продвижения. Эти задачи уже можно поручать и планировать на следующий Спринт.
Длительность и частоту встречи определяют участники
Уточнение Бэклога Продукта — полезная, но не обязательная встреча, и нигде не описано, сколько и как часто она должна идти. Владелец Продукта с Командой Разработки определяют её длительность и частоту сами — и отводят обычно не больше 10% своего рабочего времени.
Студия работает недельными Спринтами по 30 часов, а на Уточнение Бэклога Продукта собирается дважды в неделю по 1,5 часа — это как раз 10% рабочего времени.
Одной встречи хватило, чтобы полностью разобраться с блогом, поэтому на следующей встрече обсудят уже открытие франшизы.
Уточнение Бэклога Продукта — хоть и необязательная, но часто необходимая встреча. Благодаря ей Владелец Продукта и Команда Разработки детализируют задачи Бэклога — в итоге они понимают, над чем работать в следующем Спринте, и планирование проходит эффективнее.
Мы уже рассказали, как в Скраме собирают обязательные встречи. Кроме Планирования Спринта есть Ежедневный Скрам, Обзор Спринта, Ретро.
Сергей Васин Редактор Unusual Concepts
Планирование за час и другие оптимизации scrum ивентов
Чистый скрам — как единорог на музыкальном фестивале: вроде бы он существует, все о нём говорят, только вот показать тебе его никто не может. Так же сложилось и у нас в команде, об этом и поговорим. А если конкретнее — о том, как мы сократили время на встречи и не потеряли пользу от них.
Ясное дело, в Интернете полно статей о том, кто и как этот скрам у себя взращивал, что получилось, а что нет. Я не претендую на уникальность и всего не читал, ибо писателей таких статей гораздо больше, чем у меня свободного времени. Однако хочу рассказать, как мы в команде Android-разработки выстроили (и еще строим) процесс, практически не тратя время на встречи и обсуждения. Получилось так именно потому, что моё время (я PO) и время команды сильно ограничено, и я стремлюсь сделать всё, чтобы не заниматься процессами ради процессов и при этом сохранять производительность и прозрачность на высоком уровне.
Дам небольшое представление о себе, чтобы у читателя начал складываться портрет человека, от чьего лица идет повествование.
Я — продуктовый менеджер Android-команды в компании Wrike. Кроме этого мне выпала почётная роль скрам-мастра.
Мы — satellite app, а большая часть наших клиентов выполняет работу в офисе и использует web-версию продукта. Ключевых релизов у нас около 3-х в квартал, но приходится уделять много времени на поддержку улучшений из web-версии. Из-за активного развития веба мы релизимся раз в две недели. Функция приложения — не терять связь с командой и следить за рабочими процессами. Настраивать окружение можно только в web-версии. Стратегия развития продукта — увеличить аудиторию и её активность на мобильных устройствах. Наша команда состоит из пяти Android-разработчиков, двух QA, одного UX-дизайнера, одного продуктового менеджера. Все ребята очень скиловые.
Теперь, когда у читателя сложилось некоторое представление о команде, я перейду к сути статьи — процессам. Сегодня речь пойдёт про такие элементы скрама, как: PBR, Retro, Planning, Daily. Моя основная цель как скрам-мастера — использовать ценность этих встреч и одновременно тратить на них минимум времени. Кроме того, что это просто логично с точки зрения оптимизации ресурсов, у нас есть еще одно ограничение: наша команда должна поддерживать изменения двадцати продуктовых команд. Мы не поддерживаем все изменения, но те, что затрагивают существующий функционал, требуют нашего участия. В статье я расскажу подробнее о том, сколько времени мы выделяем на каждый из этих четырёх ритуалов и какие плоды приносят такие временные рамки.
Подсмотрел в интернете такое определение: «PBR (Product Backlog Refinement) — это процесс добавления деталей, оценок и порядка к элементам в списке невыполненных работ». По своему опыту знаю, что на таком событии часто присутствует вся команда, чтобы увидеть задачу заранее, подсветить неочевидные моменты. Но такая встреча требует много времени, а у нашей команды его нет, потому что изменений с web-версии прилетает много. Поэтому мы изменили формат встречи.
Как показала практика, есть список задач, которые могут быть очень сложными или нехарактерными, на первый взгляд, для продукта. Перед исследованием таких задач я собираю всех желающих и рассказываю суть происходящего — это у нас называется Forum. Происходит такое крайне редко, однако порядочно сплачивает команду и подогревает интерес к задаче, вызывает привыкание причастность к продукту. И растёт эта причастность именно из-за своей нерегулярности. Такое собрание становится чем-то особенным, нерутинным и потому значимым.
Разбор работы происходит следующим образом: каждая задача (story) планируется на одного человека (давайте назовём его «чемпион»), и он проводит исследование того, что конкретно нужно по ней сделать. Добавляет описание, уточняет у UX-дизайнера, как должны работать какие-то моменты, если этого не хватает в доке, советуется с бэкендом и пишет подробный план. На самом деле получается нечто вроде Spike’а.
Такой подход себя хорошо зарекомендовал по следующим причинам:
Retro
Тут я хвастаться не буду, просто скажу, что в команде есть правило: вместе с проблемой предлагай решение. Ребята в команде ответственные, хотят работать хорошо и не отвлекаться на неприятные мелочи, поэтому они заинтересованы, чтобы процессы были понятные и надёжные.
Позвольте мне привести пример задачи (проблемы), что встала перед нами на Retro — забываем добавлять аналитику. Может показаться, что она касается скорее PM’a, чем разработчиков, но, как я сказал, ребята в команде мотивированы и хотят делать свою работу хорошо. Из-за ограниченного ресурса аналитики вести этот процесс идеально не удаётся, потому прямо на retro мы выстроили конкретный процесс и разделили обязанности между членами команды так, что каждый вносит свою пользу на определённом этапе. Также важное замечание: если за час мы не успели придумать, как решить проблему, мы соглашаемся попробовать предложенные идеи и корректировать их по ходу.
Но случаи бывают и пограничными, когда профессиональные цели несколько расходятся, и между членами команды могут появляться шероховатости, иначе говоря, инженеры больше сфокусированы на технической части, PM на продукте, а дизайнер на удобстве и графике. Но поскольку наша главная общая цель — создать хороший продукт, то мы не стесняемся обсуждать моменты на стыке интересов членов команды. И тут стоит сказать, что у нас принято быть открытым и честным. Если же в команде кто-то стесняется высказать свою точку зрения, то высока вероятность, что в команде существует неравноправие или есть скрытые конфликты. Лишь равноправие в системе позволяет быть открытым. Если интересно, как нам это удалось, дайте знать в комментариях, а пока поехали дальше.
Planning
Моя любимая часть скрама. Нравится она мне по двум причинам:
На первый взгляд может показаться кашей, однако из-за того, что команда сама планирует, она хорошо разбирается в происходящем и оперативно вносит изменения
Daily
В первую очередь, это про синхронизацию, но хочу отдельно подчеркнуть мою роль как продакт-менеджера в этом событии. Я уже говорил о том, что в команде важно равноправие. Климат должен быть такой, чтобы ребята чувствовали себя командой, а не индивидуальными контрибьюторами. Потому, будучи продакт-менеджером, я рассказываю новости компании, а также чем я занимался, что узнал и что меня ждёт. Перед командой секретов у меня нет, хотя крайне редко возникают исключения: некоторые вещи нас просят придержать до официального анонса. Но такие анонсы — это прям что-то из ряда вон выходящее.
Spike на 1 день + редкие встречи в формате Forum для введения в курс дела ребят по необычным задачам дают хорошее понимание о том, какая работа нам предстоит. Планирование занимает всего час и проходит в свободной форме, все люди прекрасно договариваются о том, что им нужно делать. Retro проходит всегда в одном формате, но очень продуктивно, и мелочи в процессах обтачиваются регулярно. А открытость продакт-менеджера в дейли формирует в команде равноправие и доверие.
Для меня, в конечном счёте, лишь три показателя имеют смысл: уровень удовлетворённости команды, чтобы ребята не выгорели, качество продукта и скорость исполнения задач.
И эти показатели в нашей команде довольно высоки:
Icing on the cake
Немного математики. За двухнедельный спринт получается:
Ясное дело, что это число стоит умножить на количество людей в команде, чтобы понять, во сколько человеко-часов вам обходятся скрам ивенты. Мой показатель — 5.6% ±2.5% при размере команды в 9 человек. Чем больше будет команда, тем выше будет расти это значение. Но давайте не забывать, что скрам-команда имеет рекомендуемые размеры, а значит и показатель времени, которое тратится на командные события, тоже имеет разумный предел.
В общем-то, пока всё. Будет идеально, если поделитесь цифрами: сколько времени занимают скрам ивенты у вас. Ну и чтобы сделать статью более ценной, давайте обсудим пользу и вред, который, по вашему мнению, могут принести такие оптимизации.
Эффективный PBR
PBR не является официальным событием в Скраме, но он снижает вариативность элементов Бэклога Продукта (PBI) перед тем как они попадут в Спринт.
В этой статье я опишу что, с моей точки зрения, может обеспечить эффективность PBR в Скрам.
Почему PBR важен
PBR не является официальным событием в Скраме, но он снижает вариативность элементов Бэклога Продукта (PBI) перед тем как они попадут в Спринт. Когда верхние элементы Бэклога Продукта приходят в состояние “ready”, то в Спринте у команды возникает меньше “сюрпризов”, а вероятность достижения Цели Спринта возрастает.
Разработчики общаются с клиентами напрямую
Очень часто замечаю дисфункциональные имплементации Скрама, когда между разработчиками и рынком стоят промежуточные лица, препятствующие прямой коммуникации и являющиеся источником потерь. Примеры потерь:
Стейкхолдеры (внутренние, клиенты, пользователи) в хорошем Скраме общаются с Командой Разработки напрямую. Интервью с пользователями, уточнение требований напрямую со стейкхолдерами является нормальной активностью Команды Разработки.
Такой подход лежит в основе масштабируемого Скрама. Когда продукт разрабатывают много команд, то у Владельца Продукта не хватает времени на прояснение элементов Бэклога Продукта. Он делегирует эту активность командам и оставляет за собой упорядочивание Бэклога Продукта.
В масштабируемом Скраме команды выясняют детали требований напрямую со стейкхолдерами. Владелец Продукта оставляет за собой упорядочивание Бэклога Продукта.
Команда в полном составе присутствует на PBR
Некоторые команды высылают на PBR представителей. Несмотря на то, что такой подход работает в некоторых контекстах, у него есть побочные эффекты. Создаются вынужденные передачи и потери. Знания об элементах Бэклога Продукта находятся в головах лишь у нескольких лиц. Этого можно избежать, если на PBR присутствуют все участники команды.
Анализом занимается вся команда, не бизнес-аналитики
Еще один анти-паттерн, который я часто наблюдаю — выделенные бизнес-аналитики, занимающиеся только бизнес анализом. Они служат прокси между стейкхолдерами и командой. Часто в такой структуре в Спринте N-1 проводится бизнес-анализ, а в Спринте N непосредственно сама разработка (код, тестирование и т.д.).
Бизнес-анализ является одной из функций в команде и за нее отвечают все, а не выделенный бизнес-аналитик. Более того, возвращаясь к оригинальной концепции Скрама, Команда Разработки выполняет все активности, начиная от интервью с пользователями до поставки на рынок ценности и поддержки продукта. Работы максимально распараллеливаются. Для этого команда самоорганизуется и использует различные техники. Например, парное программирование, Swarming, моб-программирование.
Пример эффективного PBR
Ниже я детально опишу, как мы проводили один из PBR-ов. Контекст — продуктовая группа (≅30 человек), разрабатывающая один продукт. Соответственно, имеем один Бэклог Продукта и одного Владельца Продукта. На встречу приглашены две команды разработчиков (14 человек), стейкхолдеры из смежных подразделений, которые выступали главными заказчиками функциональности. Мы хотели, чтобы разработчики напрямую уточнили требования со стейкхолдерами.
Цель, желаемые результаты, рабочие договоренности. (5 мин)
Любая эффективная встреча начинается с определения ее цели и желаемых результатов. В нашем случае цель звучала так: “декомпозировать огромную фичу, приоритезировать полученные элементы, определить минимальный необходимый набор функциональности (MVP) для реализации”. Мы договорились о том, что встреча займет не более 2х часов и через час сделаем перерыв.
Верхнеуровневое выравнивание (10 мин)
В открытой дискуссии мы потратили не более 10 мин на обсуждение фичи в формате: Кто, Что и Зачем.
Формируем смешанные группы (5 мин)
Общение в малых группах проходит эффективно, когда в них есть как минимум один стейкхолдер и представители разных команд. Нам удалось сформировать 3 такие смешанные группы. Каждая группа сформировала станцию в общем помещение и продолжила работу.
Первый раунд: разбиение (20 мин)
Мы попросили команды на выходе получить дерево с вариантами разбиения. Сверху помещается изначальное требование. Затем подбираем подходящий паттерн разбиения, получаем следующий уровень. И так далее.
Второй раунд: переход на соседнюю станцию (5 мин)
Так как в предыдущем раунде все группы работали над одним и тем же заданием, то мы попросили команды оставить одного представителя на месте, а остальных перейти по часовой стрелке к следующей станции. Это нужно для того, чтобы узнать, что делали другие команды, а также для получения обратной связи.
Перерыв (10 мин)
Вовлеченно работать более 50-60 минут тяжело. Даже если участники говорят нам о том, что они не устали и готовы работать дальше, мы настаиваем на небольшом перерыве. Чай, кофе и глюкоза (конфеты, печенье) очень полезны. Тем ни менее, хороший знак, если кто-то остается на станциях и продолжает работать. Это сигнал высокой вовлеченности. Значит PBR эффективен.
Третий раунд: завершение разбиения (20 мин)
После перерыва мы дали еще 20 минут на то, чтобы завершить разбиение. Цель в том, чтобы получить небольшие элементы Бэклога Продукта, которые могут быть завершены в Спринте (“ready”). Ниже один из вариантов разбиения, который получился у одной из групп:
Четвертый раунд: представление результатов (20 мин)
Группы по очереди представляют свои варианты разбиения в открытой дискуссии. Интересно, что они пришли к аналогичным результатам. Минимальный набор фич (MVP) оказался на удивление мал. Главным инсайтом PBR оказалось то, что основную бизнес-ценность можно достичь относительно небольшими усилиями. Все согласились с тем, что формат проведения PBR оказался очень эффективным. Когда разработчики напрямую общаются с представителями бизнеса, работая со стикерами и маркерами, фиксируя результаты на листах бумаги, результаты оказываются просто удивительными.
О PBR на пальцах
В этом тексте я расскажу немного о PBR — концепции рендеринга, основанного на физических принципах. PBR применяется в современной компьютерной графике, и мы поговорим о том, что это такое и как готовится, и какие важные вещи стоит знать тем, кто собирается или уже имеет дело с подготовкой материалов. Акцент смещён больше в сторону игр и игровых движков, где эта концепция сейчас используется очень широко.
Прежде чем перейти к конкретике, пара слов для «прикрытия тыла».
У каждого движка и рендера есть свой пайплайн разработки, который зачастую уникален, как снежинка, и не пересекается полностью с другими. Обусловлено это в том числе и тем, что PBR относительно молодая методология, и можно сказать, что мы видим первое поколение таких движков, стандарты только-только начинают вырисовываться, поэтому есть разница и нюансы в разных реализациях. А также тем, что PBR не строгий набор требований, а скорее общее направление развития.
При написании этого текста я полагался на собственный опыт плюс теорию касательно нескольких пакетов: Unreal Engine 4, Marmoset Toolbag 3, Substance Painter. Поэтому какие-то вещи в других пакетах будут выглядеть иначе, но в целом теория универсальна.
Более подробно я опишу самые важные вещи, а в конце по остаточному принципу упомяну о том, что в PBR применяется, но не столь важно или хитро в устройстве.
Я намеренно использую термины в непереведённом виде, потому что самые актуальные и полные источники информации всегда на английском языке, и если кто-то сидит и ждёт перевода, он автоматически попадает в отстающие и зависимые от него. На мой взгляд, правильно сразу запоминать те термины, которые используются в индустрии. И гуглить, разумеется.
Материал подготовлен с участием Телеграм-сообщества Maya3D.
Про основы
Для начала давайте немного углубимся в историю. Опыт подсказывает, что лучше объяснить значение терминов и базовых понятий сразу, но если вы уже их знаете, то можете смело пропускать этот раздел.
Далее вы заметите, что PBR заимствует термины откуда попало, немного меняя их, и это нормально.
PBR — это аббревиатура от physically based rendering, что примерно означает физически корректная визуализация, и эти слова говорят сами за себя. Иногда используется термин PBS (тут rendering меняется на shader), кое-где даже есть PBT (а тут появляется texturing). Впрочем, разница минимальна — дело в традиции, и традиционно чаще используется именно термин PBR.
Последние несколько лет это мейнстрим современных систем рендеринга, от реалтайм и игровых до так называемых оффлайн-рендеров. Из названия вытекает некое следование законам физики, законам реального мира, и это уточнение как бы сообщает нам: раньше было не так. Давайте разбираться, как было и как стало, и каким боком вообще это нам вышло.
В трёхмерной графике с самого начала её жизни были реализованы самые разные подходы к отображению на экране, пока не стало понятно, что воспроизведение механизмов реальности даёт результаты более реальные, так сказать.
Примерно такая же история произошла со скелетной анимацией персонажей, которая «закопала» вертексную.
Если мы моделируем реальность, так давайте использовать её законы и архитектуру, автоматизируя константы и перекладывая часть работы на софт. Рендеры всё больше стремятся работать так, как работает наша реальность, с каждым поколением железа вводя всё новые подходы, позволяющие отказаться от фейков.
Оффлайн-рендеры, это рендеры, которые работают не в реалтайме, например, Vray или Arnold.
С какой-то стороны, наверное, это сужает полёт фантазии и обрубает побеги стилизации, но именно что наверное.
С другой стороны, уловки и фейки переходят на новый уровень, что тоже прогресс.
В реальном мире, окружающем нас, электромагнитное поле является основой взаимодействия в масштабах выше атомарных и ниже планетарных. Всё, что мы видим и можем потрогать, доступно нам благодаря именно ему. Человек — существо неидеальное, мы можем видеть не самую большую часть электромагнитного спектра, но и с ней существует масса тонкостей, которые мы используем в силу понимания. Всё, что мы видим вокруг нас, — это свет и его капризы. Неплохое вступление, а главное — очевидное, да?
Абсолютное большинство людей — трихроматы, но есть небольшой процент мутантов-тетрахроматов, которые различают больше оттенков и видят мир разнообразнее. И чаще это женщины.
В PBR свет стал менее условен, чем ранее. BxDF описывает не только как он достигает поверхности, но и как отражается от неё, учитывая характеристики материалов. Это позволяет более точно описать сцену и передать результат, максимально приблизившись к реальности.
Одно из ключевых изменений, которое принёс PBR, — это универсальность материалов в любом освещении. Правильно настроенные материалы будут выглядеть корректно всегда и в любой сцене.
В предыдущем же поколении рендеров не учитывалась микроповерхность и характер блика, типы материалов проводник/изолятор; диффузное отражение несло в себе полутени и даже нарисованные блики; не было величин отражения из реального мира; материалы не были универсальны для любой сцены и освещения.
Про вещество
Классификация взята из реального мира (с упрощениями) и старается следовать названию.
Проводники проводят электрический ток, имеют кристаллическую решётку и прочие «радости» из школьного курса физики. У них нет диффузного отражения и подповерхностного рассеивания, их поверхность не рассеивает свет, она непроницаема для него, но поглощает какую-то его часть, отражая волны конкретных длин, — цветной блик.
Впрочем, ток неважен для PBR. Кожа тоже проводит ток, но в PBR это не металл, а значит, не проводник.
Изоляторы рассеивают свет, он проникает в их поверхность; они имеют диффузное отражение и подповерхностное рассеивание, бликуют белым светом.
Оба типа материалов обладают эффектом Френеля.
Про пайплайны
Традиционно у нас есть два пайплайна для материалов и их подготовки: specular и metalness. Обычно имеется в виду, что в specular есть соответствующая карта зеркального отражения, а в metalness её нет, но есть маска металличности, и на этом можно закончить.
Разумеется, тут всё не так просто.
Пайплайн specular действительно имеет карту specular, которая контролирует интенсивность и цвет блеска на F0, значения которой полностью в руках художника, и не имеет встроенных констант в шейдере. Френель иногда контролируется отдельно, albedo контролирует только цвет, gloss/roughness контролирует характер отражений, тут всё просто.
Metalness не имеет отдельной карты интенсивности блеска, эти значения вшиты в шейдеры в пределах 2-5% для диэлектриков и 70-100% для проводников. Взаимосвязь карт тут немного выше: albedo, metalness и roughness карты суммарно влияют на цвет, интенсивность и характер зеркального отражения. В этом пайплайне на одну карту меньше, а с учётом возможности упаковки grayscale-карт в одну RGB, такие материалы занимают меньше памяти системы.
Выбор современных рендеров почти полностью пал на metalness в виду его экономичности и большей автоматизации, ибо такие шейдеры берут на себя корректные расчёты Френеля. Несмотря на то, что specular даёт больше контроля, контроль этот зачастую избыточен и отбирает больше времени и усилий при схожих результатах. Поэтому мы будем говорить именно о metalness-пайплайне в целом.
Различия пайплайнов и карт. Wes McDermott и Allegorithmic.
Про BRDF и GGX
Основа отличия PBR от предыдущего поколения в смене BxDF. BxDF — bidirectional X distribution function, что примерно звучит как двулучевая функция X-способности. А способностей у этого семейства функций несколько: это как минимум reflectance, transmission и scattering — отражение, передача и рассеивание соответственно (в профильной литературе и статьях художник чаще встречает вариант BRDF).
Эти функции описывают поведение луча при взаимодействии с поверхностью: как он рассеивается (то есть проникает в верхний слой и возвращается), зеркально отражается или проходит через прозрачный материал.
В нашей истории BxDF тесно связана с microfacet theory, у которой тоже есть масса реализаций, зачастую названных по фамилиям авторов: Cook-Torrance, Ashikhmin-Shirley, GGX и так далее. GGX как раз одна из реализаций microfacet theory — теории микроповерхностей, которая используется почти повсеместно. Она представляет упрощённую модель микроповерхности, которая в связке с BxDF имитирует реакцию на свет при всех типах взаимодействия.
Facet можно перевести и как «грань», что тоже имеет смысл. В упрощённой теории поверхность есть набор мелких граней.
GGX никак не расшифровывается, набор букв взят из переменных, используемых в формулах (или чья-то фамилия затесалась — история скрывает). Художники могут видеть этот термин в настройках параметров roughness/gloss.
Например, одна из G — это bidirectional shadowing-masking function, двулучевая функция самозатенения/маскирования.
Микроповерхность и её влияние на зеркальное отражение. Wes McDermott и Allegorithmic.
Сохранение энергии
Сохранение энергии — energy conservation — это тоже одна из фундаментальных констант PBR и означает она то, что поверхность не может вернуть больше света, чем получает. В частности, отражение albedo и specular reflection складывается, и если specular ярче, то albedo менее ярко, и наоборот. В целом это автоматизированная вещь в движках, иногда есть возможность включать и выключать, например в Marmoset Toolbag.
Про Френель
Огюстен Жан Френель (Augustin-Jean Fresnel), французский физик XIX века, создатель волновой теории света и кучи других крутых штук, описал эффект имени себя, который заключается в том, что уровень отражённого от поверхности света прямо зависит от угла зрения к этой поверхности. Под прямым углом, то есть F0, мы получаем минимальный уровень зеркально отражённого света, который доступен материалу. И чем больше угол, тем больше света мы поймаем, приближаясь к 100%.
Согласно этому эффекту, блик есть у любого материала, блестит в принципе всё, надо только найти правильный угол.
Когда мы говорим об интенсивности блеска в целом, мы всегда имеем в виду блеск на F0 — это то, что находится под контролем художника через параметры albedo/roughness/metalness.
Схема эффекта Френеля. Wes McDermott и Allegorithmic.
Про диффузное отражение
Albedo. Diffuse. Base color.
Схема взаимодействия в диффузном отражении. Wes McDermott и Allegorithmic.
Это свет, который падает на поверхность и частично поглощается ею, а частично отражается, беспорядочно рассеиваясь в верхних слоях и возвращая наблюдателю цвет этой самой поверхности. Иногда в таком случае говорят, что он окрашивается в цвет поверхности, но мы же говорим о физической корректности, так что стоит повторить — свет не окрашивается, к нам возвращается та часть спектра, которая не поглотилась и не потерялась. Та часть видимого света, которая поглощается поверхностью, в реальном мире переходит в тепловую энергию, и в PBR это тоже может учитываться, но сильно зависит от применяемого шейдера и в данном случае второстепенно.
Поглощение света и возврат наблюдателю только непоглощённых волн. Wes McDermott и Allegorithmic.
Поведение материала при диффузном отражении определяется картой albedo, или base color, или даже кое-где ещё diffuse. Разница в этих названиях вытекает из традиции и разных пайплайнов разработки движков, но поведение везде одинаковое — во всяком случае, должно быть. На карте albedo должен быть запечатлён цвет, каким бы он выглядел под прямым углом камеры к поверхности и 100% освещении белым цветом. Без теней, полутеней, бликов и всего того, что не втискивается в определение «чистый цвет». Это ключевое отличие текущего диффузного отражения в PBR от предыдущего поколения рендеров, где термин diffuse тоже используется, но немного иначе.
Фотография предмета с фильтром поляризации под прямым освещением фиксирует его albedo, например. Поляризация убирает блики.
Казалось бы, больше про цвет сказать нечего, но тут есть ещё тонкости.
Карта диффузного отражения оказывает влияние на рендер чистых металлов в metalness-пайплайне, окрашивая блик в соответствующий цвет. Помимо этого, карта albedo прямо влияет на specular reflectance для металлов, позволяя варьировать его в сочетании с metalness-картой. Это довольно хитрая конструкция, но в целом выглядит так: когда мы делаем материал изолятора, то рисуем чёрную маску metalness и шейдер присваивает блеск на F0 в 4%. Когда мы делаем переходы в metalness вплоть до белого, то есть чистого металла, на интенсивность его блеска оказывает влияние яркость в карте albedo. Чем ярче цвет в albedo, тем интенсивнее блеск, который приближается к значению в 100%. Контроль над уровнем блеска изолятора у нас отсутствует. Предполагается, что разница в 2-4% некритична и маскируется через roughness, либо тонко настраивается через specular reflectance, если это необходимо и есть возможность.
Этот пример описан с учётом шейдеров UE4, Marmoset Toolbag и продуктов Substance. Но в целом работает везде.
Нельзя недооценивать художественный эффект от цвета поверхности. Зачастую это ускользает от внимания художников, и они делают чёрный пластик чёрным, чтобы было «как в жизни». Но монолитных цветов в реальности обычно нет, и вариации цвета почти всегда присутствуют в материале, это нужно понимать и использовать.
Диффузное отражение описывается RGB-картой, или в терминах движков — массивом Vector3, что логично, мы же про цвет говорим.
PBR-валидация
Так как PBR стремится к реальным параметрам и характеристикам, значения для яркости albedo должны быть валидированы и приведены к диапазонам реальных значений, а они не могут опускаться ниже 30-50 sRGB и подниматься выше 240 для диэлектриков. В случае с чистыми металлами значение в 240 может повышаться до 255, потому что это уже не значение диффузного отражения, а значение specular reflectance.
Но, разумеется, тонкости есть и здесь.
Например, одно из самых тёмных веществ в обычном мире — это уголь. Значение яркости albedo, переведённое в sRGB, у него составляет 50, и это рядом с границей минимума того, что может позволить себе PBR для диэлектриков. Значения ниже слишком тёмные и могут некорректно выглядеть в разных световых условиях.
Не так давно кое-кто напрягся и создал материал, поглощающий 99% света и выглядящий как чёрная дыра в пространстве.
Потому что диффузное и зеркальное отражения работают в паре. Слишком тёмные значения albedo будут влиять на разницу между самим albedo и specular reflectance, и художникам придётся «выкручивать» свет для нормализации бликов на F0 и диффузного отражения, что повлечёт за собой пересвет всей сцены, и материалы в итоге станут неуниверсальны и применимы только к конкретному освещению.
Почему это может быть не важно?
Потому что зависит от композиции. Если рендерится презентация отдельной модели, а в сцене нет глобального освещения и рейтрейсинга отражений, но есть HDR-освещение, то в целом можно делать значения за пределами 30-50 sRGB. А ещё есть полумифический зверь «артовость». «Важнее не физическая корректность, — говорит он, — а восприятие». И тут можно и нужно иногда нарушать с трудом установленные законы.
Крайне спорный вопрос о допустимости нарушения законов PBR и соответствия реальности. Где-то это играет на руку восприятию, а где-то нужно выдерживать все стандарты. Примеры и обсуждение выходят за рамки этого текста.
В целом выдерживание предела яркости albedo остаётся на совести художника или его арт-лида, а немалая часть работ в PBR, существующих сегодня, не пройдут эту валидацию по нижнему пределу, что не мешает им быть качественными и корректными на неискушённый взгляд. Разница становится видна, только если проверить значения и подтянуть до нижнего предела или если отдельно выполненную модель поместить в сцену с корректным освещением.
Но даже если мы не заморачиваемся на валидацию, не стоит использовать чистый чёрный цвет в 0 sRGB для диэлектриков.
PBR-валидация обеспечивается разными инструментами как в движках, так и в редакторах. Например, в Substance Painter есть фильтр, который работает поверх всего стека слоёв, проверяя значения.
PBR-валидация в Substance Painter. Wes McDermott и Allegorithmic.
Чарт значений интенсивности для некоторых материалов. Данные взяты у Sébastien Lagarde и DONTDNOD.
Про зеркальное отражение
Specular reflectance
Specular — это латинское слово, которое и переводится как «зеркальный».
Схема взаимодействия света при зеркальном отражении. Wes McDermott и Allegorithmic.
Здесь имеется в виду та часть светового потока, которая отражается от поверхности по закону угла падения и возвращается к наблюдателю в полном объёме. Specular reflectance, или зеркальное отражение, — это и есть блики, и оно очень тесно связано с характеристиками микроповерхности. Встречается в обоих пайплайнах, но прямо контролируется в specular-пайплайне и опосредованно в metalness.
Дело в том, что прямой контроль интенсивности блеска — очень подлая штука. Мы помним про проводники и изоляторы, но точные значения интенсивности вспомнит мало какой художник без таблицы перед глазами, а ведь там есть ещё и исключения в виде драгоценных камней. Имея доступ к этой настройке шейдера, очень просто уйти от физически корректных значений куда-нибудь в астрал, ломая весь визуальный ряд, да и при подготовке материалов на наши плечи и память видеокарты ложится ещё одна карта.
К тому же замеры значений реального мира укладываются в небольшие рамки, которые вполне можно автоматизировать, что и сделали в metalness, отобрав прямой контроль и необходимость думать ещё и об этом.
В specular-пайплайне параметр specular контролируется grayscale-картой в значениях 0-255, линейным цветом либо скалярным параметром.
Скалярный параметр здесь — это значение, которое задаётся для двумерного пространства, которое проецируется на модель. Иными словами, когда вы двигаете ползунок в Marmoset для specular, это и есть скалярный параметр.
В metalness-пайплайне обычно нет прямого контроля интенсивности блеска через параметр specular. Вместо этого в шейдеры вписаны базовые значения интенсивности для F0: 4-5% для изоляторов и 80-100% для чистых металлов, что соответствует значениям реальных материалов. Остальную работу по смешиванию и расчёту эффекта Френеля берёт на себя движок, а контролировать блеск как таковой художникам предлагается через roughness и albedo.
Cavity
Со specular reflectance есть один достаточно важный нюанс, который заключается в том, что иногда у материала есть места, где зеркальный блеск полностью отсутствует, например при имитации сквозных отверстий, которые всегда затенены. Либо блеск сильно ниже остальных мест, например в глубоких трещинах или других неровностях, где свет попадает в ловушку. Обычно это контролируется через параметр cavity; эта карта позволяет указать шейдеру, где снижается его фиксированное значение. В UE4, например, есть параметр specular в материалах, и это название может сбивать с толку, но надо знать, что это не прямой контроль specular, как можно подумать, а как раз контроль cavity для снижения блика в пределах 0-4%. Такой же параметр есть в Substance-продуктах и так далее. То есть если нам надо сымитировать абсолютно небликующее место, мы рисуем карту с чёрными значениями и подключаем к этому параметру. Шейдер уберёт фиксированный блик.
Пример влияния cavity на specular reflectance. На верхней картинке в тексте на затворе и цилиндическом пине стоят дефолтные значения блика. На нижней в этих местах есть маска cavity и они не будут бликовать ни на каких углах, имитируя свет в ловушке глубины геометрии. Рендер из Marmoset Toolbag 3
Про металличность
Metalness
Металличность в PBR критически важная характеристика, потому что металлы и неметаллы по-разному ведут себя при освещении. У изоляторов есть диффузное отражение и нет окраски блика, у проводников же всё наоборот — их поверхность не позволяет свету рассеиваться из-за высокой плотности. Изоляторы зеркально отражают 2-5% светового потока, проводники — 70-100%, и эти значения вписаны в шейдеры как константы.
Казалось бы, на этом можно и закончить, но планета Земля довольно вредная и чистые металлы она быстро покрывает оксидной плёнкой, грязью, пылью и прочими неприятными для теории вещами, что выливается в использование градиентов в чёрно-белой карте metalness. И это неприятно уже для художника, очарованного теорией и ждущего прогнозируемых ею результатов. Потому что при отрисовке переходов между металлом и неметаллом мы получаем артефакт рендеринга вне зависимости от того, имеем ли мы богатый UE4 или более скромный в бюджете Unity. И единственная рекомендация (помимо «по возможности избегайте») — это повышение разрешения текстуры либо конкретного места: при высоком texel density артефакты в местах перехода менее заметны.
Артефакт перехода металл/неметалл есть и в specular-пайплайне, просто он инвертирован и не так заметен, потому что тёмный.
Артефакты перехода металл/неметалл. Wes McDermott и Allegorithmic.
Согласно теории PBR, цветной блик бывает только у металлов. Потому что у них нет диффузного отражения, зато есть сама поверхность, и иногда свет всё-таки теряет часть спектра, нагревая её, а оставшаяся часть и является цветным бликом. И если в specular-пайплайне мы вынуждены были бы использовать цветную RGB-карту в инпуте specular, нагружая память ещё двумя каналами, то в metalness уже сразу всё есть в albedo. И, согласно карте metalness, шейдер либо окрашивает блик, если у нас чистый металл, либо нет, если изолятор. Изи.
Да, жёлтый цвет бруска золота — это блик, а не диффузное отражение. Просто поверхность этого бруска неидеальная, и блик мягко размазывается по ней если, брусок не отполирован.
Другое дело, что художникам обычно плевать на такие тонкости. С точки зрения редактора материалов мы всё равно делаем цветное albedo для золота, например, в Substance Painter, поэтому какая разница, спросит художник. Важный нюанс для понимания, потому ещё раз: albedo управляет цветом у неметаллов и уровнем яркости блика у металлов.
Металличность описывается чёрно-белой картой 0-255 в линейном цвете и может быть скалярным параметром без карты.
Про шероховатость
Roughness. Glossiness. Smoothness.
Если представить себе поверхность условного материала при большом увеличении, мы неизбежно увидим его несовершенство, прихотливую топологию, которая является существенной для света. Свет беспорядочно отклоняется, натыкаясь на эти несовершенства, и частично ускользает от наблюдателя, а частично возвращается к нему. В PBR за это отвечает реализация microfacet theory в сочетании с BRDF, согласно которой поверхность условного материала можно представить как набор мелких плоских квадратов, угол которых контролируется картой roughness, или gloss, или даже smoothness кое-где.
Ещё проще — каждый пиксель на карте roughness есть отдельный квадрат поверхности. Экстраполяция при рендеринге формирует общий характер блика.
Обе карты означают одно и то же, только в roughness белый цвет — это максимальное отклонение, то есть луч света не возвращается к наблюдателю и чёткость блика размывается, а чёрный — минимальное, то есть луч света идёт к наблюдателю, а блик максимально чёткий, приближается к зеркалу. А в gloss эти значения инвертированы.
Если specular задаёт интенсивность блеска (или хардкод значений в metalness), то шероховатость описывает характер этого блеска. То есть в каком месте наш материал бликует более упорядоченно, приближаясь к зеркалу по свойствам, а в каком он обработан рашпилем и блик там настолько беспорядочен, что становится мягким, как в примере про золотой брусок.
Roughness в руках художника позволяет творить чудеса, описывая поверхность и её историю, которая меняется при изменении угла света, принося желаемую жизнь в картинку — все эти отпечатки рук, пыль, мелкие царапины.
Шероховатость определяется grayscale-картой в 0-255, хранится в линейном цвете.
Roughness-карта и схема взаимодействия. Wes McDermott и Allegorithmic.
Про псевдорельеф
Normal bump
Чтобы понять, что такое карты нормалей, нужно быстренько пробежаться по теории трёхмерной графики. Нормаль — это вектор, перпендикулярный касательной поверхности, одна из сущностей в математике рассчёта освещения поверхности.
По нормалям мне справедливо напинали в комментариях, там чуть подробнее.
В полигональной графике есть два типа нормалей: vertex normal и face normal, соответственно, нормали вертексов и нормали полигонов. Интерполяция этих значений даёт либо гладкую поверхность, либо разделение на границах hard edges.
Например, Zbrush не учитывает вертексные нормали при рендеринге, отчего поверхность на низких уровнях детализации не гладкая. За счёт этого здорово экономятся ресурсы, что позволяет оперировать миллионами полигонов.
С hard/soft edges есть ещё один нюанс, который заключается в том, что hard edges удваивают количество своих вертексов в рендере из-за особенностей собственно рендеров. Такая же история со швами UV, потому их стремятся объединять. К PBR это не относится, но с этим регулярно сталкиваются все художники-моделлеры.
Тут следует сделать небольшое отступление и поговорить о терминологии. Термин полигон в трёхмерной графике имеет плавающее значение. Само слово пришло из греческого и означает «многоугольник», применяется оно как к треугольникам — единице полигональной сетки, так и к многоугольникам с 3+n углов. В английском есть термин face с похожей историей применения. Face normal в данном случае — нормаль треугольника.
Рендеры оперируют треугольниками, потому любые полигоны 3+n имеют значение только в редакторе.
Чем больше полигонов у модели, тем больше нормалей, тем точнее передаётся рельеф поверхности. Для того чтобы сэкономить количество полигонов, нормали с высокополигональной модели «запекаются» в карту согласно текстурным координатам и накладываются на низкополигональную. Шейдер обсчитывает отражение света от поверхности низкополигональной модели, имитируя отклонения лучей на неровностях, как если бы это была реальная геометрия. При этом, в зависимости от типа карты нормалей, учитываются касательные (tangent space, пространство касательных) или объектные (object space, пространство объекта) координаты, и шейдер или учитывает собственные нормали модели, или нет.
Само понятие псевдорельефа (или bump) довольно старое, и технологии уже много лет, как и её расширению в виде карт нормалей. Я сталкивался с искренним недоверием к этому заявлению, но это правда — normal bump есть расширение старого доброго bump. Суть работы алгоритма та же — искажение поверхности. В карте нормалей есть три координаты отражения луча, а в bump, по сути, одна. Я не буду описывать разницу алгоритмов пространств касательных и координат нормалей, как правило, в рендерах используется реализация Mikk, плюс отличается система координат зелёного канала (он же Y, он же координата направления высоты).
Normal bump не является исключительно PBR-свойством, это отдельная сущность, наследие лихого прошлого и на самом деле — фейк, призванный сэкономить ресурсы. Нам она интересна, потому что влияет на направление отражения лучей света. В разработке же реальных проектов иногда принимается решение не использовать карты нормалей повсеместно, так как это становится слишком дорого. Вместо этого повышается поликаунт, то есть количество «реальных нормалей»; применяются фаски, что является компромиссом, к тому же современное железо крутит не в пример больше полигонов на меш чем раньше. Примеры можно увидеть в проектах Rockstar на движке RAGE — это GTAIV/V, RDR1/2, или в Star Citizen на движке CryEngine/Lambeyard. С другой стороны, в моделях персонажей, например, без карты нормалей не обойтись, ибо рельеф и неровности кожи ещё очень не скоро смогут быть сделаны реальной геометрией.
PBR прекрасно работает без карт нормалей.
Про подповерхностное рассеивание
Subsurface scattering, SSS.
Строго говоря, это тоже диффузное отражение, но с учётом полупрозрачных материалов или материалов с полупрозрачным верхним слоем: кожа, воск и так далее. Свет в таких средах проходит некоторое расстояние, прежде чем быть отражённым, и это вносит изменение в вид материала, слегка подсвечивая его изнутри.
С учётом корректности шейдеров, SSS, как правило, имеет всего пару настроек: глубину проникновения (обычно в миллиметрах или в юнитах сцены) и карту цвета подповерхностного рассеивания в RGB-формате. Но есть и различия в реализации.
Пример реализации SSS. Взято с просторов интернета.
Про полупрозрачность
Translucency
Как правило, идёт рука об руку с SSS, но иногда у этих двух сущностей есть разница. Translucency — это глубина полупрозрачности, лучше всего демонстрируется примером просвечивающихся кончиков ушей. Translucency управляется чёрно-белой картой в линейной гамме.
Здесь как раз пример универсального шейдера для обоих эффектов: как полупрозрачности, так и подповерхностного рассеивания. Взято с просторов интернета.
Про рассеянное затенение
Ambient occlusion
Странный перевод термина ambient occlusion — это не злой умысел, а попытка впихнуть в пару слов суть технологии. Правильнее было бы перевести это как окклюзия окружающей среды, но это ещё более странное словосочетание. AO — это имитация глобального освещения в части отрисовки мягких теней в углах и местах, где свет попадает в ловушку. Это пересекается с cavity в PBR-шейдерах, но тени более мягкие и обширные. Сама технология не является PBR-свойством и тоже довольно старая, с массой итераций и вариантов. Мы говорим о том AO, которое является частью шейдера и оверлеем накладывается на модель в условиях отсутствия реального глобального освещения. Помимо этого, есть SSAO (screen space ambient occlusion), HBAO (horizon based ambient occlusion) и прочие варианты технологии, которыми управляет движок в реалтайме. Несмотря на похожее название, к материалам эти технологии не относятся — это уже стадии deferred rendering.
На примере видно, как АО добавляет глубины рендеру, имитируя рассеянные тени. Источник: https://www.gamingscan.com/what-is-ambient-occlusion/
Вероятно, с развитием RTX и в целом технологии трассировки лучей и GI необходимость работы с АО исчезнет целиком, но сегодня это один из основных приёмов.
Про что почитать
Так как данная статья не является подробным гайдом или мануалом, а скорее памяткой, для подробного изучения темы вы можете ознакомиться с материалами по ссылкам ниже.