Comments 13
NavMeshObstacles, апроксимированный кубами, по тому же принципу что вы описали, для построения сетки пути, работает ровно также. Делали большой проект, пользовались только им для описания статичных не перемещающихся NPC. Все работает отлично в поиске пути. Проблем не замечено. Можете описать, что за проблемы у вас были с NavMeshObstacles
Наверное некорректно публиковать ссылки на сторонние ресурсы, показал бы на видео. Поэтому постараюсь объяснить как сумею.
Препятствия я использую в первую очередь как двери.
Столкнулся с неприятностью. Предположим, за дверью скопилось несколько злобных мобов, которые очень заинтересованы в игроке как деликатесе. Все они напирают на дверь — препятствие. Задние подталкивают передних (я имею ввиду CharacterController'ы персонажей). В результате по неведомой причине, в определенный момент времени несколько передних мобов «просачиваются» сквозь непрозрачный для них NavMeshObstaсle.
Поэтому и выдумываю костыли, пример с кораблем только один из.
Препятствия я использую в первую очередь как двери.
Столкнулся с неприятностью. Предположим, за дверью скопилось несколько злобных мобов, которые очень заинтересованы в игроке как деликатесе. Все они напирают на дверь — препятствие. Задние подталкивают передних (я имею ввиду CharacterController'ы персонажей). В результате по неведомой причине, в определенный момент времени несколько передних мобов «просачиваются» сквозь непрозрачный для них NavMeshObstaсle.
Поэтому и выдумываю костыли, пример с кораблем только один из.
Ну так описанная ситуация не к NavMesh имеет отношения, а к физике это раз и к поведению персонажей это два.
Если в первом случае, надо настраивать правильно физические представления, ибо чем меньше значения оных, тем менее точно физика работает. Если у вас коллидеры по 0.1f размером, это не тоже самое, что при 10f. Будут артекфакты, их можно убрать через способ определения колизии, поменять дискретный, на непрерывный.
А в лучшем случае, персонажи не должны давить друг на друга.
Если в первом случае, надо настраивать правильно физические представления, ибо чем меньше значения оных, тем менее точно физика работает. Если у вас коллидеры по 0.1f размером, это не тоже самое, что при 10f. Будут артекфакты, их можно убрать через способ определения колизии, поменять дискретный, на непрерывный.
А в лучшем случае, персонажи не должны давить друг на друга.
CharacterController
Как этот хак физики относится к NavMeshAgent (с avoidance), который и должен был быть использован?
Напишите подробнее, интересно. А лучше небольшую статью. Нашел пару ресурсов на английском, поизучаю как руки дойдут.
Напишите подробнее про avoidance, интересно. А лучше небольшую статью. Нашел пару ресурсов на английском, поизучаю как руки дойдут.
По поводу что куда кого подталкивает однозначно сказать не могу, только предполагатю. Моб сложный — CharacterController + NavMeshAgent + BoxCollider/trigger (включает/отключает скрипт ИИ). Не исключаю, что и скрипт может подбагивать.
Кхм, странно. Попытался отредактировать комментарий, ресурс пишет, что время истекло. Через какое-то время само заработало.
По поводу что куда кого подталкивает однозначно сказать не могу, только предполагатю. Моб сложный — CharacterController + NavMeshAgent + BoxCollider/trigger (включает/отключает скрипт ИИ). Не исключаю, что и скрипт может подбагивать.
Кхм, странно. Попытался отредактировать комментарий, ресурс пишет, что время истекло. Через какое-то время само заработало.
CharacterController — внутри оно реализовано как колайдер с включением-выключением rigidbody в FixedUpdate, те постоянные дергания физики с учетом движения игрока как капсулы + скольжения вдоль стен. Но это бессмысленно, потому что навмеш-агент игнорирует все, кроме других навмеш-агентов и в принципе не может выйти за пределы запеченного навмеша. При использовании физики наступает конфликт, ведущий к проталкиванию сквозь препятствие и ошибкам. По поводу авоиданса — у каждого навмеш-агента есть «качество» просчета авоиданса с указанием приоритета. Достаточно просто его включить и выставить одинаковый приоритет — каждый навмеш будет отталкивать всех прочих.
Что это за бред? У вас при такой реализации невидимая часть остаётся помеченной статичным флагом? Тогда ваше решение работает только если корабль не плывёт, правильно я понимаю?
В статье о том и речь, что если объект не перемещается но при этом анимирован, то вот можно его не NavMeshObstacles помечать, а апроксимировать кубами и запечь в карту NavMesh.
Это называется недочитал, недопонял, но неодобряю.
Бред, на мой непрофессиональный взгляд, это городить вавилонскую башню в качестве Sound Manager.
Уважаемый, начинать комментарий с указанного выше предложения — это банальный выпендреж. Пора выходить из подросткового возраста, вы же Ведущий Разработчик).
Бред, на мой непрофессиональный взгляд, это городить вавилонскую башню в качестве Sound Manager.
Уважаемый, начинать комментарий с указанного выше предложения — это банальный выпендреж. Пора выходить из подросткового возраста, вы же Ведущий Разработчик).
Ну что-ж вы так реагируете) Будьте терпимы. Sound Manager это не Вавилонская башня, это реальная вещь, к которой так или иначе придешь, если начнешь делать более или менее серьезные проекты. В 4 юнити без нее вообще никуда, в 5 стало попроще из-за наличия Mixer.
Мне грустно что хаб Unity3d превращяется в gamedev/ru…
Sign up to leave a comment.
NavMesh на костылях — маленькие хитрости