OpenGL: реализация стека матриц преобразования

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

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

4 ответов


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

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

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


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

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


функциональность фиксированного конвейера была устаревшей, потому что, по сути, она была исправлена.

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

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

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

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

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

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


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

MatrixStack stack;

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

{
    MatrixScope(stack);

    stack.push(rotate...)    
}

... back to previous stack state.

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

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