Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Определение высоты (3 стр)

Определение высоты (3 стр)

Поделиться
Страницы: 1 2 3
DiganПостоялецwww21 июня 201022:59#30
Xunter, физический движок пока не использую. Физика минимальна -столкновение с полигонами и гравитация.
Как-то можно это реализовать без физ движка?
Пока мне не понятны 2 вещи:
1) Как выделить препятствия если они являются частью статической геометрии?
  Если препятствия это отдельный меш, то можно по ID ноды при пресечении луча задавать и определенную анимацию. А вот как быть если надо выделить препятствия в целом меше.
Есть какой-то редактор, чтобы я визуально увидел как делается разметка коллижн геометрии?
2) Если выделять в группы то как определять высоту? Стенки, лестницы и т.п. разной же высоты.

Pushkoff
Я этот способ немного по другому понял...
Высота препятствия кратна тому числу через какое расстояние пускаешь луч. Если луч найдет просвет, то возвращаемся к предыдущему и пускаем луч от точки пуска в сторону пола. При пересечении с полом получим точку пересечения. Считая длину луча от точки пуска до точки пересечения получаем высоту препятствия. 

XunterПостоялецwww21 июня 201023:43#31
Digan
> Xunter, физический движок пока не использую. Физика минимальна -столкновение с
> полигонами и гравитация.
> Как-то можно это реализовать без физ движка?
посмотри bullet - в нем есть пример Collision Interfacing Demo - collision detection без динамики - он всё-равно нужен.
>Как выделить препятствия если они являются частью статической геометрии?
препятствия это отдельная collision геометрия - она намного менее детализирована по сравнению с видимой.
экспортить можно через колладу, или плагины для майи/макса. либо свой редактор.
прямо отдельно: эта геометрия - лестницы, эта геометрия - заборы. путем выставления флагов колижн геометрии.
рейкаст видимой геометрии - совсем неправильное решение. забор может быть из всяких досок - кирпичей - хлама, а
колижн геометрия - коробка.
DiganПостоялецwww22 июня 20106:33#32
Теперь ясно. Спасибо.

Тут возникает проблема посерьезней.

Получается каждая коллижн геометрия это по сути новый нод. А при повышении количества нод неизбежно падает FPS.
Если работать с мешбуферами и пихать вершины в одну ноду пока количество вершин в ноде не достигнет максимального, то я не смогу управлять отдельными объектами.

Как-то можно это оптимизировать? Пока помогает только VBO...

XunterПостоялецwww22 июня 201012:40#33
Digan
> Получается каждая коллижн геометрия это по сути новый нод. А при повышении
> количества нод неизбежно падает FPS.
какие ноды? будет у тебя btCollisionWorld или NxScene - в них всё относящееся к collision, от них результаты рейкаста будешь спрашивать. они отдельно от графики.
DiganПостоялецwww1 июля 20102:48#34
Спасибо за подсказку, но все-таки я решил пока обойтись без спец. колижн геометрии и разметки.

Думаю попробывать организовать карабканье на основе вот этого:
Изображение
То есть рейкаст делаю вертикально перед персонажем. Первое пересечение луча с полигоном даст высоту препятствия.
Для отладки, как видно на скрине, вывожу эту величину в консоль. Сам луч визуально показан зеленой линией.

Пока вижу два основных условия, чтобы этот способ хорошо работал:
1) Нужен еще один луч, чтобы проверять препятствия над головой.
2) Поверхность препятствия должна быть относительно ровной, чтобы пересечение не произошло раньше чем нужно.

Хотелось бы узнать у более опытных людей. Какие еще недостатки вы видите в этом методе?

PushkoffУдалёнwww1 июля 20103:16#35
Digan
на тонких препятствиях проверял?? мне кажется тут понадобится дополнительная геометрия...
ну и колижн геометрия имеет меньше полигонов, из-за чего рейкаст будет намного проще...
PushkoffУдалёнwww1 июля 20103:20#36
Digan
> То есть рейкаст делаю вертикально перед персонажем.
с какой высоты ты пускаешь луч? может не всегда работать, если в стене есть окно, а луч упрется в верх стены...
ZПостоялецwww1 июля 201013:00#37
Не надо лучи, надо сразу коробочками или цилиндрами тестить.
Т.е. сделать функцию типа "Вот тебе коробка/цилиндр, скажи мне  насколько со всех сторон в нее попадает геометрия уровня". Или на первое время "Попадает ли вообще геометрия уровня в".
Таким образом все действия героя можно чекать - сначала на скок (тест пръжка, т.е. цилиндр героя + въсота скока) + тест можем ли схватится. Для етого, нужно собрать геометрию там где будем хвататся и найти есть ли ребра, за которъе ухватится можно.
Тест можно ли залезть (как и само действие) - отдельно? Или просто ухватится нельзя?

Задачу решить без разметок приятно, так как можно делать арт не заморачиваясь И отдать решение, где можно карабкатся и где нет глазу игрока - он ето может делать хорошо.

Подитожим - пиши функцию, которая собирают все полики в обьеме (бокс/цилиндр) мира, которъе с ним пересекаются. Потом етой функцией тестиш возможность пръжка и вожможность перелезания. И захватъвания - если геометрия пересечения с обьемом есть - возвращяеш ее, въделяеш горизонтальнъе/вертикальнъе, исщеш между ними ребра для захвата.
И соответно запускаеш ето несколько раз, для пръжков разной въсотъ.
climbing test | Определение высоты

DiganПостоялецwww2 июля 20102:53#38
Pushkoff, Да проверял на тонких. Луч идет прямо от уровня стопы.
Есть лестница. На ней тест хорошо проходит.
Для полного теста мне не хватает нужной анимации :(
Изображение


Z, мне ваш вариант не очень понятен, но мне кажется он довольно сложен в реализации и ресурсов требует поболее.

PushkoffУдалёнwww2 июля 20103:15#39
Digan
> он довольно сложен в реализации и ресурсов требует поболее.
глюков в его варианте будет в 100500 раз меньше, он намного проще в реализации...
ZПостоялецwww2 июля 201015:11#40
Digan
Можеш на первое время заменить тест бокса, тестом множеством лучей. Т.е. снаружи тест как бокс, а внутри лучи по циклу - для лов-поли геометрии прокатит.
А идея моего варианта вообще очень прямая - тест на пръжок, тест на предмет есть ли за что ухватится и потом тест есть ли куда залезть по уже въчесленной въсоте захвата.
PushkoffУдалёнwww3 июля 20101:55#41
Z
боксы у вас представлены как OBB или меш??
DiganПостоялецwww3 июля 20102:33#42
Z
А не дорого ли по ресурсам постоянно перебирать полигоны в боксе?
И еще такая деталь -получается полигоны должны быть строго вертикальны и горизонтальны, чтобы определялись грани для зацепления. А если определять подходит ли угол наклона это еще накладней...
RmzVoidПостоялецwww3 июля 20106:39#43
Z норм метод предложил.

По сути как я понял, он предлагает для персонажа помимо боундин бокса описать еще дополнительные объемы - для места где можно зацепиться, для места куда можно прыгнуть и для места на какую высоку можно прыгнуть. Эти объемы всегда будут расположены на одном месте относительно игрока. И достаточно проверять окружающюу геометрию на пересечение с этим объемом.

ZПостоялецwww3 июля 201020:16#44
Pushkoff
> боксы у вас представлены как OBB или меш??
У нас такого нет, но я бъ делал OBB-ами.

Digan
> А не дорого ли по ресурсам постоянно перебирать полигоны в боксе?
А не дороже переборки для теста с лучом.

Digan
> получается полигоны должны быть строго вертикальны и горизонтальны, чтобы
> определялись грани для зацепления
Да нет, почему. Просто тест дает список полигонов, которъе внутри бокса. Убираем вертикальнъе, остальнъе тестим - достаточно ли хорош наклон (чтобъ туда залезть) или нет. Если да, то смотрим на самъй близкий едж полика.

Страницы: 1 2 3

/ Форум / Программирование игр / Общее

Тема в архиве.

2001—2017 © GameDev.ru — Разработка игр