Здравствуйте. До меня дошёл слух, что если открыть документацию то можно узнать о том, что в настройках от URP есть прям отдельная галочка для выключения SRP batching и static batching и ещё галка для включения dynamic batching.
@@askaranarbekov3145 В Unity 2022 для URP-проекта будет так: Edit - Preferences - Core Render Pipeline - пункт Visibility ставим в All Visible. После идём в настройки качества графики (которые называются например как URP-Balanced, обычно лежат в папке Settings, по-умолчанию 3 уровня качества создаются), там в разделе Rendering снимаем галочку SRP Batcher. У меня после этого заработало как со скриптом.
Мне кажется автор до конца не понимает что говорит. Чтобы создать экземпляр статической геометрии в рантайме... Нужно создать экземпляр префаба, помеченный статик флагом и он будет участвовать в статическом пакетировании. Даже процедурно генерируемую сетку можно сделать статической. Но она будет не подвижной, как и вся статическая геометрия. Для этого нужно было написать вершинный шейдер и перемещать вершины в нем, на видео анимация простая, вверх-вниз. Всего-то. В целом видео действительно бесполезно, просто пересказ документации движка, особенно с учетом того, что в shader graph создавать шейдеры проще, не задумываясь о том, какие строчки исправить, чтобы конкретные свойства были доступны при gpu instancing.
Никто конечно не мешает создать экземпляр статической геометрии в райнтаме, но мне не нужна была статическая геометрия. На некоторых кадрах видно, что анимации происходят далеко не только вверх вниз (например в переходе между лабиринтами). Ну и писать под это все шейдеры конечно можно, но я думаю что-то похожее было бы написать сложнее чем воспользоваться способом в видео. Да и тем более не уверен что при динамическом создании статик будет учитываться, но за это не ручаюсь щас
Ну, убедится в этом можно просто создав из префаба кубик статический, при этом в сцене на нем будет надпись static и при попытке перемещения он двигаться не будет. Юнити 2023.1. Но даже статическая обработка может перегруппировать объекты из-за различных ключевых слов, допустим свечение или металик и спекулар, хотя шейдер один и тот же. Также можно было попробовать использовать динамическую группировку, так как сцена довольна простая (когда объектов мало), но при этом сами сетки разных видов, хотя dynamic batching скрыта из интерфейса движка, наверное не очень эффективна.
GPU Instancing является проблемой для мобильных процессоров. Например, процессоры PowerVR и их драйвера плохо адаптированы под инстансинг. Это значит что на большей части девайсов низкого ценового сегмента, ФПС с инстансингом будет ниже, и колличество крашей больше.
Привет! А не подскажешь, может знаешь почему бывают такие случаи: шейдер граф генерит шейдер с 13 CBUFER блоками (что тут заменяются на UNITY_INSTANCING_BUFFER_START/END) с нужной переменной и 2 присвоениями (что тут заменяются на UNITY_ACCESS_INSTANCED_PROP). Думал это из-за использования внешнего субграфа в качестве переиспользуемой функции, но если "вписать" этот субграф как часть основного, ничего не меняется. Тупые замены всех блоков и присвоений по здешнему примеру не помогают, GPU instancing не работает.
Такая же фикня. Честно сказать у меня завёлся GPU I, но только на тех объектах, на которых я ничего не меняю в плане графики. Есть пачка объектов - 1.5К штук, вот на них приходится всего 6 дроуколов, есть вторая пачка объектов, так же 1.5 штук, и вот на них то GPU I не работает. В итоге на 1.5К объектов второй пачки приходится 1.5К дроуколов. Первую пачку я никак не трогаю, у вторых кеширую материал, чтобы потом поменять цвет эмиссии, но именно у вторых GPU I и не работает. Удаляю из сущности (класса) кеширование материала второго типа объекта, как на них начинает работать GPU I... То есть сейчас я не могу в рантайме поменять цвет, сразу же подключается SRP Batcher. Unity 2022.3.
@@PS-vj6jz если ты кешируешь материал через свойство material рендерера, то как только ты к этому свойству обращаешься, этот рендерер создает локальную копию материала, другими словами при 1.5К обращений к свойству у тебя 1.5К копий материала по 1 на каждый рендерер. Если хочешь, чтобы GPU I продолжал работать, то меняй цвет через propertyblock (renderer.setpropertyblock) -- при этом копии материала не создаются.
Странная ситуэшн... Продублирую комментарий: Честно сказать у меня завёлся GPU I, но только на тех объектах, на которых я ничего не меняю в плане графики. Есть пачка объектов - 1.5К штук, вот на них приходится всего 6 дроуколов, есть вторая пачка объектов, так же 1.5 штук, и вот на них то GPU I не работает. В итоге на 1.5К объектов второй пачки приходится 1.5К дроуколов. Первую пачку я никак не трогаю, у вторых кеширую материал, чтобы потом поменять цвет эмиссии, но именно у вторых GPU I и не работает. Удаляю из сущности (класса) кеширование материала второго типа объекта, как на них начинает работать GPU I... То есть сейчас я не могу в рантайме поменять цвет, сразу же подключается SRP Batcher. Unity 2022.3. Ps. Заработал... Делайте всё согласно документации MaterialPropertyBlock. Я так и делал, получал мешрендерер объекта и в него передавал MPB, но забыл, что в Awake кешировал материал этого объекта, кешировал его для тестов, но именно это кеширование и не давало GPU I использовать этот объект. Создавался экземпляр данного материала , а этого делать не нужно. Просто берите мешрендерер и передавайте в него объект MaterialPropertyBlock.
Хорошее видео, вот только подходит в основном под ПК игры, а Android - это уже другой разговор. Я ссейчас делаю несколько игр и вс они сильно тормозят даже на мощных устройствах и как я заметил, чем меньше батчей, тем меньше фпс, при этом если батчей батчей будет слишком много, то девайс будет сильно греться. И нет какой-то определённой золотой середины, под каждый проект, та даже под каждую сцену это значение своё... При этом такой пробелмы в моей любимой Unity 5.6.7f1 нет, начал её замечать с версий 2018 и выше...
Пока таким не занимаюсь, но возможно в будущем все изменится. Думаю скоро завести телеграм канал, там можно будет общаться и задавать интересующие вопросы)
Потому что анрыл таргетируется на хай-энд, а юнити - на лоу-энд девайсы. Там много чего нет. Например, наличие compute-шейдеров вообще не гарантировано, хотя на ПК это уже лет 10 как абсолютная норма.
@@lex_darlog_fun Ну так по этому тем более в Unity это должно быть по умолчанию для оптимизации на смартфонах и тостерах. Или неужели каждый мобильный разраб должен проделывать вручную такие махинации только для того что бы включить инстансинг?
@@scoutrava 1. Не "тем более". И тут - не то чтобы какие-то "махинации". И да, должен. Если даже показанное в видосе для вас чересчур сложно - вам не играми надо заниматься, а чем-то другим. Рендерным (оффлайновым) VFX'ом, например. 2. Это не должно быть по умолчанию, потому что даже инстансинг - хорошо работает далеко не на всех телефонах. Это вы, как разраб, должны знать конкретно СВОЮ целевую аудиторию и понимать, подходит ли ВАМ инстансинг. То же самое касается любых мало-мальски "продвинутых" рендер-фич. 3. В видосе - нет ни единой мало-мальски сложной оптимизации. Всё включается - буквально галочками в юньке. Если у вас даже такие телодвижения вызывают культурный шок - боюсь представить, какие квадратные глаза у вас будут, когда вы узнаете о НАСТОЯЩИХ оптимизациях типа VAT'ов или меш-шейдеров на ПК.
@@lex_darlog_fun Да, я не разработчик, а моделлер, и с движками знаком только с этой стороны. Мне просто казалось что это такая базовая функция, что ее можно просто по умолчанию оставить включенной. Видимо нет, спасибо за пояснение.
@@scoutrava анрыл - goes above and beyond, чтобы сделать весь экспириенс разработки максимально однокнопочным. Но: 1. Как только ты выходишь из того walled garden, в котором за тебя всё продумали - начинается настоящий ад. 2. Это именно бесконечно упрощённая разработка. В нормальных условиях - студии всё равно нужен TA. Без этого сделать что-то мало-мальски приличное - просто не выйдет. 3. Подобная однокнопочность - в принципе не возможна за пределами "мы целимся только на хай-энд ПК и консоли". Так что нельзя весь геймдев мерять по анрылу - причём, только по его инструментарию для левелдизайна. Юнька, на самом деле, делает лучшее из возможного. И даже больше. Кастомизироемость юньки - *гораздо* выше, чем в анрыле. Там сделать что угодно кроме FPS или экшона с камерой из-за спины - это задача на грани возможного.
@@-it394 ну меня это удивляет, этой юнити уже лет 15, и не работают стандартные вещи как оптимизация draw call. Какой смысл в стандартных инструменьах если при добавлении 100 кубиков у тебя 10 фпс.
Для себя я решил бы эту проблему следующим образом: для такой игры, выкинул бы нафиг юнити. Там рисовать надо однообразные тайлы. Сделал бы класс рендерера для всей поднаготной. Подключил бы либу DX или Ogl и в общем-то всё. А то "Создадим нашу игру в юнити, а теперь начинаем бороться с производительностью, выключением лишнего, оптимизацией оставшегося, допиливанием шейдерами недобитков, вкручиванием скриптов для того что недобили". Зачем такой геморрой? Надо рисовать 6 тайлов и персонажа - изучите как работает видяха и библиотеки для работы с ней. Чтобы получить банан - не надо тащить всю банановую рощу со всеми пальмами, со всеми работниками на ней работающими, всех обезьян и всех питонов которые там обитают. Учите технологию. А то трипл-А игры выходят по 20 ФПС на топовых видяхах именно потому что: "А ЧО а юнити есть, давай туда модель игрока в 70к полигонов кинем, она же должна тянуть"
Согласен нахуй эти движки, предлагаю ещё и от IDE отказаться да и ваще от готовых систем пк и ноутов, а то создадим код на пк, а теперь начинаем бороться со скачиванием пакетов, настройко ide, установкой программ, лучше сразу заебашить под себя пк, написать свою ОС систему, свою ide, свой движок и сделать свою классную игру.
Интересные темы разбираются, которые мало освещены в интернете. 👍 Важный момент для начинаюших - если проект под WebGL или мобилки, данный подход надо обязательно тестировать отдельно от других методов оптимизации. И использовать бюджетные модели телефонов, т. к. можно получить обратный эффект в итоговом фпс.
@@DELETEpoiuy SRP под веб стоит использовать только опытным специалистам. Так как веб должен предсказуемо работать на большинстве платформ, чаще имеет смысл использовать Built-in. И шейдеры, которые стабильно работают в webGl1.
Да, Batches уменьшилось, но вместо увеличения FPS он просел в 2 раза вот видео с результатом - ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-y0f_PhXbB60.html Note that this is not compatible with SRP Batcher. Using this in the Universal Render Pipeline (URP), High Definition Render Pipeline (HDRP) or a custom render pipeline based on the Scriptable Render Pipeline (SRP) will likely result in a drop in performance. Есть ли альтернатива для HDRP?
@@yaskadef Решения не существует - Note that this is not compatible with SRP Batcher. Using this in the Universal Render Pipeline (URP), High Definition Render Pipeline (HDRP) or a custom render pipeline based on the Scriptable Render Pipeline (SRP) will likely result in a drop in performance. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-y0f_PhXbB60.html
Вообще атлас по идее должен помочь. Такой подход сомневаюсь, что будет применим (в 2д редко работаю так что могу ошибаться), но проверить в принципе 5 минут)
@@-it394 Взаимно! оно как бы и помогло)) только у спрайтов сбивается цвет материала при старте, они все становятся абсолютно белыми) (использовал спрайтовый дефолтный материал) при этом колы уменьшаются в два раза, но когда цвет восстанавливаешь, колы вырастают обратно)
