3D Picture

Обсуждение вопросов, связанных с обработкой аудио и видео информации
Artem.spb

Activity Автор
professor
professor
Сообщения: 3391
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 49 раз
Поблагодарили: 172 раза
Контактная информация:

Re: 3D Picture

Сообщение Artem.spb »

alerm писал(а):Artem.spb, деталь с settranslation либо крутится как ненормальная, либо вращается относительно своего центра (в зависимости от Relative?), по другому у меня не получилось(
Крутится она как ненормальная как раз из-за относительного смещения: в случае "относительно" деталь вращается относительно своего текущего положения, т.е. угол становится всё больше и больше.
Но тут у программеров или баг, или недокументированная особенность: в одном случае деталь вращается вокруг своего центра, а во втором летает вокруг начала координат.
картинка на этом ролике:
https://yadi.sk/i/5a7OgxURt8TE2
dadreamer писал(а):
Artem.spb писал(а):Но повторюсь: я у себя никаких багов-артефактов не наблюдаю, ну если не считать, что я не понимаю, что нужно делать :)
цветная нога вполне корректно двигается с движением мышки (в пределах разумного), никуда не скачет, детали не убегают.
Проверял на LV15, win7 64, ноут без навороченной видяхи.
А если ЛКМ на сцене зажать, не глючит?
да, но не совсем.
Вот когда предыдущий пост писал, глюков не было, а теперь они появились, видны на том же видео.
Кстати, ещё одну особенность обнаружил, проверяя одно предположение: если вынести терминал 3D изображения за цикл, то картинка обновляется только при зажатой ЛКМ, т.е ваше предположение об отрисовке раньше времени вполне оправдывается, видео снимать уже не буду.
Сейчас на виртуалке проверил. Там глючит даже без нажатия ЛКМ, видимо, виной тому совсем скудные параметры гостевой системы. Думаю, если достаточно быстро отрисовывает, то глюков не видно, а если не очень - то они и видны как раз. Можно ли переработать цикл отрисовки, чтобы в нём не было очистки матрицы?
Ответ с ходу: не получится. детали нужно повернуть и сместить. Можно попробовать функции "set", но придётся переделывать математику: углы и смещения будут уже другими.
Возможен вариант, который лень проверять: подгружать детали из внешних файлов. В этом случае деталь в редакторе можно сразу расположить в нужном месте. Возможно, вращаться она будет относительно начала координат. Но это не поможет рисовать "стопу".
Artem.spb

Activity Автор
professor
professor
Сообщения: 3391
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 49 раз
Поблагодарили: 172 раза
Контактная информация:

Re: 3D Picture

Сообщение Artem.spb »

А за что мы "боремся", проблема-то в чём? то, что детали иногда мелькают не на своём месте, или что-то более серьёзное?
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: 3D Picture

Сообщение dadreamer »

Artem.spb писал(а):Крутится она как ненормальная как раз из-за относительного смещения: в случае "относительно" деталь вращается относительно своего текущего положения, т.е. угол становится всё больше и больше.
Но тут у программеров или баг, или недокументированная особенность: в одном случае деталь вращается вокруг своего центра, а во втором летает вокруг начала координат.
Так изначально все детали в одной точке созданы (геометрический центр сцены). ̶О̶т̶н̶о̶с̶и̶т̶е̶л̶ь̶н̶о̶е̶ ̶п̶е̶р̶е̶м̶е̶щ̶е̶н̶и̶е̶ ̶-̶ ̶о̶т̶н̶о̶с̶и̶т̶е̶л̶ь̶н̶о̶ ̶т̶е̶к̶у̶щ̶е̶г̶о̶ ̶ц̶е̶н̶т̶р̶а̶ ̶о̶б̶ъ̶е̶к̶т̶а̶.̶ ̶А̶б̶с̶о̶л̶ю̶т̶н̶о̶е̶ ̶-̶ ̶о̶т̶н̶о̶с̶и̶т̶е̶л̶ь̶н̶о̶ ̶и̶с̶х̶о̶д̶н̶о̶г̶о̶ ̶ц̶е̶н̶т̶р̶а̶ ̶(̶н̶а̶ч̶а̶л̶о̶ ̶к̶о̶о̶р̶д̶и̶н̶а̶т̶)̶.̶
В̶е̶р̶н̶а̶я̶ ̶л̶о̶г̶и̶к̶а̶?̶ (upd: наоборот; пояснения см. ниже)
2016-07-08_23-59-41.jpg
2016-07-09_0-00-19.jpg
Artem.spb писал(а):Кстати, ещё одну особенность обнаружил, проверяя одно предположение: если вынести терминал 3D изображения за цикл, то картинка обновляется только при зажатой ЛКМ
По идее контрол сцены должен всегда в цикле быть. Ну, то есть, на него ref на каждой итерации должен заходить. Это, собственно, и обновляет сцену. В противном случае ref может быть неявно финализирован. Правда вряд ли :labview: будет закрывать ссылки сам во время работы :vi: .
Artem.spb писал(а):Ответ с ходу: не получится. детали нужно повернуть и сместить. Можно попробовать функции "set", но придётся переделывать математику: углы и смещения будут уже другими.
А если поворачивать и смещать всё время относительно текущего положения... Допустим, генерируются на каждой итерации приращения координат и углов и объекты смещаются на эти приращения. А не так, чтобы каждый раз из нуля смещать.
Artem.spb писал(а):А за что мы "боремся", проблема-то в чём? то, что детали иногда мелькают не на своём месте, или что-то более серьёзное?
Я бы и за это поборолся :D Ибо выглядит некрасиво, даже стыдно такое кому-то показывать. Однако, у меня в программах такого не наблюдалось.
Artem.spb писал(а):картинка на этом ролике:
Вот, у меня такие же глюки, как на видео. По поводу обновления. Все эти :vi: для смещений не реентерантные. Когда мы их открываем, :labview: начинает обновлять их панели, на это тратится время и ресурсы (UI поток один же). Соответственно, на основную часть программы остаётся меньше ресурсов, вот и лагает сильнее.
Последний раз редактировалось dadreamer 16 июл 2016, 15:04, всего редактировалось 1 раз.
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: 3D Picture

Сообщение dadreamer »

Вот, ради интереса вытащил за цикл инструменты Clear Transformation и Translate Object для объекта "стопа". В цикле остался только Rotate Y Axis (Relative?=True). Подаваемые на него градусы - это контрол s? t:f. На видео видно, что вращается объект синхронно со значением генерируемого градуса. Чем больше градус - тем сильнее смещение. Отсюда и непостоянство скорости вращения. В общем, моя мысль такова, что нужно все очистки матриц и однократные смещения вынести за цикл, в цикле оставить только относительные смещения, и для них переработать арифметику (подогнать приращения) так, чтобы объекты визуально составляли единое целое. Например, если для этой вот "стопы" градус будет в диапазоне, скажем, [-15...15], то она должна будет ходить туда-сюда вместе с "ногой", а не вращаться вокруг оси. Ну и так далее.
upd: [-15...15] даже многовато, где-то [-3..3] нужно, чтоб совпало.
Вложения
capture-1.rar
относительное вращение "стопы"
(1.42 МБ) 231 скачивание
Artem.spb

Activity Автор
professor
professor
Сообщения: 3391
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 49 раз
Поблагодарили: 172 раза
Контактная информация:

Re: 3D Picture

Сообщение Artem.spb »

dadreamer писал(а):
Artem.spb писал(а):Крутится она как ненормальная как раз из-за относительного смещения: в случае "относительно" деталь вращается относительно своего текущего положения, т.е. угол становится всё больше и больше.
Но тут у программеров или баг, или недокументированная особенность: в одном случае деталь вращается вокруг своего центра, а во втором летает вокруг начала координат.
Так изначально все детали в одной точке созданы (геометрический центр сцены). Относительное перемещение - относительно текущего центра объекта. Абсолютное - относительно исходного центра (начало координат). Верная логика?
2016-07-08_23-59-41.jpg
2016-07-09_0-00-19.jpg
У меня логика такая:
- абсолютно: сказали -10 градусов, -10 градусов и стало.
- относительно: сказали -10 градусов, угол расположения объекта уменьшился на 10 относительно текущего угла.
В целом в системе так и происходит, но только центр вращения располагается в разных точках, что по-моему не логично.
и вот это:
Относительное перемещение - относительно текущего центра объекта. Абсолютное - относительно исходного центра (начало координат). Верная логика?
как раз не подтверждается, а происходит наоборот: при абсолютном вращении деталь вращается относительно своего центра (если деталь предварительно сместить, то всё равно будет вращаться вокруг себя), а при относительном смещении будет "летать" вокруг начала координат. Т.е. если не очищать угол перед вызовом "относительно", то деталь будет летать по кругу вокруг 00.

Artem.spb писал(а):Кстати, ещё одну особенность обнаружил, проверяя одно предположение: если вынести терминал 3D изображения за цикл, то картинка обновляется только при зажатой ЛКМ
По идее контрол сцены должен всегда в цикле быть. Ну, то есть, на него ref на каждой итерации должен заходить. Это, собственно, и обновляет сцену. В противном случае ref может быть неявно финализирован. Правда вряд ли :labview: будет закрывать ссылки сам во время работы :vi: .
Ну вот в вижине это совсем не обязательно, тут что-то среднее. Всё же контрол обновляет картинку, если к нему "обратиться". При вращении сцены мышью мы как раз и обращаемся к нему.
Artem.spb писал(а):Ответ с ходу: не получится. детали нужно повернуть и сместить. Можно попробовать функции "set", но придётся переделывать математику: углы и смещения будут уже другими.
А если поворачивать и смещать всё время относительно текущего положения... Допустим, генерируются на каждой итерации приращения координат и углов и объекты смещаются на эти приращения. А не так, чтобы каждый раз из нуля смещать.
я же говорю (или забыл сказать?): можно попробовать, только вопрос в серьёзной переработке математики. Впрочем, конкретно тут всё может и получиться: если бёдра и голени корректно сместить до цикла так, чтобы они концами "втыкались" в одну из осей (на которой будут располагаться колени), то вращение как раз будет происходить вокруг "колена". Стопы в принципе тоже должны без проблем летать вокруг колена. Так что конкретно тут идея вполне хорошая. А вот более сложные модели без дополнительного смещения после поворота не обойдутся.
Artem.spb писал(а):А за что мы "боремся", проблема-то в чём? то, что детали иногда мелькают не на своём месте, или что-то более серьёзное?
Я бы и за это поборолся :D Ибо выглядит некрасиво, даже стыдно такое кому-то показывать. Однако, у меня в программах такого не наблюдалось.
Отчасти согласен, но решил уточнить у автора вопроса, туда ли мы копаем.
Ну и ещё по поводу несогласия: а зачем? сама идея "ЗАТЕМ ВОДИ МЫШКОЙ ЗА СИНИМ "ДАТЧИКОМ" НА БЕЛОЙ НОГЕ" не функциональна. Если повернуть модель "лицом" к себе, или ещё как-то развернуть, то все вычисления положения курсора становятся некорректными. Ну и даже без поворота сцены я не могу получить положительную оценку, всегда "ужасно", потому и говорю, что не понимаю, что надо делать в программе пользователю.
Аватара пользователя
alerm

Activity
leader
leader
Сообщения: 682
Зарегистрирован: 02 май 2012, 21:28
Награды: 1
Версия LabVIEW: 20
Благодарил (а): 57 раз
Поблагодарили: 9 раз
Контактная информация:

Re: 3D Picture

Сообщение alerm »

Artem.spb, не-не, я же писал выше, что эта программа отличается от рабочей, так сказать. У меня на тот момент не было датчика на руках, вот и пришлось сделать такое извращение, чтобы показать, что есть "идеальное" движение (белая нога) и реальное, данные на которое идут извне.
Сейчас в программе разноцветная нога привязана к движению датчика (по одной оси, по Y). Но проблема в прорисовке есть и той и в этой программах. Изначально я хотел узнать, можно ли как-то вынести многое за пределы цикла, особенно очистку положения.

Artem.spb, dadreamer, спасибо вам за участие. Я так понимаю самый оптимальный вариант пока такой:
1) вынести изменение положения за цикл;
2) ввести сдвиговые регистры для углов;
3) при каждой итерации производить вычитание из пришедшего значения угла предыдущее;
4) задать перед циклом одинаковый угол вращения и значение сдвигового регистра;
5) профит?
Untitled 1 %287%29.vi
lv2013
(501.04 КБ) 225 скачиваний
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: 3D Picture

Сообщение dadreamer »

alerm, во, замечательно мысль уловили! :super: Теперь у меня ничего не глючит, всё чётко отрисовывается в любом положении. Есть небольшой нюанс: красно-фиолетовая нога порой дёргается, когда по ней мышью водишь. Ну, тут надо просто подрегулировать обработку движения мыши по сцене.
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: 3D Picture

Сообщение dadreamer »

Artem.spb писал(а):
dadreamer писал(а):
Artem.spb писал(а):Крутится она как ненормальная как раз из-за относительного смещения: в случае "относительно" деталь вращается относительно своего текущего положения, т.е. угол становится всё больше и больше.
Но тут у программеров или баг, или недокументированная особенность: в одном случае деталь вращается вокруг своего центра, а во втором летает вокруг начала координат.
Так изначально все детали в одной точке созданы (геометрический центр сцены). Относительное перемещение - относительно текущего центра объекта. Абсолютное - относительно исходного центра (начало координат). Верная логика?
Вложение 2016-07-08_23-59-41.jpg больше недоступно
Вложение 2016-07-09_0-00-19.jpg больше недоступно
У меня логика такая:
- абсолютно: сказали -10 градусов, -10 градусов и стало.
- относительно: сказали -10 градусов, угол расположения объекта уменьшился на 10 относительно текущего угла.
В целом в системе так и происходит, но только центр вращения располагается в разных точках, что по-моему не логично.
и вот это:
Относительное перемещение - относительно текущего центра объекта. Абсолютное - относительно исходного центра (начало координат). Верная логика?
как раз не подтверждается, а происходит наоборот: при абсолютном вращении деталь вращается относительно своего центра (если деталь предварительно сместить, то всё равно будет вращаться вокруг себя), а при относительном смещении будет "летать" вокруг начала координат. Т.е. если не очищать угол перед вызовом "относительно", то деталь будет летать по кругу вокруг 00.
Сейчас постарался более детально вникнуть. Тут некоторая путаница в терминологии, заложенной NI для инструментов Rotate X/Y/Z Axis. Если провести пару тестов и посмотреть картинки (иконки) на :vi: , то станет понятно, что операция "повернуть ось" - это по сути поворот двух других осей по отношению к указанной. Вход Relative? в данном случае - это вопрос "поворачиваем относительно оси центра координат (0,0,0) или нет?". То есть, нет двух вариантов-антонимов "относительный поворот" / "абсолютный поворот". Либо вращаем вокруг центральной оси, либо вокруг оси самого объекта (где бы он ни находился в результате операций транслирования). Но, я думаю, вы это итак поняли без меня. Я лишь поподробнее расписал. И я не думаю, что это баг или фича. Просто надо было по другому обозвать вход :vi: , и только. Вот пример, по которому можно изучить, как работает трансляция и поворот.
Axis_Rotation_Test.rar
lv2011
(29.98 КБ) 213 скачиваний
Artem.spb писал(а):Ну вот в вижине это совсем не обязательно, тут что-то среднее. Всё же контрол обновляет картинку, если к нему "обратиться". При вращении сцены мышью мы как раз и обращаемся к нему.
У этих двух графических движков совершенно разные механизмы работы. Провод IMAQ Image - это не ссылка (reference), а указатель на приватную структуру с данными, в которой, помимо служебной инфы, хранятся также сами пиксельные данные. Если интересно, сделайте Flatten To String на IMAQ-проводе. Так что, даже если сделать несколько копий IMAQ на БД, все они будут указывать на одну и ту же структуру. Поэтому, стоит один раз завести IMAQ-провод на Vision контрол, все последующие операции на этом проводе будут отражаться на контроле. Ссылка (reference) - совсем другое дело. Это не указатель, а magic cookie, т.е. индекс объекта во внутренней таблице cookie jar. Чтобы объект отобразился в контроле, его надо туда завести, т.е. присвоить контролу этот cookie, по которому графический движок считает данные и отобразит. Очевидно, процесс автообновления затратен, потому чтение данных выполняется только при явном присвоении cookie или при манипуляциях с 3D Picture Control, когда движок вынужден перечитывать инфу (мало ли, может мы не просто кликнули, а переместили объекты на сцене, следовательно, нужно отрисовать по-новой). Очевидно, что движок читает инфу согласно сохранённому cookie (который записался, когда мы первый раз завели ref на контрол).
Artem.spb

Activity Автор
professor
professor
Сообщения: 3391
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 49 раз
Поблагодарили: 172 раза
Контактная информация:

Re: 3D Picture

Сообщение Artem.spb »

dadreamer писал(а):Сейчас постарался более детально вникнуть. Тут некоторая путаница в терминологии, заложенной NI для инструментов Rotate X/Y/Z Axis. Если провести пару тестов и посмотреть картинки (иконки) на :vi: , то станет понятно, что операция "повернуть ось" - это по сути поворот двух других осей по отношению к указанной.
Таки нет, никакой путаницы в терминологии, никто оси не вращает. Объект вращается вокруг выбранной оси.
Вход Relative? в данном случае - это вопрос "поворачиваем относительно оси центра координат (0,0,0) или нет?". То есть, нет двух вариантов-антонимов "относительный поворот" / "абсолютный поворот". Либо вращаем вокруг центральной оси, либо вокруг оси самого объекта (где бы он ни находился в результате операций транслирования).
И опять нет. Вы невнимательны даже к своему примеру.
Во-первых, если заглянуть внутрь функции Rotate X/Y/Z Axis, то там можно обнаружить вызов одной из двух: Set roration и Rotate, которые и выполняют относительное или абсолютное вращение (со смещением то же самое). И в описании этих функций ничего про смену точки отсчёта.
То есть, нет двух вариантов-антонимов "относительный поворот" / "абсолютный поворот".
Очень даже есть: в абсолютном случае при сохранении величины угла смещения объект остаётся на своём месте, сколько бы я ни жал на кнопку поворота. Сказали ему 5 градусов, он в 5 и повернулся (вокруг своего центра).
А если включить относительный поворот, то при каждом вызове функции объект будет смещаться на 5 градусов из текущего положения, и при этом поворот осуществляется относительно начала координат.
Даже если принять вашу точку зрения, что абсолютно - это объект сам по себе, а относительно - это относительно начала координат, то во втором случае всё равно присутствует дополнительное действие. Точнее, доп действие присутствует в функции "абсолютно": в описании так и сказано: "Clears any rotations previously applied to an object ". А вот относительное смещение не возвращает объект в начало координат.
Artem.spb писал(а):Ну вот в вижине это совсем не обязательно, тут что-то среднее. Всё же контрол обновляет картинку, если к нему "обратиться". При вращении сцены мышью мы как раз и обращаемся к нему.
У этих двух графических движков совершенно разные механизмы работы. Провод IMAQ Image - это не ссылка (reference), а указатель на приватную структуру с данными.
ссылка / reference / указатель - слишком тонкие различия.
Механику и того и другого я понимаю. Вопрос и моё замечание лишь в том, что сцена обновляется в любом случае, а перерисовывается не всегда. Возможно, я выразился не в тему.
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: 3D Picture

Сообщение dadreamer »

Artem.spb писал(а):Таки нет, никакой путаницы в терминологии, никто оси не вращает. Объект вращается вокруг выбранной оси.
Считайте, что объект вращается, если вам так легче. Оси вообще штука вспомогательная и реально не существующая. Но они сильно облегчают понимание. Я не зря предложил представить (или нарисовать программно) прямоугольную систему координат (СК). Почему - позже будет понятно.
Artem.spb писал(а):И опять нет. Вы невнимательны даже к своему примеру.
Где именно я невнимателен? Мой пример как раз демонстрирует работу поворота по Y и расположение объекта в СК сцены до и после этой операции. Если бы вы не отвергли сходу моё высказывание, то мне не пришлось бы отвечать на следующие две-три цитаты.
Artem.spb писал(а):Во-первых, если заглянуть внутрь функции Rotate X/Y/Z Axis, то там можно обнаружить вызов одной из двух: Set roration и Rotate, которые и выполняют относительное или абсолютное вращение (со смещением то же самое). И в описании этих функций ничего про смену точки отсчёта.
СК сцены не меняет своего положения при этих операциях. СК объекта - да, и именно её мы перемещаем (вместе с объектом, т.к. объект жёстко привязан к своей СК) в процессе транслирования и поворота. 3D Picture Control вообще слабо документирован, очень многих вещей просто нет в официальной справке. Не стоит обращать на это внимание.
Artem.spb писал(а):То есть, нет двух вариантов-антонимов "относительный поворот" / "абсолютный поворот".
Очень даже есть: в абсолютном случае при сохранении величины угла смещения объект остаётся на своём месте, сколько бы я ни жал на кнопку поворота. Сказали ему 5 градусов, он в 5 и повернулся (вокруг своего центра).
А если включить относительный поворот, то при каждом вызове функции объект будет смещаться на 5 градусов из текущего положения, и при этом поворот осуществляется относительно начала координат.
Повторюсь, что не считаю эти два режима поворота противоположными друг другу. Есть "относительный поворот" - с оглядкой на СК сцены и с учётом СК объекта, и "не относительный поворот" (пусть будет "абсолютный", раз так) - только с учётом СК объекта; СК сцены не принимает участия.
Artem.spb писал(а):Даже если принять вашу точку зрения, что абсолютно - это объект сам по себе, а относительно - это относительно начала координат, то во втором случае всё равно присутствует дополнительное действие. Точнее, доп действие присутствует в функции "абсолютно": в описании так и сказано: "Clears any rotations previously applied to an object". А вот относительное смещение не возвращает объект в начало координат.
А что будет, если не очищать матрицу преобразований? Получится "относительный поворот", только без сдвига объекта по осям СК сцены. Смысл создавать два (почти) одинаковых метода? Проще пользователю самому реализовать такой подход - сдвигаем объект в (0,0,0), крутим на нужный угол, сдвигаем обратно. Подозреваю, что именно такой метод вы бы хотели видеть в качестве "относительного поворота". Но это чуть иначе работает.

Вообще, прежде чем сходу отметать мои высказывания, стоило бы почитать матчасть. Начать можно, например, отсюда:
1. OpenGL Transformation
2. OpenGL Angles to Axes
3. Народный учебник по OpenGL. Урок 4. Вращение полигонов
4. Coordinate Systems in OpenGL
5. Введение в OpenGL
6. OpenGL: преобразование координат
И так далее. Плюс вот такая весьма неплохая книжка: Компьютерная графика и стандарт OpenGL. 3-е издание. Дональд Херн, М. Паулин Бейкер
Итак, что мы имеем в очень кратком пересказе. Из [3] - наглядное представление поворота:
Чтобы лучше понять вращения по осям X, Y и Z я объясню это на примерах.

Ось X - предположим Вы работаете за токарным станком. Заготовка перемещается слева направо (также как ось X в OpenGL). Заготовка вращается вокруг оси X. Также мы вращаем что-то вокруг оси X в OpenGL.

Ось Y- Представьте что Вы стоите посреди поля. Огромный торнадо приближается к Вам. Центр торнадо перемещается от земли в небо (верх и низ, подобно оси Y в OpenGL). Предметы захваченные торнадо кружаться вдоль оси Y (центр торнадо) слева направо или справо налево. Когда вы вращаете что-то вокруг оси Y в OpenGL, это что-то будет вращаться также.

Ось Z - Вы смотрите на переднюю часть вентилятора. Передняя часть вентилятора ближе к Вам, а дальняя часть дальше от Вас (также как ось Z в OpenGL). Лопасти вентилятора вращаются вдоль оси Z (центр вентилятора) по часовой или против часовой стрелки. Когда Вы вращаете что-то вокруг оси Z в OpenGL, это что-то будет вращаться также.
Из [4] узнаём, какие существуют системы координат (СК) в OpenGL:
There are multiple coordinate Systems involved in 3D Graphics:
  • ● Object Space
  • ● World Space (aka Model Space)
  • ● Camera Space (aka Eye Space or View Space)
  • ● Screen Space (aka Clip Space)
[/i][/color]
То есть, имеем 4 основных СК: СК объекта (локальную СК), СК сцены (СК модели) (мировую СК), СК камеры и оконную СК. Нас сейчас интересуют только первые две.
Из [1] понимаем, что OpenGL выполняет все преобразования с помощью матриц размерностью 4x4, и есть 4 основных типа таких матриц: GL_MODELVIEW, GL_PROJECTION, GL_TEXTURE и GL_COLOR. Именно первая отвечает за смещение (трансляцию), поворот, масштабирование как камеры, так и объектов на сцене, причём на каждый объект (помимо самой сцены) заводится отдельная матрица модели (ModelView). Есть и вот такая картинка, расшифровывающая назначение элементов матрицы:

Изображение

Получается, что первые три столбца определяют поворот вокруг осей X,Y и Z соответственно, а последний столбец содержит смещения по этим трём осям. В [2] приведена та же картинка, а также расписано, как рассчитываются элементы матрицы GL_MODELVIEW для конкретного угла поворота. Возьмём, например, ось Y, поскольку я её использовал в своём примере.

Изображение Изображение

Инфа эта вовсе не секретная. Вообще, проходится в технических ВУЗах на начальных курсах. Ну, и в интернете всё расписано.
Матрица поворота. Матрица поворота в трёхмерном пространстве
Теперь попробуем снова запустить пример Axis Rotation Test.vi в :labview: и посмотреть, какие получаются матрицы для "относительного" и "абсолютного" поворота. Сперва транслируем кубик на 3 единицы вдоль X, затем повернём на 15 градусов. Тип поворота регулируем кнопкой.

Небольшое примечание. :labview: даёт в явном виде просмотреть или изменить матрицу ModelView только для сцены. Аналогичные матрицы для объектов рассчитываются внутри движка, а снаружи можно "пощупать" только матрицу преобразований (Transformation Matrix). Однако, довольно просто получить из одного другое. Положим, A - матрица ModelView сцены, B - матрица преобразований объекта, C - матрица ModelView объекта. Справедливо такое выражение:
C = A x B
Отсюда можем получить при желании:
B = A^-1 x C
A = C x B^-1
И это действительно так. Матрицы преобразований не хранятся, а рассчитываются "на лету":

Код: Выделить всё

glMatrixMode(GL_PROJECTION)
glLoadMatrixd({2.41, 0, 0, 0, 0, 2.41, 0, 0, 0, 0, -1.00, -1, 0, 0, -2.00, 0})
glMatrixMode(GL_MODELVIEW)
glLoadMatrixd({-0.81, -0.36, 0.45, 0, 0.58, -0.51, 0.63, 0, 0, 0.77, 0.63, 0, 0, 0, -11.09, 1})
glLoadMatrixd({-0.81, -0.36, 0.45, 0, 0.58, -0.51, 0.63, 0, 0, 0.77, 0.63, 0, 0, 0, -11.09, 1})
Ну, то есть, сначала грузится матрица проекций, затем две матрицы моделей - одна для сцены, другая для объекта. Как видим, в самом начале, когда мы ещё не трогали объект, его матрица ModelView равна матрице сцены. Как только мы сдвинем объект с помощью трансляции или поворота, матрица ModelView объекта примет другие значения. Матрицы грузятся на каждой итерации рендеринга, т.о. постоянно обновляя все элементы 3D контрола.[/size]

Матрица преобразований для "абсолютного" поворота:
Absolute_Edit.jpg
На рисунке видно, что центр объекта действительно смещён на 3 единицы по X (последний столбец матрицы), а сам объект повёрнут на 15 градусов (первые три столбца матрицы содержат синус 15°, косинус 15° и т.д. согласно описанию выше).

Матрица преобразований для "относительного" поворота:
Relative_Edit.jpg
На этой картинке видим, что объект точно так же повёрнут на 15° (первые три столбца матрицы такие же, как в случае "абсолютного" поворота), однако центр объекта смещён и по X, и по Z, а смещения какие-то "странноватые". Откуда взялись эти смещения?
Вот отсюда:
X' = X*cos (a) + Z*sin (a)
Y' = Y
Z' = Z*cos (a) - X*sin (a)

Это не что иное, как координаты локальной СК при повороте относительно глобальной СК:
Описание направлений и поворотов в трёхмерном пространстве
По каким формулам вычислить новые координаты объекта в трёхмерном пространстве при относительном перемещении?
Аналогичные формулы выведены и для поворота в двумерном пространстве:
Поворот
Поворот плоскости и его матричное представление
Поворот осей координат
И в принципе это всё выглядит довольно логично. При "относительном" повороте мы учитываем значения, на которые уже смещён центр объекта (т.е., точка отсчёта локальной СК) по осям и по этим смещениям рассчитываем новые координаты центра объекта. При "абсолютном" повороте нам "по барабану", на какое расстояние от глобальной СК смещёна локальная СК:
X' = X
Y' = Y
Z' = Z

Для большей наглядности я переделал свой предыдущий пример Axis Rotation Test: воспроизведен механизм работы инструмента Rotate Y-axis.vi. Когда кнопка Native Rotation? не нажата, рассчитывается и составляется матрица преобразований (Transformation Matrix), после чего она применяется к объекту (кубику) на сцене через соответствующий Property Node. Если кнопка нажата, для поворота используется стандартный :vi: Rotate Y-axis.vi. На панель также выведено несколько матриц: матрица модели сцены (Scene ModelView Matrix), матрица проекций (Scene Projection Matrix), текущая матрица преобразований объекта (Object Transf. Matrix (native)) и матрица преобразований объекта (Object Transf. Matrix (own)), рассчитанная согласно вышеописанной логике (расчёт ведётся только при повороте). Также имеется индикатор Matrixes are equal, который загорается, когда обе матрицы преобразований (текущая и рассчитанная) равны. По индикатору можно понять, что рассчитанная матрица в точности равна той матрице, что применяет :vi: Rotate Y-axis.vi. Единственный нюанс, который для меня остался не совсем понятен: почему движок работает с числами двойной точности (double, 8 байт), а "наружу" (т.е., в :labview: ) отдаёт числа одинарной точности (float, single, 4 байта). Из-за такой вот нестыковки происходит серьёзная потеря точности, из-за чего, например, нельзя использовать машинный эпсилон.
Вложения
Axis Rotation Test.vi
lv2011
(26.6 КБ) 225 скачиваний
Artem.spb

Activity Автор
professor
professor
Сообщения: 3391
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 49 раз
Поблагодарили: 172 раза
Контактная информация:

Re: 3D Picture

Сообщение Artem.spb »

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

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: 3D Picture

Сообщение dadreamer »

Artem.spb писал(а):Но вот я остаюсь при своём мнении, что есть путаница: получается, что если я хочу повернуть объект вокруг своей оси в определённое положение, мне надо или двигать его туда-сюда, или помнить его текущее положение и доворачивать на дельту.
Можно ещё вот так сделать: https://decibel.ni.com/content/docs/DOC-8262
А можно не использовать стандартные :vi: Rotate Object / Set Rotation, а работать сразу с матрицей преобразований. В OpenGL есть стандартные функции для трансляции и поворота - glTranslate / glRotate - но ими стараются не пользоваться, т.к. матрицы дают больше гибкости при работе с объектом. Rotate Object / Set Rotation также не использует эти функции, а сразу модифицирует матрицу модели. Ну, то есть, можно изобрести свои Rotate Object / Set Rotation и обозвать их, как душе угодно. Плюс к тому, работа с матрицами быстрее - вместо, скажем, десяти операций (5 трансляций, 5 поворотов) вы сделаете один заход - расчёт необходимого угла и смещений + запись в матрицу преобразований.
Artem.spb

Activity Автор
professor
professor
Сообщения: 3391
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 49 раз
Поблагодарили: 172 раза
Контактная информация:

Re: 3D Picture

Сообщение Artem.spb »

Я только что понял, что мне мешало постичь тайну сию, и что меня смущало. И таки да, там есть косяк. Конечно, если заниматься самостоятельным расчётом матриц преобразования, то этих ошибок не будет. И если рассматривать только вращение, то тоже вроде всё норм.
Есть вращение и есть смещение. И я рассматриваю (и использую) эти функции в комплексе
f.png
f.png (14.01 КБ) 10952 просмотра
Вращение:
Rotate (та, что relative): вращает объект (пусть ого СК) вокруг СК сцены и каждый вызов функции смещает объект в новое положение, или, что то же самое, поворачивает объект (его СК) вокруг СК сцены на указанный угол из текущего положения.
set rotation (та, что не relative): вращает объект вокруг его собственного центра, при этом сбросив текущий поворот. Т.е. сколько не вызывай функцию с одним и тем же параметром, объект остаётся с в текущем положении.

Translate (та, что relative): смещает объект в новое положение из текущего положения на указанный вектор. Опять же, каждый вызов функции (даже с теми же параметрами) смещает объект. Допустим, что каждый раз ЦК объекта смещается в новое положение в СК сцены.
set translation (та, что не relative): смещает объект в новое положение положения на указанный вектор относительно СК сцены. И снова, сколько не вызывай функцию с одним и тем же параметром, объект остаётся в одном и том же положении .

Тут уже путаница: в одном случае относительно одной СК, а в другом наоборот.

Ну Ок, предположим, что объект имеет свою СК и она трансформируется. Тогда, смещение (абс) - поворот (абс) - смещение (относ) не должно быть равно смещение (абс) - смещение (относ) - поворот (абс), а эксперимент показывает, что положение одно и то же.
Т.е. функция Translate плевать хотела на направление векторов СК объекта и руководствуется векторами сцены (которые неизменны), хотя по логике смещения "СК объекта" она должна была менять своё направление действия.

Надеюсь, я понятно изложил своё недоумение: одинаковые по сути функции действуют по-разному.
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: 3D Picture

Сообщение dadreamer »

Artem.spb писал(а):Ну Ок, предположим, что объект имеет свою СК и она трансформируется. Тогда, смещение (абс) - поворот (абс) - смещение (относ) не должно быть равно смещение (абс) - смещение (относ) - поворот (абс), а эксперимент показывает, что положение одно и то же.
Т.е. функция Translate плевать хотела на направление векторов СК объекта и руководствуется векторами сцены (которые неизменны), хотя по логике смещения "СК объекта" она должна была менять своё направление действия.
Может быть, я сейчас не догоняю... Несколько раз прогнал, не вижу вроде бы косяков.
Начинаем с начала.
2016-07-18_20-26-32.jpg
СК сцены соответствует СК объекта, так как равны их матрицы модели (матрица преобразований объекта равна единичной матрице; все перемещения - по нулям).

1. Вариант Смещение (абс.) - Поворот (абс.) - Смещение (отн.).
- Сдвигаем кубик на 1 по всем осям (абсолютное смещение). В последнем столбце матрицы должны появиться единички.
2016-07-18_20-34-47.jpg
Появились единицы.
- Поворачиваем кубик на 25 градусов вокруг Y (абсолютный поворот). Матрица должна содержать теперь синусы и косинусы 25 градусов согласно описанию выше.
2016-07-18_20-40-02.jpg
Действительно, всё так, как и должно быть.
M = Изображение, где B = 25°. Обращаю внимание, что центр объекта не изменился (1,1,1).
- Сдвигаем кубик на 1 по всем осям (относительное смещение). Раз центр на месте, а смещение относительно СК сцены, то кубик уйдёт дальше в том же направлении, а в последнем столбце появятся двойки.
2016-07-18_20-50-30.jpg
Кубик убежал, и появились двойки.

2. Вариант Смещение (абс.) - Смещение (отн.) - Поворот (абс.).
- Сдвигаем кубик на 1 по всем осям (абсолютное смещение). В последнем столбце матрицы должны появиться единички.
2016-07-18_20-34-47.jpg
Появились единицы.
- Сдвигаем кубик на 1 по всем осям (относительное смещение). Кубик уйдёт дальше в том же направлении, а в последнем столбце появятся двойки.
2016-07-18_20-56-52.jpg
Кубик убежал, и появились двойки.
- Поворачиваем кубик на 25 градусов вокруг Y (абсолютный поворот). Матрица должна содержать теперь синусы и косинусы 25 градусов согласно описанию выше.
2016-07-18_21-00-23.jpg
Имеем картинку, идентичную варианту 1, и точно такую же матрицу преобразований.
На каком этапе должен был произойти "косяк", чтобы мы получили различные результаты?
Artem.spb писал(а):set translation (та, что не relative): смещает объект в новое положение положения на указанный вектор относительно СК сцены. И снова, сколько не вызывай функцию с одним и тем же параметром, объект остаётся в одном и том же положении.
Если не relative, то это absolute, то есть, не "относительно СК сцены", а "относительно СК объекта". А если relative, то это можно читать как relative to the scene coordinate system.
Artem.spb писал(а):Т.е. сколько не вызывай функцию с одним и тем же параметром, объект остаётся с в текущем положении.
Artem.spb писал(а):И снова, сколько не вызывай функцию с одним и тем же параметром, объект остаётся в одном и том же положении .
Ну, понятно, что это происходит из-за дополнительного действия в absolute-трансформациях:
LV Help писал(а):Clears any translations previously applied to an object in a 3D scene
Преобразования начинаются с "чистого листа", т.е. с единичной матрицы для поворота / нулевого столбца для смещения. В принципе, можно было и без этого обойтись при создании :vi: , но что есть, то есть.
Artem.spb

Activity Автор
professor
professor
Сообщения: 3391
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 49 раз
Поблагодарили: 172 раза
Контактная информация:

Re: 3D Picture

Сообщение Artem.spb »

dadreamer писал(а): - Сдвигаем кубик на 1 по всем осям (относительное смещение). Раз центр на месте, а смещение относительно СК сцены, то кубик уйдёт дальше в том же направлении, а в последнем столбце появятся двойки.
2016-07-18_20-50-30.jpg
Кубик убежал, и появились двойки.
стоп-стоп-стоп, я протестую :)
Центр остался там же, да. Но оси теперь направлены иначе. Так что если бы одна из функций смещала ЦК объекта в СК самого объекта, то кубик должен уезжать не по вектору 1-1-1 в СК сцены.
Я уже окончательно запутался, кто относительный, кто абсолютный. Но на мой взгляд одна пара функций (смещения) всегда работает в СК сцены, а вторая (повороты) меняет точку отсчёта.
На каком этапе должен был произойти "косяк", чтобы мы получили различные результаты?
так, после очередного 15-минутного вращения кубика я, кажется, понял, но это окончательно сломало мой моск.

нет, не понял :)
допустим, абсолютное смещение смещает СК объекта в самой себе. При этом очищает смещение, так что получается что смещаемся относительно СК объекта, предварительно вернув её в начало (это уже самом по себе вынос мозга :suicide: ). Но поворот СК остался прежним, так что вектор 1-1-1 в СК объекта вовсе не совпадает с таким же в СК сцены.
Или я что-то снова не догоняю?
Ответить

Вернуться в «Работа с графикой и звуком»