3D.ru

Доброго времени суток. У меня мелочь) В моём проекте, на каждом подбираемом предмете висит скрипт для взаимодействия с ним в инвентаре. Скрипт большой, много условий. Чтобы каждый объект этот скрипт все время не обрабатывал я его отключаю (галочка в редакторе, через скрипт- .enabled = false;), когда предмет не у игрока. Так и в документации советовали делать. Но вот недавно я выяснил, что оказывается так скрипт не отключается полностью. Выключаются лишь сообщения OnDestroy, OnAwake, OnApplicationQuit и что то там связанное с рендером еще. Вот меня теперь интересует есть ли смысл в дальнейшем отключать скрипты, или это только лишняя трата времени. И не взорвется ли ком, если на локации будут лежать десятки объектов со скриптом в котором обрабатываются десятки условий. И на сколько вообще условия, проверки много жрут ресурсов?
Так же хочу спросить. Для оптимизации лучше делать больше классов, но меньше в них писанины, или весь код собирать в одном классе по возможности, или разницы нет?

enable отключает еще и Update. Если так важна оптимизация смотри в сторону ecs, она как раз рассчитана на множество объектов.

1max1 писал(а):ecs, она как раз рассчитана на множество объектов.

ECS - сколько читал про вводимый в Unity ECS, так и не понял как ей вообще пользоваться... Усложнение кода не больше...

Усложнение кода не больше...

На вкус и цвет, как говориться. Лично от себя могу сказать, что она реально хорошо работает, и если объектов много и на каждом из них скрипт с апдейтом, то это очень даже полезная штука.
Вкратце пользоваться так:
Есть компонент, допустим, враг (дальше из него будет создана сущность).
Всё что делает враг, это идет за целью, значит у него будет 2 поля с двумя трансформами (его и цели).

Дальше мы должны создать сущность, обычно это выглядит как-то так:

Дальше нужно двигать нашего врага, для этого нужна система, которая реализует интерфейс IEcsUpdate:

Осталось только добавить систему в список систем:

Это очень обобщенное описание и из-за кучи разных ECS реализация разная.
p.s. Вот еще статейка про апдейты https://blogs.unity3d.com/ru/2015/12/23 ... ate-calls/

Да, точно. Update не работает, я перепроверил. Но, допустим методы OnMouse.. работают. Так же есть доступ к переменным скрипта, их можно даже изменять. Это улучшает ситуацию, ради Update думаю стоит управлять активностью.
ECS интересная очень тема, буду изучать, спасибо. Как я понял это особенно полезная вещь для проектов, в которых большое количество объектов, особенно если они еще и часто спавнятся и удаляются.
А все таки на сколько условия, которые обрабатываются каждый кадр влияют на оптимизацию. Допустим простейшее if. Или метод OnTriggerStay. Хочется может на каждый объект кидать по скрипту с проверкой на столкновения. Но боюсь за оптимизацию, коллизия все таки.

MaxBorn писал(а):А все таки на сколько условия, которые обрабатываются каждый кадр влияют на оптимизацию. Допустим простейшее if. Или метод OnTriggerStay. Хочется может на каждый объект кидать по скрипту с проверкой на столкновения. Но боюсь за оптимизацию, коллизия все таки.

Создаёшь 50000 объектов на сцене, заходишь в Profiler и смотришь, удаляешь условие, повторяешь всё заново, разница во времени и будет являться влиянием на производительность.

IDoNotExist писал(а):Создаёшь 50000 объектов на сцене, заходишь в Profiler и смотришь, удаляешь условие, повторяешь всё заново, разница во времени и будет являться влиянием на производительность.

О, благодарю) О профайлере даже не знал.

Не знаю, в тему или нет, но если много условий и часть из них постоянно работает, можно силами самого си шарпа слегка упростить себе жизнь. Использовать условные операторы && и || https://docs.microsoft.com/ru-ru/dotnet ... d-operator . У меня в коде много различных проверок и немного ресурсов экономится.

dzikar писал(а):Не знаю, в тему или нет, но если много условий и часть из них постоянно работает, можно силами самого си шарпа слегка упростить себе жизнь. Использовать условные операторы && и || https://docs.microsoft.com/ru-ru/dotnet ... d-operator . У меня в коде много различных проверок и немного ресурсов экономится.

Да, это само собой) Без них я бы наверное не смог бы написать свои коды)
Вот кстати интересный вопрос. Когда программа читает код и ей встречается допустим "if (a > b && c < b)". И если первое условие "a > b" неверное, продолжается ли чтение кода, или проверка if на этом заканчивается и чтение пропускает её. Это интересный вопрос, потому что у меня допустим достаточно много бывает таких к примеру проверок " if (ammo == true && inventoryItem.weapMouseCol != null && ammoObj.nameAmmo == inventoryItem.weapMouseCol.GetComponent<Weapon>().nameAmmo) " Достаточно ресурсоёмкая проверочка)

& - проверка продолжается, && - обрывается если фолс, тоже самое и с оператором или.

1max1 писал(а):& - проверка продолжается, && - обрывается если фолс, тоже самое и с оператором или.

А я то думал чем отличается двойной знак.. Теперь понятно, спасибо) Но не понятно для чего вообще продолжать проверку, если условие уже неверно?

Для битовых операций, например.