В OpenGL уже есть некоторые понятия «Объект».
Например, что-либо с идентификатором может быть объектом в качестве объекта (есть также вещи, специально названные «Объекты»). Буферы, текстуры, объекты буфера вершин, объекты массива вершин, объекты буфера кадров и так далее. С небольшой работой вы можете обернуть классы вокруг них. Это также дает вам простой способ вернуться к старым устаревшим функциям OpenGL, если ваш контекст не поддерживает расширения. Например, VertexBufferObject может вернуться к использованию glBegin (), glVertex3f () и так далее.
Есть несколько способов отойти от традиционных концепций OpenGL, например, вы, вероятно, хотите хранить метаданные о буферах в объектах буфера. Например, если в буфере хранятся вершины. Каков формат вершин (то есть положение, нормали, texcoords и т. Д.). Какие примитивы он использует (GL_TRIANGLES, GL_TRIANGLESTRIP и т. Д.), Информацию о размере (сколько чисел с плавающей запятой, сколько треугольников они представляют и т. Д ...). Просто чтобы было легко подключить их к командам рисования массивов.
Я рекомендую вам взглянуть на OGLplus . Это привязки C ++ для OpenGL.
Также glxx , это только для загрузки расширений.
В дополнение к обёртыванию API OpenGL, вы должны взглянуть на создание немного более высокого уровня одной сборки поверх него.
Например, класс менеджера материалов, который отвечает за все ваши шейдеры, их загрузку и использование. Также он будет нести ответственность за передачу им имущества. Таким образом, вы можете просто позвонить: materials.usePhong (); material.setTexture (sometexture); material.setColor (). Это обеспечивает большую гибкость, поскольку вы можете использовать более новые объекты, такие как объекты общего унифицированного буфера, чтобы иметь только один большой буфер, содержащий все свойства, которые ваши шейдеры используют в 1 блоке, но если он не поддерживается, вы возвращаетесь к загрузке в каждую шейдерную программу. Вы можете иметь 1 большой монолитный шейдер и переключаться между различными моделями шейдеров, используя единообразные процедуры, если это поддерживается, или вы можете использовать кучу разных маленьких шейдеров.
Вы также можете посмотреть на затраты из спецификации GLSL для написания своего шейдерного кода. Например, #include было бы невероятно полезно и очень легко реализовать в вашем коде загрузки шейдера (для него также есть расширение ARB ). Вы также можете сгенерировать свой код на лету на основе поддерживаемых расширений, например, использовать общий унифицированный объект или использовать обычную униформу.
Наконец, вам понадобится API конвейера рендеринга более высокого уровня, который выполняет такие вещи, как графики сцены, специальные эффекты (размытие, свечение), вещи, которые требуют многократных проходов рендеринга, такие как тени, освещение и тому подобное. И, кроме того, игровой API, который не имеет ничего общего с графическим API, а имеет дело только с объектами в мире.