OpenGL-почему был удален стек матрицы и что люди используют сейчас?

Я читаю пятое издание OpenGL Superbible, и они обсуждают использование стеков через свой собственный класс. Это все здорово, но они упоминают, что матричные стеки были устаревшими. Почему они были осуждены и что люди используют вместо них?

6
matrix opengl stack

4 ответов

матричный стек (и остальные матричные функции) были устаревшими только в основном профиле. В профиле совместимости вы все равно сможете их использовать.

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

хотя для простых программ / учебников очень неудобно использовать и искать что-то еще.

Я предлагаю использование:

2

причины(ы) являются политическими, а не техническими и датируются началом 2000-х годов.

OpenGL 3 была первой версией, готовой сломать обратную совместимость. Дизайнеры хотели создать API для опытных пользователей, игровых программистов и высококлассных кодеров визуализации, которые знали все о шейдерах и писали свой собственный матричный код. Целью было то, что API OpenGL 3 должен соответствовать фактическому оборудованию довольно близко. (Даже в OpenGL 1/2 стек матрицы обычно был реализовано на стороне процессора, а не GPU.)

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

результатом этого процесса проектирования является основной профиль OpenGL 3/4.

Как только было объявлено OpenGL "нового поколения", все не очень опытные кодеры в университетах и компаниях поняли, что они будут ввернуты. Это люди (как и я), которые преподают 3D-графику или пишут утилиты для исследований или дизайна. Нам не нужно никакое более предварительное освещение чем простой окружающ-диффузно-отражательный. Мы часто должны смешивать код из разных источников вместе, и это легко, только если все используют точно такие же матрицы, освещение и соглашения о текстурировании, как те, которые поставляются OpenGL 2.

кроме того, я слышал, но не могу проверить, большие компании CAD/CAM поняли, что они также будут ввернуты. Выбрасывание двух миллионов строк кода за десять лет разработки не является вариантом, когда у вас есть платежеспособные (и хорошо оплачиваемые: сравните цены для клиентов Quadro vs GeForce или FireGL vs Radeon).

поэтому NVIDIA и ATI объявили, что будут поддерживать старый API столько, сколько смогут.

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

9

почему они были осуждены

потому что никто на самом деле не использовал его в реальных программах OpenGL. Возьмем, к примеру, физическую симуляцию: в любом случае все размещение объектов будет храниться в физической системе как Матрица 4×4. Так что ты просто используешь это. То же самое касается систем определения видимых объектов и анимации. Все они должны реализовать матричную математику в любом случае, поэтому наличие этого в OpenGL довольно избыточно, так как большую часть времени уже существующее матрицы были просто помещены в glLoadMatrix.

и что люди используют вместо них?

то, что они использовали раньше: их анимационные системы, физические симуляторы, графики сцен и т. д.

2

Ну, первая и основная причина для меня заключается в том, что с ростом программируемых шейдеров (обязательных после 3-й версии opengl) все переменные, такие как GL_PROJECTION и GL_MODELVIEW, которые были автоматически переданы шейдерам, удаляются из шейдеров, поэтому пользователь должен определить свою собственную матрицу, чтобы использовать ее в шейдере. Поскольку вам нужно отправить матрицу вручную, используя равномерные функции, вам больше не нужны фиксированные переменные.

1