Свой Character controller. Оно надо?

[3Dragon]

Разбираюсь сейчас с родным first person controller-ом. Интересно узнать мнение опытных человеков: имеет ли смысл писать свой char controller с аналогичным функционалом?

В родном контроллере заметил одну неприятную особенность: во время движения заметно постоянное слабое подергивание камеры (или контроллера?) вверх-вниз. Причем, как в editor-e, так и в скомпиленном приложении. Не исключено, что это только у меня такой баг нарисовался - протестировать можно, взяв родной fps controller. Кроме того, он позволяет работать исключительно с capsule collider.

Задумался, может быть стоит написать контроллер, приближенный к, хм, человеческому скелету? Т.е. взять 2 рейкаста для конечностей, определить центр тяжести и сделать "strider", умеющий шагать, учитывая особенности поверхности (ступени, платформы, пандусы и т.д.). Или все это обернется лишними сложностями? Лично вам хватает character controller-а из unity или в самописном действительно есть необходимость?
Дискасс.

[lol]

У характер-контроллера коллизии странные, такое чувство, что они работают нормально при столкновении только полностью с перпендикулярными к нам коллайдерами. И при этом когда идешь прямо на куб - то нас не поднимает(ну понятно высоты шага не хватает), но - при этом если попытаешься столкнуться левым или правым(относительно того, если смотреть прямо) краешком капсулы с этим же кубом - то нас забрасывает почему-то на кубик.

Вообще, мне интересно каким образом реализовывают более реалистичные коллизии персонажей сейчас(как в assasin creed, например), когда это визуально не просто столкновения двух капсул.. И насколько это сложно. В assasin правда: Havok, а в хавок развитая система AI(поиск путей там итд), но, возможно, это всё-таки не Хавок делает..

[Paul Siberdt]

Хотите реализовать человеческое передвижение - пишите его математикой, а не физикой. В больших играх, игровую механику и физику очень не любят смешивать.
Физику могут пользовать для трассировок, в качестве триггеров и детекторов проникновения, но самих персонажи стараются делать кинематическими.

[3Dragon]

Хотите реализовать человеческое передвижение - пишите его математикой, а не физикой. В больших играх, игровую механику и физику очень не любят смешивать.
Физику могут пользовать для трассировок, в качестве триггеров и детекторов проникновения, но самих персонажи стараются делать кинематическими.

Ну, физическую "привязку к местности" все равно придется организовывать =)
Кстати, насчет "больших" игр: что, контроллеры сильно отличаются от простой капсулы с коллизиями и movement-ом?
В каком смысле, кинематическими? IK? Юнитевский локомоушн, к примеру, все равно использует родные чар. контроллер и movement.

[Zaicheg]

Ну, физическую "привязку к местности" все равно придется организовывать =)

Зачем? Лучи + изменение позиции — этого достаточно.

В каком смысле, кинематическими?

То есть, движение объекта без учёта массы и действующих на него сил. То есть, через Transform.

[3Dragon]

Зачем? Лучи + изменение позиции — этого достаточно.

Нужен коллайдер для определения столкновений с препятствиями. + Ступеньки, платформы, возможно, залезание на объекты и т.п.

[Zaicheg]

Нужен коллайдер для определения столкновений с препятствиями. + Ступеньки, платформы, возможно, залезание на объекты и т.п.

Да, нужен. Речь здесь ведётся о другом — о том, двигать объект физическими методами, предоставляя обработку взаимодействия с другими объектами физическому движку, или двигать его напрямую, обрабатывая взаимодействия самостоятельно. Все участники знают, что лучи и коллайдеры — это тоже вообщем-то физические понятия, но под "физикой" подразумевается ригидбоди и иже с ним.

[3Dragon]

Да, нужен. Речь здесь ведётся о другом — о том, двигать объект физическими методами, предоставляя обработку взаимодействия с другими объектами физическому движку, или двигать его напрямую, обрабатывая взаимодействия самостоятельно. Все участники знают, что лучи и коллайдеры — это тоже вообщем-то физические понятия, но под "физикой" подразумевается ригидбоди и иже с ним.

Угу, это понятно. Насколько я понимаю, когда мы двигаем character controller с помощью Move или SimpleMove, это как раз означает изменение position "вручную" без участия физ. движка, так?

Возможно, имеет смысл отделить обработку перемещения (кастовать один луч для определения grounded и движения персонажа) и обработку столкновений с препятствиями (чтобы придать контроллеру "толщину" и добавить, например, скольжение вдоль препятствий)? По идее, это избавит контроллер от нелепостей типа такой:


Не очень понимаю пока что, как это реализовать

[Neodrop]

Угу, это понятно. Насколько я понимаю, когда мы двигаем character controller с помощью Move или SimpleMove, это как раз означает изменение position "вручную" без участия физ. движка, так?

Ничего подобного. Character Controller это родной компонент NVidia Physics
Любое действие над ним, учитывается физ. системой.

[3Dragon]

Нашел еще один достаточно неприятный момент:
Применяю gravity по аналогии со скриптом из справки, только добавил еще вывод в GUI.Box значение переменной controller.IsGrounded.
Так вот, когда контроллер находится на земле, значение переменной постоянно изменяется раз за фрейм. Довольно странна "фича". Недоумеваю.
Это, кстати, не дает реализовывать прыжок по Input.GetButtonDown, только по Input.GetButton (оно и понятно почему).

Синтаксис:

Синтаксис: [ Показать ]

Используется javascript

var speed : float = 6.0;
var jumpSpeed : float = 8.0;
var gravity : float = 20.0;

private var moveDirection : Vector3 = Vector3.zero;

function Update() {
    var controller : CharacterController = GetComponent(CharacterController);
    if (controller.isGrounded) {
        // We are grounded, so recalculate
        // move direction directly from axes
        moveDirection = Vector3(Input.GetAxis("Horizontal"), 0,
                                Input.GetAxis("Vertical"));
        moveDirection = transform.TransformDirection(moveDirection);
        moveDirection *= speed;
       
        if (Input.GetButton ("Jump")) {
            moveDirection.y = jumpSpeed;
        }
    }

    // Apply gravity
    moveDirection.y -= gravity * Time.deltaTime;
   
    // Move the controller
    controller.Move(moveDirection * Time.deltaTime);
}

[BlackMamba]

Задумался, может быть стоит написать контроллер, приближенный к, хм, человеческому скелету?

мой опыт говорит, что проще обойтись стандартным контроллером. Я писал свой, иммитирующий передвижение шагами: при нажатии кнопок передвижения, объект начинает передвигаться с определенной скоростью в определенный промежуток времени - это первый шаг, потом скорость и ширина шага увеличиваются по закономерности 1-(1/номер шага) и так далее. Все получается, все работает, но это очень ресурсозатратно для компа (пара сотен операций за один такт Update всего лишь дря реализации передвижения и вращения персонажа, имхо - это бред), очень длительно по времени написания, и полный треш при оптимизации и попытке модернизировать такой код, причем я делал это для ровной плоскости.

[3Dragon]

пара сотен операций за один такт Update всего лишь дря реализации передвижения и вращения персонажа

Простите, а откуда столько? о_О

[BlackMamba]

"...при нажатии кнопок передвижения, объект начинает передвигаться с определенной скоростью в определенный промежуток времени - это первый шаг, потом скорость и ширина шага увеличиваются по закономерности 1-(1/номер шага) и так далее..."
+ куча проверок на состояние объекта, на нажатие кнопок + в моем варианте скорость вращения персонажа зависела от скорости его передвижения и от момента шага + при резком поворачивании камеры, персонаж должен остановиться, развернуться и начать разбег заново + обслуживающие переменные и операции с ними, необходимые для привязки анимации + я не очень хороший программер, в общем в моем исполнении все получалось с проседанием фпс (не большим, но все же), а это, имхо, перебор, учитывая, что в игре обычно существуют и куда более сложные алгоритмы, в общем такой контроллер имел бы право на жизнь, если бы не одно но: стандартный, при всех его недостатках обладает куда лучшим соотношением (правильность имитации движения человека)/(ресурсоемкость)/(возможность модификации).
может у вас получится лучше, кто знает.

[seaman]

Не факт, что свой контроллер поможет в ситуации из мувика. Аналогичная проблема:

rrr.jpg

Окончание "падения" определяется не по CharacterController.isGrounded, а по Raycast-у вниз из transfrom.position персонажа - если есть земля на определенном расстоянии. На этом расстоянии в данной ситуации земли нет, а коллайдер не дает ниже упасть - зацепился краешком за куб. Персонаж оказывается в подвешенном состоянии. Проверять надо видимо не Raycast-ом, а SphereCast-ом по диаметру коллайдера что-ли.

ЗЫ: SphereCast в моей ситуации отлично пошел.

[lol]

А где-нибудь есть, кстати, пример создания своего контроллера? Там ведь, например, когда в стену натыкаешься, то надо, чтобы перс в зависимости от угла двигался вдоль стены.