Что такое opengl es2

В чем разница между OpenGL ES и OpenGL?

Android использует OpenGL ES, в чем разница между ним и OpenGL?

Нет ни одного места, где вы могли бы легко определить, что находится в ES, а что нет. Даже одно определение таково: «OpenGL-ES похож на OpenGL, но без большого количества вещей. Например, нет glBegin или glEnd».

Увы, пока ни один из ответов не является ни полным, ни полностью правильным. Действительно, OpenGL-ES делает две вещи, которые не делает OpenGL:

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

2) он обеспечивает интерфейс для оконного менеджера (и, следовательно, встроенного графического оборудования) мобильной платформы. Эта часть OpenGL-ES, известная как EGL, очень похожа на GLUT на рабочем столе. За исключением того, что у него нет ни одного из тех удобных методов, которые не являются строго необходимыми для этого интерфейса. Таким образом, не существует API для рисования многогранников или сфер (как в GLUT). Но есть, например, API, которые соответствуют GLUT init (), и обратным вызовам DisplayFunc () и ReshapeFunc ().

На Android доступно две версии OpenGL ES:

Внимание, OpenGL ES 2.0 не совместим с OpenGL ES 1.X!

Почти все телефоны Android имеют графический процессор OpenGL 1.X и большинство из них имеют 2.0. OpenGL ES 2.0 доступен только с Android 2.x или новее.

Источник

OpenGL ES 2.0. Один миллион частиц

В этой статье мы рассмотрим один из вариантов реализации системы частиц на OpenGL ES 2.0. Подробно поговорим об ограничениях, опишем принципы и разберем небольшой пример.

Ограничения

Информация по процессорам:

Есть проблема с NVIDIA Tegra 2/3/4, на этой серии работает ряд популярных устройств таких, как Nexus 7, HTC One X, ASUS Transformer.

Система частиц

Рассматривая системы частиц, генерируемые на CPU, в разрезе увеличения количества обрабатываемых данных (количества частиц), основной проблемой производительности становится копирование (выгрузка) данных из оперативной памяти в память видеоутсройства на каждом кадре. Поэтому, наша основная задача — избежать этого копирования, перенеся вычисления в неоперативный режим на графический процессор.

Напомним, что в OpenGL ES 2.0 нет встроенных механизмов таких, как Transform Feedback (доступного в OpenGL ES 3.0) или Compute Shader (доступного в OpenGL ES 3.1), позволяющих производить вычисления на GPU.

Суть метода заключается в том, чтобы использовать в качестве буфера данных для хранения, характеризующих частицу, величин (координаты, ускорения и т.д.) — текстуры и обрабатывать их средствами вершинных и фрагментных шейдеров. Также, как мы храним и загружаем нормали, говоря о Normal mapping. Размер буфера, в нашем случае, пропорционален количеству обрабатываемых частиц. Каждый тексель хранит отдельную величину (величины, если их несколько) для отдельной частицы. Соответственно, количество обрабатываемых величин находиться в обратной зависимости от количества частиц. Например, для того, чтобы обработать позиции и ускорения для 1048576 частиц, нам понадобиться две текстуры 1024×1024 (елси нет необходимости в сохранение соотношения сторон)

Здесь есть дополнительные ограничения, которые нам необходимо учесть. Чтобы иметь возможность записать какую-либо информацию, формат пиксельных данных текстуры должен поддерживаться реализацией как color-renderable format. Это означает, что мы можем использовать текстуру в качестве цветового буфера в рамках закадровой отрисовки. Спецификация описывает только три таких формата: GL_RGBA4, GL_RGB5_A1, GL_RGB565. Принимая во внимание предметную область, нам требуется как минимум 32 бита на пиксель, чтобы обрабатывать такие величины, как координаты или ускорения (для двухмерного случая). Поэтому, упомянутых выше форматов нам недостаточно.

По данным GPUINFO на 2013 — 2015 год поддержка расширений следующая:

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

Итак, возвращаясь к сути, общая схема того что мы будем делать, выглядит так:

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

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

Ядро прохода, это обычный texture mapping на два треугольника, где в качестве текстурных карт выступают наши буферы данных. Общий вид шейдеров следующий:

Реализация функций распаковки/запаковки зависит от величин, которые мы обрабатываем. На данном этапе мы опираемся на требование, описанное в начале, о высокой точности вычислений.
Например, для двухмерных координат (компоненты [x, y] по 16 бит) функции могут выглядить так:

Отрисовка

После этапа вычислений следует этап отрисовки. Для доступа к частицам на этом этапе нам необходим, для перебора, некоторый внешний индекс. В качестве такого индекса будет выступать вершинный буфер (Vertex Buffer Object) с текстурными координатами буфера данных. Индекс создается и инициализируется (выгружается в память видеоустройства) один раз и в процессе не меняется.

На этом шаге, вступает в силу требование о доступе к текстурным картам. Вершинный шейдер похож на фрагментный с этапа вычислений:

Пример

В качестве небольшого примера, мы попробуем сгенерировать динамическую систему из 1048576 частиц, известную как Strange Attractor.

Обработка кадра состоит из нескольких этапов:

Compute Stage

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

Такая система еще называется Peter de Jong Attractors. С течением времени, мы будем менять только коэфициенты.

Renderer Stage

На этапе рендеринга сцены, мы отрисуем наши частицы обычными спрайтами.

Postprocessing

В заключение, на этапе постобработки, мы наложим несколько эффектов

Gradient mapping. Добавляет цветовое содержание на основе яркости исходного изображения.

Bloom. Добавляет небольшое свечение.

Продолжение

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

Источник

Что такое opengl es2

Для чего эта тема?
У многих создалась иллюзия сложности изучения «OpenGL», и не понимания простоты работы этой библиотеки для программиста.
И даже используя «движок» нужно понимать как это взаимодействует с ОС, что может/не может конкретные устройства.

Все дальнейшее посвящено библиотеке OpenGL ES 2.0 под Android, и последующим версиям.

Что такое библиотека OpenGL ES 2.0?
На базовом уровне, OpenGL ES 2.0 — это просто спецификация, то есть документ, описывающий набор функций и их точное поведение. Производители оборудования на основе этой спецификации создают реализации — библиотеки функций, соответствующих набору функций спецификации ( W: ).

OpenGL ориентируется на следующие две задачи:
Скрыть сложности адаптации различных 3D-ускорителей, и предоставить разработчику единый API.

Для программиста OpenGL представляет низкоуровневую библиотеку для доступа к GPU ( графическому процессору ).

Схема вариантов реализации библиотеки ( с точки зрения программиста + для сравнения DirectX ):

В Android на 99.99% используется вариант В.
То есть реализация OpenGL ES входит в состав драйвера,
в отличие от DirectX, которая скорее является прослойкой между приложением и драйвером.
Есть еще отдельные реализации OpenGL, например Mesa3D, но они в основном достаточно медленно развиваются и часто отстают на несколько поколений от решений производителей чипов.

Теперь чуть-чуть про GPU:
В данный момент ( декабрь 2012г. ) в Android устройствах присутствуют два поколения GPU, Поддерживающие OpenGL ES 2.0 ( почти 95% ) и поддерживающие только версии 1.0 и 1.1.
Аппаратной обратной совместимости НЕТ.
Поэтому рассматривать версию стандарта меньше 2.0 на взгляд автора кроме как археологам не имеет смысла.
( стандарт версии 3.0 обратно совместим с 2.0 )

Структура конвейера OpenGL 1.x:

Структура конвейера OpenGL 2.x+:

Что может OpenGL ES?
Основным принципом работы OpenGL является получение наборов векторных графических примитивов в виде точек, линий и многоугольников с последующей математической обработкой полученных данных и построением растровой картинки на экране и/или в памяти. Векторные трансформации и растеризация выполняются графическим конвейером (graphics pipeline), который по сути представляет собой дискретный автомат. Абсолютное большинство команд OpenGL попадают в одну из двух групп: либо они добавляют графические примитивы на вход в конвейер, либо конфигурируют конвейер на различное исполнение трансформаций.
Ключевая особенность — CPU и GPU работают не синхронно, то есть CPU не дожидается окончания исполнения команд от GPU, а продолжает работать ( если не было дополнительных указаний ).
Есть стек команд ( инструкций ) OpenGL.
( стек бывает двух типов, fifo и lifo. FIFO — акроним «First In, First Out» (англ. ). Принцип «первым пришёл — первым ушёл», LIFO — акроним «Last In, First Out» (англ.), обозначающий принцип «последним пришёл — первым ушёл». В OpenGL используется fifo ( очередь )).

Представьте себе конвейер производства дед.мороза =)

Все статьи в PDF, благодаря who-e, oges2.zip ( 2.76 МБ )
. Надеюсь будет полезно. Спасибо who-e.

В теме нет куратора. Если в теме есть пользователь, желающий стать Куратором и соответствующий Требованиям для кандидатов, он может подать заявку в теме Хочу стать куратором (предварительно изучив шапку темы и все материалы для кураторов).
До назначения куратора, по вопросам наполнения шапки, обращайтесь к модераторам раздела через кнопку под сообщениями, на которые необходимо добавить ссылки.

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

Теперь пример простейшей инициализации OpenGL ES 2.0 под Android ( из премеров Google, абсолютно корявый и не применимый в реальной жизни =) ):

В приложении, методе OnCreate:

requestWindowFeature(Window.FEATURE_NO_TITLE); // Убираем заголовок
getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
WindowManager.LayoutParams.FLAG_FULLSCREEN); // Устанавливаем полноэкранный режим

// Далее устанавливаем версию OpenGL ES, равную 2
glSurfaceView.setEGLContextClientVersion(2);

renderer = new nRender();

glSurfaceView.setRenderer(renderer); // устанавливаем нашу реализацию GLSurfaceView.Renderer для обработки событий

>catch(RuntimeException e)<> // выводим окошко «увы, выше устройство слишком. «

далее создаем класс nRender

package com.example.ogl1;
import android.opengl.GLES20;
import android.opengl.GLSurfaceView;
import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.opengles.GL10;
import java.util.Random;

public class nRender implements GLSurfaceView.Renderer
<
public nRender() <
>

public void onDrawFrame(GL10 glUnused) < // Отрисовка кадра

Random rnd = new Random();

// Задаем случайный цвет и сводим с ума эпилептиков =)
// Цвет задается в формате RGBA, от 0.0f до 1.0f.
GLES20.glClearColor(((float)rnd.nextInt(2)/2.0f), ((float)rnd.nextInt(2)/2.0f), ((float)rnd.nextInt(2)/2.0f), 1.0f);

GLES20.glClear( GLES20.GL_COLOR_BUFFER_BIT ); // Очищаем буффер цвета
>

public void onSurfaceChanged(GL10 glUnused, int width, int height) < // изменение поверхности, например изменение размера

GLES20.glViewport(0, 0, width, height);
// Устанавливаем положение и размер вьюпорта
// вьюпорт устанавливаеться относительно поверхности ( OpenGLSurface ), в данном случае на весь экран.
// замечу, что GLES20.glClear очищает всю поверхность, все зависимости от установки Viewport.
>

public void onSurfaceCreated(GL10 glUnused, EGLConfig config) < // вызываеться при создании поверхности

Далее пробуем запустить, и получаем мечту эпилептика.

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

OpenGL по своему принципу является конечным автоматом.

Представьте себе конвейер производства дед.мороза =)

Пример.
Конвейер запущен, Деды Морозы поехали по ленте. И через 5 штук мы вспоминаем, что нам не нужны гламурно-сглаженные, но только рубленные топором, только хардкорные модели на выходе. Подходим к пульту и перещелкиваем первый тумблер (см. выше). Все, все последующие модели будут отрисовываться, словно резчик по дереву был пьян и забыл про шлифовку и прочие доработки. Нам ничего не нужно перещелкивать на пульте перед каждой последующей моделью.
Прибежала Снегурочка, наблюдающая все это непотребство на экране и сказала, что неплохо бы раскрасить Деда Мороза, потому что гламурное розовое нечто с неаккуратными краями смотрится на экране неканонично, хотя ей нравится. Берем у нее фотографию-картинку настоящего Деда Мороза, подсовываем в рамку под тумблером текстурирования и перещелкиваем его. Все, все последующие Деды Морозы будут выглядеть с наложенной картинкой-текстурой и с несглаженными гранями. Нам ничего не нужно перещелкивать на пульте перед каждой последующей моделью.
Снегурочка пришла еще через 10 моделей, уже немного нетрезвая, и заявила, что пусть лучше Дед Мороз будет гламурно ровненьким, но должен иметь сходство с фотографией. ок, перещелкиваем тумблер сглаживания и идем дальше праздновать НГ. На выходе получим текстурированного и сглаженного Деда Мороза для всех последующих моделей. Нам ничего не нужно перещелкивать на пульте перед каждой последующей моделью.

Источник

OpenGL ES 2.0 для начинающих

Одна из самых мощный сторон современных мобильных устройств Apple- это графическая подсистема, позволяющая писать качественные 2d и 3d игры с отличной производительностью и детальной графикой. О ней я и хочу рассказать, так как в интернете для новичков информации про OpenGL ES 2.0 на русском языке очень мало.

Итак, что же такое OpenGL? Это Открытая графическая библиотека (Open Graphics Library), которая имеет свой api, свои переменные, и является самой ближайшей точкой взаимодействия между процессором и графическим чипом (GPU).

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

В устройствах на iOS есть центральный процессор (CPU) и графический процессор (GPU). GPU призван разгрузить центральный процессор от обработки графических данных перед выводом на экран.
Другими словами, OpenGL позволяет рассчитывать все детали конечного изображения на графическом чипе (Графический чип в разы быстрее в расчетах чисел с плавающей точкой), а центральный процессор оставить для других расчетов, например, игровой логики.
Так же OpenGL предоставляет множество возможностей для хранения информации, данных и изображений в оптимальном для графического чипа формате для более быстрой обработки. Эти данные будут обрабатываться напрямую непосредственно графическим чипом.

Логика OpenGL

Примитивы

Буферы

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

буфер визуализации цвета хранит итоговое цветное изображение, созданное рендером OpenGL. Это цветное (RGB) изображение.
буфер визуализации глубины хранит координату глубины (точка z) объектов в пространстве.
буфер визуализации шаблона хранит видимую часть объекта (как маску видимой части). В буфере хранится черно-белое изображение.

Растеризация

Растеризация это процесс, когда OpenGL собирает всю информацию о 3d объектах (координаты, вершины и т. д. ) и создает 2d изображение, как правило для отображения на экране устройства.
В реализации OpenGL Apple вы не можете вывести изображение сразу на экран, а должны обязательно его поместить в кадровый буфер, а уже оттуда, средствами EAGL (Extended Apple GL) вывести его на экран устройства.

Конвейеры OpenGL

В OpenGL ES 2.0 используется программируемый конвейер. Это означает что вся ответственность за камеры, освещение, эффекты лежит полностью на разработчиках. Делается все это шейдерами. Таким образом, когда слышите о программируемом конвейере, думайте о шейдерах 🙂
Шейдеры это такие маленькие кусочки кода, маленькие программки, которые выполняются непосредственно на графическом чипе для совершения сложных расчетов.
Фиксированный конвейер это полная противоположность программируемому. Фиксированный конвейер предоставляет api для управления камерой, освещением, эффектами, материалами.

Для создания шейдеров в OpenGL ES используется язык, весьма похожий на C, называемый OpenGL ES Shader Language (GLSL ES или ESSL).
Как же работают шейдеры? Вы создаете их либо в отдельных файлах, либо прямо в коде, главное что бы строка, содержащая код шейдера, была отправлена в ядро OpenGL и скомпилирована там для использования.
Шейдеры работают в паре — вершинные шейдеры и фрагментные. Что бы понять что каждый из них означает, вернемся к примеру с кубом.

Вершинный шейдер

Вершинные шейдеры (vertex shader), так же известные как VS или VSH, это маленькие программы, которые выполняются для каждой вершины. Если посмотреть на куб на рисунке выше, то у куба получается 8 вершин (5 вершина невидимая). Соответственно вершинный шейдер обработает этот куб 8 раз на графическом процессоре.
Вершинный шейдер задаст конечные позиции вершин с учетом положения камеры, а так же подготовит и выведет некоторые переменные, требуемые для фрагментного шейдера. В OpenGL мы не можем задавать переменные напрямую для фрагментного шейдера, только через вершинный. Почему нельзя обращаться к фрагментному шейдеру напрямую? Давайте рассмотрим.

Фрагментный фейдер (fragment shader, FSH)

Давайте посмотрим вновь на куб.
5 вершина невидимая по причине местоположения и поворота куба в пространстве, значит мы можем видеть только 3 стороны куба, и они составляют 7 вершин.
Это то, что делает фрагментный шейдер. Он обрабатывает каждую видимую часть конечного изображения. Можно преставить каждую часть как пиксель, но это не совсем так, потому что пиксеть в рендеринге OpenGL и в итоговом изображение, которое вы видите на экране, может различаться по размеру. Таким образом фрагмент может быть больше или меньше нежели реальный пиксель, в зависимости от конфигурации устройства и параметров рендеринга. В кубе, приведенном выше, фрагментный шейдер обработает каждый пиксеть на всех 3х сторонах куба, сформированных с помощью 7 вершин.
Внутри фрагментного шейдера мы будем работать со всем, что связано с поверхностью- освещение, тени, отражения, текстуры и любые эффекты, которые вы захотите. Результат работы фрагментного шейдера это цвет пикселя в формате RGBA (красный, зеленый, синий и альфа-канал).
Вершинный и фрагментный шейдеры работают вместе. Один вершинный шейдер и один фрагментный, не больше и не меньше. Что бы гарантировать, что м ы не наделаем ошибок, OpenGL всегда компилирует пару VSH и FSH.

Ошибки в OpenGL

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

Если тема будет интересна, продолжу уже с реальными примерами для iOS.

Источник

• ← Что такое opencl и cuda
• Что такое opengl skia →