Роман Марченко UrsusDominatus

Нет, GameObject'ов нету. Есть массив позиций и типов мешей на уровне, которые рисуются без участия CPU. Kуллинг и LOD switch'ing полностью на GPU, в шейдре. Про это и статья.

Есть вот: youtu.be/4Ghulpp6CPw, и вот: youtu.be/aKvsd7I4VQA
В описании к видео есть ссылка на пейпер.

Деревья и так модели. Они не GameObject'ы. Надо физика? Ставим коллидеры на местах деревьев. Надо непроходимость и огибание их отрядами? При генерации навмеша помечаем небольшие радиусы вокруг дерева как непроходимая область. Рендер деревьев при этом остается неизменный.

1. Да, примерно так. Про траву, возможно, будет отдельная статья. Взаимодействовать с конкретным деревом не сложно. Зависит от того как это взамодействие будет выглядеть? Нужно срубить? Помечаем в массиве как «невидимое». Нужна особая кастомная анимация? То же самое, но на месте исчезнувшего ставим обычный GameObject.
2. Скрытой камеры нет. Все делает SpeedTree Modeller. Там готовятся billboards. В оффлайне. На каждое дерево — свой набор спрайтов. Там, в статье, есть пример как выглядит.
3. Unity 5.6 :)

Материалы для начинающих я рекомендовать не буду, так как я ими уже много лет не интересовался. Книги: Серии ShaderX, GPU Pro, GPU Zen, GPU Gems. Real-Time Rendering. Но это все для подготовленного читателя.

Без знания математики такие системы не создашь, это 100%. Но можно начать с простого, постепенно осваивая новые моменты, принципы, архитектуру 3D рендера и т.д. Я, например, с туториалов и всяких там обучалок начинал.

Ну игру я не видел эту, но судя по видео там никакой физики нет. А есть там Flow Map (http://graphicsrunner.blogspot.com/2010/08/water-using-flow-maps.html). А геометрия статичная, с небольшим vertex displacement.

Naval Action.

Несколько уточнений для интересующихся:
— В NSight есть возможность сохранять кадр для отложенного анализа. Сделано просто немного необычным образом. Экспортируется C++ программа в исходниках + ресурсы, которая после компиляции рендерит один единственный статичный кадр. Эту программу можно анализировать как любое другое приложение.
— Геометрия террейна сделана с помощью технологии CDLOD (https://github.com/fstrugar/CDLOD/blob/master/cdlod_paper_latest.pdf)

Век живи, век учись. Все оказалось еще проще. Спасибо.

В студии очень просто работать с Graphics Debugger'ом. Создаем пустой native проект (С++), или открываем абсолютно любой существующий. В настройках проекта, в разделе Debugging в поле Command вписываем полный путь к исследуемому exe. По необходимости также заполняем поля Command Arguments и Working Directory. Закрываем настройки. Графический дебаггинг запускаем в меню Debug->Graphics->Start Diagnostics. Никаких PDB и «своего DirectX-кода» при этом не надо. Возможность дебагать child процессы была в PIX. Я когда игры реверсил постоянно ею пользовался. Сейчас в студийном дебаггере такой возможности найти не могу, возможно ее и нету. Зато в NSight есть. В настройках проекта надо поставить галочку «Application is a launcher». После запуска появится список child процессов среди которых надо выбрать нужный. Я не буду сравнивать различные дебаггеры (хотя бы потому что не работал с RenderDoc). Мне с лихвой хватало возможностей PIX/Visual Studio Graphics Debugger, PerfHUD/NSight, GPA, но весь тот функционал, что описан в статье есть во всех этих утилитах. Могу лишь только сказать, что все тезисы в разделе «Но:» кроме «PIX — уже устарел, не развивается и не работает на последних ОС» не соответсвуют действительности.

Технология крутая, но в этой демке показана только базовая реализация. Плюс немного криво сделанная. Не видна зависимость волны от направления ветра. Т.е. увеличивая силу ветра вода больше бурлит, вместо того чтобы формировать направленные волны. А данный метод это позволяет. Вот видео с презентации NVidia, которые сделали воду по подобной технологии, но гораздо более продвинутую: www.youtube.com/watch?v=WGjRLJpXYxA. Там создается несколько таких симуляций, для создания крупных волн и мелких волн-деталей. Все это хитро замешивается для устранения тайлинг артефактов. Также они считают турбулентность для создания красивой пены.

PH не закрывается по ESC, что грустно

Options->Hide when closed. Странное название настройки, но если ее включить, то по esc сворачивается

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

Хм, не совсем понял что хотел сказать автор, но по статье видно что явно не технарь. Вся современная 3Д графика это геометрия, текстуры и сложные шейдера. Та фактура, о которой идет речь — это новые сложные шейдерные эффекты, высокополигональные объекты (возьмите ту же аппаратную тесселяцию в DX11) и много, очень много текстур. Современнй шейдер позволяет делать новые, необычные материалы и модели освещения, которые были недоступны еще недавно из-за сложности вычислений. И использовать большое количество текстур для своих нужд. Текстура уже давно перестала быть просто «цветной картинкой». Это универсальное хранилище больших объемов самых разнообразных данных, из которых цвет занимает лишь малую часть. И их использование в будущем только увеличится.

я ГТА4 только мельком смотрел. Сильно не разбирался.

Константа передающаяся из игры в шейдер.

Глянул для чего еще один канал выводится. Все банально — там записана интенсивность тени. Т.е. обычной константой задается как сильно будет влиять тень от данного кастера на затемнение оригинального цвета места на которое ложится тень. Значение от 0 до 1. Получается per-object shadow intencity. Один канал остается свободный

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

Я просто старался термины разнообразить. Везде писать «делаем выборку из карты теней» будет стилистически не очень красиво

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

Бегал всеми комбинациями классов. Вчетвером. Нормально вроде все.

Осталось конечно. Как будет время я гляну.

Безбожно тормозит? У меня на стареньком GeForce 9600GT вполне шустро бегает практически на максимальных настройках. Есть проблемы с тормозами во время подгрузки ресурсов, но это к рендеру не имеет отношения.

Думаю имелось в виду текстура формата R32G32F. Как раз 64 бит на пиксель.

Нет, нет. Там еще 1 канал в этой шадоу мапе используется для каких-то целей. Я не до конца понял для чего именно и тогда видимо пошел дальше, оставив это на потом. И вот вспомнил только про это как раз.

Реверсом игр я занимаюсь давно, просто вот на хабре первый пост. Рендер реверсится с помощью свободно доступных тулзов, ну и знаниями как что работает. Я подумываю написать статью о методике реверсинга/отладки 3D приложений.
Я всегда реверсю на максимальных настройках графики игры. Карт нормалей в D3 нет вообще. А спекуляр спокойно живет и без них (спекуляр и карты нормалей никак не связаны по сути), и он есть в игре.
Откровений про рендер от разработчиков DiabloIII я в сети не видел, но есть дока по StarCraft2 pds17.egloos.com/pds/200908/12/03/Chapter05-Filion-StarCraftII.pdf

Тут я допустил промашку в объяснении. Приношу извинения.

Свой отдельный depth буфер можно не использовать, а использовать основной depth буфер (если разрешение экрана и shadow map'ы совпадают, что практически никогда не происходит), либо depth буфер каких-либо других эффектов. В случае «другой» буфер глубины multisampled, а shadow map'a non-multisampled, то вместе они работать не смогут. Это я хотел сказать.

В данном случае shadow map это не depth buffer. Это обычная текстура (render target), куда мы шейдером выводим глубину пикселя, рисуя сцену с позиции источника освещения. Для корректного z-отсечения нам нужен depth буфер.

Да, именно так. Спасибо за развернутое пояснение

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

1. Объекты невозможно сдвинуть. Если игра базируется на таких принципах, зачем применять более тяжелое и сложное решение (например SSAO)? Визуально то ничего не меняется.
2. Мягкая тень (пусть и не физически корректная) всяко лучше чем жесткая и угловатая. В игре персонажи занимают небольшую часть экрана, и при таком ракурсе все равно ничего не видно. Так зачем платить больше?

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

INTZ это особый формат буфера глубины. Он не используется для shadow mapping'a. Формат карты теней не будет меняться. Он останется ARGB32F. Но, тут два варианта. 1. Делать multisampled shadow map чтобы использовать существующий multisampled depth buffer. В этом случае размер карты теней смело умножаем на количество семплов мультисемплинга. 2. Делаем дополнительный non-multisampled depth buffer для рендера в non-multisampled буфер тени. И тот и тот вариант требует дополнительных затрат по памяти.

Ну, мне графика нравится. Понятно, что это субъективно, и графика в Frostbyte 3 явно технологичнее и красивее. Непонятных «багов» как-то и не встречал. Тормоза из-за потоковой подргузки и кеширования данных. Графика тут не при чем. Я говорил о том что рендер у них сделан хорошо.