OpenGL: реализация матрицы матриц трансформации

Question

В новом OpenGL нет стека матриц. Я работаю над простым движком отображения, и я собираюсь реализовать стек преобразования.

Что такое общая стратегия здесь? Должен ли я создать стек push/pop и использовать его с деревом, представляющим мою модель? Я полагаю, что это «старый» подход, который устарел в новых версиях OpenGL. Может быть, тогда это не самое лучшее решение (оно было удалено по какой-то причине, мне неизвестно)

Answer 1

(она была удалена по какой-то причине)

Он был удален, так как в современных 3D-приложениях полная функциональность манипулирования матрицей OpenGL была чрезвычайно избыточной. Любое современное 3D-приложение должно иметь дело с матрицами в любом случае, и поскольку OpenGL не является подходящей матричной математической библиотекой, вы все равно будете использовать что-то вроде Eigen oder GSL или что-то домашнее.

Стек все еще является очень жизнеспособной структурой.

Answer 2

Я не очень опытен в этом конкретном случае, но я сделал небольшую часть графики/разработки игр. У меня больше идеи, чем ответа. На мой взгляд, вещи glPushMatrix и glPopMatrix устарели, потому что многие разработчики хотели полностью контролировать преобразования, а не OpenGL, заботясь о них. Поэтому моя идея заключается в том, что они не устарели, потому что матричный стек не подходит, а потому, что разработчики GL должны сами заботиться о самих матрицах или использовать другую библиотеку для этого.

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

Answer 3

Функциональность с фиксированным контуром устарела, поскольку, по существу, она была исправлена.

Для поддержки новых трюков и таких, как правило, требуемых новых функций OpenGL, и стало ясно, что постоянная поддержка запрашиваемых функций означает увеличение размера API OpenGL и постепенное увеличение его количества.

Между тем, аппаратное обеспечение становилось все более изощренным и мощным, и OpenGL полностью не эксплуатировалось. Таким образом, программируемый конвейер был задуман.

С OpenGL3 группа Kronos «устарела» от фиксированной функциональности трубопровода. Это вызвало огромный шум, так как было так много кода и столько талантов, которые были вложены в устоявшийся фиксированный конвейер, поэтому они частично отказались от своего решения, представив профили «ядро» и «совместимость». Основной профиль охватывает новую программируемую модель трубопровода, а профиль совместимости включает в себя ядро ​​плюс большинство/всех фиксированных функциональных возможностей, позволяя приложениям использовать любую модель.

Теперь мы работаем с OpenGL 4.2, и профиль совместимости все еще существует и не показывает признаков исчезновения.

Короче говоря, причина для устаревания заключается не в том, что старая модель не подходит для прикладных программистов; скорее, это было более тяжелое бремя для разработчиков . Фактическая модель достаточно прочная, и многие приложения/разработчики, которые используют программируемые функции, находят себе перераспределение основных частей фиксированной функциональности (glBegin, glEnd, матричные стеки, вызовы преобразования и т. Д.).

Так что вперед, реализуйте свои собственные стеки матрицы.Но, если вы придумаете еще лучшую идею, пожалуйста, поделитесь ею с нами :)

Answer 4

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

MatrixStack stack; 

stack.push(rotate...) 
stack.push(translate...) 

{ 
    MatrixScope(stack); 

    stack.push(rotate...)  
} 

... back to previous stack state. 

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

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