Кто хотя бы раз играл в TcX AoS, тот, скорее всего, помнит, что все движущиеся объекты детонируют / отскакивают от / упираются в разрушаемые объекты (далее "декорации"), каждый из которых воспринимается физическим движком карты как куб (имеет collision box в форме куба).
Снаряды отражаются от верхней и боковых поверхностей декораций, игроки могут ходить по верхней поверхности и упираются в боковые. На карте нет ни одной декорации, нижняя поверхность collision box которой не погружена в террейн целиком, так что можно предположить, что нижняя поверхность попросту не обсчитывается физической моделью.
Из всего этого я могу сделать вывод, что в каждой декорации дополнительно к её координатам хранится только длинна стороны её collision box (вернее, её половина), поскольку коллизия каждой декорации ориентирована строго в соответствии с направлением координатных осей. Её вполне можно задавать в рантайме посредством void SetDestructableOccluderHeight(destructable d, float height) и, соответственно, узнавать с помощью float GetDestructableOccluderHeight(destructable d), здесь всё более-менее ясно. Если у декорации нет коллизии, то в ней хранится 0.0.
Тем не менее, мне не вполне понятно, как именно реализован алгоритм обработки столкновений с декорациями. Неужели каждый тик движок ищет все декорации в радиусе sqrt(2)*(сторона самого большого collision box на карте)/2 от каждого физического объекта?

Моё предположение:
При старте игры создаётся квадратный rect с длинной стороны, равной длинне стороны самого большого collision box на карте, который через void MoveRectTo(rect whichRect, float newCenterX, float newCenterY) двигается в координаты каждого следующего обсчитываемого физического объекта. После каждого передвижения rect происходит выбор в нём всех декораций и через поочерёдное сравнение координат проверяется, не ударился ли объект в ту или иную декорацию. Такой подход позволяет не париться с нахождением нормали к поверхности декорации, т.к. она всегда будет равна одному из базисных векторов (Ox, Oy, Oz, xO, yO, zO или i, j, k, -i, -j, -k, если угодно).
Если предположение верное, то вопрос вырождается в следующий:
"Насколько такой подход оптимален, какие ограничения он несёт и насколько тяжелее будет считать сферические, цилиндрические или капсульные коллизии?"

Принятый ответ

На карте нет ни одной декорации, нижняя поверхность collision box которой не погружена в террейн целиком, так что можно предположить, что нижняя поверхность попросту не обсчитывается физической моделью.
Из всего этого я могу сделать вывод, что в каждой декорации дополнительно к её координатам хранится только длинна стороны её collision box (вернее, её половина)
я уже точно не помню но как припомнил там суть что идёт евент входа в регион соответсвенно регион дефайнит ХУ оси и отдельно есть мин/макс екстенды этого объекта и поидеи всё. юнит входит в регион чекается где он. скорее всего в движке движения юнита есть "потолок" и "пол"
function Trig_Doodads_Actions takes nothing returns nothing
set ax=35
call CreateHWRectBR(-8174,-3900,-7914,-3639,1054,1679)
это я для теста делал т.е. по этому "в 3д" можно бегать (спиральная лестница)
if xux.hwmaxz!=0 and xux.hwmaxz-rr>xux.Zsize then//mhg>xux.Zsize then
это чек на сабж потолка
мне просто лень настраиваеть ворледитор и тулы что бы запустить АОС с той лестницей и сделать видео с демо.
с другой стороны возможно позже и сделаю.
система максимально простая что бы вц3 не обсирался там жасс и так еле дышит.
`
ОЖИДАНИЕ РЕКЛАМЫ...

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
2 комментария удалено
8
28
7 лет назад
Отредактирован Clamp
8
На карте нет ни одной декорации, нижняя поверхность collision box которой не погружена в террейн целиком, так что можно предположить, что нижняя поверхность попросту не обсчитывается физической моделью.
Из всего этого я могу сделать вывод, что в каждой декорации дополнительно к её координатам хранится только длинна стороны её collision box (вернее, её половина)
я уже точно не помню но как припомнил там суть что идёт евент входа в регион соответсвенно регион дефайнит ХУ оси и отдельно есть мин/макс екстенды этого объекта и поидеи всё. юнит входит в регион чекается где он. скорее всего в движке движения юнита есть "потолок" и "пол"
function Trig_Doodads_Actions takes nothing returns nothing
set ax=35
call CreateHWRectBR(-8174,-3900,-7914,-3639,1054,1679)
это я для теста делал т.е. по этому "в 3д" можно бегать (спиральная лестница)
if xux.hwmaxz!=0 and xux.hwmaxz-rr>xux.Zsize then//mhg>xux.Zsize then
это чек на сабж потолка
мне просто лень настраиваеть ворледитор и тулы что бы запустить АОС с той лестницей и сделать видео с демо.
с другой стороны возможно позже и сделаю.
система максимально простая что бы вц3 не обсирался там жасс и так еле дышит.
Принятый ответ
Этот комментарий удален
4
28
7 лет назад
4
ну и офк в отличие от чмошников которые накатывают бесполезные посты, сделал видео как и писал, притом мне пришлось запустить вин хр на вмке и там запустить мой сетап и смодифаить/забилдить карту. ну и потом уже на хост системе видео капчюр сделать.
0
30
7 лет назад
0
Toadcop, спасибо за разъяснения!
Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.