Почему списки отображения устарели в opengl 3.1?

Ответ 1

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

Обратите внимание, что эти функции были устаревшими в версии 3.0 и фактически удалены в 3.1 (но все же обеспечивали совместимость через расширение ARB). В OpenGL 3.2 они перенесли эти функции в профиль "совместимости", который является дополнительным для разработчиков драйверов.

Так что это значит? NVidia, по крайней мере, пообещала продолжить поддержку режима совместимости старой школы в обозримом будущем - существует большое количество устаревшего кода, который им необходимо поддерживать. Вы можете найти обсуждение своей поддержки в слайд-шоу по адресу:

http://www.slideshare.net/Mark_Kilgard/opengl-32-and-more

начиная с слайда # 32. Я не знаю позицию ATI/AMD по этому вопросу, но я бы предположил, что это будет похоже.

Итак, в то время как списки отображения технически удаляются из необходимой части стандарта OpenGL 3.2, я думаю, что вы долгое время их используете. В конце концов, вы можете изучить интерфейс, основанный на буфере/шейдере, на OpenGL, особенно если ваша конечная цель - конвертирование с помощью конвертов, но на самом деле это намного менее интуитивно понятное (без glRotate, даже!), Поэтому я бы рекомендовал начиная с старого старого OpenGL 2.x.

Матф

Ответ 2

Дисплейные списки были удалены, поскольку с opengl 3+ все данные вершин, текстуры и освещения хранятся на графической карте в так называемом рендеринге сохраненного режима (данные сохраняются, что позволяет отправлять на карту одну команду нарисовать сетку, вместо того, чтобы отправлять данные вершин на карту каждый кадр). Основным узким местом в компьютерной графике является пропускная способность данных между оперативной памятью и gpuRAM. генерируя одномерные ячейки и сохраняя эти данные, мы можем преобразовать их с помощью однородных матриц преобразования и легко сделать это. Это эффективно уменьшает узкое место, с недостатком более длительного времени загрузки. Однако в режиме немедленного доступа (pre 3.0) используется огромное количество графической пропускной способности для отправки данных вершин в каждый кадр, предварительно преобразованных, с пересчитанными нормалями и т.д. Проблемы с этим подходом двоякие: 1) чрезмерное использование полосы пропускания и слишком большое время простоя gpu. 2) Чрезмерное использование времени процессора для вычислений, которое может быть выполнено параллельно на 100+ ядрах, на gpu

Простым решением этого является режим сохранения.

В сохраненном режиме списки отображения больше не нужны. Следовательно, их удаление из основного профиля.

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

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

Есть несколько простых в понимании учебных пособий opengl 3.0 в Интернете. Как только у вас будет openGL 2.0, вам стоит подумать о переходе на 3.0+, поскольку он позволяет создавать очень быстрые 3D-графические приложения.

Ответ 3

В то время как Мэтью Холл имеет хороший ответ и охватывает большинство вещей, есть несколько вещей, которые я добавлю.

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

Когда дело доходит до того, какой контекст использовать, ну, что до вас. Хотя, если производительность важна, тогда возможно 3.x. Я лично определенно хочу узнать opengl 3.x, но я сомневаюсь, что я откажусь от 1.x/2.x. Просто гораздо проще собрать быстрое приложение с тем, что доступно в контексте 1.x или 2.x.

Если вам нужен список устаревших, загрузите 3.0 спецификацию и посмотрите в разделе "Модель устаревания"

Ответ 4

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