hdrp перегружен, а то что built-in встроенный не значит, что на нём нельзя делать красиво. Глянь на "Hail to the Rainbow", сделана на built-in, а выглядит лучше чем половина игр на анриле. Конечно, это экстримальный пример, но думаю, у студии таркова есть бюджет на несколько таких разработчиков.
У hdrp ужасная производительность из коробки (имхо), и его надо ещё долго дорабатывать напильником, чтобы был какой-то приемлимый результат. Всё подчиняется простому правилу: чтобы было хорошо, надо делать хорошо.
Но дело ведь не просто в удобстве, дело в том, что в Вангерах вся земля была из разрушаемых вокселей. Динамичный террейн означает дополнительный геймплейные возможности. От реализации зависит, на сколько удобно передвигаться по такой поверхности, как коллайдеры колёс отрабатывают по земле, и как реагирует земля. Зато, это кратно повышает вариативность машин: разный вес и подвеска по разному будут реагировать с землёй, это мы ещё не говорим о чём-то более экзотическом, вроде машин-буров. К тому же, это опять же намного увеличивает потенциальное разнообразие дорог.
Если честно, мне трудно себе представить Вангеров без их системы земли. Просто аркадных гоночек из пункта а в пункт б было много, а Вангеры были одни.
Статью считаю не полной без упоминания сеток с низким расхождением, хотя бы без упоминания дизера IGN. Они дают ошибку ниже, чем Bayer, и имеют менее очевидный паттерн. К тому же, Bayer нельзя менять по времени, чтобы сглаживать ошибку между кадрами. Код с сравнением: https://www.shadertoy.com/view/w3BfRV подробнее про GPU friendly алгоритимы https://habr.com/ru/articles/881258/
Ощущение, что текст нейросеть написала, без погружения в материал.
Перед отрисовкой деревьев бери только буфер глубины как рендертаргет, отрисовывай деревья без пиксельного шейдера (только пиши глубину, либо с минимальным пикс шейдером, если есть клиппинг), затем бери в рендрертагрет свой колор буфер и устанавливай тот же буфер глубины без очистки (чтобы информация о ближайшей глубине сохранилась), после чего в пиксельном шейдере деревьев ставь Depth Test LEqual.
После этих действий весь овердроу уходит ценой того, что ты удваиваешь стоимость расчёта вершин. Это выгодный обмен. Если у тебя упор по вершинам, значит что-то идёт не так, и стоит задуматься о лучшей системе кулинга и лодов.
На счёт VSM, буфер глубины теней там стандартный, без экспоненты.
Под более ранними тестами глубины я имею в виду операции выше по пайплайну, во время меш шейдера, который до момента сборки примитивов решает прекратить отрисовку. Стоило уточнить.
У юнити ещё огромный технический долг в плане графики, всё ещё плохо работает dx12, по сути не давая какой-то значительной разницы с dx11, нельзя кастомные per draw буфферы пропихивать и т.д. В этом году, например, в 6.1 презентовали Variable Rate Shading, хотя он был реализован в dx шесть лет назад.
Короче, отставание на годы от индустрии, а в некотрых моментах и десятилетие.
Отличие современных грфических api (Vulkan, Dx12) от старых в асинхронности, которая позволяет поддерживать гораздо большую и более равномерную загрузку на gpu. На моменте с асинхронностью и получается проблема, надо серьёзно перелапачивать исходный код движка. Без этого, с кучей GPU Fence (точек синхронизации), на синхронном cpu коде, dx12 будет работать также медленно, как и 11.
Интересный факт: в оригинальных фолычах не было изометрии, потому что движок её не поддерживал. Там максимально удалённая камера с минимальным фовом. В итоге перспектива есть, но маленькая. Однако её было достаточно, чтобы ноги персонажей скользили по полу.
Стоит добавить, что не обязательно каждый раз горадить какие-то перегруженные математические конструкции, чтобы просто отбросить какое-то значение. Достаточно использовать тернарный оператор. Если брать пример из статьи, то его можно применить так: Texture2D res = normal.y > 0.5 ? textureA : textureB;
color = res.Sample(sampler, uv); Он не вызывает бранчинг или смену контекста, по скольку расчитываются все части выражения. Оператор bool ? a : b работает везде. Пожалуйста, дорогие разработчики, используйте его, и не городите костыли.
У меня спустя время добавились аргументы, почему этот подход с расчётом позиции оптимальнее, чем разчёт позиции на процессере. Дело в использование шины памяти, это самое узкое горлышко почти для всего, связанного с графикой. В стандартной системе частиц, положение каждой вершины каждый кадр напрямую обновляется процессором, то есть нам надо каждый кадр высылать новый массив вершин частиц (где в каждой вершине хранится как минимум float3 позиция, float2 uv, half lifetime + массив индексов вершин, с помощью которого образуются треугольники). Когда мы имеем дело с шейдером, мы можем один раз загрузить меш в VRAM, и обнавлять только специфическую информацию (например, матрица трансформов или прогресс анимации, если она контролирется скриптом). То есть, даже в ситуации с идеально быстрым CPU, мы будем страдать от больших издержек связанных с передачей информации. И, как показывает практика, эти издержки больше, чем стоимость исполнения шейдера.
Как я понимаю, этот код работает попиксельно для каждого пикселя сообщения, и смещает его в bitmap'е. Выглядит как действительно большое колличесто операций, при худшем сценарии, когда сообщение занимает почти весь экран.
В телеграмме, мне кажется, не так много операций на процессоре, как в юнити, где надо постоянно обсчитывать физику, плюс каждый кадр проверяется каждый monobehavior и исполняется его код в update. Но из относящегося чисто к графике, каждый кадр надо рассчитвать: матрицы преобразования из 3д в экранное 2д, затем Particle System повершинно рассчитывает положение для частиц в 3д (гравитация, вращение, энерция, размер(это всё разные функции)), цвет, uv, применяет матрицы преобразования и делает draw call после расчёта всех вершин. Колличество итераций той функции из телеграмма здесь заменяется сложностью каждой. Ну и на практике, уже при 10к частиц на среднем телефоне могут быть серьёзные просадки, и вам нужно оставаться в пределах пары тысяч, чтобы везде шло плавно. Это не так много, вы вполне можете упереться в этот лимит.
На больших платформах, для сравнения, на среднем цп 300к частиц в пустой сцене подарят почти кинематографический эскпириенс в 40 кадров. В то время как уже довольно старенькая gtx 1080 обрабатывает 5 миллионов частиц в VFX graph в 47 кадров. (см видео https://www.youtube.com/watch?v=0deXRHX9C08&ab_channel=Brackeys )
Так что разница есть, и в зависимости от сложности поведения частиц она может быть довольно разительной. И на мобильных устройствах приходиться использовать любые ухищрения, чтобы повысить fps.
Естественно, любой шейдер повышает нагрузку на гпу, по скольку на нём и исполняется. Здесь скорее дело в эффективности. На экране 1000 частиц, у каждой по 4 вершины, для каждой вершины нужно сделать расчёт положения. У процессоров нет столько ядер, чтобы параллельно их обработать. А видеокарта может.
Конечно может быть такая ситуация, что у вас распределён бюджет на кадр. Цель 60 фпс, значит один кадр видеокарта и процессор не должны обрабатывать дольше 16 милисекунд(по отдельности, грубо говоря). И так вышло, что видекарта уже занята все 16 милисекунд, тогда конечно нет выбора, исполняем на цп. Просто на цп это займёт больше времени, вот и всё.
Специально для тебя выкладываю на гитхаб билд с пустой сценой и двумя системами частиц, которые выполняют одинаковые действия (двигаются, меняют цвет и размер, используют одну текстуру и т.д.). Менять активную систему можно по пробелу.
Диваны, конечно, плоские, но само помещение выглядит объёмным. Параллакс это смещение близкого объекта относительно дальнего, и тут я никого не обманываю, дальняя стена двигается медленнее боковых, перспектива создаётся.
А если для игрока не принципиально или невозможно близко подойти к окну и рассмотреть, то плоскость дивина относительно стены будет незаметна.
hdrp перегружен, а то что built-in встроенный не значит, что на нём нельзя делать красиво. Глянь на "Hail to the Rainbow", сделана на built-in, а выглядит лучше чем половина игр на анриле. Конечно, это экстримальный пример, но думаю, у студии таркова есть бюджет на несколько таких разработчиков.
У hdrp ужасная производительность из коробки (имхо), и его надо ещё долго дорабатывать напильником, чтобы был какой-то приемлимый результат. Всё подчиняется простому правилу: чтобы было хорошо, надо делать хорошо.
Но дело ведь не просто в удобстве, дело в том, что в Вангерах вся земля была из разрушаемых вокселей. Динамичный террейн означает дополнительный геймплейные возможности. От реализации зависит, на сколько удобно передвигаться по такой поверхности, как коллайдеры колёс отрабатывают по земле, и как реагирует земля. Зато, это кратно повышает вариативность машин: разный вес и подвеска по разному будут реагировать с землёй, это мы ещё не говорим о чём-то более экзотическом, вроде машин-буров. К тому же, это опять же намного увеличивает потенциальное разнообразие дорог.
Если честно, мне трудно себе представить Вангеров без их системы земли. Просто аркадных гоночек из пункта а в пункт б было много, а Вангеры были одни.
Статью считаю не полной без упоминания сеток с низким расхождением, хотя бы без упоминания дизера IGN. Они дают ошибку ниже, чем Bayer, и имеют менее очевидный паттерн. К тому же, Bayer нельзя менять по времени, чтобы сглаживать ошибку между кадрами. Код с сравнением: https://www.shadertoy.com/view/w3BfRV подробнее про GPU friendly алгоритимы https://habr.com/ru/articles/881258/
Ощущение, что текст нейросеть написала, без погружения в материал.
Самое простое: препасс глубины.
Перед отрисовкой деревьев бери только буфер глубины как рендертаргет, отрисовывай деревья без пиксельного шейдера (только пиши глубину, либо с минимальным пикс шейдером, если есть клиппинг), затем бери в рендрертагрет свой колор буфер и устанавливай тот же буфер глубины без очистки (чтобы информация о ближайшей глубине сохранилась), после чего в пиксельном шейдере деревьев ставь Depth Test LEqual.
После этих действий весь овердроу уходит ценой того, что ты удваиваешь стоимость расчёта вершин. Это выгодный обмен. Если у тебя упор по вершинам, значит что-то идёт не так, и стоит задуматься о лучшей системе кулинга и лодов.
На счёт VSM, буфер глубины теней там стандартный, без экспоненты.
Под более ранними тестами глубины я имею в виду операции выше по пайплайну, во время меш шейдера, который до момента сборки примитивов решает прекратить отрисовку. Стоило уточнить.
У юнити ещё огромный технический долг в плане графики, всё ещё плохо работает dx12, по сути не давая какой-то значительной разницы с dx11, нельзя кастомные per draw буфферы пропихивать и т.д. В этом году, например, в 6.1 презентовали Variable Rate Shading, хотя он был реализован в dx шесть лет назад.
Короче, отставание на годы от индустрии, а в некотрых моментах и десятилетие.
Отличие современных грфических api (Vulkan, Dx12) от старых в асинхронности, которая позволяет поддерживать гораздо большую и более равномерную загрузку на gpu. На моменте с асинхронностью и получается проблема, надо серьёзно перелапачивать исходный код движка. Без этого, с кучей GPU Fence (точек синхронизации), на синхронном cpu коде, dx12 будет работать также медленно, как и 11.
Интересный факт: в оригинальных фолычах не было изометрии, потому что движок её не поддерживал. Там максимально удалённая камера с минимальным фовом. В итоге перспектива есть, но маленькая. Однако её было достаточно, чтобы ноги персонажей скользили по полу.
Стоит добавить, что не обязательно каждый раз горадить какие-то перегруженные математические конструкции, чтобы просто отбросить какое-то значение. Достаточно использовать тернарный оператор. Если брать пример из статьи, то его можно применить так:
Texture2D res = normal.y > 0.5 ? textureA : textureB;color = res.Sample(sampler, uv);Он не вызывает бранчинг или смену контекста, по скольку расчитываются все части выражения.
Оператор bool ? a : b работает везде. Пожалуйста, дорогие разработчики, используйте его, и не городите костыли.
У меня спустя время добавились аргументы, почему этот подход с расчётом позиции оптимальнее, чем разчёт позиции на процессере. Дело в использование шины памяти, это самое узкое горлышко почти для всего, связанного с графикой. В стандартной системе частиц, положение каждой вершины каждый кадр напрямую обновляется процессором, то есть нам надо каждый кадр высылать новый массив вершин частиц (где в каждой вершине хранится как минимум float3 позиция, float2 uv, half lifetime + массив индексов вершин, с помощью которого образуются треугольники). Когда мы имеем дело с шейдером, мы можем один раз загрузить меш в VRAM, и обнавлять только специфическую информацию (например, матрица трансформов или прогресс анимации, если она контролирется скриптом). То есть, даже в ситуации с идеально быстрым CPU, мы будем страдать от больших издержек связанных с передачей информации. И, как показывает практика, эти издержки больше, чем стоимость исполнения шейдера.
Как я понимаю, этот код работает попиксельно для каждого пикселя сообщения, и смещает его в bitmap'е. Выглядит как действительно большое колличесто операций, при худшем сценарии, когда сообщение занимает почти весь экран.
В телеграмме, мне кажется, не так много операций на процессоре, как в юнити, где надо постоянно обсчитывать физику, плюс каждый кадр проверяется каждый monobehavior и исполняется его код в update. Но из относящегося чисто к графике, каждый кадр надо рассчитвать: матрицы преобразования из 3д в экранное 2д, затем Particle System повершинно рассчитывает положение для частиц в 3д (гравитация, вращение, энерция, размер(это всё разные функции)), цвет, uv, применяет матрицы преобразования и делает draw call после расчёта всех вершин. Колличество итераций той функции из телеграмма здесь заменяется сложностью каждой. Ну и на практике, уже при 10к частиц на среднем телефоне могут быть серьёзные просадки, и вам нужно оставаться в пределах пары тысяч, чтобы везде шло плавно. Это не так много, вы вполне можете упереться в этот лимит.
На больших платформах, для сравнения, на среднем цп 300к частиц в пустой сцене подарят почти кинематографический эскпириенс в 40 кадров. В то время как уже довольно старенькая gtx 1080 обрабатывает 5 миллионов частиц в VFX graph в 47 кадров. (см видео https://www.youtube.com/watch?v=0deXRHX9C08&ab_channel=Brackeys )
Так что разница есть, и в зависимости от сложности поведения частиц она может быть довольно разительной. И на мобильных устройствах приходиться использовать любые ухищрения, чтобы повысить fps.
Естественно, любой шейдер повышает нагрузку на гпу, по скольку на нём и исполняется. Здесь скорее дело в эффективности. На экране 1000 частиц, у каждой по 4 вершины, для каждой вершины нужно сделать расчёт положения. У процессоров нет столько ядер, чтобы параллельно их обработать. А видеокарта может.
Конечно может быть такая ситуация, что у вас распределён бюджет на кадр. Цель 60 фпс, значит один кадр видеокарта и процессор не должны обрабатывать дольше 16 милисекунд(по отдельности, грубо говоря). И так вышло, что видекарта уже занята все 16 милисекунд, тогда конечно нет выбора, исполняем на цп. Просто на цп это займёт больше времени, вот и всё.
Специально для тебя выкладываю на гитхаб билд с пустой сценой и двумя системами частиц, которые выполняют одинаковые действия (двигаются, меняют цвет и размер, используют одну текстуру и т.д.). Менять активную систему можно по пробелу.
Диваны, конечно, плоские, но само помещение выглядит объёмным. Параллакс это смещение близкого объекта относительно дальнего, и тут я никого не обманываю, дальняя стена двигается медленнее боковых, перспектива создаётся.
А если для игрока не принципиально или невозможно близко подойти к окну и рассмотреть, то плоскость дивина относительно стены будет незаметна.