Очередной раз захотел радиального размытия в Substance Designer для тестов всяких пост-процесс гипотез. Психанул, наговнякал на Pixel processor.
Может кому-то тоже нужен иногда или хотите изучить Pixel processor, и while loop в нем (та еще веселуха)
sbs - буквально исходник
sbar - кидаете в граф и пользуетесь

файлы в первом комментарии

в презентации по Портал 2 увидел некую технику Surface-embedded sprite, основанную на том, что мы поворачиваем uv в сторону камеры. А у меня про это незакрытый гештатль уже 4 года. В общем вот.

Файлы опубликовал в unity_cg (обязательно вступайте, если еще не)

Я опять бесполезной фигни принес

Плагин VkQuality для движка Unity предоставляет рекомендации по запуску графического API — Vulkan или OpenGL ES — для использования в вашей игре на определенных устройствах.

https://developer.android.com/games/engines/unity/unity-vkquality?hl=ru

Как всегда, пока это очень глубокое R'n'D и тест, и совсем не продакшен реди. Это пример квантайза мешей. Скорее всего, наиболее любопытным будет упаковка нормалей и тангента в кватернион, что может пригодится и в деферред. Будут мысли - пишите. Найдете ошибку, или как можно сделать лучше - так же в себе не держите.

Позиции сломаются на объектах размером меньше 1, копит заметную ошибку на мешах размерах больше 50 - меш становится немного больше. Пока не решил.

(файлики в комментах)

К предыдущему посту.
Другой подход к квантованию с масштабированием. Мелкие мешки работают прекрасно, под большие подбираем множитель. С благодарностью @alexmtq (https://t.me/madcsharp)

https://github.com/BarkarIvan/Unity_mesh_quantization_example

на гифке оптимизировання мешка размером в 50 единиц сравнивается с оригиналом.

Я уже говорил, но.
Применение NICE-фильтра (на основе имплементации от Valve) при генерации мип-мап даёт ощутимый прирост качества по сравнению с окном Кайзера в Unity.

На реальном проекте (зависит, конечно, от него) разница в качестве текстур очень заметна.

Минусы?
- реализация в лоб очень долгая ) текстуры 1024 обрабатывает минуты. Но это решаемо.

https://developer.valvesoftware.com/wiki/NICE_filtering

UPD: если реализовать кайзер с регулируемыми настройками (хотя бы бета), то можно добиться результатов не хуже

Нейтральный тон маппинг от кронос

https://github.com/KhronosGroup/ToneMapping/blob/main/PBR_Neutral/pbrNeutral.glsl

https://www.khronos.org/news/press/khronos-pbr-neutral-tone-mapper-released-for-true-to-life-color-rendering-of-3d-products

https://github.khronos.org/glTF-Sample-Viewer-Release/

https://tone-mapping.glitch.me

К слову, тут пару месяцев назад пробегал диалог про сжатие вершин, в том числе нормалей, там я упомянул презу из дума, вот готовый рабочий код в 3 байта + битмаска ужаты нормаль, тангент и TBN знак.
https://gist.github.com/wiseConst/fdedf4bf9461f2c6a4dc003aadb331d3

Новости генерации кастомных мип-мап.

слева Юнити, справа - мое

Пришел все же к Kaiser с разными настройками и пытаюсь сохранить покрытие, если нужен альфа-клип. Честно говоря, не совсем понимаю, как решается эта задача в Unity — у них, похоже, мелкие козявки не исчезают так быстро и как-то бустят альфу на мелких мипах чтол-ли (хотя мне сложно представить подобную текстуру, или же ей стоит подбирать порог). Но в целом, мне нравится как все работает.

К тому же, для альфа-клиппинга, мне кажется, удобнее сразу заложить SDF на этапе рисования текстуры, чтобы не заморачиваться. Генерация SDF в мип-мапе — дело слишком долгое и замороченное (но, если надо, можно подключить бесплатный плагин от Катлайка).

Оставлю так, и пущу в дело, там посмотрим.
Вывод в том, что было бы здорово иметь пару (да даже одну) настроек кайзера, чтобы регулировать резкость текстуры.

А чего вы без таких полярных координат для сабстанс дизайнера сидите? Делал себе для трещин.


(файлы в первом комментарии)
Домашнее задание: сделать color версию

Полезный доклад с GDC от Ани Булавиной из CD PR об устройстве игровых городов с практически готовыми советами по тому, как игровой город делать.

Основные тезисы с моими комментариями:

🔸 Пространство в игре не должно быть реалистичным, оно должно быть достоверным.
Это та самая тема, по которой я хочу пройтись в своей части 2 тома Архитектуры виртуальных миров.

🔸 Город это упорядоченная структура.
От себя добавлю, что это будет верно для любого пространства, организованного человеком. Снижайте хаос на ваших уровнях.

🔸 Улица, площадь и задний двор - основные элементы города.
Если про улицу и площадь мы помним (хотя многие начинающие дизайнеры помнят только улицу), то вот про задний двор мы зачастую забываем, в результате чего наши игровые города становятся излишне коридорными.

🔸 Основные параметры вашего города - размеры, пропорции и степень детализации - зависят от скорости перемещения и геймплея.
Dog Town в Phantom Liberty потому такой шумный на мой взгляд, что разработчики полагали, что он будет преодолеваться игроком не только на машине, но и пешком, и потому увеличили детализацию. Типа а давайте запушим игроков играть иначе. Получили то, что получили.

🔸 Лейаут, архитектура и лендмарки - то, что делает ваши районы отличающимися.
От себя добавлю, что самый сильный элемент тут это именно лейаут. При этом важно помнить, что различия в лейауте должны быть на уровне игрока, а не при взгляде из вьюпорта.

По Аниному докладу можно набросать примерно вот такой пайплайн работы с игровым городом:

1. Определяем размеры города, исходя из геймплея
2. Определяем количество районов и их опознавательные лендмарки
3. Собираем референсы, обращаем внимание на структурные рефы
4. Продумываем элевацию (мне кажется, что наиболее корректно начать думать об этом где-то на этом этапе)
5. Прокладываем главные улицы через весь город
6. Помним про чередование пространств улица-площадь
7. Закладываем навигацию через размер улиц и лендмарки

❗️ Ну а самый главный вывод, как по мне, - вашего В2 уровня английского вполне достаточно, чтобы выступать с докладом на GDC. Так что перестаньте тормозить себя знанием языка.

#video #gamecities #Cyberpunk2077

оч люблю виртуальные города, а тут такой канал

Конечно, вот вариант, который создаст о вас впечатление, как о самом сеньерном сеньере+.


Последние месяц-два вечера проходят за изучением UECS и прочих аспектов DOTS. И, честно говоря, мне нравится. Сейчас основной фокус — на построении автоматизированного пайплайна между Unity и Houdini: экспорт, импорт и сборка сцен для стриминга. Unity Entities предусмотрены механизмы для этого — например, поддержка секций сцен.

Всё строится довольно прагматично: парсинг имён, логика действий на их основе, рядом пресеты импорта для Unity. С геометрией на террейне разобрались, и теперь думаю перейти к передаче мелких объектов — в том числе через обмен бинарными данными. Потихоньку движемся в сторону грейбоксов.

Уже работает на Steam Deck :3

Полной автоматизации не хочется — это путь в никуда. Но на уровне грейбокса и основной геометрии, с итерацией результатов — вполне. То есть: террейн, дороги, автоматическое размещение декора по заданной логике — всё это должно собираться само. А дальше — руками, но с удобными и хорошо подогнанными под задачи инструментами. В итоге должно получиться грамотное сочетание автоматизации и ручной доработки с обменом данными. Посмотрим, куда выведет.

лонг в несколько сообщений про всякие апи, было интересно, выше еще про форматы кратко
https://t.me/abyssal_code/16

Пакет с физикой транспорта для UECS от Юнити
https://discussions.unity.com/t/unity-vehicles-experimental-package-now-available/1636923
хоть мне и нравится моя шустрая перделка на физическом шарике (доделок там правда масса), надо все ж заценить