Comments 8
Отличная статья ? и действительно без коллайдера работает). Однако хотелось бы уточнить есть ли прирост в производительности при использовании данного способа реализации нежели использовать коллайдер?
На большом количестве обьектов будет прирост, так как математика в несколько раз проще физики. На практике можно считать дистанции к маркерам внутри JobSystem, в качестве результата выдавая близжайший из них.
Если пойти еще дальше (от физики) то удаление Rigidbody через Destroy компонента и создание компонента через AddComponent так-же дает заметный прирост производительности на большом количестве обьектов, по сравнению с isKinematic той-же физики.
А не могли бы вы уточнить, как динамическое удаление / добавление компонента Rigidbody целиком (не проще деактивировать объект?), дает заметный прирост по сравнение с включением / отключением флага isKinematic в нем? (Если я правильно понимаю вашу мысль).
Пишется обертка RigidbodyLink которой добавляются поля аналогичные Rigidbody (те что вам нужны), и методы Enable и Disable.
Enable - выполняет AddComponent<Rigidbody> и выставляет ему нужные параметры из локальных полей.
Disable - Destroy(rigidbody).
Плюс в производительности на выключенных обьектах, если на сцене присутствует ~5к физ обьектов. Так как kinematic обьекты все-еще считаются.
Минус - за один кадр можно только включить или выключить обьект 1 раз, если будет 2 запроса, выполнится только 1 из них.
У нас в проекте физика включалась на определенном радиусе от игрока (проверялось математикой по дистанции от игрока на обьекты в JobSystem), в остальных ситуациях она отключена и ничего не делает. Переход на удаление обьекта вместо kinematic дало нам ~25-30% производительности, на 25к динамических обьектов в сцене, это разрушаемые стены/мебель и подобные динамические обьекты.
Надеюсь ответил на вопрос.
Трассировать всё равно придется - потому что иначе можно будет взаимодействовать с метками через препятствия.
На этот случай как раз можно выставлять свое расстояние для активного режима метки. И выбрать, где удобно разместить саму метку относительно ее физического объекта.
Если объект нужно прямо у стены поставить или там за деревом, и так чтобы с другой стороны нельзя было по нему нажать, то можно просто сократить это расстояние (сделав его по толщине стены). А подойти поближе, не так и тяжело)
Понятно, что индивидуально нужно поработать, на все случаи жизни 100% решение тяжело сделать.
Вместо луча, можно например, написать пару строк для задания области подхода к ней в мировых координатах, относительно ее начального угла поворота:)
Очень корявое решение, сложно настраивать, плюс куча проблем вроде нажатий через стену, код тоже очень слабый, магические числа, массивы там где не нужны, пространные имена переменных, неправильный код стаил, очень много операторов ветвления, глобальные объекты, нарушение srp, почти в каждой строчке ошибка. По поводу скорости работы, встроенная физ подсистема алгоритмтческий будет сильнее, потому что под капотом имеет дерево, для отсечения лишних запросов, тут такого нету, так что вероятно если меток будет много, будут проблемы с производительностью
Урок на Unity. Интерактивное взаимодействие игрока с окружающими предметами в 3D с помощью меток