Мне одно время приходили предложения типа "мы проверили ваш гитхаб — все, вы нам подходите. Вот тут у вас 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). Ни слова не было сказано про освещение скинмешей (лайтпробы — тоже статика, но можно переливать в динамике).
Брался кабель не из дешевых, потом там же докупалось еще несколько комплектов — домой, в офис и т.п. Да, удобно. Да, хорошо держит магнит, но вот получилось как получилось.
Убил магнитным кабелем батарею в iPhone6s+ — через какое-то время пропадает четкий контакт части, вставляемой в телефон, с контактами внутри телефона + второй частью провода. Выглядит как втыкание-вытыкание кабеля раз в секунду, помогало вытаскивание "штырька" из телефона и втыкание обратно. На 3-4 недели, чем дальше, тем чаще приходилось вытаскивать. Месяца через 4 емкость аккумулятора упала на 10% (по внутренней статистике iOS). После возврата на штатный lighting-кабель деградация прекратилась.
В википедии в разделе "Использование в кино" есть линк про человека-паука, который ведет на 3д-домен. Линк после редиректа уже мертвый.
Ну и в твиттере тег #blender3d идет наравне с #b3d и #blender.
С npm 5.x (не помню точно какой версии) больше не нужно указывать ключ -S — оно само сохраняет. Для записи в devDependencies ключ -D по-прежнему нужен.
Смысл был в том, что перепутана последовательность — сначала делается npm init -y и только потом npm install discord.js, который запишет пакет в dependencies секцию.
Так ночным он был на момент начала портирования, в статье указано, что теперь нужный функционал в стейбле. По поводу трехлетнего голанга — самый свежий получил возможность отключения GC? Статья как раз про особенности работы с памятью и сборку мусора.
Мне одно время приходили предложения типа "мы проверили ваш гитхаб — все, вы нам подходите. Вот тут у вас 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".
Так и делал, но в итоге перестал использовать.
Разговор был про lighting.
Брался кабель не из дешевых, потом там же докупалось еще несколько комплектов — домой, в офис и т.п. Да, удобно. Да, хорошо держит магнит, но вот получилось как получилось.
Убил магнитным кабелем батарею в iPhone6s+ — через какое-то время пропадает четкий контакт части, вставляемой в телефон, с контактами внутри телефона + второй частью провода. Выглядит как втыкание-вытыкание кабеля раз в секунду, помогало вытаскивание "штырька" из телефона и втыкание обратно. На 3-4 недели, чем дальше, тем чаще приходилось вытаскивать. Месяца через 4 емкость аккумулятора упала на 10% (по внутренней статистике iOS). После возврата на штатный lighting-кабель деградация прекратилась.
Причем здесь старожил. Твиттер-теги до сих пор с "3д", локальные коммунити-сайты с "3д" — это все пошло с тех пор, но живо и сейчас.
Потому что раньше он так и назывался, по крайней мере новости вели на 3д-домен:
https://www.opennet.ru/prog/info/45.shtml
https://3dnews.ru/220672
Этот домен https://blender3d.org жив до сих пор, хотя и редиректит уже на новый.
В википедии в разделе "Использование в кино" есть линк про человека-паука, который ведет на 3д-домен. Линк после редиректа уже мертвый.
Ну и в твиттере тег #blender3d идет наравне с #b3d и #blender.
P.S. вот новость о переезде на новый домен: https://web.archive.org/web/20021124122712/http://www.blender3d.org/
Вот конкретный пример разработки игры с нуля от одного из выступавших на митапе:
Стоит уточнить, что 90 дней отображаются на сайте пока не выберешь страну. Для России, например, остались те же самые 30 дней.
Можно стрелять в любой момент, главное — следить за флагом рядом с целью. Флаг опадает, ветер минимальный, можно стрелять по прямой.
Вижу рекламу, не вижу технических подробностей.
С npm 5.x (не помню точно какой версии) больше не нужно указывать ключ -S — оно само сохраняет. Для записи в devDependencies ключ -D по-прежнему нужен.
Смысл был в том, что перепутана последовательность — сначала делается npm init -y и только потом npm install discord.js, который запишет пакет в dependencies секцию.
Если автор сам попробует выполнить свою инструкцию пошагово, то узнает, что первые 2 команды упадут с ошибками.
Но ведь это отключение автоматической сборки, руками-то все-равно придется звать
runtime.GC()
Так ночным он был на момент начала портирования, в статье указано, что теперь нужный функционал в стейбле. По поводу трехлетнего голанга — самый свежий получил возможность отключения GC? Статья как раз про особенности работы с памятью и сборку мусора.