Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Ошибка вычисления поворотов объекта вокруг осей

Ошибка вычисления поворотов объекта вокруг осей

Страницы: 1 2 3 4 Следующая »
IsaevПостоялецwww9 июля 201818:52#0
В общем возникла проблема при визуализации
Где-то закралась логическая ошибка, но я не совсем понимаю где именно...

Возьмём, например, классический кубик Рубика 3х3х3
и будем следить только за правым верхним передним углом (RUF), допустим он имеет координаты (2, 2, 0)

Если мы делаем поворот R он переходит в позицию (2, 2, 2) и поворачивается вокруг оси X -> (90, 0, 0)

И я как бы был полностью уверен, что начальные/конечные координаты + вектор поворота вокруг осей должны однозначно определять положение кубика в пространстве...

Но, если мы из собранного положения делаем следующие повороты: (R B L F) см. gif снизу,
то наблюдаемый элемент возвращается в исходное положение, т.е. он никуда не переместился... теперь смотрим как меняется вектор поворота:
После хода R(+90 вокруг оси X) -> (90, 0, 0)
После хода B(+90 вокруг оси Z) -> (90, 0, 90)
После хода L(-90 вокруг оси X) -> (0, 0, 90)
После хода F(-90 вокруг оси Z) -> (0, 0, 0)

т.е. он не повернулся по моим расчётам, хотя на самом деле развернулся на месте по часовой стрелке
Изображение

В чём моя ошибка?

PS: чтобы не объяснять какая буква что значит, классический язык вращения кубика
Изображение

bykabakПостоялецwww9 июля 201819:10#1
По-моему , нужно каждой позиции для кубиков присвоить уникальный номер и отслеживать в какой позиции какой кубик находится. Т.е. после любого поворота грани нужно обновлять позиции кубикам которые участвовали в повороте.  Можно ещё определить для каждого кубика его поворот ( для углового кубика 3 позиции поворота, для кубика на грани 2 позиции поворота )
MikleМодераторwww9 июля 201819:10#2
Isaev
> В чём моя ошибка?
Ты не учитываешь, что после поворота следующий поворот - это уже поворот повёрнутого кубика. Считай повороты в локальный координатах.
После хода R(+90 вокруг оси X) -> (90, 0, 0) //пока верно
После хода B(+90 вокруг оси Z) -> (90, 0, 90) //тут кубик вращается вокруг своей предыдущей оси Y.
IsaevПостоялецwww9 июля 201820:32#3
Mikle
> Ты не учитываешь, что после поворота следующий поворот - это уже поворот
> повёрнутого кубика. Считай повороты в локальный координатах.
А на этом же примере можно подробно?

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

Правка: 9 июля 2018 20:35

IsaevПостоялецwww9 июля 201820:42#4
bykabak
> По-моему , нужно каждой позиции для кубиков присвоить уникальный номер и
> отслеживать в какой позиции какой кубик находится. Т.е. после любого поворота
> грани нужно обновлять позиции кубикам которые участвовали в повороте
Ну это естествено, оно так и есть

bykabak
> Можно ещё определить для каждого кубика его поворот ( для углового кубика 3
> позиции поворота, для кубика на грани 2 позиции поворота )
дополннительно? хорошо, вопрос остаётся как их просчитывать? в какой момент должен сработать этот триггер, который должен переключить позицию поворота с 0 на 1 или на 2?

MikleМодераторwww9 июля 201822:01#5
Isaev
Понимаешь... даже сама запись поворота, типа (90, 0, 90), не имеет смысла. Нельзя повернуть вокруг трёх осей одновременно, можно по очереди, но от порядка зависит результат.
Я бы ориентацию указанного кубика хранил не как набор углов, что бессмысленно, а как набор направлений - URF (Up, Right, Front), соответственно белый, красный и зелёный.
Далее простые преобразования, например, поворот вокруг оси X по ч.с. превращает U->B, B->D, D->F, F->U, L и R не трогает. То есть после этого поворота кубик из URF стал BRU, и так далее.
IsaevПостоялецwww9 июля 201822:20#6
Mikle
> Далее простые преобразования, например, поворот вокруг оси X по ч.с. превращает
> U->B, B->D, D->F, F->U, L и R не трогает.
хм... у меня в предыдущей версии так и было... и работало
я хранил куб как 54 наклейки и двигал их... в целях оптимизации и упрощения дальнейшей 3Д визуализации перешёл на модель из 26 кубиков. Работать стало в 2 раза быстрее, но повороты поломал) неужто необходимо вернуть всё назад? Или можно как-то 3Д логику адаптировать, не потеряв в производительности?

Правка: 9 июля 2018 22:37

bykabakПостоялецwww9 июля 201823:52#7
Isaev,
Поворот нужно фиксировать. Нужен ещё массив для каждой грани. Чтобы знать какой кубик на какой грани находится и какой стороной он повёрнут для каждой грани к которой он имеет отношение. Для углового кубика число граней три. Т.е. когда вращается конкретная грань в конкретную сторону угловым кубикам на этой вращающейся грани ( кроме новых позиций в массиве из 26 кубиков ) присваиваются их новые повороты для каждой грани на которой он находится. У каждого углового кубика есть 3 стороны и тебе нужно фиксировать какой именно стороной из 3-х кубик повёрнут на этих 3-г гранях ( по отношению к среднему кубику на грани, который определяет номер и цвет грани )

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

IsaevПостоялецwww10 июля 20180:44#8
bykabak это в принципе тоже самое, что Mikle написал в одной строке, только как-то запутаннее выражено :), но я понял, т.к. это уже делал, как и писал выше...

Я всё равно упёрся в то, что не понимаю для чего нужен вектор поворота для каждой грани 1 единственного объекта, чтобы знать его ориенацию в пространстве? Т.е. ориентация одного куба должна задаваться 18 координатами только поворотов(если нам интересен он со всех сторон)? Серьёзно?Это действительно нельзя задать проще?

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

Правка: 10 июля 2018 1:03

bykabakПостоялецwww10 июля 20181:26#9
Вектор поворота не нужен. Нужен массив int для граней. На грани 9 кубиков. ( на средних гранях 8 ).  Где конкретный индекс - конкретная позиция на грани. И в каждом элементе массива хранится номер стороны кубика.

Изображение

IsaevПостоялецwww10 июля 20182:23#10
bykabak
> Нужен массив int для граней.
Ещё раз: Был, стёрли его, не нужен. Ибо долго это. Другой вариант возможен?
bykabakПостоялецwww10 июля 20188:46#11
Это самый быстрый и удобный способ.

По-моему, хранить и анализировать углы поворота - вариант не лучше. Точно такой же, только выглядит иначе.

Всё что нужно для анализа, знать какой цвет кубика на какой грани находится + какой кубик на какой грани находится и в какой позиции.

Дело в том, что когда вы начнёте считать вектора и углы поворота, то они считаются во float или double, и будет набегать погрешность при повороте. Могут быть косяки при расчётах из-за этого.

Правка: 10 июля 2018 8:49

IsaevПостоялецwww10 июля 20189:00#12
Дело в том, что угол, как и ребро про поворотах не распадается, т.е. обход цветов остаётся одинаковым, потому следить нам нужно по сути только за одной из граней, а остальные вычислять. Нумеруем стороны 0,1,2 с обходом по часовой и следим только за 0. А для этого снова нужны только 3 числа и это хорошо!)

Правка: 10 июля 2018 10:09

MikleМодераторwww10 июля 20189:07#13
Isaev
> Т.е. ориентация одного куба должна задаваться 18 координатами только поворотов
Зачем вообще хранить информацию о кубиках, когда достаточно хранить информацию только о их гранях, а это 4 величины, цвет и 3D позиция, повороты тогда вообще не требуются. По-человечески понятнее позиция, как № стороны (их 6) и две координаты на стороне, но я бы хранил, скорее, x, y и z. Для фронтальной грани всего кубика координаты будут -1..1 по x и y и 2 по z. Для правой -1..1 по y и z и 2 по x, и т. д.

Правка:
Пока писал, ты сам примерно то же написал, только с привязкой к кубикам.

Правка: 10 июля 2018 9:08

IsaevПостоялецwww10 июля 201810:16#14
Mikle
> достаточно хранить информацию только о их гранях, а это 4 величины, цвет и 3D
> позиция, повороты тогда вообще не требуются.
а если куб строится не по сторонам, а как меш экспортируется из какого-то редактора? что я буду делать с информацией о гранях?
Страницы: 1 2 3 4 Следующая »

/ Форум / Программирование игр / Графика

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