а вам точно надо именно сравнивать текстуры??
нельзя ли у вас в проекте просто вычислить точку в которую должен смотреть прицел ??
и проверить, на сколько прицел (его вектор направления) отклоняется от требуемого?
а то странно как то все выходит.
и кстати пробовал перечитать раз 10. и не смотря на скриншот и описания - все еще непонятно толком как это работает) где там прицел. где калиматор. что они из себя в иерархии представляют.
двигаются через изменение Offset.x, но как? просто в скрипте туда сюда меняется? от поворота?
как собственно вообще происходит смещение прицела? игрок вращается как то по кнопкам? за мышкой движется?
но это наверно не критично) просто пишу что не очень понятно к сожалению. что происходит и что надо.
может вообще изначально подход к "прицеливанию" проще изменить, чем сравнить на экране текстуры..
может текущая архитектура/иерархия/и тп "прицела и прицеливания" не годится..
опишите, может кто прочитает да разберется и подскажет)
а скриншот иерархии? что там в настроиках инпутфилда у вас покажете?
EventSystem есть в сцене?
в канвасе евент камера выставлена? насамом канвасе висит график реикаст?
чтоб оно могло ловить клики и прочее))
рядом просто кнопки есть? они нажимаются? (ну то есть убедится ,что просто евенты кликов попадают на канвас)
а зачем вам там физика? в подавляющем случае это просто анимация + немного IK (инверсной кинематики на руки)
хотя слово "просто" - для начинающих тут явно лишнее.
вам проще будет попытаться найти пример такой реализации в каком-нить ассете (возможно платном)
или просто дополнительно почитайте про инверсную кинематику если не выдели/не сделали с ней ничего)
не знаю чем еще толком помочь, Анимации и аниматоры не мой профиль.
ну еще чуток)
перерыл историю википедии))
страная штука)) где тот до 2010 - 2011 просто юнити зовется.
потом в 2012-2013 появляется упоминания названия Unity3d.
а потом через время снова пропадает)) https://en.wikipedia.org/w/index.php?title=Unity_(...
справедливости ради - раньше мелькало в названиях Unity3d, до ребрендинга))
потом добавили 2D мод, и чтоб не отпугивать инди ребят с их любимым пиксель артом и 2D игрулями - стали выпиливать название с приставкой 3d отовсюду)))))
конкретно в случае с счетчиком фпс - бессмысленная затея)) даже счетчики из бенчмарков (системные так сказать) и те неадекватные данные показывают и провисают в момент включения/выключения и загрузок/выгрузок сцен/объектов.
а в остальном просто на фоне какую-то незатейливую операцию выполнять (таимер там, или анимация из кода) - просто короутина.
если что то серьезное - потоки вам в помощь.
если фоновое (дождаться ответа от плагина или системы к примеру) - колбеки, делегаты, евенты и вот это вот все подобное))
и для этой логики не нужен OnTriggerStay. заводить список вошедших и очередность. о чем уже писал. в вопросе, подозрительно похожем на ваш же с другого аккаунта))
каждый такт физики - проверять что-то для пары сотен объектов - как ни крути - кривая реализация в данном случае.
если это поиск соперника/цели в радиусе вокруг себя. то зачем вам вообще проверять тех кто ОСТАЕТСЯ В ТРИГЕРЕ ??
заводите список всех кто вошел и вышел.
и выбирайте из них, проверяя на всякий случай, что выбранный не умер..пока до него очередь дошла.
а в чем проблема? проседает производительность? под пк?под мобильную платформу?
у вас может там внутри какой-нибудь вызов Debug.log (или какой другой вывод в консоль)??
вы уверены что вам нужны именно OnTriggerStay? просто детектить вход и выход не годится?
все 100 ботов всегда должны быть активны?)
как уменьшить количество вызовов?) не вызывать всегда и у всех)
в общем по факту без примеров кода и понимания целевого устроиства и прочего уточнения - оптимизация вам к чертям не нужна)) и по факту вопроса. сам метод оптимизировать - никак . это просто встроенный метод. а вот что вы в нем делаете вообще не ясно)
а разве префаб это не GameObject.
как вы хотите префаб в холст превратить?
или просто данные описания храните или берите ссылку на GameObject (префаб) и инстанцируйте его)
а вообще если у вас это данные о предмете) вам бы хранить именно данные. а всякие ссылки на префабы и картинки -- отдельно) обычно облегчает потом дело)
но пока можете просто пометить себе и забыть про такое)) потом вспомнится может)
мой ответ скорее про организацию этого дела.
вам нет смысла делать иерархихию типа
Wheel
-Disk1
-Disk2
-Disk3
можно просто выставить
Wheel
-Disk
--Cup
и сделать скрипт. где в одном поле указать ссылку на Disk.
В другом поле указать ссылку на Cup.
И завести два массива текстур. под диски и колпаки. и просто заменять картинку в компоненте Sprite. вместо включения выключения кучи объектов) если позиции у них всегда остаются одни и те же.
Как сделать ссылку и завести массив текстур. тут уж даже не знаю, наверное вам начальные туториалы по Юнити надо бы прям с офф саита глянуть - и должно все проясниться.
еще предложил бы сравнить версию юнити свою и та что в уроках. возможно уроки на какой-нибудь 5.4 ..а с тех пор освещение поменялось по настроикам и визуалу.
пять долларов - я б тоже зажал, за такой туториал) очень уж он паршивый.
но вам все же минус за нежелание на английском чуток погуглить - по базовым всем вещам у Юнити - прекрасная и документация и примеры и туториалы.
и если вы ничего на пол не ставили - то как у вас по гравитации все к чертям не проваливалось тогда?))
ладно. разбирайтесь. уж больше чем сейчас по такому абстрактному вопросу - особо не поможешь.
еще раз удачи в обучении.
давайте еще так https://learn.unity.com/tutorials/?k=%5B%22t%3Atut...
уж с английским надеюсь нет проблем.
(если сбросится фильт - то для начинающих. 2d. и отключить фильр по языку)
и аккаунт для юнити тоже есть (вдруг нужен логин чтоб открыло нормально страницу)
так берите и делайте. там есть и статейка с пояснением и демо проектик даже со скриптами и прочими исходниками..в чем проблема?)
вы у себя сделали пол из 2D коллайдера, на нем два объекта и с коллайдерами2d и Rigidbody2d??
один из двух этих - двигаете - все. толкается. слои если не меняли галочки в физике не выключали.
если не смешивали 3d коллайдерыи делали по дефолту в новом пустом проекте - все должно работать. если нет - берете еще более простые примеры и просто на круг скидываете по гравитации другой круг, и смотрите что и как. учитесь анализировать.
а без скриншотов , попыток показать свой код и настройки , просто "хочу как тут" не выйдет к сожалению.
на этом все) удачи)
нельзя ли у вас в проекте просто вычислить точку в которую должен смотреть прицел ??
и проверить, на сколько прицел (его вектор направления) отклоняется от требуемого?
а то странно как то все выходит.
и кстати пробовал перечитать раз 10. и не смотря на скриншот и описания - все еще непонятно толком как это работает) где там прицел. где калиматор. что они из себя в иерархии представляют.
двигаются через изменение Offset.x, но как? просто в скрипте туда сюда меняется? от поворота?
как собственно вообще происходит смещение прицела? игрок вращается как то по кнопкам? за мышкой движется?
но это наверно не критично) просто пишу что не очень понятно к сожалению. что происходит и что надо.
может вообще изначально подход к "прицеливанию" проще изменить, чем сравнить на экране текстуры..
может текущая архитектура/иерархия/и тп "прицела и прицеливания" не годится..
опишите, может кто прочитает да разберется и подскажет)