Комментарии 12
Все так любят CanvasGroup, но то ли не видят, то ли игнорируют тот факт, что он управляет ИСКЛЮЧИТЕЛЬНО ДОЧЕРНИМИ элементами. Обрезает обход поддерева рейкастером или передает модификатор прозрачности дочерним CanvasRenderer. В итоге, получается не очевидно желаемое полупрозрачное окошко с содержимым, а просто каждый элемент этого окна становится полупрозрачным. На полупрозрачной панельке полупрозрачная кнопка, через которую просвечивает панелька, и сверху на все это накладывается еще и текст на кнопке, по тому же принципу. А уж если кто-то придумает использовать стандартный юнитиевский shadow или outline - это идея сама по себе сомнительная, но в сочетании с CanvasGroup она заиграет новыми красками. Лет 6 уже наблюдаю эту ситуацию, ничего не меняется. Даже в проде все так и работает, анимации меняют прозрачность элементов, а не канвы в целом. Способа добраться до результата отрисовки канвы, чтобы менять его прозрачность(казалось бы, очевидное решение), по крайней мере я не нашел.
То, что вы хотите возможно сделать только предварительным рендерингом в RenderTexture, а это дорого, поэтому никто так и не делает. Да особо и не нужно, на самом деле - в падавляющем большинстве случаев такие анимации достаточно быстрые, редкий взгляд такое заметит, а ещё более редкий увидит в этом проблему.
Верно, поэтому я и не стал упоминать это как способ решения. Едва ли подобную конструкцию можно назвать таковым. Обычно в таком случае действительно пытаются "выехать" на скорости анимации. И я действительно уже пару лет не слышал жалоб на это кроме как в контексте замедленного видео. Что касается нужности - остановимся на том, что я тот самый редкий случай, кому вечно не везет с сотрудниками.
Немного дополню.
Уже довольно давно появились assembly definitions, части кода можно выделять в отдельные assembly. Это ускоряет процесс разработки (компилируется только измененённые), а также даёт возможность разбить проект на куски и настроить кто от кого зависит.
AssetPostprocessor'ы лучше скомпилировать и подключать как DLL особенно если используется кеш-сервер (сейчас наверно можно через asmdef). Дело в том, что они не выполняются если в их assembly есть ошибки. И если у вас одновременно новый ассет и ошибки в коде, то на кеш сервер уходит ассет для которого post processor не был вызван. И потом может внезапно выплыть на билд машине.
Также была забавная проблема с AssetPostprocessor'ом. На одном из релизов вдруг поменялись хеши у кучи asset bundle'ов. Для пользователей это гигабайты перекачки. Оказалось в одной из используемых нами внешних библиотек добавили AssetPostprocessor для сцен. Он как бы ничего особо не делал, просто был. Но Unity ведь не знает об этом. Изменён пост процессинг ресурса, значит ресурс импортится по-другому, вот тебе новый хеш.
Хороший список. Добавлю только по двум пунктам:
Animation — это старый анимационный движок, который помечен как legacy, и использовать его уже не ререкомендуют
На Unite их инженеры как раз рекомендавали Animation использовать для простых анимаций. И акцентировали внимание, что "легаси" тут никого не должно пугать. Даже показывали сравнение перформанса, когда какой использовать в зависимости от количества кривых в анимации.
При этом наоборот для UI не стоит использовать Animator, так как он сетает dirty флаг и меш перестраивается, даже когда визуально ничего не происходит (например idle стейт)
3.5. Layout и ContentSizeFitter.
И эти компоненты не рекомендуют использовать. Лучше использовать якори, либо если контент действительно динамический, то написать кастомный скрипт.
4.4. Не используйте стандартный Update
Неужели с Update все так плохо? Как-то не верится что это ещё не оптимизировали.
4.7. Не доверяйте OnDestroy/OnTriggerExit.
Не знаю насчёт OnTriggerExit, но всегда OnDestroy вызывается на выключенном объекте.
И правда не вызывыется. Тоже сначала усомнился на счет OnDestroy.
Из документации:
Note: OnDestroy will only be called on game objects that have previously been active.
Довольно странная логика по отношению к имени метода.
Используйте асинхронную загрузку ассетов, если это возможно. Такое размазывание загрузки положительно скажется на плавности вашей игры, открытии интерфейсов, особенно с большими списками.
Асинхронная загрузка может очень заметно снижать FPS, поэтому тоже уместна не везде.
Unity «Best» Practices