Я читаю онлайн-книгу "Навчання сучасного 3D-графічного програмування" Джейсона Л. Маккесона
На сьогоднішній день я вирішував проблему блокування карданних виробів і як її вирішити за допомогою кватерніонів.
Однак тут, на сторінці Кватерніонів .
Частина проблеми полягає в тому, що ми намагаємось зберігати орієнтацію у вигляді серії з 3 накопичених осьових обертів. Орієнтації - це орієнтації, а не обертання. І орієнтації - це, звичайно, не ряд обертів. Тому нам потрібно ставитися до орієнтації корабля як до орієнтації, як до конкретної кількості.
Я думаю, що це перше місце, яке я починаю плутати, причина в тому, що я не бачу різкої різниці між орієнтаціями та обертаннями. Я також не розумію, чому орієнтація не може бути представлена рядом обертів ...
Також:
Першою думкою до цієї мети було б зберегти орієнтацію як матрицю. Коли настає час змінити орієнтацію, ми просто застосуємо перетворення до цієї матриці, зберігаючи результат як нову поточну орієнтацію.
Це означає, що кожне відхилення, нахил та рулон, застосоване до поточної орієнтації, буде відносно цієї поточної орієнтації. Що саме те, що нам потрібно. Якщо користувач застосовує позитивне похитування, ви хочете, щоб він поворотів їх відносно місця, де вони вказують на поточний час, а не щодо якоїсь фіксованої системи координат.
Я розумію, що ця концепція не розуміє, як якщо накопичення матричних перетворень є вирішенням цієї проблеми, то як код, наведений на попередній сторінці, це не просто так.
Ось код:
void display()
{
glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
glClearDepth(1.0f);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glutil::MatrixStack currMatrix;
currMatrix.Translate(glm::vec3(0.0f, 0.0f, -200.0f));
currMatrix.RotateX(g_angles.fAngleX);
DrawGimbal(currMatrix, GIMBAL_X_AXIS, glm::vec4(0.4f, 0.4f, 1.0f, 1.0f));
currMatrix.RotateY(g_angles.fAngleY);
DrawGimbal(currMatrix, GIMBAL_Y_AXIS, glm::vec4(0.0f, 1.0f, 0.0f, 1.0f));
currMatrix.RotateZ(g_angles.fAngleZ);
DrawGimbal(currMatrix, GIMBAL_Z_AXIS, glm::vec4(1.0f, 0.3f, 0.3f, 1.0f));
glUseProgram(theProgram);
currMatrix.Scale(3.0, 3.0, 3.0);
currMatrix.RotateX(-90);
//Set the base color for this object.
glUniform4f(baseColorUnif, 1.0, 1.0, 1.0, 1.0);
glUniformMatrix4fv(modelToCameraMatrixUnif, 1, GL_FALSE, glm::value_ptr(currMatrix.Top()));
g_pObject->Render("tint");
glUseProgram(0);
glutSwapBuffers();
}
Наскільки я розумію, не те, що він робить (модифікація матриці на стеку), вважається накопичуваними матрицями, оскільки автор об'єднав усі індивідуальні перетворення обертання в одну матрицю, яка зберігається у верхній частині стека.
Моє розуміння матриці полягає в тому, що вони використовуються для того, щоб взяти точку, яка відносно походження (скажімо, ... модель), і зробити її відносно іншого походження (камери). Я майже впевнений, що це безпечне визначення, проте я відчуваю, що чогось не вистачає, що заважає мені зрозуміти цю проблему з фіксацією карданчика.
Одна річ, яка для мене не має сенсу: якщо матриця визначає відносну різницю між двома "пробілами", яким чином відбувається обертання навколо осі Y для, скажімо, рулону, не ставить крапку в "просторі рулону "який потім може бути перетворений ще раз відносно цього рулону ... Іншими словами, не повинно бути подальших перетворень до цього моменту відносно цього нового" місця прокрутки "і, отже, не повинно обертання бути відносно попереднього" модельний простір ", що спричиняє фіксацію каркаса.
Ось чому химерний замок відбувається правильно? Це тому, що ми обертаємо об'єкт навколо осей X, Y і Z, а не обертаємо об'єкт навколо власних відносних осей. Або я помиляюся?
Оскільки, мабуть, цей код, з яким я пов’язаний, не є накопиченням матричних перетворень, ви можете, будь ласка, навести приклад рішення за допомогою цього методу.
Отже, підсумовуючи:
- Яка різниця між обертанням і орієнтацією?
- Чому код пов'язаний не в прикладі накопичення матричних перетворень?
- Яке справжнє, конкретне призначення матриці, якщо я помилився?
- Як можна було б реалізувати вирішення проблеми фіксації каркаса за допомогою накопичення матричних перетворень?
- Також як бонус: Чому перетворення після обертання все ще відносяться до "простору моделі?"
- Ще один бонус: чи помиляюсь у припущенні, що після перетворення відбудуться подальші перетворення відносно струму?
Крім того, якщо це не малося на увазі, я використовую OpenGL, GLSL, C ++ та GLM, тож приклади та пояснення з точки зору цього високо оцінюються, якщо не потрібно.
Чим більше деталей, тим краще!
Заздалегідь спасибі.
