Стратегии управления конечным автоматом OpenGL

Question

Я сейчас вхожу в борьбу с OpenGL.Я начал с GLUT, но решил "перейти" на библиотеки SFML.SFML фактически предоставляет даже меньше утилит GL, чем GLUT, но является переносимым и предоставляет некоторые другие функции.Так что это действительно только я, GL и GLU.Да, я отстойник для наказания.

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

В настоящее время я выполняю рендеринг.из одного потока, следуя философии дизайна "Голые предметы".то есть.Каждый графический объект имеет функцию Render(), которая выполняет работу по рисованию.Эти объекты сами могут быть совокупностями других объектов или совокупностями графических примитивов.Когда вызывается конкретный Render(), у него нет информации о том, какие преобразования / материальные изменения были вызваны до него (это, конечно, хорошо).

По мере развития вещей я остановился на определенных стратегиях, таких как созданиекаждая функция обещает нажать и затем вытолкнуть матрицы, если они выполняют какие-либо преобразованияС другими настройками я явно устанавливаю все, что нужно настроить перед вызовом glBegin() и ничего не принимаю как должное.Проблемы возникают, когда одна функция рендеринга вносит некоторые изменения в менее распространенные переменные состояния, и я начинаю рассматривать использование некоторого RAII для принудительного отмены всех изменений состояния, сделанных в области.Использование OpenGL иногда очень напоминает мне программирование на ассемблере.

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

Обновление: 13/5/11

Теперь рассмотрим рендеринг с помощью вершины / нормального /Цветовые массивы и VBO Я решил объединить все фактические коммуникации OpenGL в отдельный модуль.Процесс рендеринга будет состоять из загрузки независимых от GL пространственных / материальных данных из моих объектов и последующей передачи всей этой информации в openGL в интерпретируемом формате.Это означает, что вся обработка необработанных массивов и состояний будет объединена в одну область.Это добавляет дополнительную косвенность и небольшие накладные расходы на процесс рендеринга, но это означает, что я могу использовать один VBO / массив для всех моих данных, а затем передавать все сразу, один раз за кадр в openGL.

Answer 1

Так что на самом деле это только я, GL и GLU

Я не вижу в этом ничего плохого.Я бы даже избавился от GLU, если это возможно.

С другими настройками я явно устанавливаю все, что нужно настроить перед вызовом glBegin () и ничего не принимаю как должное.

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

Проблемы возникают при одном рендереФункция вносит некоторые изменения в менее распространенные переменные состояния, и я начинаю рассматривать использование некоторого RAII для принудительного отмены всех изменений состояния, сделанных в области.

Более старые версии OpenGL предоставляют вам стек атрибутовс функциями доступа glPushAttrib / glPopAttrib и glPushClientAttrib / glPopClientAttrib для состояний клиента.

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

Использование OpenGL иногда напоминает мне много оПрограммирование на ассемблере.

Это вовсе не удивительно, поскольку самое первое воплощение OpenGL было разработано, предполагая, что некоторая абстрактная машина (реализация), на которой вызовы OpenGL являются своего рода кодами операций этой машины.

Answer 2

Во-первых, старайтесь не использовать вызовы glBegin / glEnd для новой разработки.Они устарели в OpenGL 3 и просто не работают в OpenGL ES (iOS, WebOS, Android).Вместо этого используйте вершинные массивы и VBO для консолидации вашего чертежа.

Во-вторых, вместо того, чтобы писать свою собственную обертку, взгляните на некоторые недавние открытые источники, чтобы увидеть, как они работают.Например, посмотрите библиотеку визуализаций (http://www.visualizationlibrary.com/jetcms/). Это довольно тонкая оболочка для OpenGL, поэтому стоит посмотреть.