А где посмотреть версию без аллокаций или с околонулевыми аллокациями? Потому что сейчас это enterprise-like код, ни сколько не заботящийся о производительности и фризах на сборке мусора и который нельзя использовать под реальной нагрузкой хотя бы в сотню агентов.
Смысл в том, что нет dead code elimination — 1.6Мб — это для пустого проекта практически без пользовательского кода, который никак не использует все это богатство. Если так рассуждать, то 20кб в голанге — это тоже весь богатый рантайм, необходимый для такого же минимального пользовательского кода. Если начать подкидывать своего кода, то размер будет увеличиваться и там и там, просто в одном случае это будет 1.6Мб+, в другом 20кб+.
wasm-код работает в песочнице, для взаимодействия с апи браузера и DOM-ом надо выходить наружу через маршалинг/интероп и вот все это. Если злоупотреблять такими вызовами — скорость падает до уровня обычного js, если нет, то есть буст.
У того же голанга размер пустого бинарника с реализацией сборщика мусора после tinygo — 20кб — вполне вменяемо по сравнению с 1.6мб blazor-а от c#. Т.е реализация managed-управления памятью уже не проблема прямо поверх wasm-а без таковой.
В начале статьи был упомянут голанг — чем он не устроил? тот же standalone бинарник, скорость и отсутствие жопоразрывания borrow checker-ом — код пишется если не просто, то хотя бы без большого напряга. Если захотелось бы всякого нестандартного — можно было бы попробовать собрать проект через tinygo и получить похожий по размеру бинарник как и в расте.
Имелось ввиду скорее всего касание, а не нажатие (можно настроить касание как клик софтово) — вся поверхность мыши (включая место под ладонью) может распознавать 5 тачей одновременно. Т.е по ней можно тапать 2-3 пальцами, драгать в разные стороны разным количеством пальцев — это все распознается как разные жесты. Все то же самое относится и к внешнему тачпаду. Софт для настройки, например, этот http://magicprefs.com (скорее всего не работает на последней macos).
В принципе, можно слать специальный линк с урл-схемой (deeplink), на которую зарегано специальное приложение, которое по урлу сможет считать то, что нужно. Вот только смысл теряется в этом случае, т.к надо ставить специальный софт, который уже может качать все что-угодно более простым способом.
Смысл в том, что сейчас уже нет смысла упарываться в динамик-батчинг на плотной сцене с повторяющимися объектами (как вот елки на картинке из статьи) — он никогда не вытянет скорость инстансинга. Динамик-батчинг уже по дефолту отключен на новых проектах и скорее всего будет выпилен через пару мажорных релизов в угоду инстансингу и urp batching-у, который работает совершенно не так.
Я хочу сказать, что конторы заказавают сканы гитхаба у посредников с плохо-настроенными фильтрами (без учета языка и т.п технологий — исключительно по совпадению кейвордов), а потом неподготовленные hr-ы используют это в своих офферах.
Мне одно время приходили предложения типа "мы проверили ваш гитхаб — все, вы нам подходите. Вот тут у вас ECS, вот тут у вас Unity". При этом им абсолютно пофик, что ECS в моем случае ничего общего с облаками амазона не имеет, а Unity — это не ORM для баз данных от MS.
Дерьмовая статья и дерьмовый перевод (что намекает на общее качество курса).
Начнем с перевода.
Для систем частиц, линий рендеринга и рендеринга трейлов…
… с помощью окклюзии Unity…
У Legacy Deferred (предварительный проход света) пути рендеринга
И так по всему тексту. Гуглопереводчик на марше.
По исходной статье. Практически везде фейл.
Чтобы подключить Remote Profiler, перейдите в меню Edit > Project Settings > Editor и в разделе Device выберите Any Android Device.
Вообще-то это никак не связано с профайлингом на девайсе, а нужно для использования мобильного приложения UnityRemote для отладки мультитач-ввода в редакторе.
Батчинг (Batching, или пакетная обработка) — очень хороший метод повышения производительности за счет сокращения количества вызовов Draw, который представляет из себя группирование рендеринга нескольких похожих GameObject-ов в одном вызове draw.
Не GameObject-ов, а мешей, висящих на них с MeshFilter / MeshRenderer. Рендерить меши можно и без GameObject — через Graphics.XXX, что тоже может батчиться.
Если ваши GameObject-ы не взаимодействует с вашим Player или если вы не меняете Transform, то лучше всего использовать статический батчинг для большинства вариантов среды в вашей игре, таких как здания, дороги и т. д.
Лучше никогда не использовать статик-батчинг, т.к он неконтролируем от слова "совсем" — можно получить меш из десятка треугольников на одном крае локации и десятка треугольников на другом, а т.к юнити определяет видимость меша для камеры через попадания баунда (габаритного AxisAlignedBox) в область видимости камеры, то такой меш будет всегда рендериться, даже если его не видно. К тому же такой меш всегда лежит как жирный меш в ресурсах самого билда, сильно раздувая его. Ну и копия статик-меша всегда лежит в оперативной памяти. Как неплохую замену следует использовать Mesh.CombineMeshes (о чем было указано ниже по тексту).
Пакетная обработка динамических GameObject-ов имеет определенные накладные расходы на каждую вершину, поэтому пакетная обработка применяется только к сеткам, содержащим не более 300 вершин и не более 900 атрибутов вершин.
Меш собирается каждый фрейм в буфер, что при большом количестве мелких мешей может наоборот — начать тормозить рендеринг из-за большой нагрузки на цпу при подготовке данных. Цифра 900 скорее всего никогда не поменяется, скорее динамический батчинг полностью будет выпилен из движка в угоду инстансингу и urp batching.
Ничего не сказано про "render queue", что очень важно и тоже ломает батчинг даже если все остальные условия были выполнены.
GameObject-ы не обрабатываются пакетно, если они содержит зеркальное отражение в transform (например, GameObject A со скейлом +1 и GameObject B со скейлом –1 не могут быть объединены вместе).
Любые отрицательные скейлы ломают батчинг, а не только идеальное зеркалирование.
Использование разных экземпляров Material приводит к тому, что GameObject-ы не объединяется в пакет, даже если они по сути одинаковы. Исключение составляет рендеринг Shadow Caster.
Если в тенях включена поддержка каскадов — они тоже ломают батчинг + дальность тени (не будет батчиться то что с тенями и то, что без).
Игровые объекты с картами освещения имеют дополнительные параметры рендеринга: индекс карты освещения и смещение/скейл в карте освещения. Как правило для пакетной обработки, GameObject-ы с динамической картой освещения должны указывать на одно и то же местоположение карты освещения.
Тут возникает 2 проблемы:
лайтмапы в юнити могут быть запечены только от статики, которую не стоит использовать.
попадание в нужную лайтмапу сложно контролировать.
Как решение — или сторонние плагины-запекалки или запекание во внешнем редакторе как надо и импортом мешей в юнити с сохранением UV2, содержащим координаты в лайтмапе.
В целом Occlusion Culling подразумевает, что Unity не будет отображать GameObject-ы, которые полностью скрыты с точки зрения камеры (окклюдированны) другими GameObject-ами.
Это опять же подразумевает статику, что автоматически увеличивает вес билда.
Ни слова не было сказано про instancing, что является на сегодняшний момент предпочтительным способом оптимизации рендера без значительной перегрузки цпу даже на мобильных платформах (доля gles2 устройств меньше 8% и будет все сильнее падать к 2022). Ни слова не было сказано про освещение скинмешей (лайтпробы — тоже статика, но можно переливать в динамике).
Тогда они очень плохо следят за своим сайтом — в разделе цен четко указано, что wildcards только за деньги: https://zerossl.com/pricing/
Вот когда бесплатные wildcards подвезут — сравняется и станет какой-никакой альтернативой, а пока...
А где посмотреть версию без аллокаций или с околонулевыми аллокациями? Потому что сейчас это enterprise-like код, ни сколько не заботящийся о производительности и фризах на сборке мусора и который нельзя использовать под реальной нагрузкой хотя бы в сотню агентов.
Смысл в том, что нет dead code elimination — 1.6Мб — это для пустого проекта практически без пользовательского кода, который никак не использует все это богатство. Если так рассуждать, то 20кб в голанге — это тоже весь богатый рантайм, необходимый для такого же минимального пользовательского кода. Если начать подкидывать своего кода, то размер будет увеличиваться и там и там, просто в одном случае это будет 1.6Мб+, в другом 20кб+.
Если логика максимально долго работает без интеропа с апи браузера (webgl сюда же относится), то получается хороший буст. По поводу webgl — работа с гпу подразумевает редкие вызовы с большим объемом данных, так что падение не должно быть значительным.
Вот пример ускорения: https://habr.com/ru/company/skillbox/blog/452190/
Вот не совсем удачный пример ускорения: https://habr.com/ru/company/yandex/blog/475382/
Вот про DOM: https://habr.com/ru/post/347804/
wasm-код работает в песочнице, для взаимодействия с апи браузера и DOM-ом надо выходить наружу через маршалинг/интероп и вот все это. Если злоупотреблять такими вызовами — скорость падает до уровня обычного js, если нет, то есть буст.
У того же голанга размер пустого бинарника с реализацией сборщика мусора после tinygo — 20кб — вполне вменяемо по сравнению с 1.6мб blazor-а от c#. Т.е реализация managed-управления памятью уже не проблема прямо поверх wasm-а без таковой.
В начале статьи был упомянут голанг — чем он не устроил? тот же standalone бинарник, скорость и отсутствие жопоразрывания borrow checker-ом — код пишется если не просто, то хотя бы без большого напряга. Если захотелось бы всякого нестандартного — можно было бы попробовать собрать проект через tinygo и получить похожий по размеру бинарник как и в расте.
Имелось ввиду скорее всего касание, а не нажатие (можно настроить касание как клик софтово) — вся поверхность мыши (включая место под ладонью) может распознавать 5 тачей одновременно. Т.е по ней можно тапать 2-3 пальцами, драгать в разные стороны разным количеством пальцев — это все распознается как разные жесты. Все то же самое относится и к внешнему тачпаду. Софт для настройки, например, этот http://magicprefs.com (скорее всего не работает на последней macos).
В принципе, можно слать специальный линк с урл-схемой (deeplink), на которую зарегано специальное приложение, которое по урлу сможет считать то, что нужно. Вот только смысл теряется в этом случае, т.к надо ставить специальный софт, который уже может качать все что-угодно более простым способом.
"Моноповедения" — спасибо, докинул в копилку лучших переводов надмозгов.
Дальше можно было не читать — таким образом можно пофиксить все, что мешает нужному кривому "исследованию".
Смысл в том, что сейчас уже нет смысла упарываться в динамик-батчинг на плотной сцене с повторяющимися объектами (как вот елки на картинке из статьи) — он никогда не вытянет скорость инстансинга. Динамик-батчинг уже по дефолту отключен на новых проектах и скорее всего будет выпилен через пару мажорных релизов в угоду инстансингу и urp batching-у, который работает совершенно не так.
Я хочу сказать, что конторы заказавают сканы гитхаба у посредников с плохо-настроенными фильтрами (без учета языка и т.п технологий — исключительно по совпадению кейвордов), а потом неподготовленные hr-ы используют это в своих офферах.
Мне одно время приходили предложения типа "мы проверили ваш гитхаб — все, вы нам подходите. Вот тут у вас ECS, вот тут у вас Unity". При этом им абсолютно пофик, что ECS в моем случае ничего общего с облаками амазона не имеет, а Unity — это не ORM для баз данных от MS.
Дерьмовая статья и дерьмовый перевод (что намекает на общее качество курса).
Начнем с перевода.
И так по всему тексту. Гуглопереводчик на марше.
По исходной статье. Практически везде фейл.
Вообще-то это никак не связано с профайлингом на девайсе, а нужно для использования мобильного приложения UnityRemote для отладки мультитач-ввода в редакторе.
Не GameObject-ов, а мешей, висящих на них с MeshFilter / MeshRenderer. Рендерить меши можно и без GameObject — через Graphics.XXX, что тоже может батчиться.
Лучше никогда не использовать статик-батчинг, т.к он неконтролируем от слова "совсем" — можно получить меш из десятка треугольников на одном крае локации и десятка треугольников на другом, а т.к юнити определяет видимость меша для камеры через попадания баунда (габаритного AxisAlignedBox) в область видимости камеры, то такой меш будет всегда рендериться, даже если его не видно. К тому же такой меш всегда лежит как жирный меш в ресурсах самого билда, сильно раздувая его. Ну и копия статик-меша всегда лежит в оперативной памяти. Как неплохую замену следует использовать Mesh.CombineMeshes (о чем было указано ниже по тексту).
Меш собирается каждый фрейм в буфер, что при большом количестве мелких мешей может наоборот — начать тормозить рендеринг из-за большой нагрузки на цпу при подготовке данных. Цифра 900 скорее всего никогда не поменяется, скорее динамический батчинг полностью будет выпилен из движка в угоду инстансингу и urp batching.
Ничего не сказано про "render queue", что очень важно и тоже ломает батчинг даже если все остальные условия были выполнены.
Любые отрицательные скейлы ломают батчинг, а не только идеальное зеркалирование.
Если в тенях включена поддержка каскадов — они тоже ломают батчинг + дальность тени (не будет батчиться то что с тенями и то, что без).
Тут возникает 2 проблемы:
Как решение — или сторонние плагины-запекалки или запекание во внешнем редакторе как надо и импортом мешей в юнити с сохранением UV2, содержащим координаты в лайтмапе.
Это опять же подразумевает статику, что автоматически увеличивает вес билда.
Ни слова не было сказано про instancing, что является на сегодняшний момент предпочтительным способом оптимизации рендера без значительной перегрузки цпу даже на мобильных платформах (доля gles2 устройств меньше 8% и будет все сильнее падать к 2022). Ни слова не было сказано про освещение скинмешей (лайтпробы — тоже статика, но можно переливать в динамике).
Советую сравнить производительность — она будет далеко не "такой же". :)
А можно вообще не страдать и сделать вот так.
На самом деле движок 4-ой части, 5-ая была по сути контент-паком и продолжением истории, обе части потом были выпущены как "World of Xeen".
Так и делал, но в итоге перестал использовать.