Я просто узнаю о них и считаю, что это обескураживает то, что они устарели. Должен ли я продолжать инвестировать в их изучение? Могу ли я узнать что-то полезное для текущей модели?Почему отображались списки, устаревшие в opengl 3.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.
Матф
На белой бумаге AMD GL3 (http://developer.amd.com/gpu_assets/GL3_WhitePaper.pdf) было найдено следующее: «В настоящее время AMD не планирует удалять любые из этих устаревших и удаленных элементов из контекстов OpenGL, не поддерживающих прямой доступ AMD планирует поддерживать функции и интерфейсы, которые в настоящее время широко используются многими кодовыми базами ». – Gretchen
* «Это создает огромный барьер для людей, которые учатся писать код OpenGL, и (для моих собственных целей) является большим препятствием для взлома быстрого, разборчивого и достаточно хорошо исполняемого кода» * - OpenGL следует рассматривать как низкоуровневую, так что говорить о терминах «объекты буфера памяти» и «указатели атрибутов». Для взлома быстрого кода может быть более подходящим графический движок Irrlicht или Ogre или Horde3D или, возможно, Cinder. – Kos
Это говорит о том, что взломать быстрый код в основном OpenGL 3 или 4 не означает, что * трудно. Добавление вершин в 'std :: vector' не сложнее, чем команды' glVertex', а шейдеры намного проще, чем 'glLight' и' glTextureEnv'. На самом деле есть какой-то шаблонный код для обработки, но большая его часть - это линейная алгебра, которая лучше всего подходит для библиотеки, такой как GLM. Я говорю: Забудьте о списках отображения, идите с ядром OpenGL. – Kos
Поскольку О (буфер вершин объекты) являются гораздо более эффективным и могут сделать списки всех отображений могут сделать. Они тоже не сложны, просто немного отличаются. Если вы уже не знакомы со старым стилем glBegin/glEnd, вам, вероятно, лучше всего узнать о буферах с самого начала.
нет, VBO не может делать все отображаемые списки. например Профессиональный магазин драйверов nvidia меняет настройки в оптимизированной форме и потенциально выполняет их на вторичном потоке. – Bahbar
Часто задаваемые вопросы по OpenGL Wiki: «Если и только если существует потребность в сохранении существующего устаревшего кода, и нет возможности переписать систему рендеринга, использование списков отображения может быть весьма выгодным по сравнению с массивами вершин для статических данных. требуется, нет аргона для вершинных массивов ». – legends2k
@ Бахбар: Это, кроме того, точка. Возможно, VAO может сделать это почти близко и, возможно, потеряется в небольшом количестве, когда сравнивается кусочек муки, но, глядя на большую картину, есть большая победа (как с точки зрения перформативности, так и с гибкостью) при переходе к современному конвейеру с шейдером. – legends2k
Хотя Мэтью Холл имеет хороший ответ и охватывает большинство вещей, я добавлю несколько вещей.
Если вы посмотрите на то, что устарело, вы увидите, что у него много клиентской и фиксированной функциональности. Таким образом, очевидно, что они пытаются отодвинуть людей от кода, ориентированного на клиентскую сторону, и заставить людей делать все возможное на стороне сервера на графическом процессоре.
Когда речь идет о том, какой контекст использовать, ну, это зависит от вас. Хотя, если производительность важна, тогда возможно 3.x. Я лично определенно хочу узнать opengl 3.x, но я сомневаюсь, что я откажусь от 1.x/2.x. Просто гораздо проще собрать быстрое приложение с тем, что доступно в контексте 1.x или 2.x.
Если вы хотите получить список того, что было устаревшим, скачать 3.0 specification и посмотреть в разделе «устаревания модели»
списки отображения были удалены, так как с OpenGL 3 + все вершинные, текстуры и световые данные сохраняются на графическая карта в том, что называется рендерингом сохраненного режима (данные сохраняются, позволяя вам отправить одну команду на карту, чтобы нарисовать сетку, вместо того, чтобы отправлять данные вершин на карту каждый кадр).Основным узким местом в компьютерной графике является пропускная способность данных между оперативной памятью и gpuRAM. генерируя одномерные ячейки и сохраняя эти данные, мы можем преобразовать их с помощью однородных матриц преобразования и легко сделать это. Это эффективно уменьшает узкое место, с недостатком более длительного времени загрузки. Непосредственный режим, однако (до 3.0) использует огромное количество графической пропускной способности для отправки данных вершин в каждый кадр, предварительно преобразованных, с пересчитанными нормалями и т. Д. Проблемы с этим подходом двоякие: 1) чрезмерное использование полосы пропускания и слишком много Время простоя gpu. 2) Чрезмерное использование времени процессора для расчетов, которые могут выполняться параллельно на 100+ ядрах, на gpu
Простым решением является сохранение режима.
С сохраненным режимом больше не нужно отображать списки. Отсюда их удаление из основного профиля.
Непосредственный режим по-прежнему очень хорош для изучения теории компьютерной графики. (и это очень забавно, для загрузки). Это просто страдает с точки зрения максимально возможной производительности.
VBOs & VAO могут быть, поначалу, менее интуитивными, но с точки зрения скорости он намного превосходит.
В Интернете есть несколько простых для понимания учебных пособий opengl 3.0. Как только у вас будет openGL 2.0, вам стоит подумать о переходе на 3.0+, поскольку он позволяет создавать очень быстрые 3D-графические приложения.
Существует разница между «устаревшими» и «удаленными». FYI. Устаревшие вещи обычно не удаляются сразу. – cHao
@cHao Они удаляются только из ядра, но доступны в режиме совместимости. Поэтому они не полностью удалены. – Calmarius
@Calmarius Это именно то, что * устарело * означает в GL. –