Что такое opengl и для чего он нужен


что это: для чего нужна такая поддержка?

Опубликовано 30.01.2020 автор — 0 комментариев

Здравствуйте, дорогие читатели! Сегодня мы с вами разберем OpenGL — что это такое, для чего используется, требуется ли что то настраивать для его эксплуатации.

Что это за программа

И сразу же хочу уточнить, что это вовсе не программа в привычном понимании, не драйвер, не протокол и не служба.

OpenGL — спецификация, которой определяется программный интерфейс для написания приложений, использующих 2D и 3D графику. По сути, это инструмент, который регулирует рендеринг изображения видеокартой.

Название расшифровывается как Open Graphics Library, то есть «Открытая графическая библиотека». Открытость инструмента означает, что им может воспользоваться любой разработчик без всякой маржи и лицензионных отчислений.

Инструмент кроссплатформенный: созданные с его помощью приложения будут работать в любой среде, которые осуществляют его поддержку.

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

Основные области применения OpenGL — видеоигры, системы автоматизированного проектирования, поддержка виртуальной реальности и визуализация различных проектов. На платформе Windows главным конкурентом технологии является DirectX.

О том, что такое DirectX и зачем он нужен, вы можете почитать вот тут.

Концепция OpenGL была разработана в 1982 году в университете Стэнфорда. Аппаратно прототип технологии впервые реализовала компания Silicon Graphics, создавшая конвейер для рендеринга. Ее разработки стали основой библиотек OpenGL.

Как работает OpenGL

Если смотреть с точки зрения разработчика, то OpenGL — программный интерфейс, который управляет работой видеокарты. Всего есть чуть более 150 команд, с помощью которых программист определяет, какие именно объекты будут отправлены на рендеринг.Этим же стандартом определяются более тонкие настройки: например, тройная буферизация, трассировка лучей или сглаживание в играх.

Нет необходимости создавать разные версии графических объектов для отображения в различных режимах качества графики: все подстраивается «на автомате», исходя из заданных программистов параметров.

Проще говоря, программист определяет отображаемые объекты в трехмерном пространстве, их взаимное положение и взаимодействие, масштабирование, угол обзора и т.д., а также цвет и текстуру, а OpenGL уже заботится об их рендеринге.

Можно утверждать, что этот инструмент только воспроизводит объекты, но не взаимодействует с устройствами ввода — мышью, клавиатурой, геймпадом или игровым рулем. За это, а также за работу менеджера окон, отвечают уже другие компоненты.

Несмотря на кажущуюся сложность, OpenGL имеет четко продуманную структуру и простой процедурный интерфейс. При этом с помощью этого инструмента можно создавать действительно сложные сцены, состоящие из множества компонентов. Вычислительных мощностей требуется меньше по сравнению с другими библиотеками.

Некоторые версии OpenGL поддерживают работу по сети: объекты рендерятся на сервере, а клиентское приложение получает только их отображение. Благодаря этому можно создавать мощные воспроизводящие комплексы, состоящие из множества компьютеров.

Следует отметить, что в отличие от главного конкурента OpenGL можно считать универсальным инструментом. Главный конкурент, DirectX, «заточен» именно под игры. Многие игры поддерживают обе технологии.

Нужно ли переключаться между ними? На мой взгляд, нет никакой разницы, что именно вы используете, Независимо от технологии существенной разницы в производительности не замечено, если речь идет о платформе Windows.

Если же вы используете эмулятор Андроид на ПК, в этом случае рекомендую переключиться OpenGL: для систем семейства Unix этот инструмент подходит больше.

Также рекомендую ознакомиться с публикациями «Что делать, если видеокарта не поддерживает DirectX» и «Как посмотреть параметры видеокарты». Буду признателен, если вы расшарите этот пост в социальных сетях. До скорой встречи!

 

С уважением, автор блога Андрей Андреев.

Друзья, поддержите блог! Поделитесь статьёй в социальных сетях:

Direct3D vs OpenGL: история противостояния / Хабр

По сей день в Интернете можно встретить споры о том, какой же графический API лучше: Direct3D или OpenGL? Несмотря на свой религиозный характер, такие словесные баталии приносят полезный результат в виде неплохих исторических обзоров развития аппаратно-ускоренной графики.

Целью данного поста является перевод одного из таких экскурсов в историю, написанного Джейсоном МакКессоном (Jason L. McKesson) в ответ на вопрос «Почему разработчики игр предпочитают Windows». Этот текст вряд ли отвечает на поставленный вопрос, но историю развития и противостояния двух самых популярных графических API он описывает очень красочно и довольно подробно, поэтому в переводе я сохранил авторскую разметку. Текст написан в середине 2011 года и охватывает промежуток времени, начинающийся незадолго до появления Direct3D и до момента написания. Автор оригинального текста является опытным разработчиком игр, активным участником StackOverflow и создателем обширного учебника о современном программировании 3D-графики. Итак, предоставим слово Джейсону.

Предисловие

Прежде чем мы начнём, я хотел бы сказать, что знаю больше об OpenGL, чем о Direct3D. В своей жизни я не написал ни строчки кода на D3D, но писал руководства по OpenGL. Но то, о чём я хочу рассказать — вопрос не предубеждения, а истории.

Рождение конфликта

Однажды, где-то в начале 90-х, Microsoft огляделись вокруг. Они увидели, что

SNES

и

Sega Genesis

— это очень здорово, на них можно поиграть во множество экшн-игр и всего такого. И они увидели ДОС. Разработчики писали досовские игры как консольные: близко к железу. Тем не менее, в отличие от консолей, где разработчик знал, какое железо будет у пользователя, дос-разработчики были вынуждены писать под множество конфигураций. А это намного сложнее, чем кажется.

Но у Microsoft была бо́льшая проблема: Windows. Видите ли, Windows хотела полностью владеть железом в отличие от ДОС, которая позволяла разработчикам делать всё что угодно. Владение железом необходимо для взаимодействия между приложениями. Но такое взаимодействие — это в точности то, что ненавидят разработчики игр, потому что оно потребляет драгоценные ресурсы, которые они могли бы использовать для всяких крутых вещей.

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

Так родился DirectX.

3D ускорители появились несколько месяцев спустя. И Microsoft вляпались в неприятности. Дело в том, что DirectDraw, графический компонент DirectX, работал только с 2D графикой: выделял графическую память и делал быстрые битовые операции между различными секторами памяти.

Поэтому Microsoft купили немного стороннего ПО и превратили его в Direct3D версии 3. Его ругали абсолютно все. И было за что: чтение кода на D3D v3 выглядело как расшифровка письменности исчезнувшей древней цивилизации.

Старик Джон Кармак в Id Software посмотрел на это безобразие, сказал «Да пошло оно...», и решил писать с использованием другого API: OpenGL.

Однако другая сторона этой запутанной истории заключалась в том, что Microsoft совместно с SGI работали над реализацией OpenGL для Windows. Идея была в том, чтобы привлечь разработчиков типичных GL-приложений для рабочих станций: САПР, систем моделирования и тому подобных вещей. Игры были последним, о чём они думали. В основном это касалось Windows NT, но Microsoft решили добавить OpenGL и в Windows 95.

Чтобы сманить разработчиков софта для рабочих станций на Windows, Microsoft решили подкупить их доступом к новомодным 3D-ускорителям. Они реализовали протокол для устанавливаемых клиентских драйверов: графическая карта могла заменить программный OpenGL от Microsoft своей аппаратной реализацией. Код автоматически использовал аппаратный OpenGL, если таковой был доступен.

Однако, в те времена потребительские видеокарты не имели поддержки OpenGL. Это не остановило Кармака от портирования Quake на OpenGL на рабочей станции SGI. В readme-файле GLQuake можно прочитать следующее:

Теоретически, glquake запустится на любой реализации OpenGL, которая поддерживает расширение texture objects. Но пока вы не запустите её на очень мощном железе, которое ускоряет всё, что нужно, работать она будет непростительно медленно. Если игре потребуется работать через какие-либо программные эмуляции, её производительность скорее всего не превысит один кадр в секунду.

В настоящее время (март 1997), единственной полностью совместимой с opengl железкой, способной потянуть glquake на приемлемом уровне, является ОЧЕНЬ дорогая видеокарта intergraph realizm. 3dlabs существенно увеличили её производительность, но с имеющимися драйверами она всё ещё недостаточно подходит для игры. Некоторые из драйверов от 3dlabs для плат glint и permedia ещё и крэшат NT при выходе из полноэкранного режима, поэтому я не рекомендую запускать glquake на железе от 3dlabs.

3dfx предоставляет opengl32.dll, которая реализует все нужное для glquake, но это не полная реализация opengl. Другие opengl-приложения скорее всего с ней не заработают, поэтому рассматривайте её в основном как «драйвер для glquake».

Это было рождением miniGL драйверов. В конечном итоге они эволюционировали в полноценные реализации OpenGL, как только железо стало достаточно мощным для аппаратной поддержки этой функциональности. nVidia стала первой, кто предложил полную реализацию OpenGL. Другие поставщики всё ещё медлили, что стало одной из причин перехода разработчиков на Direct3D, поддерживаемый более широким спектром оборудования. В конце концов остались только nVidia и ATI (которая сейчас AMD), и у обеих имелись хорошие реализации OpenGL.

Рассвет OpenGL

Итак, участники определены: Direct3D против OpenGL. Это поистине удивительная история, учитывая то, как плох был D3D v3.

Совет по архитектуре OpenGL (Architectural Review Board, ARB) — это организация, ответственная за поддержание и развитие OpenGL. Они выпускают множество расширений, содержат репозиторий с расширениями, и создают новые версии API. ARB — это комитет, состоящий из большого количества игроков индустрии компьютерной графики и некоторых производителей ОС. Apple и Microsoft в разное время тоже были членами ARB.

3Dfx выходит на сцену со своей Voodoo2. Это первая видеокарта, позволяющая делать мультитекстурирование, которое не было ранее предусмотрено в OpenGL. В то время как 3Dfx была решительно против OpenGL, nVidia, следующий производитель чипа с мультитекстурированием (TNT1), были без ума от OpenGL. Тогда ARB выпустил расширение GL_ARB_multitexture, которое предоставляло доступ к множественным текстурам.

Тем временем появляется Direct3D v5. Теперь D3D действительно стал API, а не какой-то несуразицей. В чём же проблема? В отсутствии мультитекстурирования.

Упс.

Но это не доставляло таких неудобств, какие могло бы доставить, потому что почти никто не использовал множественное текстурирование. Мультитекстурирование почти не вредит производительности, и во многих случаях разница незаметна на фоне многопроходности. И конечно, разработчики игр очень любят чтобы их игры уверенно работали на старом железе, которое не имело поддержку множественных текстур, поэтому многие игры были выпущены без неё.

D3D вздохнул с облегчением.

Время шло, и nVidia выкатили GeForce 256 (не путать с самым первым GeForce GT-250), прекратив борьбу на рынке графических плат на следующие два года. Главным конкурентным преимуществом этой платы была возможность делать преобразования вершин и освещение (transformation & lighting, T&L) аппаратно. Но это ещё не всё: nVidia любила OpenGL настолько, что их T&L-движок фактически и был OpenGL. Почти буквально! Как я понимаю, некоторые из их регистров получали на вход напрямую численные значения переменных типа GLenum.

Выходит Direct3D v6. Наконец то подоспело множественное текстурирование… но без аппаратного T&L. В OpenGL всегда был T&L-конвейер, хотя до GeForce 256 он был реализован программно. Поэтому для nVidia оказалось довольно просто переделать программную реализацию в аппаратное решение. В D3D аппаратное T&L появилось только к седьмой версии.

Заря эпохи шейдеров, OpenGL во мгле

Затем появилась GeForce 3. В то же самое время произошло много интересных вещей.

В Microsoft решили, что они больше не собираются опаздывать. Поэтому вместо того, чтобы смотреть, что сделает nVidia, и копировать их разработки уже пост-фактум, Microsoft приняли изумительное решение: пойти и поговорить. И они полюбили друг друга, и у них появилась совместная маленькая консоль.

Шумный развод произошёл позже, но это совсем другая история.

Для рынка PC это значило, что GeForce 3 вышла одновременно с D3D v8, и нетрудно видеть, как GeForce 3 повлияла на шейдеры D3D v8. Пиксельные шейдеры Shader Model 1.0 были очень сильно заточены под оборудование nVidia. Не было предпринято ни единой попытки сделать хоть что нибудь для абстрагирования от железа nVidia. Shader Model 1.0 стала тем, для чего предназначена GeForce 3.

Когда ATI ворвалась в гонку производительности видеокарт со своей Radeon 8500, появилась одна проблема. Пиксельный конвейер Radeon 8500 оказался более мощным, чем у nVidia. Поэтому Microsoft выпустила Shader Model 1.1, которая в основном была тем, для чего предназначена 8500.

Это звучит как поражение D3D, но успех и провал — понятия относительные. На самом деле эпический провал поджидал OpenGL.

В nVidia очень любили OpenGL, поэтому после выхода GeForce 3 они выпустили целую пачку расширений для OpenGL. Проприетарных расширений, которые работали только на nVidia. Естественно, когда появилась плата 8500, она не могла использовать ни одно из них.

Итак, на D3D 8 вы могли хотя бы запустить шейдеры SM 1.0. Конечно, чтобы использовать всю крутость 8500, приходилось писать новые шейдеры, но код хотя бы работал.

Чтобы получить любые шейдеры на Radeon 8500 в OpenGL, ATI пришлось разработать несколько расширений для OpenGL. Проприетарных расширений, которые работали только на ATI. В итоге, чтобы разработчики могли заявить, что они прикрутили к своему движку шейдеры, им приходилось писать отдельный код для nVidia и отдельный код для ATI.

Вы возможно спросите: «А где же был комитет ARB, который должен поддерживать OpenGL на плаву?». А были они там, где в конечном итоге оказываются многие комитеты: они сидели и тупили.

Обратите внимание, выше я упомянул ARB_multitexture, потому что это расширение глубоко замешано во всей ситуации. Стороннему наблюдателю казалось, что ARB вообще хочет избежать идеи шейдеров. Они решили, что если они вбухают достаточно конфигурируемости в фиксированный конвейер, то он сравняется по своим возможностям с программируемым шейдерным конвейером.

ARB выпускали расширения одно за другим. Каждое расширение со словами «texture_env» в названии было попыткой залатать этот устаревающий дизайн. Посмотрите на список расширений: таких расширений было выпущено восемь штук, и многие из них были переведены в основную функциональность OpenGL.

В то время Microsoft входила в ARB, и покинула его только к выпуску D3D 9, поэтому возможно, Microsoft саботировали OpenGL некоторым образом. Лично я сомневаюсь в этой теории по двум причинам. Во-первых, они должны были бы заручиться поддержкой других членов Комитета, потому как каждый участник имеет всего один голос. Во-вторых, что более важно, Комитету не нужна была помощью Microsoft чтобы всё запороть, свидетельства чему мы увидим далее.

В итоге ARB, скорее всего под давлением ATI и nVidia (обе являются активными участниками), наконец очнулся и ввёл в стандарт ассемблерные шейдеры.

Хотите ещё более дурацкую историю?

Аппаратное T&L. Это то, что в OpenGL было изначально. Чтобы получить максимально возможную производительность аппаратного T&L, нужно хранить данные вершин на GPU. Все-таки, GPU — это основной потребитель вершинных данных.

В D3D v7 Microsoft ввела концепцию вершинных буферов, которые выделяют куски памяти в GPU и размещают там данные вершин.

Хотите знать когда в OpenGL появилась эквивалентная функциональность? Да, nVidia, как самый большой любитель OpenGL, выпустила своё расширение для хранения массивов вершин на GPU ещё во времена выхода GeForce 256. Но когда же ARB представил такую функциональность?

Два года спустя. Это было после того, как она утвердили вершинные и фрагментные (пиксельные в терминах D3D) шейдеры. Столько времени ушло у ARB чтобы разработать кросс-платформенное решение для хранения вершинных данных в памяти GPU. И это то, что необходимо, чтобы аппаратное T&L достигло максимальной производительности.

Один язык, чтобы убить их всех

Итак, OpenGL был сломан в течение какого-то времени. Отсутствовали кросс-платформенные шейдеры и аппаратно-независимое хранение вершин в GPU, в то время как пользователи D3D наслаждались и тем и другим. Могло ли стать ещё хуже?

Можно сказать, что могло. Встречайте: 3D Labs.

Вы спросите: кто же они? Они — мёртвая компания, которую я считаю истинным убийцей OpenGL. Конечно, общая несостоятельность Комитета сделала OpenGL уязвимым, в то время как он должен был рвать D3D в клочья. Но по-моему, 3D Labs — возможно единственная причина текущего положения OpenGL на рынке. Что они для этого сделали?

Они разработали язык шейдеров для OpenGL.

3D Labs были умирающей компанией. Их дорогостоящие GPU были вытеснены с рынка рабочих станций всё возрастающим давлением nVidia. И в отличие от nVidia, 3D Labs не были представлены на потребительском рынке; победа nVidia означала бы смерть для 3D Labs.

Что в итоге и случилось.

В стремлении оказаться на плаву в мире, которому были не нужны их продукты, 3D Labs заявились на конференцию Game Developer Conference с презентацией того, что они назвали «OpenGL 2.0». Это был OpenGL API, переписанный с нуля. И это имело смысл, ибо в те времена в API OpenGL было полно хлама (который, впрочем, остаётся там и по сей день). Посмотрите хотя бы на то, насколько эзотерически сделаны загрузка и биндинг текстур.

Частью их предложения был язык шейдеров. Да, именно он. Тем не менее, в отличие от имеющихся кросс-платформенных расширений, их язык шейдеров был «высокоуровневым» (C — это высокий уровень для языка шейдеров).

В это же время в Microsoft работали над своим собственным языком шейдеров. Который они, включив всё своё коллективное воображение, назвали… Высокоуровневым Языком Шейдеров (HLSL). Но их подход к языку был фундаментально иным.

Наибольшей проблемой языка от 3D Labs было то, что он был встраиваемым. Microsoft полностью самостоятельно определяла свой язык. Они выпустили компилятор, который генерировал ассемблерный код для шейдеров SM 2.0 (или выше), который, в свою очередь, можно было скармливать D3D. Во времена D3D v9, HLSL никогда не касался D3D напрямую. Он был хорошей, но необязательной абстракцией. У разработчика всегда была возможность взять выхлоп компилятора и подправить его для максимальной производительности.

В языке от 3D Labs ничего этого не было. Вы отдаёте драйверу C-подобный язык, и он создаёт шейдер. На этом всё. Никакого ассемблерного шейдера, ничего, что можно скормить чему-то ещё. Только объект OpenGL, представляющий шейдер.

Для пользователей OpenGL это означало, что они становились подвержены капризам разработчиков OpenGL, которые только научились компилировать ассемблероподобные языки. В компиляторах новорождённого языка шейдеров OpenGL (GLSL) свирепствовали баги. Что ещё хуже, если вам удавалось заставить шейдер корректно компилироваться на различных платформах (что уже само по себе было большим достижением), то он всё ещё был подвержен оптимизаторам тех времён, которые были не так уж оптимальны, как могли бы быть.

Это было большим, но не единственным недостатком GLSL. Далеко не единственным.

В D3D, как и в старых ассемблерных языках OpenGL, можно было смешивать и всячески комбинировать вершинные и фрагментные шейдеры. Можно было использовать любой вершинный шейдер с любым совместимым фрагментным шейдером, если они взаимодействовали через одинаковый интерфейс. Более того, допускалась даже некоторая несовместимость: например, вершинный шейдер мог подать на выход значение, которое не использовалось фрагментным шейдером.

В GLSL ничего такого не было. Вершинный и фрагментный шейдер сплавлялись воедино, образовывая нечто, названное компанией 3D Labs «программным объектом». Поэтому, для совместного использования нескольких вершинных и фрагментных шейдеров в различных комбинациях, приходилось создавать несколько программных объектов. Это стало причиной второй по величине проблемы.

3D Labs думали, что они самые умные. Они взяли C/C++ за основу для модели компиляции GLSL. Это когда вы берёте один c-файл и и компилируете его в объектный файл, а затем берёте несколько объектных файлов и компонуете их в программу. Именно так компилируется GLSL: сначала вы компилируйте вершинный или фрагментный шейдер в шейдерный объект, затем помещаете эти объекты в программный объект и компонуете их воедино чтобы наконец сформировать программу.

В теории это позволяло появиться таким крутым вещам, как «библиотечные» шейдеры, которые содержат код, вызываемый основным шейдером. На практике это приводило к тому, что шейдеры компилировались дважды: один раз на стадии компиляции и второй раз на стадии компоновки. В частности, этим славился компилятор от nVidia. Он не генерировал какой-либо промежуточный объектный код; он компилировал вначале, выбрасывал полученный результат и компилировал заново на стадии компоновки.

Таким образом, чтобы приделать вершинный шейдер к двум разным фрагментным шейдерам, приходилось компилировать намного больше, чем в D3D. Особенно с учётом того, что вся компиляция производится оффлайново, а не перед непосредственным исполнением программы.

У GLSL были и другие проблемы. Возможно, было бы неправильным сваливать всю вину на 3D Labs, ибо в конечном итоге ARB утвердили и включили в OpenGL язык шейдеров (но ничего больше из предложений 3DLabs). Однако, изначальная идея всё равно была за 3D Labs.

И теперь самое печальное: 3D Labs были правы (в основном). GLSL не векторный язык, каким в то время был HLSL. Так случилось потому, что железо 3D Labs было скалярным (как современное железо от nVidia), и они были полностью правы в выборе направления, которому позднее последовали многие производители оборудования.

Они были правы и с выбором модели компиляции для «высокоуровневого» языка. Даже D3D в итоге к этому пришёл.

Проблема в том, что 3D Labs были правы в неправильное время. И в попытках попасть в будущее преждевременно, в попытках быть готовыми к будущему, они отставили в сторону настоящее. Это выглядит как T&L-функциональность в OpenGL, которая была в нём всегда. За исключением того, что T&L-конвейер OpenGL был полезным и до появления аппаратного T&L, а GLSL был обузой до того как остальной мир догнал его.

GLSL — это хороший язык сейчас. Но что было в то время? Он был ужасен. И OpenGL пострадал от этого.

На подходе к апофеозу

Я поддерживаю ту точку зрения, что 3D Labs нанесли OpenGL смертельный удар, но последний гвоздь в крышку гроба забил сам ARB.

Возможно вы слышали эту историю. Во времена OpenGL 2.1, у OpenGL были большие проблемы. Он тащил за собой огромный груз совместимости. API больше не был простым в использовании. Одну вещь можно было сделать пятью разными способами и непонятно какой из них быстрее. Можно было «изучить» OpenGL по простым руководствам, но при этом вы не изучали тот OpenGL, который даёт настоящую графическую мощь и производительность.

ARB решили предпринять ещё одну попытку изобрести OpenGL. Это было как «OpenGL 2.0» от 3D Labs, но лучше, потому что за этой попыткой стоял ARB. Они назвали это «Longs Peak».

Что такого плохого в том, чтобы потратить немного времени на улучшение API? Плохо то, что Microsoft оказалась в довольно шатком положении. Это было время перехода на Vista.

В Vista Microsoft решили внести давно напрашивающиеся изменения в графические драйверы. Они заставили драйверы обращаться к ОС за виртуализацией графической памяти и многим другим.

Можно долго спорить о достоинствах такого подхода, и о том, был ли он вообще возможен, но факт остаётся фактом: Microsoft сделала D3D 10 только для ОС Vista и выше. Даже на поддерживающем D3D железе было невозможно запустить D3D приложение без Висты.

Вы возможно помните, что Виста… скажем так, работала не очень хорошо. Итак, у нас была неторопливая ОС, новый API, который работал только на этой ОС, и новое поколение железа, которое нуждалось в этом API и ОС чтобы делать нечто большее, чем просто превосходить предыдущее поколение в производительности.

Тем не менее, разработчики могли использовать функциональность уровня D3D 10 через OpenGL. То есть могли бы, если бы ARB не был занят работой над Long Peaks.

ARB потратили добрые полтора-два года, работая над улучшением API. Ко времени выхода OpenGL 3.0 переход на Висту закончился, Windows 7 была на подходе, и разработчиков игр больше не заботила функциональность уровня D3D 10. В конце концов, оборудование для D3D 10 прекрасно работало с приложениями на D3D 9. С увеличением темпов портирования с ПК на консоли (или с переходом ПК-разработчиков на консольный рынок), разработчикам всё меньше была нужна функциональность D3D 10.

Если бы разработчики получили доступ к этой функциональности даже на Windows XP, развитие OpenGL могло бы получить живительный заряд бодрости. Но ARB упустили эту возможность. А хотите знать что самое ужасное?

ARB не смогли изобрести API с нуля несмотря на трату двух драгоценных лет на попытки сделать это. Поэтому они вернули статус-кво, добавив лишь механизм для объявления функциональности устаревшей.

В итоге ARB не только упустили ключевые возможности, но и не выполнили ту работу, которая привела их к этому упущению. Это был epic fail по всем направлениям.

Такова история о противостоянии OpenGL и Direct3D. История упущенных возможностей, величайшей глупости, умышленного безрассудства и банальных нелепостей.

Знакомимся с OpenGL / Хабр

OpenGL

Знакомство с OpenGL нужно начать с того, что OpenGL — это 

спецификация

. Т.е. OpenGL лишь определяет набор обязательных возможностей. Реализация же зависит от конкретной платформы.

OpenGL является кроссплатформенным, независимым от языка программирования API для работы с графикой. OpenGL — низкоуровневый API, поэтому для работы с ним неплохо иметь некоторое представление о графике в целом и знать основы линейной алгебры.

Именования

Скажем пару слов об именовании функций в OpenGL. Во-первых имена всех функций, предоставляемых непосредственно OpenGL, начинаются с приставки 

gl

. Во-вторых функции, задающие некоторый параметр, характеризующийся набором чисел (например координату или цвет), имеют суффикс вида [число параметров + тип параметров + представление параметров].


  • Число параметров — указывает число принимаемых параметров. Принимает следующие значения: 1, 2, 3, 4
  • Тип параметров — указывает тип принимаемых параметров. Возможны следующие значения: b, s, i, f, d, ub, us, ui. Т.е. byte (char в C, 8-битное целое число), short (16-битное целое число), int (32-битное целое число), float (число с плавающей запятой), double (число с плавающей запятой двойной точности), unsigned byte, unsigned short, unsigned int (последние три — беззнаковые целые числа)
  • Представление параметров — указывает в каком виде передаются параметры, если каждое число по отдельности, то ничего не пишется, если же параметры передаются в виде массива, то к названию функции дописывается буква v

Пример:

glVertex3iv

задает координату вершины, состоящую из трех целых чисел, передаваемых в виде указателя на массив.

Графика

Все графические объекты в OpenGL представляют собой набор точек, линий и многоугольников. Существует 10 различных примитивов, при помощи которых строятся все объекты. Как двухмерные, так и трехмерные. Все примитивы в свою очередь задаются точками — вершинами.


  • GL_POINTS — каждая вершина задает точку
  • GL_LINES — каждая отдельная пара вершин задает линию
  • GL_LINE_STRIP — каждая пара вершин задает линию (т.е. конец предыдущей линии является началом следующей)
  • GL_LINE_LOOP — аналогично предыдущему за исключением того, что последняя вершина соединяется с первой и получается замкнутая фигура
  • GL_TRIANGLES — каждая отдельная тройка вершин задает треугольник
  • GL_TRIANGLE_STRIP — каждая следующая вершина задает треугольник вместе с двумя предыдущими (получается лента из треугольников)
  • GL_TRIANGLE_FAN — каждый треугольник задается первой вершиной и последующими парами (т.е. треугольники строятся вокруг первой вершины, образуя нечто похожее на диафрагму)
  • GL_QUADS — каждые четыре вершины образуют четырехугольник
  • GL_QUAD_STRIP — каждая следующая пара вершин образует четырехугольник вместе с парой предыдущих
  • GL_POLYGON — задает многоугольник с количеством углов равным количеству заданных вершин

Для задания примитива используется конструкция 

glBegin (тип_примитива)…glEnd ()

. Вершины задаются 

glVertex*

. Вершины задаются против часовой стрелки. Координаты задаются от верхнего левого угла окна. Цвет вершины задается командой

glColor*

. Цвет задается в виде RGB или RGBA. Команда glColor* действует на все вершины, что идут после до тех пор, пока не встретится другая команда glColor* или же на все, если других команд glColor* нет.

Вот код рисующий квадрат с разноцветными вершинами:


  1. glBegin(GL_QUADS);
  2. glColor3f(1.0, 1.0, 1.0);
  3. glVertex2i(250, 450);
  4. glColor3f(0.0, 0.0, 1.0);
  5. glVertex2i(250, 150);
  6. glColor3f(0.0, 1.0, 0.0);
  7. glVertex2i(550, 150);
  8. glColor3f(1.0, 0.0, 0.0);
  9. glVertex2i(550, 450);
  10. glEnd();

Основы программы на OpenGL

Для платформонезависимой работы с окнами можно использовать библиотеку 

GLUT

. GLUT упрощает работу с OpenGL.

Для инициализации GLUT в начале программы надо вызвать

glutInit (&argc, argv)

. Для задания режима дисплея вызывается 

glutInitDisplayMode (режим)

, где режим может принимать следующие значения:


  • GLUT_RGBA — включает четырехкомпонентный цвет (используется по умолчанию)
  • GLUT_RGB — то же, что и GLUT_RGBA
  • GLUT_INDEX — включает индексированный цвет
  • GLUT_DOUBLE — включает двойной экранный буфер
  • GLUT_SINGLE — включает одиночный экранный буфер (по умолчанию)
  • GLUT_DEPTH — включает Z-буфер (буфер глубины)
  • GLUT_STENCIL — включает трафаретный буфер
  • GLUT_ACCUM — включает буфер накопления
  • GLUT_ALPHA — включает альфа-смешивание (прозрачность)
  • GLUT_MULTISAMPLE — включает мультисемплинг (сглаживание)
  • GLUT_STEREO — включает стерео-изображение

Для выбора нескольких режимов одновременно нужно использовать побитовое ИЛИ '|'. Например: glutInitDisplayMode (GLUT_DOUBLE|GLUT_RGBA|GLUT_DEPTH) включает двойную буферизацию, Z-буфер и четырехкомпонентный цвет. Размеры окна задаются 

glutInitWindowSize (ширина, высота)

. Его позиция —

glutInitWindowPosition (х, у)

. Создается окно функцией

glutCreateWindow (заголовок_окна)

.

GLUT реализует событийно-управляемый механизм. Т.е. есть главный цикл, который запускается после инициализации, и в нем уже обрабатываются все объявленные события. Например нажатие клавиши на клавиатуре или движение курсора мыши и т.д. Зарегистрировать функции-обработчики событий можно при помощи следующих команд:


  • void glutDisplayFunc (void (*func) (void)) — задает функцию рисования изображения
  • void glutReshapeFunc (void (*func) (int width, int height)) — задает функцию обработки изменения размеров окна
  • void glutVisibilityFunc (void (*func)(int state)) — задает функцию обработки изменения состояния видимости окна
  • void glutKeyboardFunc (void (*func)(unsigned char key, int x, int y)) — задает функцию обработки нажатия клавиш клавиатуры (только тех, что генерируют ascii-символы)
  • void glutSpecialFunc (void (*func)(int key, int x, int y)) — задает функцию обработки нажатия клавиш клавиатуры (тех, что не генерируют ascii-символы)
  • void glutIdleFunc (void (*func) (void)) — задает функцию, вызываемую при отсутствии других событий
  • void glutMouseFunc (void (*func) (int button, int state, int x, int y)) — задает функцию, обрабатывающую команды мыши
  • void glutMotionFunc (void (*func)(int x, int y)) — задает функцию, обрабатывающую движение курсора мыши, когда зажата какая-либо кнопка мыши
  • void glutPassiveMotionFunc (void (*func)(int x, int y)) — задает функцию, обрабатывающую движение курсора мыши, когда не зажато ни одной кнопки мыши
  • void glutEntryFunc (void (*func)(int state)) — задает функцию, обрабатывающую движение курсора за пределы окна и его возвращение
  • void glutTimerFunc (unsigned int msecs, void (*func)(int value), value) — задает функцию, вызываемую по таймеру

Затем можно запускать главный цикл

glutMainLoop ()

.

Первая программа

Теперь мы знаем основы работы с OpenGL. Можно написать простую программу для закрепления знаний.

Начнем с того, что нужно подключить заголовочный файл GLUT:


  1. #if defined(linux) || defined(_WIN32)
  2. #include <GL/glut.h>    /*Для Linux и Windows*/
  3. #else
  4. #include <GLUT/GLUT.h>  /*Для Mac OS*/
  5. #endif

Теперь мы уже знаем, что писать в main. Зарегистрируем два обработчика: для рисования содержимого окна и обработки изменения его размеров. Эти два обработчика по сути используются в любой программе, использующей OpenGL и GLUT.


  1. int main (int argc, char * argv[])
  2. {
  3.         glutInit(&argc, argv);
  4.         glutInitDisplayMode(GLUT_DOUBLE|GLUT_RGBA); /*Включаем двойную буферизацию и четырехкомпонентный цвет*/
  5.        
  6.         glutInitWindowSize(800, 600);
  7.         glutCreateWindow(«OpenGL lesson 1»);
  8.        
  9.         glutReshapeFunc(reshape);
  10.         glutDisplayFunc(display);
  11.        
  12.         glutMainLoop();
  13.  
  14.         return 0;
  15. }

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

glViewport (х, у, ширина, высота)

. Затем загрузим матрицу проекции 

glMatrixMode (GL_PROJECTION)

, заменим ее единичной

glLoadIdentity ()

и установим ортогональную проекцию. И наконец загрузим модельно-видовую матрицу 

glMatrixMode (GL_MODELVIEW)

и заменим ее единичной.

В итоге получим:


  1. void reshape(int w, int h)
  2. {
  3.         glViewport(0, 0, w, h);
  4.        
  5.         glMatrixMode(GL_PROJECTION);
  6.         glLoadIdentity();
  7.         gluOrtho2D(0, w, 0, h);
  8.        
  9.         glMatrixMode(GL_MODELVIEW);
  10.         glLoadIdentity();
  11. }

Осталось только написать функцию рисования содержимого окна. Рисовать будем тот квадрат, что я приводил выше в качестве примера. Добавить придется совсем немного кода. Во-первых перед рисованием надо очистить различные буфера при помощи 

glClear (режим)

. Используется также как и glutInitDisplayMode. Возможные значения:


  • GL_COLOR_BUFFER_BIT — для очистки буфера цвета
  • GL_DEPTH_BUFFER_BIT — для очистки буфера глубины
  • GL_ACCUM_BUFFER_BIT — для очистки буфера накопления
  • GL_STENCIL_BUFFER_BIT — для очистки трафаретного буфера

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

glutSwapBuffers ()

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

мерцания

экрана.

Получаем:


  1. void display()
  2. {
  3.         glClear(GL_COLOR_BUFFER_BIT);
  4.        
  5.         glBegin(GL_QUADS);
  6.         glColor3f(1.0, 1.0, 1.0);
  7.         glVertex2i(250, 450);
  8.         glColor3f(0.0, 0.0, 1.0);
  9.         glVertex2i(250, 150);
  10.         glColor3f(0.0, 1.0, 0.0);
  11.         glVertex2i(550, 150);
  12.         glColor3f(1.0, 0.0, 0.0);
  13.         glVertex2i(550, 450);
  14.         glEnd();
  15.        
  16.         glutSwapBuffers();
  17. }

Итог

Все! Можно компилировать. Должно получиться что-то вроде этого:



Весь код целиком

(для кто не осилил статью).

В принципе ничего сложного в этом нет, по крайней мере если вы уже сталкивались с графикой до этого.

OpenGL — удобный инструмент для создания кроссплатформенных приложений, использующий графику. OpenGL легко использовать с тем языком программирования, который вам более удобен. Привязки к OpenGL есть для множества популярных языков, таких как C, C++, C#, Java, Python, Perl, VB и других. Посмотреть информацию о них можно на официальном сайте OpenGL.

Устранение проблем с OpenGL | After Effects CS4-CS5.5

В этом документе содержатся рекомендации по решению проблем, связанных с OpenGL, проявляющихся при использовании After Effects. Проблемы с OpenGL могут проявляться различным образом, включая (но не ограничиваясь) следующее:

  • Adobe After Effects испытывает сбой или закрывается без ошибки при запуске.
  • Сбой или зависание при очистке шкалы времени или предварительном просмотре или рендеринге композиции.
  • Сбой при изменении настройки эффекта, когда включен предварительный просмотр OpenGL.
  • Сбой или зависание при включении или отключении предварительного просмотра OpenGL.
  • Перерисовка в окне композиции занимает очень много времени.
  • Артефакты или блоки «мусорных» пикселов отображаются в окне композиции.
  • Окно композиции отображается по-разному в браузере, когда предварительные просмотры OpenGL включены и отключены.
  • Сообщение об ошибке, например:

    «Предупреждение After Effects: Произошла ошибка при обработке команд OpenGL».

    «Инструкция 0x00fe1940 ссылается на память по адресу 0x000000000. Память не может быть «read»».

    «AE_OpenGL: не удалось создать карту теней (5065::0)»

    «Данная композиция слишком сложна для аппаратного обеспечения OpenGL».

    «Ошибка After Effects: AE_OpenGL: Ошибка создания текстуры. (5065 :: 0)»

Сведения о том, как настраивать параметры предварительного просмотра в After Effects для OpenGL, и список новых функций в After Effects, которые могут выполняться с помощью OpenGL, см. в разделе Рендеринг с помощью OpenGL в справке по After Effects.

Для того, чтобы данный документ принес вам пользу, выполняйте приведенные в нем задания по порядку. Запишите задания, которые вы выполняете, и запишите результаты каждого задания, в том числе ошибки и иные проблемы. Служба технической поддержки Adobe сможет использовать эту информацию, чтобы помочь вам в устранении неполадки.

Для того, чтобы произвести некоторые процедуры, перечисленные в этом документе, вы должны войти в систему как администратор.

В Windows, для некоторых из этих процедур требуется определение местонахождения скрытых файлов и скрытых папок. Для некоторых процедур требуется поиск файлов по их полному имени, включая расширения (например, example_filename.ini). По умолчанию Проводник Windows не показывает скрытые файлы и папки, а также расширения имен файлов, которые он распознает. См. Показать скрытые файлы и папки в Windows для получения подробной информации.

Для Windows Vista, упомянутые в данном документе уровни, которые ссылаются на Панель управления, являются ссылками на ее классический вид. Для получения информации о переключении Панели управления в классический вид и многих других общих процедурах операционной системы см. раздел Общие процедуры операционной системы.

Приведенные ниже рекомендации помогут вам решить самые распространенные проблемы, связанные с OpenGL. Перед выполнением любого из указанных действий создайте резервные копии всех личных файлов (например, созданных вами файлов After Effects). После обнаружения системной ошибки всегда перезагружайте компьютер, чтобы обновить память. Если Вы продолжите работу без перезагрузки компьютера, это может лишь усугубить проблему.

Настройки производительности с OpenGL - 2021

Чтобы изменить параметры системы, нажмите кнопку Параметры (панель инструментов "Стандартная") или .

Использовать программу OpenGL выбран

  • Включить:

    Высокое качество для нормального вида

    (Параметры быстродействия)

  • Выключить:

    Высокое качество для динамического вида

    (Параметры быстродействия)

    Отобразить закрашенные плоскости

    (Параметры отображения и выбора)

    Верхний/нижний полутоновой переход цветов

    (Параметры цвета)

    Отобразить плоскость при оттенении

    (Параметры эскиза)

    Тени

    (Нажмите кнопку Просмотр настроек (панель инструментов Отображение поверх окна вида) и отключите Тени в режиме Закрасить)

Использовать программу OpenGL не выбрана

  • Включить:

    Высокое качество для нормального вида

    (Параметры быстродействия)

    Высокое качество для динамического вида

    (Параметры быстродействия)

    Плавный полутоновой переход цвета (Верхний/нижний переход цвета)

    (Параметры цвета)

    Отобразить закрашенные плоскости

    (Параметры отображения и выбора)

    Тени

    (Нажмите кнопку Просмотр настроек (панель инструментов Отображение поверх окна вида) и отключите Тени в режиме Закрасить)

  • Выключить:

    Отобразить плоскость при оттенении

    (Параметры эскиза)

изучайте технологии для программирования 2D и 3D графики, 3D моделирования, методы работы с операционными системами и многое удругое.

OpenGL (Open Graphics Library — открытая графическая библиотека, графический API) — спецификация, определяющая независимый от языка программирования платформонезависимый программный интерфейс для написания приложений, использующих двумерную и трёхмерную компьютерную графику.
Подробнее, что такое OpenGL

просмотров:

12 938

комментариев:

2

обновлено:

19.06.2017 Проигрывание видео-заставки в C# Данный урок основывается на авторской публикации пользователя. В нем речь пойдет о быстром и простом в реализации способе проиграть видео на основной форме окна приложения с помощью COM элемента Windows Media Player.

просмотров:

3 805

комментариев:

0

обновлено:

19.06.2017 Загрузка .X (DirectX) файлов в OpenGL Данный урок основывается на авторской публикации пользователя. Так как OpenGL - это кросс-платформенная библиотека, которая была написана для вывода графики, а не для работы с файловой системой и потоками, поэтому в ней нет встроенных решений для загрузки трехмерных объектов (<b>Meshs</b>) из файла. В этом уроке вы научитесь загружать файл .X (DirectX).

просмотров:

12 264

комментариев:

0

обновлено:

19.06.2017 Создание класса Камеры (C#, TaoFramework) Данный урок основывается на авторской публикации пользователя. В нем вы познакомитесь с технологией создания камеры с видом как от первого, так и от третьего лица, научитесь поворачивать и перемещать ее. Для этого понадобится разобраться с командой библиотеки Glu - GluLookAt, которая принимает три набора аргументов.

просмотров:

4 614

комментариев:

0

обновлено:

19.06.2017 Звук в игре (мультимедиа, С++) Данный урок основывается на авторской публикации пользователя. В нем вы научитесь создавать код для воспроизведения звуковых файлов с помощью простой и удобной библиотеки Audiere (C++). Audiere - это доступная и несложная, кроссплатформенная, высокоуровневая библиотека для воспроизведения звуковых файлов.

просмотров:

3 915

комментариев:

0

обновлено:

19.06.2017 Проигрывание видео (Microsoft.DirectX.AudioVideoPlayback) Данный урок основывается на авторской публикации пользователя. В нем вы познакомитесь с методом проигрывания видео контента на форме приложения с использованием Microsoft.DirectX.AudioVideoPlayback. В статье будет рассмотрена возможность воспроизведения видео, а также обработка события нажатия клавиши для остановки воспроизведения видео-контента

просмотров:

9 917

комментариев:

0

обновлено:

19.06.2017 GLFW. Скелет OpenGL приложения со сглаживанием. (C/C++) Данный урок основывается на авторской публикации пользователя. В нем вы научитесь создавать приложения с использованием OpenGL в связке с библиотекой GLFW. GLFW -  бесплатная кроссплатформенная библиотека для создания оконных приложений, позволяющая быстро реализовывать поддержку OpenGL 3.2 в вашем приложении. Кроме того, она предлагает множество дополнительных возможностей, таких как работа с несколькими окнами, несколькими мониторами и поддержка большого количество устройств ввода.

просмотров:

10 497

комментариев:

3

обновлено:

19.06.2017 OpenGL. Убрать консольное окно (С/C++) Данный урок основывается на авторской публикации пользователя. У многих при использовании библиотек (GLUT, GLFW), создающих окна и контекст OpenGL, возникает необходимость убрать консоль, которая появляется вместе с запуском OpenGL-приложения. В данном уроке вы познакомитесь с простым и коротким способом, который избавит вас от этой проблемы.

просмотров:

7 185

комментариев:

5

обновлено:

19.06.2017 Использование Freetype. Получение битового образа символов Данный урок основывается на авторской публикации пользователя. В нем вы подробнее познакомитесь с библиотекой Freetype, которая позволяет читать файлы шрифтов, таких как TrueType fonts, OpenType fonts, BDF fonts и многие другие. Кроме того, с ее помощью можно извлекать битовые образы глифов, а также различную дополнительную информацию о шрифтах и глифах, необходимую для их правильной отрисовки.

просмотров:

8 263

комментариев:

0

обновлено:

20.06.2017 C#/Tao.framework. Простой способ отобразить текст в OpenGL Данный урок основывается на авторской публикации пользователя. Задача отрисовки текста в OpenGL обычно сводится к рисованию прямоугольников с натянутой текстурой, на которой отображена та или иная буква. Затем нужно располагать их друг относительно друга так, чтобы получались слова. На C# это делается очень легко с помощью встроенных методов класса Graphics.

просмотров:

10 985

комментариев:

3

обновлено:

20.06.2017 Создание онлайн-игры: основы Автор:   |   Теги: online Данный урок основывается на авторской публикации пользователя. В этой статье вы познакомитесь с базовыми понятиями, в которых необходимо разбираться разработчику для создания онлайн-игры, а также увидите, как можно создать простейший сервер на платформе .NET с использованием протокола TCP/IP.

OpenGL в фотошопе

OpenGL — это спецификация, которая помогает графическим контроллерам (видеокартам) современных компьютеров быстрее и эффективнее рисовать графику.

Чтобы определить, поддерживает ли ее ваш компьютер, перейдя в меню Редактирование — Установки — Производительность. Если установлен флажок Включить отрисовку OpenGL, значит все включено.

Если флажок не установлен, но вы можете установить его, сделайте это.

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

Параметр Включить отрисовку OpenGL активирует определенные функции и расширенные дополнительные элементы интерфейса. Эти параметры вступают в силу только для новых документов.

Он активируют следующие функции фотошопа:

  • поворот вида;
  • масштабирование с высоты птичьего полета;
  • пиксельная сетка;
  • настройка «Захват рисования»;
  • масштаб перетаскиванием;
  • палитра цветов HUD;
  • кольцо пробы;
  • изменение размера и жесткости кисти на холсте;
  • предварительный просмотр кончика щетины;
  • чеканка.

Отвечает за следующие улучшения:

  • плавное панорамирование и масштабирование;
  • наложение теней для границ холста;
  • ускорение взаимодействия с 3D-объектами;
  • виджет 3D-оси;
  • 3D-наложения.

Также большинство установок 3D-эффектов выключены, если отключена отрисовка OpenGL.