Это довольно дорогостоящия операция. Так что использование ее оправдано только при инициализации классов. И последующем кэширование нужных объектов. Как отметили ниже, никогда не стоит использовать поиск объектов, в методах вызываемых каждый кадр или чаще (Update, FixedUpdate и т.д.) Часто люди опасаются использовать кэширование объектов через инспектор. Считается что это нарушает инкапсуляцию, ссылки могут потеряться. Или кто то сменит их случайно. Но это вполне рабочая схема если использовать ее внутри одного префаба. Нужно следить за балансом времени и сложности кода. Понимание того что лучше для конкретного проекта приходит с опытом.
Не стоит боятся Coroutines это достаточно удобный базовый функционал предоставленный Unity. Его не обходимо изучить и использовать. Он отлично покрывает потребности небольших проектов.
При использование GetComponent редактор создаёт отдельный объект в который пытается поместить искомый компонент. Это приводит к выделению дополнительной памяти. этот происходит только в редакторе но может критично сказаться на тестирование приложения. Плюс требуется создание отдельной переменной для проверки компонента на null. Что бы решить данную проблему было создано новое api TryGetComponent. Главное отличие в том что метод возвращает bool, а нужный компонент назначается атрибуту с модификатором out. Это позволяет избежать выделения памяти. Плюс код легче читается и выглядит чище.
Удачи, будущих проектах. Небольшие советы. Лучше использовать не GetComponent а TryGetComponent. Это позволит избежать лишнего выделения памяти. Что бывает критично при частных проверках. Так же с паттерном синглтон стоит быть аккуратным. При всей его внешней простоте и удобстве, он сильно влияет на гибкость и масштабируемость программы. Нужно четко разграничивать область его применения, и понимать в чем он будет удобнее для данной задачи.
Это шейдер, который реагирует на коллайдер машины и поворачивает мэшь в зависимости от нормали контакта?
Это довольно дорогостоящия операция. Так что использование ее оправдано только при инициализации классов. И последующем кэширование нужных объектов. Как отметили ниже, никогда не стоит использовать поиск объектов, в методах вызываемых каждый кадр или чаще (Update, FixedUpdate и т.д.) Часто люди опасаются использовать кэширование объектов через инспектор. Считается что это нарушает инкапсуляцию, ссылки могут потеряться. Или кто то сменит их случайно. Но это вполне рабочая схема если использовать ее внутри одного префаба. Нужно следить за балансом времени и сложности кода. Понимание того что лучше для конкретного проекта приходит с опытом.
Не стоит боятся Coroutines это достаточно удобный базовый функционал предоставленный Unity. Его не обходимо изучить и использовать. Он отлично покрывает потребности небольших проектов.
При использование GetComponent редактор создаёт отдельный объект в который пытается поместить искомый компонент. Это приводит к выделению дополнительной памяти. этот происходит только в редакторе но может критично сказаться на тестирование приложения. Плюс требуется создание отдельной переменной для проверки компонента на null. Что бы решить данную проблему было создано новое api TryGetComponent. Главное отличие в том что метод возвращает bool, а нужный компонент назначается атрибуту с модификатором out. Это позволяет избежать выделения памяти. Плюс код легче читается и выглядит чище.
Удачи, будущих проектах. Небольшие советы. Лучше использовать не GetComponent а TryGetComponent. Это позволит избежать лишнего выделения памяти. Что бывает критично при частных проверках. Так же с паттерном синглтон стоит быть аккуратным. При всей его внешней простоте и удобстве, он сильно влияет на гибкость и масштабируемость программы. Нужно четко разграничивать область его применения, и понимать в чем он будет удобнее для данной задачи.