Как вычислить координаты многоугольного объекта и как с ними работать?

Question

[Игорь]

На данный момент работает такой код ,но он вычисляет для прямоугольного,что мне не подходит.

rock= document.all("rock"); //Цепляем  <img src="rock.SVG" >

function MuCoord(rock){
	coord=rock.getBoundingClientRect();

	return rockObj={
		top:coord.top,
		left:coord.left
	};

};

console.log(MuCoord(rock));

И как собственно вставить svg чтобы отображались его реальные координаты сторон.

В дальнейшем эти координаты хочу использовать для вычисления обработки события столкновения с другими объектами.

P.S.желательно конечно без библиотек

Comments

[Святослав Хусамов]

Что-то не понятно что вы хотите получить... Песочница есть?

Answer 1

[Kovalsky]

Я в принципе понял, чего вы хотите, но чтобы определиться с тем, как именно нужно решать эту проблему, сначала надо определиться с тем, что вы хотите на выходе получить. Вы уже выбрали формат и способ обработки координат? Как будет происходить обработка округлых фигур? Собираетесь обрабатывать только внешнюю часть фигур или внутренняя тоже нужна будет?

Comments

[Игорь]

1. что вы хотите на выходе получить.
//1.Чтобы персонаж прыгал на объект и там мог на нем ходить по заданным координатам

2.Вы уже выбрали формат и способ обработки координат?
//2.Да и он в коде показан

[Kovalsky]

Ну, я имел ввиду не такой выход, я имел ввиду в каком формате вы хотите координаты: просто массив точек или может быть массив функций, описывающих кривые из которых состоит объект, и соответствующие им диапазоны координат? Это важно.

Это ж не формат, то что у вас в коде, это был бы формат если бы мы искали координаты для вертикальных прямоугольников нулевой ширины. То что у вас написано, это, насколько я понял, левый и верхний отступы объекта rock от начала координат родительского элемента. Вы же хотите полноценные камни, не прямоугольные, правильно? Тогда какие камни вы хотите? Будут ли грани камней только отрезками или еще и кривыми? В первом случае вам придется собирать координаты вершин в массив, во втором придется делать то же самое, только для кривых придется брать точки из аппроксимации функций, описывающих эти кривые. Или как-то впиливать массив функций, описывающих все кривые в объекте, но тогда придется еще учитывать диапазоны, в которых эи функции будут актуальны.

[Игорь]

Никита Полевой: и вашем метод реализации не должен сильно грузить CPU так как там и без этого куча нагрузки)

[Kovalsky]

Ну, реализацию сначала надо придумать, а для этого надо знать исходные данные и условия, в том числе требования к игре, например какие будут камни и все такое.

Я предполагал что в основе метода будет лежать анализ SVG, осталось только придумать, как это делать.
Делать анализ на сервере? Тогда на странице можно и лучше для SVG использовать img, но придется где-то хранить инфу об анализе.
Делать анализ на клиенте? Тогда существует два варианта: а) создавать img, а потом AJAX-ом запрашивать .svg и анализировать его, б) создавать object и анализировать его. В первом случае минусом является двойная загрузка одного и того же файла, хоть и из кеша (если он включен на клиенте), во втором - object представляет из себя вложенный документ, при большом количестве подобных объектов производительность страницы может упасть.

Answer 2

[Павел Волынцев]

В твоём случае, как мне кажется, камень изображён в изометрии, то есть мы видим его фронтальную, боковую и верхнюю грань. Исходя из этого столкновение произойдёт не тогда, когда границы точно пересекутся, а при небольшом наложении.

Как то вот так:


Границы можно вычислять условно, упрощённо. Например, через параллелепипеды, а ещё проще через прямоугольники. Я бы сохранил координаты двух прямоугольников - который описывает фигуру снаружи и внутри и исходя из них делал вычисление пересечений.

Вот пример видео для иллюстрации пересечений объектов https://www.dropbox.com/s/so1j4p12f3awodd/rock_hit...

Comments

[Kovalsky]

Можно и так. Но тогда ему нужно будет свои SVG поправить: кадр (непосредственно блок внутри SVG документа) включает много пустого пространства. Если бы весь кадр был занят изображением, вариант Павла можно было бы применить прямо на лету, т.к. координаты считались бы тривиально вычислением ширины и высоты блока.

[Павел Волынцев]

Никита Полевой: наверное ещё важно, какие объекты собираются столкнуться. Если это нога мамонта, наступающая на камень, то прямоугольника будет достаточно.
Если объекты приблизительно равного размера, то возможно была бы уместнее специальная аппроксимация с помощью функции.
Если объект значительно меньше камня, например теннисный мяч, то тогда надо использовать всю мощь математики - посчитать огибающую кривую, вычислить нормаль в точке соприкосновения, учесть момент силы, инерцию и гравитацию и на основе этого рассчитать траекторию дальнейшего движения.

[Павел Волынцев]

Никита Полевой:
Вариант с объектами приблизительно равного размера и аппроксимацией на прямоугольники codepen.io/copist/pen/XdMWLy
Вариант с вычислением траектории и гравитацией codepen.io/ge1doot/pen/MypKyq, но со значительным упрощением - объекты имеют форму кругов