3D Engineering

...Лучшее из общего.

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Всем привет! Так как это мой первый making of то сначала я бы хотел представиться

Всем привет! Так как это мой первый making of, то сначала я бы хотел представиться. Меня зовут Федор Набоков, в настоящий момент живу в Москве. Компьютерной графикой увлекаюсь уже 5 лет. 3 года назад закончил МГТУ им. Н.Э. Баумана, работаю инженером. Образование и работа, как оказалось, накладывают довольно сильный отпечаток на творческую мысль и восприятие вещей, но об этом ниже. Художественного образования, кстати говоря, не имею, о чем очень часто жалею.

Так как этот “making of” похоже будет эпического масштаба, я позволю себе рассказать не только о процессе создания, но и о тех мыслях и чувствах, что я испытывал.

Эволюция идеи

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

Комментарии были в основном хорошие, и я отчасти поверил в себя, в то, что я могу создавать красивые вещи. После отзывов о работе Шаровой кран я понял, что технически выполнить работу грамотно можно, однако для того, чтобы получить award не хватает оригинальной идеи, масштабов, сюжета. После просмотра кучи фотографий в интернете, обдумываний вариантов, я решил остановиться на роботе, сделанном из флешки. Почему робот? Скажу честно, органических существ (людей и т.д.) у меня рисовать не получается, сказывается, видимо, недостаток художественного образования. К тому же меня всегда привлекали роботы, и я могу подолгу смотреть и действительно восхищаться красивой конструкцией. Задумка была сделать робота-собаку, однако необходимо было наделить его какими-то качествами, чтобы он казался живым, думающим, действующим.  Первоначально я думал изобразить собаку с печеньем-рыбкой в зубах, ну а в описании работы написать, что он очень любит их грызть. Однако в процессе моделирования идея была пересмотрена, совершенно не смотрелся тот дизайн, который я придумал, с печеньем в зубах. Весь облик собаки говорил о том, что это не просто собака, а скорее дикий зверь, волк. А что делают волки? Правильно, воют на Луну. Так как Луну в комнате изобразить проблематично, я повесил ее фотографию на стене, а собаку расположил наверху колонки. Добавил сзади пару елок и получилась на мой взгляд живописная композиция.

В комментариях к работе пару раз даже слово award прозвучало, из чего я сделал вывод, что иду в правильном направлении, однако не хватает масштабности, сюжета и какой-то новизны.  Раз идея создания роботов из электронной техники оказалось успешной, было бы логично и дальше ее развивать.  Будучи фанатом фантастических фильмов, фанатом спецэффектов и эпических битв, я решил создать свою битву, пусть и в миниатюре. Компьютерную мышку я когда-то давно уже моделировал, так что ее модель была взята за основу и превращена в страшного паука. Почему в паука? Во-первых, многие люди их боятся или испытывают отвращение, так что само появление паука должно будет произвести впечатление, возможно даже заставить зрителя переживать. Собак было решено сделать две, причем разного пола. Тоже по идее должно вызвать определенные чувства. Что касается второй собаки, то ее создание, даже сама ее идея оказалась довольно сложной. Во-первых, ее надо было сделать тоже из флешки, так как я что-то сомневаюсь в том, чтобы собака из флешки и собака например из фена могли между собой подружиться. Во-вторых, нужно было всеми доступными способами показать ее принадлежность к женскому полу. Все-таки согласитесь, первая собака явно мужского пола. Пересмотрев множество моделей флешек, я решил использовать в качестве  основы максимально обтекаемую, круглую флешку, так как женские формы обычно более округлые, чем мужские. Чтобы подчеркнуть женственность использовал ленточки и кольца в ушах. Однако не хватало какой-то изюминки, принципиального отличия от другой собаки. Пришла мысль – сделать ее летающей, с крыльями как у ангела. На мой взгляд, женственней уже было бы просто некуда. Но технически я это реализовать не смог, поэтому принял решение в пользу механических приспособлений для полетов, тем более заготовка у меня уже была – незаконченный hovercraft, как я его в свое время назвал.  После нескольких пробных рендеров я понял, что персонажей в кадре маловато, да и не смогут эти две собаки загрызть паука. И тут на глаза попались лего человечки, сами по себе ничего особенного не представляли, однако из них получилось сделать настоящих солдат.

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

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

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

Скажу честно, закончить работу было очень тяжело. Часто я не мог уснуть, потому что думал как решить ту или иную задачу, что делать дальше, что делать с дизайном каких-то частей, которых не было. Наверно, решение этой психологической проблемы, когда не хочешь продолжать или не знаешь как продолжить, у каждого свое. Мне помогало переключение внимания на что-то другое, например велосипед, на нем кстати за 2009 год проехал больше 1600 км. Очень полезно распечатывать рендеры, пусть даже черновые или рендеры болванок и прямо на них ручкой рисовать то, что хочешь добавить. Не знаю, как у других, но придумывать дизайн сразу в 3д – для меня  гиблое дело.

Самый главный вывод, который я сделал после 4 месяцев труда – не обязательно быть крутым профессионалом, чтобы создать что-то стоящее. Я до сих пор считаю себя почти новичком, кроме 3dmax, vray и photoshop, ничем другим не пользуюсь, причем photoshop я знаю довольно плохо, поэтому тратил много времени и вытягивал картинки рендером. Самое главное - это упорство, поиск обходных решений в тех случаях, когда разобраться будет очень долго или почти невозможно, запоминание удачных решений, опыт и еще раз опыт. Многие могут не согласиться с предыдущим предложением, но я приведу простой пример – во всех работах, фигурирующих в этом making of, освещение – vray dome light со всем известной картой kitchen.hdr. Делайте выводы, а мы плавно переходим к техническим аспектам создания работ.

USB flash drive

Моделировать всегда проще то, что можно повертеть в руках. Это наверно первый закон, а второй закон – моделировать всегда нужно имея фотографию на бэкграунде. У человеческого глаза есть интересная особенность, при моделировании очень сложно соблюсти пропорции точно, однако когда уже все готово, глаз с легкостью замечает, что что-то не так. Так что, имея эту флешку, особого труда сделать ее модель, не составило. Я всегда использую полигональное моделирование, очень редко сплайны, другими методами типа nurbs просто не умею. При полигональном моделировании очень важно чтобы полигоны были 4 угольными, также желательно, чтобы их размер был примерно одинаков. Также важно, чтобы размер трехмерной модели был близок к оригиналу, иначе потом будут проблемы с DOF и с освещением в целом. Если объект имеет сложную форму, то лучше его разбить на составные части, иначе проблем со сглаживанием не избежать. После создания модели делаю chamfer ребер и применяю либо модификатор turbosmooth, либо meshsmooth и сверху smooth.

Для освещения я использовал два vray plane источника света, расположены специально таким образом, чтобы подчеркнуть форму модели через specular отражения.

Для environment освещения и для отражений я использовал всем знакомую kitсhen.hdr. Очень советую сразу после этапа моделирования настраивать освещение, а потом уже материалы.  Поведение материалов очень сильно зависит от освещения, все наверно сталкивались с тем, что на vray-materials.de видишь одно, а у себя в сцене получаешь абсолютно неудовлетворительный результат. При постановке освещения нужно руководствоваться тем, чтобы не было явных засветов, слишком темных зон, но с другой стороны и равномерным освещением быть не должно, реалистично смотрится именно “градиент” освещения. Обычно я делаю несколько тестовых рендеров, при этом каждый раз горизонтально поворачиваю HDR на 60 градусов. Если какой-то вариант более менее похож на то, что я хотел бы увидеть, то уже более тонко настраиваю именно этот вариант. Всем материалам для этих рендеров назначаю серо-голубой материал с небольшим рефлектом.

Вот несколько примеров.

HDR повернута на 60 градусов, блики спереди создает не хдр, так что от самой хдр мы получаем только плоское освещение и никаких подчеркивающих форму бликов.

HDR повернута на 120 градусов,  немного лучше, стало светлее, но все равно не то.

HDR повернута на 180 градусов, опять не то, видимо источник света в хдр не с этой стороны.

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

Кстати говоря, HDR карту здесь я использовал вот в таком виде:

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

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

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

Как я уже писал, текстуры я взял с отсканированной флешки:

Как видите, тогда Photoshop я владел плохо, поэтому текстуры выглядят неряшливо, хотя с другой стороны на результате это никак не отражается. Почти все материалы содержат текстуры в diffuse, reflect, reflection glossiness и bump каналах. На USB разъеме еще используется дисплейс для следов от засовывания флешки в компьютер и заводских углублений.

Царапины сделаны с помощью bump.

Текстура кожи  - это просто фотография, причем удачно получилось ее использовать даже без бампа и спекулара.

Настройки рендера в принципе стандартные, поэтому тут останавливаться не на чем. Разве что скажу, что обычно пользуюсь Reinhard с значением 0,5, получается что-то среднее между linear и exponential. Для GI использую irradiance map + light cache. DOF честный от vray camera. Рендер так и остался без постобработки, однако смотрится по-моему неплохо.

Читать дальше>>

 

Архив статей

 окт   Ноябрь 2019   дек

ВПВСЧПС
   1  2
  3  4  5  6  7  8  9
10111213141516
17181920212223
24252627282930
Julianna Willis Technology

Случайная новость

Обзор

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

1. Введение

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


2. Классический алгоритм построения теней Shadow Volumes

Рис. 1 "к понятию о теневом объеме"

Алгоритм Shadow Volumes [1,2] был впервые предложен Франклином Кроу (Franklin Crow) в 1977 году для генерации теней в трехмерном пространстве. Особенностями алгоритма можно назвать построение геометрически правильных теней с четкими краями, а также использование буфера шаблонов (stencil-буфера) в современных реализациях [4]. К достоинствам алгоритма можно отнести также то, что тени можно строить только от необходимых объектов, а не вообще от всех объектов сцены (хотя такая возможность есть).
Буфер шаблонов - это, по сути, дополнительная плоскость в буфере кадра (обычно 8 битов на точку), используемая для поточечного отсечения изображения [3]. Практически все современные графические ускорители поддерживают эти возможности отсечения (stencilling capabilities).
Алгоритм основан на использовании так называемых "теневых объемов" (shadow volumes). Теневой объем представляет собой область трехмерного пространства, полностью заполненную тенью (см. рис. 1). Теоретически, теневые объемы строятся по точкам силуэта объекта, отбрасывающего тень, и лучам, исходящим из этих точек по направлению от источника света. Однако практически, вместо лучей используются отрезки конечной длины, так как, во-первых, технически сложно работать с бесконечными величинами, а во-вторых, сцена всегда ограничена пирамидой видимости.
Чтобы определить, попадает ли данная конкретная точка экрана в тень, или нет, предлагается подсчитывать число пересечений луча, идущего от наблюдателя через эту точку с границами теневых объемов. Если результат нечетный - точка лежит в тени. Этот подход был впоследствии усовершенствован для использования с буфером шаблонов. Мы увеличиваем значение в буфере, соответствующее точке на экране, при пересечении лучом "видимых" граней (нормаль которых повёрнута к наблюдателю) теневых объемов и уменьшаем при пересечении "невидимых" граней (см. рис. 1). В результате мы получаем маску в буфере шаблонов, по которой впоследствии рисуем тень, причем делается это за два цикла обхода сцены, за один цикл рисуются освещенные участки сцены, а за другой - затененные. Более подробное описание дается в работах [1,2]

3. Тени от невыпуклых объектов

Классический алгоритм основывается на построении теневого объема по точкам силуэта объекта, отбрасывающего тень. Для выпуклых объектов достаточно построить проекцию объекта на плоскость, перпендикулярную направлению на источник света, и затем по полученным точкам построить огибающую ломаную. Точки, принадлежащие ломаной, являются точками силуэта.
В случае если объект невыпуклый, классический алгоритм не подходит по очевидным причинам. Наиболее общим решением в этом случае является алгоритм, когда для каждой "невидимой" источнику света грани объекта строится отдельный теневой объем. Однако этот вариант не является оптимальным, поскольку в этом случае будут построены лишние теневые объемы от внутренних граней.
Выход, однако, есть. Для того чтобы исключить внутренние грани, нами был адаптирован алгоритм [6]. В результате адаптации в алгоритм была внесена возможность построения силуэта от источников света, находящихся на конечном расстоянии от затеняющего объекта (перспективная теневая проекция).

ИщемСилуэт (набор граней объекта P, список ребер силуэта L)
{
для каждой грани р из Р
для каждого ребра n из р
{
i = первая вершина n
j = вторая вершина n
если L[j] уже содержит i то удалить i из L[j]
иначе добавить j в L[i]
}
вернем L
}

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


4. Ограничение теневых объемов

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

Рис. 2 "к понятию о шапках"

Шапка - это полигон, являющийся результатом пересечения теневого объема и отсекающей плоскости. Так как есть две отсекающих плоскости, различают "ближние" и "дальние" шапки. Нормаль шапки выбирается таким образом, чтобы теневой объем был всегда замкнутым.
Следует заметить, что построение шапок - сложная задача вычислительной геометрии, так как теневой объем представляет собой сложный многогранник, в общем случае невыпуклый и с дырами.
В случае построения "дальних" шапок был реализован простой способ решения. В сцену была добавлена плоскость, позади всех остальных объектов, развернутая от наблюдателя (с нормалью, направленной от наблюдателя). Это дало возможность не заботиться о "дальних" шапках, так как теневой объем в любой конфигурации замыкается этой плоскостью.
Для "ближних" шапок такой способ не подходит, потому что когда в z-буфере будет лежать подобная замыкающая плоскость, но впереди сцены, то все остальные грани сцены не смогут быть нарисованы и мы не увидим сцену. В результате мы приходим к необходимости точного подсчета шапок для каждого теневого объема.
Для того чтобы построить шапку тени, нам пришлось решить задачу нахождения пересечения теневого объема с произвольной плоскостью.
В общем случае, чтобы решить поставленную задачу для произвольного тела, нам потребовались бы сложные математические вычисления, параметризация теневого объема системой уравнений и затем решение полученной системы. Однако в нашем случае, теневой объем - не совсем произвольное тело.
Для построения ограничивающего многоугольника теневой объем можно разделить на усечённые пирамиды, каждая из которых образована:
1. Из грани (треугольника), отбрасывающей тень.
2. Из трех боковых граней (косых трапеций), образованных проецированием ребер верхней грани по направлению от источника света.
3. Из грани (треугольника), замыкающей теневой объем снизу.
Для каждой отдельной усечённой пирамиды можно достаточно просто найти пересечение с плоскостью. Решая задачу для теневого объема и ближней отсекающей плоскости, мы получим в результате набор граней, которые и составляют "ближнюю" теневую шапку.

5. Проблемы с точностью

В процессе работы были решены задачи, связанные с недостаточным уровнем точности вычислений - как на уровне алгоритма, так как размеры теневого объема значительны, так и на уровне используемого API (DirectX8). DirectX8 использует для внутреннего представления числа 4 байта, что эквивалентно максимальному десятичному числу 4.3х109. В некоторых случаях (в частности, для случая "космических" расстояний) этой точности оказывается недостаточно. В этом случае "невидимые" грани теневого объема могут "не сшиваться" по краям, оставляя после себя видимые артефакты, например, в виде линий из точек.
Для того чтобы максимально нивелировать артефакты, связанные с недостаточной точностью, нами были использованы приемы:
1. На уровне алгоритма реализован как ручной (через UI), так и автоматический выбор расстояния, на которое производится проекция тени. Это позволяет обеспечивать достаточно гибкий контроль размеров теневого объема.
2. На уровне API применяется преобразование формата списков граней из простого линейного списка (LIST) в список-полоску (STRIP). Это позволяет, во-первых, сократить объем используемой памяти, а во-вторых, практически избавиться от артефактов, связанных со сшиванием граней.
Еще одним примером, иллюстрирующим проблему с точностью, является рисование шапок, построенных на ближней отсекающей плоскости. Недостаточно просто отправить их в графический конвейер - из-за недостаточной вычислительной точности рисование граней, слишком близко расположенных к отсекающей плоскости, становится проблематичным. В этом случае нами был реализован перенос граней шапки на некоторое расстояние от наблюдателя вглубь сцены и последующее масштабирование.

6. Производительность

Тема производительности является одной из самых важных, когда заходит разговор о генерации теней в реальном времени. Генерация теней является затратной операцией, так как каждый теневой объем имеет геометрическую сложность, сопоставимую со сложностью объекта, от которого он был образован. В самом худшем случае, когда все объекты сцены отбрасывают тень, нагрузка на API и лежащее за ним аппаратное обеспечение возрастает как минимум в два раза. Более того, так как теневые объемы считаются динамически, в классическом алгоритме их нужно строить отдельно для каждого нового кадра.
Предложенный алгоритм изначально разрабатывался с таким расчетом, чтобы получить максимально возможную производительность при достаточном качестве. В процессе работы над алгоритмом был разработан и реализован ряд оптимизаций, которые позволили существенно сократить время работы:
1. Прежде всего, это однопроходная реализация, в отличие от классического варианта. Вместо второго цикла обхода сцены для рисования тени применяется смешивание цветов, грубо говоря, уже сгенерированный буфер кадра смешивается с плоскостью цвета тени, по маске из буфера шаблонов.
2. Во-вторых, оптимизация уже заложена в самом алгоритме - мы можем выбирать те объекты сцены, от которых хотим получить тень, а все другие игнорировать.
3. Еще один способ оптимизации, как следствие уже существующих возможностей системы, заключается в использовании информации об ограничивающих сферах объектов сцены. Эта информация при подсчете "ближних" шапок позволяет сократить число исследуемых ребер на одну треть, так как если сам объект не пересекается с ближней отсекающей плоскостью, то и все его грани (по части из которых построен теневой объем) не пересекаются с этой плоскостью.
4. Известно, что теневой объем, как тело в пространстве, зависит от положения источника света, положения объекта отбрасывающего тень и не зависит от положения камеры. В приложениях, где полезная работа осуществляется за счет движения камеры, а сцена по большей части статична (таких, как большинство современных 3D стрелялок) это может играть существенную роль: теневой объем может просчитываться только один раз на все время жизни сцены (прегенерация). В общем случае, когда сцена не является статичной, подобная оптимизация тоже имеет право на жизнь, так как позволяет сократить вычисления (в худшем случае мы получаем ту же картину, как и без оптимизации).
5. Если же у нас неподвижна и камера и источник света и теневые объемы, это дает возможность не строить заново маску в буфере шаблонов, так как маска, сохранившаяся с предыдущего кадра, все еще валидна. Таким образом, время работы алгоритма сокращается практически до нуля. Этот случай имеет место, когда, например, движутся объекты, не отбрасывающие тень.
Кроме всего прочего нами был реализован управляющий интерфейс (через UI) который дает возможность максимально гибко настроить алгоритм в соотношении скорость/качество для каждой конкретной задачи. В число возможностей, среди прочего, входят:
1. отключение теней (и всех затрат на них со стороны системы)
2. изменение цвета и интенсивности тени
3. выбор параллельной или перспективной проекции теневых объемов
4. отключение генерации шапок, как дальних, так и ближних

7. Результаты

Все результаты получены на тестовом стенде с конфигурацией 256Mb RAM, GeForce3, модель: МКС (Международная космическая станция) ~ 20000 граней. Измерения проводились в полноэкранном режиме.

далее