Если вы узнали это только два года назад, то учебники были чрезвычайно устаревшими.Известно, что немедленный режим считается устаревшим очень и очень долгое время.На самом деле первые планы отказаться от него и отобразить списки датируются 2003 годом.
Массивы вершин существуют еще с версии 1.1, и с тех пор они были предпочтительным методом отправки геометрии в OpenGL;в непосредственном режиме каждая вершина вызывает несколько вызовов функций, поэтому для любого сложного объекта вы тратите больше времени на управление стеком вызовов функций, чем на реальную работу по рендерингу.Если вы использовали вершинные массивы с момента их появления, переключение на объекты буфера вершин так же сложно, как просто вставить или заменить несколько строк.
Самое большое препятствие при использовании OpenGL-3 - в Windows, где нужно использоватьконтекст прокси для получения доступа к функциям расширения, необходимым для выбора возможностей OpenGL-3 для создания контекста.Однако, опять же, нет больших препятствий, 20 строк кода.И некоторые программы, такие как моя, например, в любом случае создают прокси-контекст GL, в который загружаются все совместно используемые данные, что позволяет быстро уничтожать / воссоздавать видимые контексты, но при этом иметь полный доступ к текстурам, VBO и прочему (вы можете поделиться VBO,что является еще одной причиной их использования вместо простых массивов вершин: это может не выглядеть как нечто большое, по крайней мере, если контекст используется из одного процесса, однако на платформах, таких как X11 / GLX, контексты OpenGL могут совместно использоваться клиентами X11,который может даже работать на разных машинах!)
Кроме того, существование таких функций, как стек матричных манипуляций, вводило людей в заблуждение, OpenGL была некоторой математико-математической библиотекой, некоторые даже полагали, что она была особенно быстрой.Ни то, ни другоеУдаление функций манипулирования матрицей было очень важным и правильным делом.В любом случае каждое серьезное OpenGL-приложение будет реализовывать свою собственную матричную математику.Например, любая современная игра, использующая какой-то физический движок, используемый для непосредственного использования в OpenGL (glLoadMatrix или glUniformMatrix) матрицы преобразования, выдаваемой физическим вычислением, полностью обходя остальные функции матрицы.Это также означает, что единственная причина иметь несколько матричных стеков (GL_PROJECTION, GL_MODELVIEW, GL_TEXTURE, GL_COLOR), а именно возможность использовать один и тот же набор функций манипуляции для нескольких матриц, была устаревшей и могла быть заменена чем-то вроде glLoadMatrixSelected{f,d}v(GLenum target, GLfloat *matrix)
,Однако униформы и шейдеры уже были рядом, поэтому логичным шагом было не введение новой функции, а повторное использование существующего API, который уже использовался для этой задачи, и вместо этого удалить того, что больше не требуется.
TL; DR: новый API OpenGL-3 значительно упрощает его использование.Это намного понятнее, меньше ловушек, и IMHO также более дружественный к новичкам.