Смену дня и ночи с лайтмапами я не использовал на мобильных платформах, выглядит слишком жирно. Это уже даже не просто лайтмапы, это массив GI карт, но подход я думаю применим тот же: В каждом MeshRenderer есть LightmapIndex и в каждом меше есть дополнительный набор UV, этих данных уже достаточно чтобы Unity по ним накатывал освещение штатными средствами. Если запечь куски сцены по отдельности, делая бекапы получившихся лайтмап, потом их можно подгружать в рантайме или мерджить отдельным скриптом. Но вообще, именно в описанной в статье задаче, написать самому работу с лайтмапами и картами теней и не использовать штатные средства Unity будет мб проще.
Статический батчинг можно проворачивать прям в рантайме комбинируя меши или их куски уровня, если у них отдельные root объекты. Таким же образом и передвигать мир можно попробовать в центр координат. В худшем и самом медленном случае достаточно будет: Mesh.CombineMeshes. Я не разбирался с аргументом hasLightmaps но я полагаю он будет учитывать как раз LightmapIndex/
По некоторым вопросам движка автор выразился слишком критично. И статический батчинг и лайтмапы и Occlusion можно заставить работать с подгрузкой уровня, это описано в документации и управляется из кода. Да, неудобно и нужно писать руками вспомогательные утилиты, но апи для этого всё же есть.
Не представляю, как можно в 2020 году в мультиплеерной игре сделать не авторитарный сервер. Тут бороться не с читерами нужно а со своим сетевым стеком.
Заметил что на шариках в гифках отражение не правильно смещается. Получается как буд-то шарик полупрозрачный как ёлочная игрушка. Должно же быть не так?
Странно что так мало оценок, очень важная и полезная статья! Сейчас культура работы с LWRP только зачинается и никаких best practice еще не устоялось! Респект!
На сколько сложно теперь подвязать к этому шейдеру Master Node и расширять с помощью Shader Graph?
Даже только для того чтобы нельзя было в таких вопиющих случаях ссылаться на правила хабра, призываю руководство портала рассмотреть коррекцию этого пункта правил. Все и так понимают кто в стране кто и пора иметь профессиональную площадку где это можно заявлять. Многие действия или бездействия в нашей стране отражаются на профессиональном сообществе, сейчас это приходится читать только между строк. Чем лучше информация распространяется, тем больше мы можем сделать для людей, которых система ест прямо сейчас.
А сами проверки производились в редакторе? Какая версия редактора была? (UPD: пропустил, оказывается есть в статье) Была ли включена настройка Editor Attaching? Были ли отключены проверки безопасности для нативных коллекций и вообще?
Я считаю что самый правильный способ сравнивать эти цифры, это делать сборку на целевую платформу, выключив все проверки и development build option, тогда вариант 3 станет эффективнее на порядки раз, судя по замерам моей команды. Хотя мы не с Actors, а с Entities тестируем.
Забавно, но мы столкнулись с другой проблемой, хоть вариант 3 самый эффективный, в редакторе на большом проекте работать все равно нормально невозможно так как всё тормозит. А галочка Editor Attaching работает только с перезапуском редактора, что неудобно, дебагер нужно подключать всегда не вовремя.
Разработка роботов началась несколько лет назад и там использовались немного другие подходы к проектированию. Чуть подробнее можно прочитать в статье нашего СТО Сергея Жданова “Почему мы не стали делать идеально” habr.com/company/pixonic/blog/346374
Вы пытаетесь оптимизировать тот этап, который и не планировался быть быстрым. Сжатие текстур, подсчет хешей, сбор бандлов — это всегда будет долго выполняться, не нужно это оптимизировать пока не мешает работе. Во все времена, для трудоемких операций использовали кеш чтобы не делать ненужную работу. В вашей статье по кеш-сервер и его варианты не написано совсем, а рекомендовать в первую очередь нужно именно его, а не покупку новых машин. Для сложных случаев есть локальный кеш в коробке с редактором.
По поводу карт освещения — оно как раз делается с использованием GPU, и, по логике, должно версионироваться синхронно со сценой. В настройках запекания тоже есть опции для быстрого превью вместо полного прохода.
Отличный вопрос! При первоначальном исследовании фотона и eNet — внутри него я не обнаружил стратегии доставки Reliable-unOrdered. Это означает что пакеты, пришедшие не в том порядке могут быть молчаливо пропущены. В случае с нашим инпутом это вредно — у нас есть кейс, когда мы не можем выстрелить ракетой сейчас по какой либо причине, но должны сделать это в симуляции при выходе из блокирующего состояния. Может у меня устаревшая информация и апи фотона стало гибче в этом плане?
Да, клиент — «телевизор», верит только серверу. Лишь изредка экстраполирует по примитивным правилам для поддержания плавности при высокой потере пакетов. Симуляция на клиенте нужна только для отладки и работы оффлайн. Например: стартовое обучение бою. Поддерживать подключение к серверу расточительно и излишне влияет на воронку прохождения — мы запускаем симуляцию с ботами локально на девайсе.
Технически, мы поддерживаем любой пинг в ущерб быстрой реакции на ввод. Но с пингом выше 300 играть не рекомендуется, необратимо портится игровой опыт. В итоге все сводится к вопросу расположения и стоимости серверов.
Игровой сервер — NET приложение на фреймворке Photon, Unity в сервере не участвует.
В симуляции используем отдельную 2D физику (VolatilePhysics) и периодически туда контрибьютим, т.к. в ней есть конкретные баги. Нам повезло, что мы смогли упростить взаимодействия до столкновений неупругих примитивов + рейкастов (сферические и обычные) для расчета видимости и попаданий.
Как при игре по сети вы боретесь с задержкой результатов ввода? Клиент ждет результат от сервера или отправляет на сервер ввод и действия постфактум а сервер верит?
Лучше забыть про юнити-опыт и изучать по Э.Троелсену, тренируясь в консольных приложениях и так далее по NET. стеку. Одна из плохих особенностей юнити, это то, что вы привыкаете работать в рамках фреймворка и не прививаете себе мышление использования инверсии зависимостей.
Статический батчинг можно проворачивать прям в рантайме комбинируя меши или их куски уровня, если у них отдельные root объекты. Таким же образом и передвигать мир можно попробовать в центр координат. В худшем и самом медленном случае достаточно будет: Mesh.CombineMeshes. Я не разбирался с аргументом hasLightmaps но я полагаю он будет учитывать как раз LightmapIndex/
По некоторым вопросам движка автор выразился слишком критично. И статический батчинг и лайтмапы и Occlusion можно заставить работать с подгрузкой уровня, это описано в документации и управляется из кода. Да, неудобно и нужно писать руками вспомогательные утилиты, но апи для этого всё же есть.
Выглядит что и в исходниках так же. Чекните юзинги, такое не соберется как я догадываюсь. https://github.com/HolyMonkey/unity-typed-scenes/blob/master/Assets/Plugins/TypedScenes/Core/TypedScene.cs
AssetDatabase API доступен только в редакторе, у вас разве код соберется вообще из примера?
На сколько сложно теперь подвязать к этому шейдеру Master Node и расширять с помощью Shader Graph?
Я считаю что самый правильный способ сравнивать эти цифры, это делать сборку на целевую платформу, выключив все проверки и development build option, тогда вариант 3 станет эффективнее на порядки раз, судя по замерам моей команды. Хотя мы не с Actors, а с Entities тестируем.
Забавно, но мы столкнулись с другой проблемой, хоть вариант 3 самый эффективный, в редакторе на большом проекте работать все равно нормально невозможно так как всё тормозит. А галочка Editor Attaching работает только с перезапуском редактора, что неудобно, дебагер нужно подключать всегда не вовремя.
Второй аргумент показывает максимум диапазона значений не включая саму границу. S всегда будет равно 1.
Вот док, для float и int различное поведение, что логично:
docs.unity3d.com/ru/530/ScriptReference/Random.Range.html
По поводу карт освещения — оно как раз делается с использованием GPU, и, по логике, должно версионироваться синхронно со сценой. В настройках запекания тоже есть опции для быстрого превью вместо полного прохода.
В симуляции используем отдельную 2D физику (VolatilePhysics) и периодически туда контрибьютим, т.к. в ней есть конкретные баги. Нам повезло, что мы смогли упростить взаимодействия до столкновений неупругих примитивов + рейкастов (сферические и обычные) для расчета видимости и попаданий.