Если не можешь контролировать js вне песочницы - перестань использовать электрон. Даже не так - перестань использовать на хосте ноду, электрон в песочнице - ок.
Лучше расскажите про полное отсутствие аудита в их unity hub, что по сути позволило выполнять произвольный код на всех машинах пользователей, став одним из самых крупных ботнетов.
Но в итоге ты вынужден давать доступ на запись, если ты пилишь unityhub (ланчер движка с автоапдейтом, выкачиванием зависимостей и т.п). Т.е не помогут никак эти запреты.
Их конечность. Изначально классика была на масках и была лимитирована 64 (1x ulong) компонентами. Потом было расширение на 128, 256, 512 (2-4-8x ulong). Но в любом случае сразу прилетел фидбек. И пришло осознание, что проверка масок много жрет - в случае 512 компонентов это 8 итераций цикла по полной маске. В итоге маски были выкинуты и вместо них стал массив интов индексов типов (пулов) компонентов, повешенных на энтити. В среднем на энтити висит 4-6 компонентов, т.е будет 4-6 итераций для проверки совместимости энтити с фильтрами, что уже выгоднее. И к тому же количество компонентов в мире не ограничено.
Ecs-подход рассматривается с 2 сторон - как архитектурный, так и перфоманс-паттерн. Dots - это не ecs, а скорее dod, ecs там пришит сбоку. К слову, в большинстве популярных фреймов возможно использование jobs/burst, т.е тот самый dod вполне возможен и вне dots. В общем, когда берут 3dparty ecs-фрейм - пытаются как раз не в dod, а в архитектуру. Архитектурно ecs дает легкость рефакторинга, расширяемость - можно перекроить все механики достаточно быстро, что невозможно в случае классического ООП подхода (ригидность иерархии наследования и вот все это). Об этом писалось не раз, в том числе и на хабре.
"Классическая" версия не использует спарсеты, там просто пулы с масками компонентов на энтитях и дикты в фильтрах. Советую поглядеть кишки lite-версии, там больше нет никаких масок компонентов и все на спарсетах (пулы, фильтры). Ну и да, нет больше никакой статики в ядре - плохая идея была позаимствована.
Про итерацию через лямбду - это очень медленно, она не инлайнится и в итоге колбек вызывается для каждой энтити, но думаю ты это и так знаешь.
Про сортинг энтитей "по порядку" - это тоже возможно в лайте как постпроцессинг, причем порядок можно задавать самому на основе данных с энтити.
В каждом тике система пробегалась по всем энтити и выбирала соответствующие, но производительность такого подхода оказалась, мягко говоря, неудовлетворительной.
Надо было бежать не по всем, а по самому короткому пулу из констрейнтов с чеком остальных на совместимость - это резко уменьшает количество перебираемых данных в общем случае. Такие проверки дают падение производительности на 20% примерно, но зато убирают необходимость фильтров в принципе - это дает буст на перекладывании данных по фильтрам (убирает все накладные расходы), что чаще является затыком, чем линейный процессинг.
К сожалению, ни чем не могу помочь - прошло 4 года с момента публикации комментария, бот сгинул с сорцами в районе 2018 после перехода на ApplePay + выписку из банка.
Мы поддерживаем очень много старых смартфонов и планшетов.
Сейчас девайсов без gles3 около 8%, к тому же платежеспособность этой аудитории весьма сомнительна. А vtf, etc2 и инстансинг — весьма вкусные вещи.
Инстансинг внедрили, но не сразу. К удивлению большого прироста он не дал, видимо дело в том, что нужно отрендерить не тысячу одинаковых елок, а 20 елок, 50 камней, 10 ящиков и так далее. К тому же мы получили кучу багов с графикой на девайсах с сомнительными видеочипами. В итоге от инстансинга отказались и вернулись к старому доброму динамическому батчингу.
Так в том и дело, что инстансинг рисует кучу одинаковых мешей за 1дк, а лоды это ломают, потому и надо пробовать в комплексе. Еще инстансинг как и динамик батчинг ломает пересечение материалов по RenderQueue (сортируя по дистанции от камеры) — если четко разнести все материалы по своим индексам без пересечений, то инстансинг заработает как надо.
Штатный террейн кривоватый и рисует больше чем нужно, его надо настраивать. Но по итогу все-равно разумнее снять дамп мешем, обработать, распилить на чанки и включать-выключать руками. Для разных слоев объектов тоже можно настроить дистанцию отсечения, но это тоже надо настраивать из кода, визуально через инспектор это сделать невозможно.
Не пробовали печь текстуру на старте уровня? Это должно сильно уменьшить размер билда, правда сожрет больше видеопамяти.
По поводу лодов — был ли вообще смысл в них, если туманом все рубилось по фиксированной дистанции? FarPlane просто бы кулил ненужное и все — сэкономили бы по памяти на мешах.
Инстансинг использовался?
Достаточно принять стоимость движения не 1, а 2, тогда по диагонали будет 3 — проблема решена, причем количество направлений 8 — больше чем у хексов и нет зигзагов при движении по одной из перпендикулярных осей.
Если не можешь контролировать js вне песочницы - перестань использовать электрон. Даже не так - перестань использовать на хосте ноду, электрон в песочнице - ок.
Лучше расскажите про полное отсутствие аудита в их unity hub, что по сути позволило выполнять произвольный код на всех машинах пользователей, став одним из самых крупных ботнетов.
https://forum.unity.com/threads/unity-hub-3-1-release-overview.1253823/
https://github.com/vuejs/vue-cli/issues/7054
https://github.com/RIAEvangelist/node-ipc/issues/233
Но в итоге ты вынужден давать доступ на запись, если ты пилишь unityhub (ланчер движка с автоапдейтом, выкачиванием зависимостей и т.п). Т.е не помогут никак эти запреты.
Который поможет только если лоды будут совпадать.
Их конечность. Изначально классика была на масках и была лимитирована 64 (1x ulong) компонентами. Потом было расширение на 128, 256, 512 (2-4-8x ulong). Но в любом случае сразу прилетел фидбек. И пришло осознание, что проверка масок много жрет - в случае 512 компонентов это 8 итераций цикла по полной маске. В итоге маски были выкинуты и вместо них стал массив интов индексов типов (пулов) компонентов, повешенных на энтити. В среднем на энтити висит 4-6 компонентов, т.е будет 4-6 итераций для проверки совместимости энтити с фильтрами, что уже выгоднее. И к тому же количество компонентов в мире не ограничено.
Собственно, гугль тоже в курсе пары "ecs gamedev".
Ecs-подход рассматривается с 2 сторон - как архитектурный, так и перфоманс-паттерн. Dots - это не ecs, а скорее dod, ecs там пришит сбоку. К слову, в большинстве популярных фреймов возможно использование jobs/burst, т.е тот самый dod вполне возможен и вне dots. В общем, когда берут 3dparty ecs-фрейм - пытаются как раз не в dod, а в архитектуру. Архитектурно ecs дает легкость рефакторинга, расширяемость - можно перекроить все механики достаточно быстро, что невозможно в случае классического ООП подхода (ригидность иерархии наследования и вот все это). Об этом писалось не раз, в том числе и на хабре.
А, не заметил, сорян. Да, тогда нормально, но зачем лямбда, если можно через тот же итератор и foreach-loop или просто через for-loop?
"Классическая" версия не использует спарсеты, там просто пулы с масками компонентов на энтитях и дикты в фильтрах. Советую поглядеть кишки lite-версии, там больше нет никаких масок компонентов и все на спарсетах (пулы, фильтры). Ну и да, нет больше никакой статики в ядре - плохая идея была позаимствована.
Про итерацию через лямбду - это очень медленно, она не инлайнится и в итоге колбек вызывается для каждой энтити, но думаю ты это и так знаешь.
Про сортинг энтитей "по порядку" - это тоже возможно в лайте как постпроцессинг, причем порядок можно задавать самому на основе данных с энтити.
Надо было бежать не по всем, а по самому короткому пулу из констрейнтов с чеком остальных на совместимость - это резко уменьшает количество перебираемых данных в общем случае. Такие проверки дают падение производительности на 20% примерно, но зато убирают необходимость фильтров в принципе - это дает буст на перекладывании данных по фильтрам (убирает все накладные расходы), что чаще является затыком, чем линейный процессинг.
Скорее "решение в лоб".
https://stackoverflow.com/questions/257331/how-do-i-explain-what-a-naive-implementation-is
"Вы были распознаны нашими супер-алгоритмами как перекуп, ваша сосноль уезжает к следующему более сговорчивому покупателю, прощайте!"
домра выдает белую статику в регионах за 20р в месяц.
Но, но... это же не Марс, а Арракис на КДПВ.
К сожалению, ни чем не могу помочь - прошло 4 года с момента публикации комментария, бот сгинул с сорцами в районе 2018 после перехода на ApplePay + выписку из банка.
Сейчас девайсов без gles3 около 8%, к тому же платежеспособность этой аудитории весьма сомнительна. А vtf, etc2 и инстансинг — весьма вкусные вещи.
Так в том и дело, что инстансинг рисует кучу одинаковых мешей за 1дк, а лоды это ломают, потому и надо пробовать в комплексе. Еще инстансинг как и динамик батчинг ломает пересечение материалов по RenderQueue (сортируя по дистанции от камеры) — если четко разнести все материалы по своим индексам без пересечений, то инстансинг заработает как надо.
Штатный террейн кривоватый и рисует больше чем нужно, его надо настраивать. Но по итогу все-равно разумнее снять дамп мешем, обработать, распилить на чанки и включать-выключать руками. Для разных слоев объектов тоже можно настроить дистанцию отсечения, но это тоже надо настраивать из кода, визуально через инспектор это сделать невозможно.
Когда-то давным давно делал похожий мапинг теней:
Не пробовали печь текстуру на старте уровня? Это должно сильно уменьшить размер билда, правда сожрет больше видеопамяти.
По поводу лодов — был ли вообще смысл в них, если туманом все рубилось по фиксированной дистанции? FarPlane просто бы кулил ненужное и все — сэкономили бы по памяти на мешах.
Инстансинг использовался?
Статья годная, давно тут такого не было...
Достаточно принять стоимость движения не 1, а 2, тогда по диагонали будет 3 — проблема решена, причем количество направлений 8 — больше чем у хексов и нет зигзагов при движении по одной из перпендикулярных осей.
Хм, интересно. Спасибо за информацию, игнорировал их исключительно из-за отсутствия такой фичи в списке бесплатных.