Выпущенный в 1993 году первый DOOM внёс фундаментальные изменения в разработку игр и механик, он стал мировым хитом и создал новых идолов, таких как Джон Кармак и Джон Ромеро.
Сегодня, 23 года спустя, id Software принадлежит Zenimax, все основатели уже покинули компанию, но это не помешало коллективу id продемонстрировать весь свой талант, выпустив отличную игру.
Новый DOOM прекрасно дополняет франшизу. В нём используется новый движок id Tech 6; после ухода Джона Кармака его сменил на должности ведущего рендер-программиста бывший разработчик Crytek Тьяго Соуза (Tiago Sousa).
Традиционно id Software через несколько лет после создания публиковала исходный код своих движков, что часто приводило к возникновению интересных ремейков и аналитических статей. Неизвестно, продолжит ли id Tech 6 эту традицию, но нам не обязательно нужен исходный код, чтобы оценить любопытные графические техники, использованные в движке.
Как рендерится кадр
Мы разберём сцену с картинки ниже, на которой игрок атакует гнездо крови, охраняемое несколькими одержимыми, сразу после получения преторианской брони в начале игры.
В отличие от большинства современных игр под Windows, в DOOM используется не Direct3D, а OpenGL и Vulkan.
Vulkan — это новая потрясающая технология, к тому же Балдур Карлссон (Baldur Karlsson) только совсем недавно добавил поддержку Vulkan в RenderDoc, так что трудно было удержаться от искушения забраться внутрь движка DOOM. Все представленные ниже наблюдения выполнены в игре, запущенной с Vulkan на GTX 980 со всеми настройками, установленными на Ultra, некоторые догадки взяты из презентации Тьяго Соузы и Джина Джефроя (Jean Geffroy) на Siggraph.
Обновление мегатекстур
Первый этап рендеринга — это обновление мегатекстур; эта технология, представленная ещё в id Tech 5, использовалась в RAGE, а теперь и в новом DOOM.
Если объяснять вкратце, то смысл этой технологии в том, что несколько огромных текстур (в DOOM они имеют размер 16k x 8k) располагаются в памяти видеопроцессора; каждая из них — это коллекция из тайлов 128x128.
Страницы 128 x 128, хранящиеся в текстуре 16k x 8k
Все эти тайлы должны представлять собой идеальный комплект актуальных текстур с хорошим уровнем мип-текстурирования, которые в дальнейшем будут использованы пиксельными шейдерами для рендера той самой сцены, которую мы видим.
Когда пиксельный шейдер выполняет считывание из «виртуальной текстуры», он просто считывает некоторые из этих физических тайлов размером 128x128.
Разумеется, в зависимости от того, куда смотрит игрок, набор этих текстур будет изменяться: на экране появляются новые модели, ссылающиеся на другие виртуальные текстуры, требуется загрузка новых тайлов и выгрузка старых…
Итак, в начале кадра DOOM обновляет несколько тайлов с помощью инструкции
vkCmdCopyBufferToImage, чтобы записать актуальные текстурные данные в память графического процессора.Подробно почитать о мегатекстурах можно здесь и здесь.
Атлас теневых карт
Для каждого источника света, отбрасывающего тень, создаётся уникальная карта глубин, сохраняемая в один тайл огромного текстурного атласа размером 8k x 8k. Однако не каждая карта глубин рассчитывается для каждого кадра: DOOM активно повторно использует результаты предыдущего кадра и пересчитывает только те карты глубин, которые требуют обновления.
Буфер глубин 8k x 8k (предыдущий кадр)
Буфер глубин 8k x 8k (текущий кадр)
Когда источник света статичен и отбрасывает тени только на статичные объекты, то разумно будет просто хранить его карту глубин «как есть» и не выполнять ненужных пересчётов. Однако если к этом свету переместится противник, то карту глубин нужно будет создать снова.
Размеры карт глубин могут сильно отличаться в зависимости от расстояния от источника до камеры; кроме того, пересчитанные карты глубин не обязательно должны находиться в том же тайле атласа.
В DOOM используются определённые оптимизации, например, кэширование статической части карты глубин с расчётом проекций только динамических сеток и последующим композитингом результатов.
Предварительный проход обработки глубин
Рендеринг всех непрозрачных сеток уже выполнен и информация об их глубине передана в карту глубин. Сначала это оружие игрока, затем статическая геометрия, и, наконец, динамическая геометрия.
Карта глубин: готовность 20%
Карта глубин: готовность 40%
Карта глубин: готовность 60%
Карта глубин: готовность 80%
Карта глубин: готовность 100%
Но на самом деле во время предварительного прохода обработки глубин сохраняется не только информация о глубинах.
При рендеринге в карту глубин динамически объектов (одержимых, кабелей и оружия игрока) их скорость на пиксель также вычисляется и записывается в другой буфер для создания карты скоростей. Расчёты выполняются вычислением в вершинном шейдере разницы положений каждой вершины между предыдущим и текущим кадром.
Карта скоростей
Для хранения скорости нужно всего 2 канала: в красном хранится горизонтальная скорость, а в зелёном — вертикальная.
Одержимый быстро движется к игроку (поэтому он зелёный), а оружие почти неподвижно (чёрное).
А что же это за жёлтая область (красный и зелёный равны 1)? На самом деле это исходный цвет буфера по умолчанию, означающий, что там нет динамических сеток: это «область статичных сеток».
Почему DOOM не выполняет расчёт скорости для статичных сеток? Потому что скорость статичного пикселя легко найти из его глубины и нового состояния камеры по сравнению с последним кадром; не обязательно рассчитывать её для каждой сетки.
Карта скоростей пригодится нам позже при добавлении motion blur.
Запросы отсечения
Мы стремимся отправить для рендеринга в графическом процессоре как можно меньшее количество геометрических объектов, и лучший способ достичь этого — отсечь все сетки, которые невидимы для игрока. БОльшая часть отсечения невидимых частей в DOOM выполняется промежуточным ПО Umbra, но всё равно движок выполняет запросы отсечения к графическому процессору для дополнительной обрезки видимой области.
В чём же смысл запросов отсечения к графическому процессору? Первый шаг — это группирование нескольких сеток мира в виртуальную область, охватывающую все эти сетки, с последующим запросом к графическому процессору на рендеринг этой области согласно текущему буферу глубин. Если ни один из растровых пикселей не проходит проверку по глубине, это означает, что эта область полностью отсекается и все объекты мира, содержащиеся в этой области можно спокойно игнорировать при рендеринге.
Однако проблема в том, что результаты этих запросов отсечения становятся доступными не сразу, и мы не хотим, чтобы конвейер графического процессора простаивал, заблокированный этими запросами. Обычно считывание результатов откладывается на последующие кадры, поэтому необходимо иметь немного более консервативный алгоритм, чтобы избежать появления объектов на экране.
Проверка области. Красное — отсечённое, зелёное — видимое.
Кластерный прямой рендеринг непрозрачных объектов
Теперь рендерятся вся непрозрачная геометрия и декали. Информация об освещении хранится в HDR-буфере с плавающей запятой:
25% освещения
50% освещения
75% освещения
100% освещения
Функции проверки глубины устанавливается значение
EQUAL, чтобы избежать лишних вычислений: благодаря предыдущему предварительному проходу обработки глубин мы точно знаем, какое значение глубины должен иметь каждый пиксель. Декали также наносятся прямо при рендеринге сеток, они хранятся в текстурном атласе.Картинка уже выглядит неплохо, но нам всё ещё не хватает прозрачных материалов, например стекла, частиц, а также совсем отсутствуют отражения среды.
Скажу пару слов об этом проходе: в нём используется кластерный прямой рендерер, основанный на работах Эмиля Персона (Emil Person) и Олы Олссона (Ola Olsson).
Слабым местом прямого рендеринга всегда была невозможность обработки большого количества источников освещения, эту задачу намного проще выполнить с помощью отложенного затенения.
Как же работает кластерный рендерер? Сначала окно просмотра разделяется на тайлы: в DOOM создаётся 16 x 8 областей. Некоторые рендереры останавливаются на этом и вычисляют список источников освещения на тайл, который позволяет снизить объёмы расчётов освещения, однако всё равно имеют определённые проблемы с пограничными случаями.
Кластерный рендеринг развивает эту концепцию глубже, переходя из 2D в 3D: не останавливаясь на разделении двухмерного окна просмотра, он выполняет разбивку в 3D всей пирамиды видимости камеры, создавая срезы вдоль оси Z.
Каждый «блок» называется «кластером», можно также назвать их "вокселями в форме пирамиды видимости".
Ниже представлено простое разделение окна просмотра размером 4 x 2; 5 срезов глубины разделяют пирамиду видимости на 40 кластеров.
В DOOM пирамида видимости камеры разделена на 3072 кластера (размером 16 x 8 x 24), срезы глубины логарифмически распложены вдоль оси Z.
В случае кластерного рендерера типичный алгоритм будет таким:
- Сначала ЦП вычисляет список элементов, влияющих на освещение в каждом кластере: источники освещения, декали и кубические текстуры…
Для этого все эти элементы «вокселизируются», так, чтобы их область воздействия могла быть проверена на пересечение с кластерами. Данные хранятся в индексированных списках в буфере графического процессора, чтобы шейдеры могли иметь к ним доступ. Каждый кластер может содержать до 256 источников света, 256 декалей и 256 кубических текстур.
- Затем графический процессор рендерит пиксель:
- из координат и глубины пикселя вычисляется, к какому кластеру он принадлежит
- считывается список декалей/источников освещения для этого кластера. При этом используются косвенная адресация со смещением и расчёт индекса (см. иллюстрации ниже).
- код проходит по всем декалям/источникам освещения в кластере, вычисляя и добавляя степень их влияния.
Также существует список зондов (не показан на схемах выше), доступ к которому получается точно таким же образом; однако он не используется на этом проходе и мы вернёмся к нему позже.
Издержки влияния на ЦП предварительного создания списка элементов для кластеров окупаются значительным снижением сложности расчётов рендеринга в графическом процессоре ниже по конвейеру.
На кластерный прямой рендеринг стали в последнее обращать внимание: он имеет хорошее способность обрабатывать большее количество источников света, чем простой прямой рендеринг; к тому же он работает быстрее, чем отложенное затенение, которое должно выполнять запись и считывание из нескольких G-буферов.
Однако я не упомянул кое-что: на этом проходе не просто передаётся одна операция записи в буфер освещения; при его выполнении также с помощью MRT создаются два тонких G-буфера:
Карта нормалей
Карта отражения
Карта нормалей хранится в формате R16G16 с плавающей запятой, карта отражения — в R8G8B8A8, альфа-канал содержит коэффициент сглаживания. Так что в DOOM продуманно используется комбинация прямого и отложенного рендеринга с гибридным подходом. Эти новые G-буферы станут полезными при добавлении дополнительных эффектов, таких как отражения.
Я пропустил ещё одно: в то же время создаётся feedback-буфер размером 160 x 120 для системы мегатекстур. Он содержит информацию для потоковой системы, сообщающую о текстурах и их мип-текстурировании, которые необходимо передавать дальше.
Движок мегатекстур работает по принципу обратной связи: если после прохода рендеринга сообщается об отсутствии каких-то текстур, то движок загружает их.
Частицы в графическом процессоре
Затем запускается compute shader для обновления симуляции частиц: положения, скорости и срока жизни.
Он считывает текущие состояния частиц, а также буферы нормалей и глубин (для обнаружения столкновений), воспроизводит этап симуляции и сохраняет в буферы новые состояния.
Преграждение окружающего света в экранном пространстве (SSAO)
На этом этапе генерируется карта SSAO.
Она предназначена для затемнения цвета вокруг узких швов, складок и т.д.
Также она используется для применения отсечения отражений, чтобы избежать артефактов яркого освещения, возникающих на отсечённых сетках.
Карта рассчитывается на половине от исходного разрешения в пиксельном шейдере, считывающего данные из буфера глубин, карт нормалей и отражения.
Первый результат получается довольно шумным.
Карта SSAO
Отражения в экранном пространстве
Теперь пиксельный шейдер создаёт карту SSR. С помощью информации, присутствующей на экране, он рейтрейсингом обрабатывает отражения, заставляя лучи отражаться от каждого пикселя в окне просмотра и считывая цвет пикселей, на которые упали лучи.
Глубины |
Нормали |
Отражение |
 Предыдущий кадр |
 |
|||
 Карта SSR |
|||
SSR — это хорошая и не очень затратная техника для создания динамических отражений сцены в реальном времени, создающая неизменную нагрузку; она значительно усиливает ощущение погружения и реализм.
Но у неё возникают собственные артефакты, так как она работает только в экранном пространстве и ей не хватает «глобальной» информации. Например, вы можете видеть красивые отражения в сцене, но когда вы начинаете опускать взгляд, количество отражения уменьшается, и глядя на свои ноги, вы не увидите почти никаких отражений. Мне кажется, что SSR хорошо интегрированы в DOOM, они улучшают качество изображения, но при этом они довольно неброские, и вы не заметите их исчезновения, если не следите за ними специально.
Отражения статичных кубических текстур
После расчёта всех динамических отражений на предыдущем проходе (и их ограничений) настало время создания статических отражений с помощью IBL.
Эта техника основана на использовании сгенерированных кубических текстур 128 x 128, представляющих собой информацию об освещении среды в различных местах карты (они также называются «зонды среды»). Точно так же, как и источники освещения с декалями на этапе кластеризации пирамиды видимости, зонды тоже индексируются для каждого кластера.
Все кубические текстуры уровня хранятся в массиве; их десятки, однако основной вклад в нашу сцену вносят всего 5 (кубические текстуры в этой комнате):
 |
 |
 |
 |
 |
Карта статичных отражений
Смешивание карт
На этом этапе compute shader комбинирует все сгенерированные ранее карты. Он считывает карты глубин и отражений и смешивает освещение прямого прохода:
- с информацией SSAO
- с SSR для рассматриваемого пикселя, когда она становится доступной
- если информация SSR отсутствует, в качестве замены используются данные карты статичных отражений
- также рассчитывается эффект тумана
Смешивание и туман: до
Смешивание и туман: после
Fog — туман, Probe Reflection — отражение зондов
Освещение частиц
В нашей сцене есть частицы дыма и освещение рассчитывается для каждого спрайта. Каждый спрайт рендерится так, как будто он находится в пространстве мира: из его положения мы получаем список источников освещения и соответствующие им теневые карты, после чего рассчитывается освещение четырёхугольника (частицы). Затем результат сохраняется в тайл атласа размером 4k; тайлы могут быть различного размера, зависящего от расстояния от частицы до камеры, настроек качества и т.д. Атлас имеет выделенные области для спрайтов одного разрешения, вот как выглядят спрайты 64 x 64:
Атлас освещения частиц
В таком низком разрешении хранится только информация об освещении. Позже, когда частица на самом деле отрисовывается, используется текстура в полном разрешении, а масштаб четырёхугольника освещения увеличивается и он смешивается с текстурой.
Здесь DOOM отделяет вычисление освещения частиц от основного рендеринга игры: при каком бы разрешении вы ни играли (720p, 1080p, 4k…), освещение частиц всегда вычисляется и хранится в таких небольших тайлах фиксированного размера.
Уменьшение масштаба и размытие
Сцена несколько раз уменьшается в размерах до 40 пикселей. Самые маленькие уровни масштабирования размываются с помощью отдельных вертикальных и горизонтальных проходов (создаётся «цепочка размытия»).
Зачем же так рано выполнять размытие? Этот процесс обычно происходит в конце, во время постпроцессинга для создания эффекта bloom в ярких областях.
Но все эти различные уровни размытия пригодятся нам в следующем проходе для рендеринга преломлений в стёклах.
Прозрачные объекты
Все прозрачные объекты (стёкла, частицы) рендерятся поверх сцены:
Прозрачные объекты: до
Прозрачные объекты: после
Стёкла очень красиво рендерятся в DOOM, особенно стёкла, покрытые изморозью или грязью: декали влияют только на часть стекла, чтобы сделать преломления более или менее размытыми. Пиксельный шейдер вычисляет коэффициент «размытости» преломления и выбирает из комплекта «цепочки размытия» две карты, наиболее близкие к коэффициенту размытости. Он считывает эти две карты и линейно интерполирует два значения, чтобы аппроксимировать конечный цвет размытия преломления. Благодаря этому процессу стёкла могут создавать попиксельно красивые преломления на различных уровнях размытия.
Карта искажений
Карта искажений
Очень горячие области могут создавать на изображении тепловые деформации. В нашей сцене немного искажает изображение гнездо крови.
Искажения рендерятся относительно буфера глубин для создания карты искажений низкого разрешения.
Красный и зелёный каналы представляют собой значение искажений по горизонтальной и вертикальной осям. Синий канал содержит количество применяемого размытия.
Настоящий эффект искажения применяется позже, как постпроцессинг, с использованием карты искажений для перемещения нужных пикселей.
В этой сцене искажения совсем небольшие и практически незаметны.
Пользовательский интерфейс
UI рендерится в другой буфер рендеринга в режиме заранее умноженного на альфа-канал (premultiplied alpha mode), хранящегося в формате LDR.
Преимущество хранения всего UI в отдельном буфере вместо отрисовки непосредственно поверх завершённого кадра в том, что игра может применить фильтрацию/постпроцессинг, например, хроматическую аберрацию или оптическое искажение для всех виджетов UI за один проход.
Рендеринг не использует каких-то техник батчинга и просто отрисовывает один за одним элементы интерфейса, примерно за 120 вызовов отрисовки.
В последующих проходах буфер UI смешивается поверх картинки игры, создавая окончательный результат.
Временной анти-алиасинг (TAA) и motion blur
TAA и motion blur применяются с использованием карты скоростей и результатов рендеринга предыдущего кадра.
Фрагменты можно отслеживать, так что пиксельный шейдер знает, где находился в предыдущем кадре текущий обрабатываемый пиксель. Каждый второй кадр рендеринг слегка сдвигает проекцию сеток на половину пикселя: это позволяет устранить артефакты субпиксельного искажения.
TAA и motion blur: до
TAA и motion blur: после
Результат получается очень хорошим: не только сетка становится сглаженной, но и искажения отражений (при которых в кадре могут возникать отдельные яркие пиксели) также уменьшаются. Качество гораздо лучше того, которое можно было достичь с помощью метода постпроцессинга FXAA.
Яркость сцены
На этом этапе вычисляется средняя яркость сцены, это один из параметров, позже передаваемых для тональной компрессии.
Буфер HDR-освещения циклично уменьшается в два раза от своего разрешения, пока не становится текстурой 2 x 2, при каждой итерации рассчитывается значение цвета пикселя как среднее от яркости четырёх его «родительских» пикселей из карты большего размера.
Bloom
Bloom
Применяется фильтр яркости для приглушения самых тёмных областей изображения. Результат использования фильтра яркости затем циклично уменьшается и размывается способом, похожим на описанный выше.
Слои размываются с помощью гауссова размытия с разделением на вертикальный и горизонтальный проход, на которых пиксельный шейдер вычисляет средневзвешенное значение вдоль одной оси.
Затем размытые слои соединяются для создания эффекта bloom, который является HDR-текстурой в четыре раза меньше исходного разрешения.
Окончательный постпроцессинг
Весь этот этап выполняется в одном пиксельном шейдере:
- применяется тепловая деформация с использованием данных карты искажений
- текстура bloom добавляется поверх буфера HDR-освещения
- применяются такие эффекты, как виньетирование, грязь/блики
- вычисляется средняя яркость при помощи сэмплирования карты яркости 2x2, а также дополнительных параметров выдержки, применяются тональная компрессия и грейдинг.
Тональная компрессия: до
Тональная компрессия: после
Тональная компрессия берёт буфер HDR-освещения, содержащий цвета, изменяющиеся в широком диапазоне яркости, и преобразует его в цвет с 8 битами на компонент (LDR), чтобы кадр можно было отобразить на мониторе.
Оператор кинематографической тональной компрессии основан на уравнении
(x(Ax+BC)+DE) / (x(Ax+B)+DF) - (E/F), это тональная компрессия Uncharted 2, также применённая в GTA V.Также надо заметить, что общий красный оттенок сцены получается цветокоррекцией.
UI и зернистость плёнки
И наконец UI располагается поверх кадра игры; в то же время добавляется небольшой эффект зернистости плёнки.
UI и зернистость: до
UI и зернистость: после
И мы завершили обработку кадра, он готов к передаче на монитор для отображения; выполнено множество вычислений, но всё это произошло меньше чем за 16 миллисекунд.
DOOM удаётся создать высококачественную картинку при высокой скорости игры, потому что он с умом использует старые данные, рассчитанные в предыдущих кадрах. Всего у нас получились 1331 вызов отрисовки, 132 текстуры и 50 буферов рендеринга.
Бонусная информация
Подробнее о стёклах
Результат рендеринга стекла очень хорош; при этом он достигнут довольно простыми способами, которые мы рассматривали выше:
- подготовка нескольких уровней размытия рендеринга непрозрачных сеток
- отрисовка просвечивающих элементов в порядке «сзади вперёд» в прямом режиме с применением декалей/освещения/отражения зондов с помощью предыдущей цепочки для различных значений размытия преломления стекла; при этом каждый пиксель может получить собственное значение преломления.
Стекло: до
Стекло: после
Глубина резкости
На изученном нами кадре не видно глубины резкости, так что давайте рассмотрим следующую сцену до и после её применения:
Глубина резкости: до
Глубина резкости: после
Не все игры правильно применяют глубину резкости: наивный подход часто заключается в использовании гауссова размытия и выполнении размывания за один проход в зависимости от глубины пикселя. Такой подход прост и экономен, но имеет некоторые проблемы:
- гауссово размытие хорошо для эффекта bloom, оно неправильно создаёт боке: вам потребуется плоский центр, чтобы свет яркого пикселя распространился по всему диску или шестиграннику. Гауссово размытие не способно создавать красивые формы боке.
- применение глубины резкости за один этап пиксельного шейдера может легко привести к артефактам на границах.
В DOOM глубина резкости применяется правильно; по моему опыту, выбран один из подходов, дающих наилучшие результаты: создаются изображения с большой и малой глубиной резкости: выбор пикселей выполняется в зависимости от его глубины и параметров глубины резкости.
- Изображение с малой глубиной может быть сильно размыто, чем больше оно «растекается» на пиксели за ним, тем лучше.
- Изображение с большой глубиной также размыто, но оно не считывает пиксели из области в фокусе/малой глубине резкости, поэтому избегает проблем с объектами на переднем плане, ошибочно «растекающихся» на фон.
Для создания размытия боке DOOM работает на половинном разрешении и выполняет круговое размытие с 64 наложениями текстур, каждый фрагмент имеет одинаковый вес, так что яркость действительно распространяется вокруг, в отличие от гауссова размытия.
Диаметр круга может изменяться попиксельно, в зависимости от значения пятна рассеяния пикселя.
Затем боке распространяется дальше с размытием из 16 наложений, но на этот раз средневзвешенное значение не вычисляется, а просто накапливаются значения сэмплов и сохраняется самое большое значение соседних наложений; это не только расширяет первое размытие, но и устраняет небольшие артефакты (пропуски в сэмплировании) первого прохода. Последняя часть алгоритма взята из работы Макинтоша (McIntosh).
Такая техника итерации на несколько проходов позволяет получить очень красивые большие размытия, оставаясь в то же время эффективной с точки зрения производительности; количество наложений текстур на пиксель всё равно достаточно мало, если учесть большой радиус полученного конечного кругового размытия.
Большая глубина резкости
Большая глубина резкости и размытие 1
Большая глубина резкости и размытия 1 и 2
Наконец изображения с большой и малой глубиной резкости накладывается на исходную сцену со смешиванием альфа-каналов для создания окончательного эффекта глубины резкости. Этот проход выполняется прямо перед применением motion blur.
Дополнительные источники
Если вы хотите глубже погрузиться в технологию idTech 6, то к счастью на эту тему есть множество лекций и публикаций:
- The devil is in the details: idTech 666 (Siggraph 2016), Tiago Sousa and Jean Geffroy
- Tech Interview: Doom, Digital Foundry
- id Software Tech Interview, DSOGaming
- QuakeCon 2016: Doom Uncapped – Part1 и Part 2
- Doom: The definitive interview, VentureBeat
- Graphics Gems CryEngine 3 (Siggraph 2013), многие техники постпроцессинга используются в idTech 6.
Комментарии (71)
we1
13.09.2016 23:57+3Круто. Жаль нет видео этих фрагментов.
PatientZero
14.09.2016 09:11+1Посмотрите видео прохождения игры на ютубе, судя по описанию, кадр брался из самого начала игры. Также рекомендую оценить оригинал статьи, там изображения сменяются как слайд-шоу, немного нагляднее получается. К тому же там есть интересные WebGL-вставки.
we1
14.09.2016 10:31Спасибо. Действительно есть. Отличные разводы крови на полу. До грязного стекла правда пока не дошел.
Grief
14.09.2016 02:45+1Спасибо за перевод. Кластерный рендеринг — для меня что-то новое, надо будет попробовать. Жалко, что ничего нет по SVO (Sparse Voxel Octree). Хотя, я догадываюсь, почему — всю информацию, содержащуюся в статье, автор выцепил из вызовов API, а вот как оно устроено внутри — нужно декомпилировать код. Ну и больше всего удивило, что на интерфейс ушло почти 10% вызовов API, они ведь далеко не бесплатные (ну, по крайней мере в OpenGL, не знаю насчет Vulkan), интересно, почему незаоптимизировали. Хотя, наверное, по сравнению с рендерингом сцены — это пренебрежимо мало.
klogg4
14.09.2016 22:34А кто сказал, что в idTech 6 используется SVO? Единственное упоминание о нём дал Кармак в 2008 году, после этого ни одного упоминания об SVO не было, а ведь прошло 8 лет, более того, 2.5 года движок разрабатывался вообще без Кармака. Что на данный момент используется в idTech 6, вопрос, как по мне, очень даже открытый.
creker
14.09.2016 23:07http://www.eurogamer.net/articles/digitalfoundry-2016-doom-tech-interview вот одно из немногих технических интервью и тут ни намека на SVO. Более того, я только на вики и читал об этом, которая ссылается на презентацию 2008 года, где речь просто об исследовании новых техник. SVO вообще никто в релиз не пускал, насколько знаю, техника плохо изучена, а единственное ее применение в виде SVOGI было быстренько отключено в Unreal Engine 4 и заменено другой более дешевой техникой. В ближайшее время SVO мы точно не увидим. И я даже не уверен, что оно прямо так нужно. Непонятно, какую такую насущную проблему оно должно решить. Собственно, тот же вопрос и к виртуальным текстурам. Да, прикольно, но результат себя как-то не оправдывает.
Diaskhan
14.09.2016 07:29Когда Id software выпускает DOOM, значит они хотят показать возможности движка нового поколения в данном случае idTech 6
Потом и начинается штамповка других игр на этом современном движке idTech 6.
А то что дуум стал похож на своего кровного брата Quake, итак понятно, динамика игры слишком быстрая!Idot
14.09.2016 07:49А мне драйв нового Дума — очень понравился. Напомнил скоростное прохождение классического Дума.
rkfg
14.09.2016 08:17+5Странно, технология такая крутая, а картинка… не ощущается некстгена. Всё такое же металло-пластиковое, как и в DOOM 3. Сейчас даже в Unity шейдеры (читай: материалы) лучше, чего уж говорить про UE4. А Id, похоже, решили вложиться в технологии оптимизированного рендера (чтобы быстро было и с глубиной резкости), а не в реалистичные материалы и освещение, тогда как у конкурентов упор на всякие subsurface scattering и прочий physics-based lighting с почти-почти-уже-честным global illumination. Вот эта их мегатекстура как технология хороша и даже революционна, но игроки разве оценили её? Дизайнерам, возможно, по душе пришлось, но и только. А вау-эффекта со времён D3 у меня лично не возникало от их игр/движков. Печально.
Idot
14.09.2016 08:28-2В DOOM III тоже некстгена не ощущалось — потому что там все лампочки не бьющиеся, и прочих динамических источников света — тоже как у козла молока. И дело не в движке (который всю эту радость позволяет), а в криворукости и консерватизме дизайнеров :-(
А так, реально порадовало — что наконец-то появились открытые пространства! :-)rkfg
14.09.2016 08:40+4Я в саму игру не играл (в новый DOOM), так что оцениваю чисто по скриншотам и видео. А в DOOM 3 были крутые динамические тени от всех предметов, пусть и чернущие, ну и normal mapping. На фоне других игр это выглядело совершенно потрясно. А ещё там были интерактивные интерфейсы, вписанные в мир, т.е. жать кнопки на сенсорных экранах можно было не открывая модальный интерфейс, а двигая головой. Жаль, что не очень это прижилось.
rkfg
14.09.2016 08:48И вообще, сами их дизайнеры не используют возможности движка, выходит, а больше им никто не пользуется. Я разве что Prey могу вспомнить из того, что делали сторонние разработчики, ну и отчасти Wolfenstein, но это всё же Id'шная франшиза. Тогда как на UE3/4 сделана невообразимая масса игр от кучи различных студий, а теперь ещё и инди подтянулись. И учитывая тенденции по уходу в опенсорс, Id останется либо сидеть на своём стогу сена и стагнировать, либо присоединяться. Сомневаюсь, что появится много желающих лицензировать Id tech, когда вон тут бесплатно раздают намного более технологичный, кроссплатформенный и обвешанный экосистемой UE4 со смехотворными отчислениями. Ну понятно, что 5% с определённой суммы могут перестать быть смешными, однако ж вряд ли Id/Zenimax сумеют по совокупности сделать более интересное предложение.
ordoss
14.09.2016 22:57Там весь вау-эффект возникает при бешеной динамике игры, статические картинки не могут этого передать
fshp
15.09.2016 00:19Я так и не понял, какую проблему решает мегатекстура.
rkfg
15.09.2016 09:29+2В классическом подходе на модели накладываются небольшие одинаковые текстуры, ну там «камень» или «кирпич» и повторяются сколько надо раз, чтобы покрыть всю поверхность. Мегатекстура же имеет размер во всю поверхность карты, так что можно рисовать уникальные текстуры, которые никогда не повторяются. На самом деле, глаз это не очень замечает, если сама игра интересна, так что для игрока эффект не особо впечатляющий. Разве что специально ходить и разглядывать уникальные трещины и пыль.
HOMPAIN
14.09.2016 08:58+3Спасибо, интересная статья.
Не понятны 2 вещи:
1) Зачем нужны мега текстуры? В чём их плюс в данной случаи по сравнению с отдельными текстурами. А сейчас тем более уже есть Texture Array.
2) Для чего двигающиеся объекты, статические и оружие рисуются отдельно?knstqq
14.09.2016 10:54+12) Для чего двигающиеся объекты, статические и оружие рисуются отдельно?
Чтобы использовать результат вычисления предыдущего кадра для отрисовки текущего
creker
14.09.2016 11:321) их плюс в теоретической неограниченности разнообразия текстур и общего их количества при минимальном потреблении VRAM. Особенно при сравнении с обычным подходом. Теоретически, потому что все равно ограничено все размерами игры, которые желательно уложить в 50Гб где-то. И тем, что их все равно надо стримить в реальном времени, да еще в зависимости от того, где игрок находится и куда смотрит. В основном упор именно на разнообразие. Rage был раскрашен, грубо говоря, полностью вручную.
Но тут есть обратная сторона медали — это слишком большая работа и, можно сказать, она себя не окупает. В Rage технология явно была еще молодая и, я не помню конкретно почему, но именно из-за нее все освещение было статическим. Даже прямой свет от солнца там был статический, хотя сейчас в играх совмещение этих вещей уже обязательная программа
К Doom они существенно упростили и ограничили использование виртуальных текстур. Добавили привычный тайлинг и detail maps. Вроде как раз ради динамического освещения. Подозреваю, что и PBR повлиял, будучи более требовательным к количеству текстур на материал. К сожалению, полноценной презентации на эту тему я не видел.
По мне, оно того не стоит. Тем более если посмотреть на то, чего можно достичь с обычным текстурированием вкупе с фотограмметрией. Примеры, которые вспомнил, star wars battlefront, order 1886 (может они немного по-другому делали, но PBR текстуры они снимали именно с реальных материалов) и вот скоро выходящий forza horizon 3.
nikitasius
14.09.2016 09:40+1Выглядит офигенно!
Bloom и тональная компрессия радикально меняют эффект от игры, как и отражения. Чего далеко ходить — Alien Isolation (который идет на средних, без лагов, на HD5500).
Но вот чего не хватает… Doom 3 со своими убогими тенями и отсуствием глубины и кривыми отражениями заставлял срать кирпичами, ибо черное было по настоящему черным и звук там радикальный. У меня он стоит на внешнем харде и раз в год (c 2005 года) я его запускаю и до-прохожу сюжет. В далеком 2005м меня не хватило надолго фонарик-пистолет-дробовик, в итоге поставил мод фонарик+пистолет и фонарик+дробовок. Именно эта игра (на максимальной сложности и в больших наухниках) заставляла матерится, имея арсенал оружия.
К примеру упомянутый выше AI добивается такого эффекта в силу проработанного звука и… беспомощности героя (чужого не убить, оружия крохи..).
отщепяткиIdot
14.09.2016 10:27Поиграй в первый Aliens vs Predator — если хочешь по-настоящему высрать кирпичей. Игра кстати, с динамическим освещением и задолго до DOOM III. Играть желательно в темноте и с Surround Sound.
TheShock
14.09.2016 11:20+1AvP, конечно, прекрасна, но там не было ничего даже похожего на динамические тени (а прорыв дума именно в тенях, а не просто освещении), посмотрите сами на видео — никаких теней. А чтобы понять в чем прорыв Дума3 — сравните его, например, с Unreal Tournament, который вышел в том же году. Как на меня — разница очевидна. Как раз в поколение.
Nerock
15.09.2016 08:42Имхо, сравнивать одинчную игру, вроде Дума, (которая не у всех может работать без лагов на тот момент), с мультиплеер-игрой, (которая должна работать у всех), некоректно. Все таки цели у игр разные, и подходы к графике тоже
elmm
14.09.2016 16:54В те времена это была настоящая фабрика по производству кирпичей (если играть за человека). Думаю, что сейчас это уже не сработает.
Rasifiel
14.09.2016 17:58+3Ну это совсем разный жанр. DOOM и DOOM 2 не были ужастиками, а были динамичными шутерами. Новый DOOM к ним возвращается.
tangro
14.09.2016 11:05всё это произошло меньше чем за 16 миллисекунд.
Давайте, любители Java, .NET, Python, Javascript и прочего, расскажите мне ещё о смерти С и С++.creker
14.09.2016 11:18+3Вы же понимаете, что практически все вычисления происходят на GPU? .Net и Java здесь не сильно помешают
RomanArzumanyan
14.09.2016 11:46+4Может вмешаться сборщик мусора в ненужный момент. Ну и всякие фишки для байтослесарей в С/С++ идут на ура.
Nagg
14.09.2016 13:00Ну гц не будем вмешиваться в каждый кадр, а так в современных гц с поколениями и конкаррент сборками это может и не помешать совсем.
tangro
14.09.2016 18:13+1Не «все вычисления», а «все связанные с графикой вычисления». А помимо графики там ещё дофига всего есть — физика, логика игры, управление, звук, сеть и т.д. да и «связанные с графикой» вычисления не все на GPU работают, об этом в статье тоже написано.
creker
14.09.2016 18:19Вот не надо. Я написал "практически все вычисления". Это именно так. Подавляющее большинство вычислений идет на GPU. Поэтому .Net и Java помешают не так уж сильно. Разве что какая-нить физика может буксовать будет и вспомогательные графические вычисления на CPU. Хотя надо еще смотреть, какая она нужна для игры. В Doom ее, по сути, и нет никакой. А логика, звук, управление, сеть — все это ерунда для managed языков.
Idot
15.09.2016 10:29В новом DOOM — наконец-то Марсианская Гравитация!!! А не земная как в DOOM III. Сила тяжести на Марсе примерно вдвое меньше, чем на Земле.
YegorVin
16.09.2016 10:11Разве все вычисления с подготовкой буферов, затронутые в этой статье, идут на ГПУ?
creker
16.09.2016 11:18Судя по статье — да, что совсем не удивительно. CPU тоже помогает, но его вмешательство минимально и с каждым годом все меньше. Все больше задач переносят на теже compute шейдеры, а CPU все больше оставляют задачи просто подготовить данные. Как вот cluster и tiled deferred rendering, где разделение можно реализовать на CPU. Хотя никто не мешает это сделать и в compute шейдере.
ultranoob
14.09.2016 12:01+2Ну как-бы если нужно аккуратно вбить шуруп, то очевидно что лучше его вкрутить…
Всему свой инструментарий и не более того.
rkfg
14.09.2016 12:23У C++ есть киллер-фича — ты не платишь за то, чем не пользуешься. То есть, вся эта темплейтная ООП-мешанина в ряде случаев конвертируется или инлайнится в обычные функции без vtable, что позволяет сэкономить память и такты процессора. Конечно, в JIT и интерпретируемых языках такое отсутствует, но сам JIT очень неплох. Хоть и не истина в последней инстанции, Benchmarks Game позволяет оценить качество оптимизаций JVM против C++: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=gpp — отрыв не такой уж большой. А вот потребление зато памяти серьёзное, да и самопроизвольно срабатывающий GC для игрового кода подходит не очень. Вообще, на Java игры есть, не только известный Minecraft, но и Starmade, например, или Retro-Pixel Castles. Мне кажется, отсутствие красивой графики вызвано и непопулярностью платформы для игроделия, и отсутствием серьёзных движков с хорошим инструментарием, и падением производительности на стыке Java и нативного кода (JNI), который дёргает OpenGL.
А компилирующиеся в нативный код языки никуда не уйдут, у них огромная кодовая база и сообщество. Может, Rust что-то сможет предложить, время покажет.creker
14.09.2016 12:33Unity работает вполне сносно со своей сборкой мусора. Хотя и есть проблемы, в основном на консолях. По идее, достаточно настроить GC, чтобы он делал паузы гарантированной продолжительности. Как в том же Go, где низкая латентность главная цель их сборщика мусора.
rkfg
14.09.2016 14:07+3Unity написан таки на C++, а на C# там только игровая логика, вроде. Думаю, это не оказывает такого сильного влияния.
SAWER
16.09.2016 10:11+1Не совсем верно будет говорить только о С++ — там мешанина как минимум 3 языков, которые образуют редактор Unity. Да и не важно на чем написан Unity. Вопрос то об играх, не так ли? И игры то уж точно работают на С#, где с плюсов только некоторые модули движка(основные игровые циклы и низкоуровневая работа с графикой). И если игру делали опытные разрабы, да и с нормальными сроками разработки, то они хороши и по графике, и по производительности. Во всех проектах, с которыми я работал, ни разу не доходило до переписывания или глубокой оптимизации обработки графики для Unity — везде больший профит дала бы оптимизация кода игры. Порой даже было наоборот — собственные реализации для рендера давали худшую производительность и работали хуже стандартных средств Unity. Так что, я считаю, что тут просто в нужном месте используют нужный язык.
Так же стоит отметить, что Unity проект может собрать разными способами, в том числе, по сути, не используя компилятор mono, а используя свой, который делает из C# IL кода С++ (условно). И у самих работников Unity получалось добиться производительности ~ обычного С++ кода, при этом используя почти все возможности mono .Net 3.5, коих много больше чем у С++.
Чуточку о сборщике мусора. Они могут быть разными. Обычный подходит для сервера или офисной программы, а для приближенных к обработке данных в реалтайме или таковых же, его можно и подпилить, ну или наделить нужным функционалом. Что во всех игровых движках на C# постоянно и делают. Всё таки GC не основа С#, а скорее просто способ собрать программу. Кстати, JIT так же не обязателен, есть NGen.
PS: Гораздо чаще сталкиваюсь с тем, что нужно сделать проект быстрее, и производительность далеко не на 1 местах(тут разве что для айфонов исключение было). А этому больше помог бы C# 6 и .Net 4.5+, а они всё пилят С++ компилятор из IL. А ведь можно было бы и кривоту архитектуры Unity и её же ограничения легко поправить c async/await, что убрало бы множество костылей.Nagg
16.09.2016 21:11Unity не могли взять и обновить моно до последней версии с C#6 и т.п. из-за лицензии моно. Но в марте этого года моно стало MIT и теперь unity скоро будет со свежачком ;-)
varnav
14.09.2016 14:33+1Кстати, игра хорошо оптимизирована. Выдаёт отличные FPS даже на средних видеокартах.
BFG1992
14.09.2016 22:35-1Скажите это моей GT645M, на которой всё остальное идёт вполне сносно и даже не на минималках, а новодум в разрешении 1366x768 на настройках в самый минимум и половинном внутреннем разрешении не просто ужасно тормозит, а ещё дёргается как паралитик. Я в локации, что на скрине, импов нормально стрелять не мог, FPS постоянно прыгал с 30 до 10. Это при i3-3120M 2.5 ГГц и 6 Гб RAM.
varnav
14.09.2016 23:14+1645M всё таки не средняя видеокарта, средняя сейчас это 880 или 780.
BFG1992
14.09.2016 23:39Что, простите? Мне вот всегда казалось, что GTX*80 — топовые решения. Хотя для товарищей с кучей лишней денег и первый титан уже посредственность, да.
По мне, так разница между поколениями сейчас не настолько большая, чтобы считать карты трёх-четырёхлетней давности «средними».
Моя GT645M на 1366x768 по производительности примерно как 750Ti в FullHD. И я не требую от игры 60 fps, я и на 30 согласен, лишь бы поиграть.creker
15.09.2016 00:10+2Средние карточки сейчас это radeon 480 или geforce 1060 — какой там эквивалент будет в ноутбуках не знаю. Они способны тянуть дум чуть ли не в 4к, что как бы очень круто. Ваша карта это жуткий low-end и ни в какое сравнение не идет с упомянутой 750ti (вы не ошиблись тут? Это карта другого класса абсолютно). Помимо этого у вас жутко low-end процессор. Поэтому совершенно не удивительно, что дум вообще не играбелен. Дергается он как раз из-за процессора.
BFG1992
15.09.2016 02:04Я смотрел производительность различных видеокарт в различных играх на Notebookcheck, и сравнивал со своей. На основании этого делал такие выводы. Ещё раз отмечу, что сравниваю я производительность более слабой видеокарты в 1366x768 и более мощной в 1920x1080.
Но ладно, пусть моя видеокарта и процессор жуткй лоу-энд, я не спорю. Но вот почему-то я на этом жутком лоу-энде относительно комфортно играю подавляющее большинство современных AAA-игр, порой даже позволяя себе включить такие красоты, как SSAO и отражения. Так чего же игра на движке, чуть более старая версия которого у меня летала на высоких (последних два вольфенштейна, особенно Old Blood), не может нормально идти на самом минимуме?
P.S. Сейчас ещё скачаю демку новодума и посмотрю на графики загруженности процессора, аж интересно вспомнить, насколько он у меня лоу-эндовый :)creker
15.09.2016 02:29Лучше посмотрите на 3mark результаты этих карт, насколько это кардинально разные карты. Они в абсолютно разных классах находятся.
Что до комфортной игры. Современные игры это какие? Я вот сейчас посмотрел ролик ведьмака 3 на 640m, что, по сути, таже самая карта. 15 фпс даже на низких настройках. Это нормально, потому что это low-end решение по всем статьям и это современная игра. У нас тут наступило новое поколение консолей и требования игр довольно сильно изменились с тех пор. Не имеет смысла даже смотреть на игры, которые способны идти на прошлом поколении консолей. Это не показатель. Doom показатель, потому что это чертовски шустро бегающая игра на среднем железе на момент выхода этой игры. Опять же, 480 и 1060 это бюджетные средние решения, и они тянут эту игру в 4к на максах.BFG1992
15.09.2016 02:59Ведьмака я не смотрел — исключительно ради теста качать его не хочется, а проходить ещё рано — первые две игры ещё нужно пройти :)
Современные игры — это, например, Alien: Isolation, где оптимизация была настолько хороша, что я даже включал DX11 глубину резкости вместо обычной гауссовой размывки, которая обычно отнимает 10-15 fps. Или вот прямо сейчас прохожу Far Cry 4, на средних 25-40 fps, но ровных. Могу ещё бету The Division вспомнить — шла на удивление хорошо, и выглядела тоже приятно. Mad Max и Shadow of Mordor — обе шли хорошо, 30-50 fps на средневысоких, а это игры с открытым миром. Новый Вор — тот шёл просто идеально, на полном максимуме (без SSAA и с тенями попроще) 50-60 fps почти везде. Да много их.
Могу вспомнить, что шло не очень: Dying Light — ну никак не получалось выжать из игры 30 fps на открытых локациях, хотя игралось всё равно относительно неплохо. XCOM 2 — тормозило жутко, без особых на то причин, хотя, если спустить до минимума, то до 45 fps поднять можно было. Rainbow Six: Siege бета — при никакой графике минимальных настроек 60 fps выжать никак не получалось, а при разрушениях всё тормозило просто адски. Unreal Tournament новый и почти всё на UE4 — что они сделали с божественным UE3, который летал на кофеварках, не пойму. AC: Unity и Black Flag — с первым понятно, он тормозил практически у всех, а вот что не так со вторым — неясно (хотя играть можно, если привыкнуть).
Так вот, даже то, что тормозило, в основном тормозило адекватно (Unity — великолепная детализация и открытый мир, Siege — разрушения, UE4 — шейдеры сильно некстгеновые, наверное?), а вот что не так с коридорным новодумом, который использует тот же движок, что и чуть ли не летавший у меня последний Wolfenstein: Old Blood, не пойму. Вот это и раздражает.BFG1992
15.09.2016 03:40Затестил демку… Знаете, я беру свои слова назад :) Частично, во всяком случае. Не знаю, в чём дело — то ли патчи помогли, то ли обновления драйвера, но теперь дум
1) тормозит меньше — 20-30 fps на минимуме с родным разрешением экрана.
2) идёт ровно! Играть можно :)
3) починился Vulkan! Ранее дум с ним работал только в меню. Увы, быстродействия он не добавляет (в моём случае).
В целом, я очень рад, ведь очень хотел поиграть и теперь, наконец, могу :) Спасибо за то, что заставили меня проверить.
Насчёт процессора и его лоу-эндовости — игра его не особо-то и кушает, как и видеокарту, что не мешает ей выдавать 43-52 fps в меню: OGL, Vulkan и во время игрового процесса: OGL, Vulkan.
Alexeyslav
13.01.2017 11:56Приведённую схему красивой может назвать только художник, и то только потому что использовано больше одного цвета. На самом деле, с инженерной точки зрения схема очень запутана и некрасива. Аккумулятор находится где-то в середине схемы, расположенный самым неудобнейшим образом. Он вообще должен быть изображен в самой правой части схемы логически отделённый от неё как внешний элемент, через клеммы.
Точно так же, изобразить источник питания схемы(зарядное) — в виде клемм в ЛЕВОЙ части схемы.
Общий провод должен быть в самой нижней части схемы, простота схемы вообще позволяет обойтись без вынесенных значков земли.
У изображённой ардуины убрать все неиспользуемые выходы, датчик тока вообще обозначен непонятным чёрным ящиком, и понять что это датчик тока можно только по косвенным признакам.
Логически все входные сигналы расположить в левой части модулей, а выходные в правой. Но есть и исключения — датчик тока таким образом расположить будет крайне неудобно, поскольку контролируемая цепь находится в правой части схемы, и для него делается исключение.
Схема должна быть понятной и очевидной. Да и упущен вопрос питания самой ардуины, там наверно ещё и DC-DC конвертор имеется с 12В в 5В? Который не изображён на схеме…
Да, разные цвета на схеме для компонентов и проводов предназначены лишь для удобства редактирования схемы, но «выходной документ» должен быть черно-белым.
А кстати, где-то на просторах интернета видел информацию о том что лучший алгоритм десульфатации — это те же заряд-разряд но с периодом в 20-40мс и скважностью 10 к 1.BFG1992
17.09.2016 01:06Как-то я не могу понять, как «чертовски эффективный рендер» может так сильно тормозить. И если не по слабому железу судить, то по какому же? На мощном железе и так тормозов не будет, на то оно и мощное :)
>Wolfenstein: Old Blood сделан на предыдущей версии ID Tech, а Doom на новой
Это я узнал уже после того, как написал комментарий :)
>HDR (судя по интервью, только в думе появлось)
HDR существует ещё с третьих шейдеров. Как сейчас помню проблему первых решений, когда не могли совместить HDR и антиалиасинг. Это было с десяток лет назад. Или вы о каком-то другом HDR говорите?
Совсем лоу-энд — это всё, что ниже GT*40 по видеокартам и i3 2.2 ГГц по процессорам. Вот там совсем ни во что поиграть нормально нельзя. А то, что у меня — просто ниже среднего, учитывая разрешение экрана.
Про минимальные требования — их часто завышают и/или пишут для игры на FullHD. Я вполне себе играю многие современные игры на моей системе, которая почти везде ниже минимальных требований, о чём я уже писал. Но проблема дума не в этом. Он просто оптимизирован исключительно на три последних поколения видеокарт. Уже на 6xx серии нвидий начинаются проблемы, например — почти ничего не дающий в производительности (а донедавна и вообще работавший только в меню) Vulkan, а уж на поколениях постарше там всё ещё хуже, наверное. Это я не только по своему железу сужу, в сети полно отзывов.
Насчёт AC: Unity я, в принципе, ничего не возражаю, там таки есть, чему тормозить. У меня больше недоумения от Black Flag.creker
17.09.2016 01:36. И если не по слабому железу судить, то по какому же? На мощном железе и так тормозов не будет, на то оно и мощное
Совсем лоу-энд — это всё, что ниже GT*40 по видеокартам и i3 2.2 ГГц по процессорам
Я понимаю, что вам хочется, чтобы на вашем железе бегало все быстро. И естественно закрадываются мысли о недобросовестных разработчиками и понатыканных слипах для старых видеокарт, чтобы на них все тормозило. Но так не бывает. Идет прогресс. Опять же, вышли консоли, произошел очень сильный скачек в том, что разработчики понимают под минимальными и средними возможностями железа, а с ними очень сильно изменились современные движки. Да, бывают делают не честно, но в данном случае нет ничего удивительного, а ваше железо просто морально устарело. Идут на нем еле еле только те игры, которые не являются современными. Это закономерно. И дум нельзя никаким образом назвать прожорливой игрой. Все с точностью до наоборот.
Сейчас вот вышла пс4 про. В следующем году выйдет обновленный иксбокс. Это еще сильнее подтолкнет прогресс и требования игр. От этого никуда не деться.
И если не по слабому железу судить, то по какому же?
Мне сложно назвать ваше железо даже слабым.
HDR существует ещё с третьих шейдеров. Как сейчас помню проблему первых решений, когда не могли совместить HDR и антиалиасинг. Это было с десяток лет назад. Или вы о каком-то другом HDR говорите?
Существовал он еще раньше. Дело в том, что реализовывать его все равно разработчикам своими руками. В интервью они говорили, что это одна из новых фич движка. Да и HDR это слишком размытое понятие и реализовать его можно очень сильно по-разному. В каком виде он существовал до этого не знаю. Могло не быть вообще, а могло быть его жалкое подобие. Вариантов там достаточно.
почти ничего не дающий в производительности (а донедавна и вообще работавший только в меню) Vulkan
Вулкан и dx12 дают прирост в строго определенных случаях, это не silver bullet. Отрицательные отзывы здесь всегда исходят от того, что люди не понимают, как эти вещи работают и когда они дают прирост. Я это вижу уже многие годы. Люди лезут в эту тему, которая, вообще-то, предназначена для разработчиков, а не игроков, и делают выводы, не имея малейшего понимания темы. Это было при d10, это было при dx11. Это происходит сейчас. Во всех случаях игроки все еще не могут ничего понять, хотя информация подается ну уж в очень упрощенном виде в пресс релизах.
Все дело в том, что это сложные вещи и их невозможно просто взять и объяснить. И здесь нет такого, что было 30 фпс, включил вулкан, и стало 60 фпс. Как минимум, могу сказать, что наибольший эффект получает новое железо, потому что оно имеет более совершенную архитектуру. Новые API эту архитектуру умеют использовать. Конкретно, async compute. У нвидии на нее способным толком только паскаль чипы. Это лишь одна деталь, но очень важная. Опять же, здесь нет никаких заговоров. Все закономерно и понятно, но только для тех, кто немножко в этой теме.BFG1992
17.09.2016 04:33Прогресс — понимаю, да. И потому не требую от новых игр заоблачных fps на моём ноуте трёхлетней давности. Тем не менее, некоторые разработчики всё же умудряются заоптимизироввать свои творения так, что даже я на своей машине могу в них поиграть. Примеры выше приводил.
И да, взгляните на мои скриншоты выше. Как вы обьясните менее 60 fps в меню, где ничего нету кроме пары текстур дыма и частиц, при загрузке видеокарты в 70-80%? Мне вот кажется, что некая недобросовестность всё же присутствует. Или даже заговор, кто знает? ;)
Мне сложно назвать ваше железо даже слабым.
Ну да, если иметь в распоряжении машину, способную на 60 fps в 1080p в любых играх — то да, с такой колокольни моя машина вообще ерунда :) А если ещё и зарплата в долларах…
А вот для вчерашнего студента, так и не нашёдшего работу, это вполне приличный агрегат, на котором можно поиграть во всё современное… можно было :(
Интересно, какого вы мнения будете о людях, которые на интелах встроенных играют :)
Про HDR — погуглил. Подозреваю, что это как-то имеет отношение к недавнему Dolby Vision, который последними (и только самымипонтовымидорогими, естественно) телевизорами поддерживается. Там есть эдакий HDR, который для десятибитного видео и игр. Хотя могу ошибаться, конечно же.
Про DX12 и Vulkan — вы так жирно намекаете, что я нуб и сужу о том, в чём ничего не смыслю, что мне аж смешно :) Тем временем, я по меньшей мере неплохо понимаю, что из себя представляют эти новые API. Всё, что в них нового — более низкоуровневый доступ к железу видюхи, а именно — перекладывание (почти всех) забот по переносу инфы от процессора к видеокарте на плечи (и головы) программистов игровых движков. Это приводит к более быстрой обработке draw calls, использовании ресурсов нескольких разных ГП и более прямому доступу к данным в видеопямяти, что открывает возможность различных оптимизаций, недоступных на старых API — это если разработчик сумеет это всё реализовать. Это я понимаю, как и понимаю, что часто далеко не всё можно оптимизировать даже на новых API. Но вот почти всегда можно снизить нагрузку на ЦП, например (оптимизация пресловутых draw calls же). И да, даже на видеокартах, которые не поддерживают этот вот async compute. Включая мою GT645M! Чёрт, да я перешёл на Win10 только из-за того, что в (моём любимом) эмуляторе GameCube/Wii под названием Dolphin реализовали DX12 бэкэнд, и он в некоторых играх выдаёт аж 50% прирост по сравнению с DX11! Это означает, что я наконец смог нормально поиграть во многие шедевры в фуллспиде без заиканий звука (которое неизбежно при падении fps ниже 60 для NTSC / 50 для PAL из-за жесткой синхронизации в железе консолей). Да, можно сказать, что эмулятор — довольно специфичный случай, но я не верю, что хотя бы некоторые методы, использованные разработчиками Dolphin, нельзя использовать в обычных играх.
varnav
15.09.2016 16:27GTX да, топовые — в момент выхода. А как только выходит GTX следующей серии — то увы, топовыми их считать больше нельзя.
Varkus
14.09.2016 17:38+1Читая такие статьи начинаю верить, что всё-таки увижу в этой жизни «реальную» отрисовку реалистичной графики, это радует.
1vanK
14.09.2016 23:57Это нужно ждать видюхи с хардварным рейтрейсингом, картинка уровня blender cycles уже плотную приближается к реализму
Varkus
15.09.2016 11:51Рождаешься, растёшь, детсад, школа, первая любовь, универ, работа, свадьба, дети, внуки, больница, свет уходит в точку…
И в этот момент с тебя снимают шлем виртуальной реальности и вытаскивают из ванны с питательным гелем:
— с пробуждением, как всё прошло? вы довольны прожитой жизнью?
— сколько я здесь провёл?
(если верить фильму «Начало», то соотношение течения времени сна и реала 1:12, т.е. 72 года вирта это 6 лет реала)
— около 6 лет, не беспокойтесь, вашему мозгу нужно пару дней на адаптацию и принятие этой реальности.
Вот как я хочу, почти фильм Начало, но более правдоподобно и это походу будет реально дорого.
andrey_aksamentov
15.09.2016 21:14Недавно установил игру, посмотреть Vulkan API, на старте был ощутимый прирост кадров, но через минут 20 все поменялось, сильно проседает производительность, вплоть до 10fps!
Может кто поборол недуг и может поделиться?
конфиг: amd 8320, 8gb, amd 7850 2gb.
Предположительно заканчивается память видеокарты.
A-Stahl
И что в итоге? Картинка ничем не выделяется на фоне других современных игр, а жрёт как в не себя.
Обещали вернуть геймплей 1-2 Дума, а получили коридор с комнатами в которых тебя закрывают и ждут пока ты там всех не перебьёшь и гонят в следующую такую же комнату. Монстры появляющиеся из ниоткуда. Дробовик из универсального оружия превратили в штык — на расстоянии больше метра он бесполезен. И теснота. Чёрт подери, да я не помню в первом думе потолков ниже 5 метров, а тут даже «на улице» тесно. Там были карты где шар от импа мог секунд 10 лететь до ближайшего препятствия.
Стыд и срам. Они не смогли даже повторить геймплей 20летней давности. Это провал. Полнейший. Даже gzdoom даст фору новому думу в 100 очков по графике, а по геймплею даже сравнивать некорректно.
ZimM
Что, простите? Добрая половина уровней Дума 1-2 представляла собой те самые тесные коридоры и маленькие комнатки. Уровней с реально большими пространствами было очень немного.
A-Stahl
Ага. Введите, скажем, «doom 2» в гугл и переключитесь на изображения. Увидите скриншоты. И посмотрите.
Да узкие коридоры во втором думе были просторней, чем широкие пространства в 4ом.
ZimM
Я прекрасно знаю, как выглядят Дум 1-2, проходил их множество раз. Да, там есть уровни с очень большими пространствами, которых нет в Думе2016. Но в Думе2016 открытых пространств тоже предостаточно. Лично меня ощущение клаустрофобности в Думе 1 не покидало никогда.
В среднем в Думе2016 открытых пространств даже больше, пожалуй.
Idot
В DOOM 2, уровни с большими пространствами встречались существенно чаще, чем в Первом. Но, и в Первом — они тоже встречались. Чем мне новый DOOM понравился — тем, что в нём наконец-то появились открытые пространства, которых так не хватало в DOOM III.
albik
Вы действительно не заметили, что статья о движке, а не о геймплее?
gunlinux
Как раз таки использует видеокарту на полную, бегает даже на устаревших процессорах. А про повторение геймплея 20летней давности – это что-то про траву и её RGB?
pshhpshh
Подтверждаю. Ноут с 950М. До выхода новый драйверов — лагало жутко, даже в меню. После — отлично катит на средних. 35-40фпс.
Viacheslav01
В контесте травы имеет смысл упоминать только R и его интенсивность.
Kopleman
Сложно сказать что то про движок в целом, но новый дум выглядит потрясающе, при этом он очень хорошо оптимизирован, не требует каких то заоблачных конфигурации для игры с 60+ фпс. Ну и по нему очень хорошо видно что Вулкан это очень круто.