Думаю если там есть какая-то проверка в этом алгоритме, то она выполнится независимо от того проходит число эту проверку или нет.

А зачем такая оптимизация, ты реально миллион раз в секунду вызывать будешь? Кстати, по моему если писать gameobject.transform - то это равносильно gameobject.Getcomponent<Transform>() и это в 10 00 раз больше расчетов займёт чем вопрос про минус

Слышал, что в Юнити они поправили это

Я полтора года назад тестил и эта проблема была. Лучше убедиться)

Нет, теперь это не равносильно gameobject.Getcomponent<Transform>()
Но задержка есть.
Там, по моей памяти, сейчас есть поле, которое хранит в себе трансформ, а gameobject.transform проверяет, на null это поле и, если оно null, тогда делает для него gameobject.Getcomponent<Transform>()
Так что сильной просадки в производительности больше нет. Разве что одна лишняя проверка на null.
Но я привык уже выносить gameobject.transform в отдельную переменную, да и мысль о том что мой старенький процессор не будет лишнюю проверку на null делать - греет душу)

Двухмерные коллайдеры проще обрабатываются?

У меня 2.5D игра — фактически 3D, но в геймплее третья ось не участвует.

Будет ли иметь смысл всё переключить на двухмерные коллайдеры? Это как-то сделает лучше дела с просчетом физики?

У 2Д и 2Д в Юнити "немножко" по-другому устроена физика и геометрия. Не советую скрещивать 2Д и 3Д физику - затрахаешься.

лучше не рискуй с 2д коллайдерами

А можно на 2д играх 3д физику юзать ?

Нет

Посути нужно только ограничить одну ось и получается 2 д

Физические объекты так не пересекаются в Юнити

Настраиваешь 3Д физику так, чтобы ограничить одну из осей

Подскажите, в новых версиях это где находится? Не могу найти что-то

сейчас новая система gui и выходит еще одна на подобии html

почитай про новую систему

там везде теперь спрайты (они через импорт картинок настраиваются)

Понял суть, спасибо)