Стратегии управления конечным автоматом OpenGL
В настоящее время я начинаю разбираться с OpenGL. Я начал с GLUT, но решил «перейти» к библиотекам SFML. SFML на самом деле предоставляет даже меньше утилит GL, чем GLUT, но является переносимым и предоставляет некоторые другие функции. Так что это действительно только я, GL и GLU. Да, я любитель наказаний.
Я хотел спросить о стратегиях, которые люди используют для управления такими вещами, как изменение матрицы, изменение цвета, изменение материала и т. Д.
В настоящее время я выполняю рендеринг из одного потока, следуя Философия дизайна «Обнаженные предметы». т.е. Каждый графический объект имеет функцию Render () , которая сама выполняет работу по рисованию. Эти объекты могут сами быть совокупностями других объектов или совокупностями графических примитивов. Когда вызывается конкретный Render () , он не имеет информации о том, какие преобразования / материальные изменения были вызваны до него (конечно, хорошо).
По мере развития событий я остановился на определенных стратегиях. например, заставить каждую функцию обещать нажать, а затем вытолкнуть матрицы, если они выполняют какие-либо преобразования. С другими настройками я явно устанавливаю все, что нужно настроить, перед вызовом glBegin () и ничего не принимаю как должное. Проблемы закрадываются, когда одна функция рендеринга вносит некоторые изменения в менее распространенные переменные состояния, и я начинаю рассматривать возможность использования некоторого RAII, чтобы принудительно отменить все изменения состояния, сделанные в области. Использование OpenGL иногда очень напоминает мне программирование на ассемблере.
Чтобы все это было управляемым и чтобы помочь с отладкой, я обнаружил, что практически разрабатываю свою собственную оболочку openGL, поэтому я подумал, что было бы хорошо услышать о стратегиях, которые использовали другие, или о мыслях и соображениях по этому поводу . Или, может быть, просто пора переключиться на что-то вроде библиотеки графов сцены?
Обновление: 13/5/11
Теперь, изучив рендеринг с массивами вершин / нормальных / цветов и VBO, я решил объединить все актуальные openGL связь в отдельный модуль. Процесс рендеринга будет состоять из получения загрузки независимых от GL пространственных / материальных данных из моих объектов и последующей передачи всей этой информации в openGL в интерпретируемом формате. Это означает, что вся обработка необработанных массивов и манипуляции с состоянием будут объединены в одну область. Это добавляет дополнительную косвенность, и небольшие накладные расходы на вычисления для процесса рендеринга, но это означает, что я могу использовать один VBO / массив для всех моих данных, а затем передавать их все сразу, один раз на кадр в openGL.