Поворот группы предметов по вертикали как одного

тоесть если хотим поворачивать группу предметов по X, ихние углы "доворачиваем" по оси Z?

8 минут назад, Electr0 сказал:

не очень понимаю что это даст.., ты предлагаешь поворачивать обе оси сразу?

Я предлагаю поменять порядок расчёта. Пока не уверен, но он вполне может зависеть от порядка расчётов Rx, Ry и Rz отсюда https://en.wikipedia.org/wiki/Rotation_matrix#In_three_dimensions Получается - меняем при расчётах местами Rx, Ry и Rz, создавая нужную для поворота по этой оси иерархию и получаем правильный поворот.

дело в том что там менять ничего не нужно, он не используется даже в повороте углов

видишь сразу видно что не правильно доворачивает углы предметов, а само смещение центров предметов в пространстве обыгранно верно

обожаю работать с векторами:

перепробовал разные методы, но пока что не выходит: пробовал через функцию  поворот вектора в 3D матрице повернуть углы и по разному, и несколько сразу, итог один они куда-то не туда съезжают один хер. жаль нельзя показать геометрию всех предметов сразу (упираемся в лимит временных пропов отрисовки)

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

Делаю вектор АВ, затем поворотом получаю АС

После этого перемещаю второй объект в точку С и доворачиваю оба объекта на градус, на который был повёрнут АС. Получается вот такая шняга с разлётом объектов:

Как видим, один объект попал внутрь другого, в то время как они должны были прилегать друг к другу, без более тесных взаимоотношений 

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

Но у неё есть некоторое преимущество, пока не вкурил какое, но связано это с размерами объектов и векторами... Psycho (Shower Scene Theme).mp3 (можно заметить, что сейчас при переносе второй объект "вошёл" в первый на половину своего размера по ширине - как раз расстояние от пересечения осей объекта до его ближней точки к первому объекту). 

В общем, я решил быстренько проверить, что будет, если вектор АВ будет соединять "нулевые" точки объектов, а не пересечения осей объектов. Вот я провёл вектор АВ между нулевыми точками, повернул его, получив АС и уже переместил "нулевую" точку второго объекта в точку С:

Теперь беру и поворачиваю объект на тот же угол, что и вектор АС до этого (как раньше, короче). При этом "нулевые" точки объектов и пересечения осей расползаются, но так и должно быть - поворачиваем объекты мы ведь не вокруг "нулевых" точек (я тут градусы в скобках не поменял, должно быть уже 90;-45;0, накосячил):

Но зато что получилось - объекты не разлетелись!

Стало/Было

Расчёт "нулевых" точек

«Нулевая» точка - чтобы узнать её для объекта из восьми крайних точек объекта узнаётся наименьший вектор к нулевым координатам карты. (или просто используются координаты всех восьми точек, если есть, по ним наименьшая длина и вычисляется)

Вектор AB у первого объекта (жёлтый) самый маленький, поэтому В – «нулевая» точка для него.

Если таких четыре, то берётся точка с наименьшей аппликатой (значение по Z для карты).

AB=AC=AD=AE – при этом нулевой точкой выбирается B, так как она ниже всех расположена.

Если таких две – выбирается точка с наименьшей ординатой (значение по Y для карты)

AB=AC – выбирается В, так как у неё значение ординаты меньше.

Это конечно может работать если ты имеешь плотно собранную убегу, но в остальном не годится, ибо то тут то там будут вылезать не дочеты

4 минуты назад, Electr0 сказал:

Это конечно может работать если ты имеешь плотно собранную убегу, но в остальном не годится, ибо то тут то там будут вылезать не дочеты

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

42 минуты назад, KOllapsE сказал:

Но зато что получилось - объекты не разлетелись!

Стало/Было

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

Вы оба молодцы, нет, серьезно, очень круто.

Шкурка стоит выделки то?

На счет бета теста, будет  шикарно по времени (лично мне) в 00:00 по Пермски, на счёт дня пока хз.

Давно хочу себе мего дом в перевернутом виде (привет Заяц)  

@KOllapsE это не мой метод, это из разряда что не надо делать когда ты что-то разрабатываешь, потому что если была цель повернуть, нужно это повернуть, а если мы поворачиваем потом три часа считаем все багнутые предметы и фиксим их, это не идеально.., костыли это все, а представь какая нагрузка, ведь это все нужно предварительно расчитать перед тем как я смогу дать добро на групповое действие, ведь край объекта мог попасть туда куда ему не стоит попадать, лучше отложить поворот по X Z до лучших времен, самая главная проблема как повернуть эти оси в соотвествии с повернутой убегой, по крайней мерее по Y все идеально, и он куда более востребователен чем остальные

@Electr0, ну да, поворот по У - самый нужный. Я вот думаю, что это  может быть хорошей идеей - что-то делать с углами при других поворотах:

13 часа назад, Electr0 сказал:

тоесть если хотим поворачивать группу предметов по X, ихние углы "доворачиваем" по оси Z?

Просто добавлять углы не получится - мы не знаем, как повёрнут объект и можно вызвать gimble lock там, где его не было.

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

что-то мне говорит что от перемены мест слагаемых сумма не изменится..

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

4 часа назад, EibachSprings сказал:

Вы оба молодцы, нет, серьезно, очень круто.

Шкурка стоит выделки то?

 

На счет бета теста, будет  шикарно по времени (лично мне) в 00:00 по Пермски, на счёт дня пока хз.

 

Давно хочу себе мего дом в перевернутом виде (привет Заяц)  

тут чисто любительско-научный интерес как это сделать)

43 минуты назад, Electr0 сказал:

что-то мне говорит что от перемены мест слагаемых сумма не изменится..

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

Всё действительно происходило точно так же, только в другом порядке? Это же отлично! Это прямо указывает на gimble lock и что надо думать конкретно над ним  Можно сделать следующее: обнулили углы, до этого у объекта были углы (45; 67; 89). Потом высчитали, как он должен повернуться - (90; 67; 89) (или YAW тут использовать, если неправильно я посчитал), т.е. сам объект не поворачиваем, только держим в памяти значения углов.

Чтобы обойти "шарнирную ловушку", нужно грамотно использовать иерархию. Давай ещё раз глянем в видео (4:18), как там происходят повороты. Повороты по У там проходят идеально только в двух случаях - XYZ и ZYX. Смотрим дальше на другие повороты и выводим следующие рекомендации по поворотам:

Если поворачиваем по У, то делаем после поворота три изменения углов в таком порядке - XYZ или ZYX. (это надо сразу проверить, если поворачивать будет нормально, как и раньше, только тогда пробовать другие, чтобы не тратить зря время)

Если поворачиваем по Х, то делаем в таком - ZXY или YXZ. (0; 0; 89) → (90; 0; 89) → (90; 67; 89)

Если поворачиваем по Z, то в таком - XZY или YZX.

P.S. Если я нещадно туплю и не могу понять, что каждый раз используется одна иерархия, то надо узнать, какая она. Допустим, это XYZ. Тогда надо всегда сначала прибавлять Z, потом Y, потом X

1 час назад, Electr0 сказал:

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

Тут была надежда на то, что не будет скоса при повороте второго объекта, т.к. по другим осям в момент поворота ноль.

Кстати, такие повороты  "Если поворачиваем по Х, то делаем в таком - ZXY или YXZ. (0; 0; 89) → (90; 0; 89) → (90; 67; 89) можно смоделировать просто поворачивая объект в стройке по заданным углам. Действительно, если после поворота по Х не можешь правильно повернуть, допустим, по Z, то надо поменять порядок и сначала поворачивать по Z, чтобы в конце получить желаемый результат. Поменять порядок, в общем

что-то сложна D

Попробовал вертеть по Z симулируя повороты группы по X

вот оси центральные:

и вторая:

как видно они смотрят друг на друга

а вот что будет если я их поверну на -1 градус по оси z:

одна идет в одну сторону, другая в другую =D

как это обойти?

данные дверей после поворота:

как видно ось Y повернута.

EDIT:

с дверьми получилось так.

Обнулил углы дверей, повернул каждую на -2 по Z, далее если я их поверну по оси Y до того как на скринах выше, то получится такая же картина, однако если я поверну не просто по Y,  а через RotateYaw, то ситуация исправлена. Однако это касается только вертикальных дверей.

Знакомьтесь, это - Ящик! Ящик недавно увидел этот свет, поэтому у него все углы по нулям.

На следующем фото Ящик немного перебрал спиртного и завалился по оси Х

После такого, на следующий день, надо ли ему идти на работу или всё же можно дрыхнуть до обеда (повороты по осям Z или Y), он выберет только одно : D 

В общем, мы наблюдаем, что повороты по Z и Y свалились в одну ось, причём совпали по направлениям (это мы +90 по Х сделали). Если же сделаем -90 по Х, то они всё равно свалятся в одну ось, но уже будут поворачивать в разные стороны (!).

Если сначала повернуть по Y или Z, а потом поворачивать другие, то сваливания двух осей в одну уже не можем поймать. Делаем вывод - используется одна иерархия и она во всём виновата. Теперь смотрим на повороты в видео и видим, что так происходит только при иерархии YXZ.

Итог: надо бороться с алкоголизмом предметов : D. А если серьёзно, то повороты сначала по Z, потом Y, потом X не меняют конечного результата. Кругом пичалька. В общем, можно попробовать использовать повороты вокруг осей предметов (rotate YAW), но там может возникнуть та же проблема. Или узнать, где сидит эта иерархия (смотреть код поворотов) и при поворотах по другим осям менять иерархии - раз уж по Y сейчас всё нормально, то по другим тоже так можно.