Как в TcX у разрушаемых объектов реализован collision box?
Кто хотя бы раз играл в 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 не обсирался там жасс и так еле дышит.



Просмотров: 705

» Лучшие комментарии


quq_CCCP #1 - 9 месяцев назад 0
Хм, TCX же открыть и Toadcop онлайн бывает, что мешаело его спросить?
Начет производительности имхо это все очень тяжело, там же реализация собственного движения юнито и снарядов.
Clamp #3 - 9 месяцев назад (отредактировано ) 2
TCX же открыт
Если не найдётся ответа, то само собой, придётся открывать и искать этот момент. Не очень хотелось бы этим заниматься, так как манера написания кода в TcX, так скажем, довольно своеобразна, по крайней мере, на мой взгляд.
Поэтому надеюсь, что кто-нибудь разбирался в этом моменте или продумывал аналогичный алгоритм, который хорошо себя показал.

имхо
"Личное скромное мнение" - не очень точная мера производительности, кмк.

там же реализация собственного движения юнитов и снарядов
Я полагаю очевидным, что подобный вопрос мог возникнуть только при реализации "собственного движения снарядов".
quq_CCCP #4 - 9 месяцев назад (отредактировано ) 0
Clamp, ну может подумать как то использовать стандартное движение юнитов и снарядов? Или ты решил всех удивить?
Clamp #5 - 9 месяцев назад (отредактировано ) 0
Поскольку копаться в TcX особого желания не появилось, реализовал так, как описывал в вопросе, вроде как работает достаточно шустро. Также ради развлечения попробовал сферические и цилиндрические коллижнбоксы (благо алгоритмы получились очень схожие между собой), капсулы проверять не стал, но по моим прикидкам они будут примерно в полтора-два раза более тяжелыми для обработки.

Можно ещё подумать, как сохранить в декорации побольше значений (inb4: перехватом создания декораций и записью параметров в структуру), чтобы сделать коллижнбоксы не кубами, а параллелограммами с поворотами.
ZlaYa1000 #6 - 9 месяцев назад 2
хм, написал тоаду, он о писал что ресурс закрыт для комментирования. Я думаю точечные вопросы можно с автором тсх напрямую выяснить
Clamp #7 - 9 месяцев назад 0
ZlaYa1000, открыл ресурс, было бы интересно его комментарии увековечить на сайте, а не в личке =)
2 комментария удалено
Toadcop #10 - 9 месяцев назад (отредактировано ) 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 не обсирался там жасс и так еле дышит.
Это сообщение удалено
Toadcop #12 - 9 месяцев назад 4
ну и офк в отличие от чмошников которые накатывают бесполезные посты, сделал видео как и писал, притом мне пришлось запустить вин хр на вмке и там запустить мой сетап и смодифаить/забилдить карту. ну и потом уже на хост системе видео капчюр сделать.