OpenGL ES

Все через шейдеры

Ох уж эти извращенцы! Лишь бы GLU/GLUT не использовать! А между тем, даже для жабоскриптика есть GLU!

GLU

устаревшее Г, которое годится только для студентов

GLUT

малоюзебальная херня для демок

Да что ты говоришь! Неужто есть стильно-модно-молодежные современные обертки? Которыми можно пользоваться точно так же просто, а не извращаться с идиотизмом под названием "шейдеры"?

«Обертки», которые ты хочешь - для даунов-ретроградов.

Для OpenGL существуют нормальные платформеные привязки разного уровня абстракции - egl, sfml, glfw, sdl2.

идиотизмом под названием «шейдеры»

Идиотизм - это отрицать шейдеры. Примерно такого же уровня как отрицание НТР. Хочешь песочницу - добро пожаловать в darkbasic.

Если тебе просто данные визуализировать, то есть специальные либы и софт.

2015
неиронично отвечать Eddy_Em

Ох уж эти извращенцы! Лишь бы GLU/GLUT не использовать!

И какая связь между шейдерами и мертвым хелпером а-ля glut? Очередное сравнение теплого с мягким.

малоюзебальная херня для демок

Эта херня еще и deprecated начиная с os x 10.9.

Которыми можно пользоваться точно так же просто, а не извращаться с идиотизмом под названием «шейдеры»?

Неужели есть апельсины вкуснее яблок?

Мне тупо отображать картинку, чтобы ее можно было тудым-сюдым двигать и увеличивать/уменьшать. Ну и иногда еще всякие графики рисовать.

есть специальные либы и софт

Нету. Либо я про такую прелесть не знаю. Но что-то готового не встречал.

http://mathgl.sourceforge.net/doc_en/2D-samples.html#g_t2D-samples

Знаю про mathGL, но в моем случае оно не подходит никак.

Вот, скажем, надо мне с веб-камеры показывать видео с какими-то дополнительными данными и иметь возможность увеличить картинку и подвигать туда-сюда. MathGL мне вряд ли в этом поможет. Вот — простой велосипед, который делает то, что мне нужно: кажет картинку. Еще добавлю движение (забыл про это) и буду использовать в следующем велосипеде (надо по-быстрому навелосипедить расширение к моему велосипеду, который фитсы с USB-ПЗСки забирает: хочется иметь возможность в непрерывном режиме щелкать кадры и не сохранять их, а отображать на экране, чтобы можно было приборы фокусировать и юстировать).

Ох уж эти извращенцы! Лишь бы GLU/GLUT не использовать! А между тем, даже для жабоскриптика есть GLU!

Ну, увы - не увы, а ffp официально считается устаревшим и менее эффективнымhttps://www.opengl.org/wiki/Fixed_Function_Pipeline

Нужно быть полным кретином, чтобы вместо божественной сишечки писать гуевый софт на ассемблере. Ну, ты понял. Рисовать для каждой задачи рейтрейсинг в шрейдерах вместо того, чтобы GLU/GLUT использовать — это идиотизм чистой воды! Ты вместо 1-2 страниц кода напишешь 20, да еще и убьешь кучу времени!!!

Я не понимаю разработчиков опенгля: они упоролись вообще в крайняк!

Боюсь я пока толком не знаю GLSL чтобы заявлять четкое мнение, может потом.

Нужно быть полным кретином,
Рисовать для каждой задачи рейтрейсинг в шрейдерах вместо того, чтобы GLU/GLUT использовать

Нужно быть полным кретином, что бы сравнивать теплое с мягким.

Погуглил про GLSL, ужас. Это как раз то, что я терпеть ненавижу и избегаю!

С трудом верится, что разрабы стандарта OpenGL разрабатывали - разрабатывали, разрабатывали-разрабатывали и внезапно упоролись и придумали GLSL.Ну едва ли. Посмотри, кто в Khronos group входит. Да и в ссылке, что я привел, черным по белому написано, что с развитием вычислительных возможностей, применять ffp - вчерашний день. То что это не так очевидно, и где-то нужно перепрограммировать свой мозг для нового подхода - ну и что теперь?Сам С++ каким-то людям покажется муторным и сложным.Однако это не изменяет его преимуществ.

P.S. А современный DirectX какой подход использует?

Сам С++ каким-то людям покажется муторным и сложным

Я считаю это совершенно ненужной дрянью.

P.S. А современный DirectX какой подход использует?

Спроси на винфаке.

Я считаю это совершенно ненужной дрянью

Ты только про GLSL или про C++ тоже 0_0?

Рисовать для каждой задачи рейтрейсинг в шрейдерах вместо того, чтобы GLU/GLUT использовать — это идиотизм чистой воды!

Ты бы поближе ознакомился с GLSL прежде чем критиковать.Трассировка лучей тут ни при чем.Даже современный OpenGL использует подход «растеризация», а не «трассировка лучей».Банальный перевод «shader» как «затенитель» вводит тебя в заблуждение. Конкретно в современном OpenGL шейдер - это программа-настройка узла конвеера рендеринга (того самого pipeline), а вовсе не пресловутая трассировка лучей.Так что современный opengl это тот же ffp - только гибкий и настраиваемый. И никаких 20 страниц кода на простейшие задачи не нужно.Это можно понять, прочитав меньше тех же 20 страниц этой книги

http://rutracker.org/forum/viewtopic.php?t=4418099

Загружаются простейшие шейдеры и простейший рисунок быстро пишется.

Про С++ тоже.

Я с шейдерами намучился, когда webGLU писал. Для того, чтобы можно было просто по-человечески, как в настоящем GLU, рисовать объемные объекты и подсвечивать их всяко-разно, пришлось забульбенить рейтрейсинг в шейдере, т.к. в оригинале webgl свой рейтрейсинг не умеет.

А ведь рейтрейсинг — такая часто используемая вещь, что могли бы и стандартизировать, как в настоящем OpenGL, когда ты рисуешь себе поверхности, задаешь их характеристики (отражение/рассеяние/поглощение), располагаешь в пространстве N источников освещения (и каждому тоже свою характеристику задаешь), ставишь "камеру" в нужную тебе точку и — вуаля! Опенгль тебе все кошерненько нарисовал без необходимости ломать в течение месяца голову, отражая все тонкости трассировки лучей в шейдере.

Да, я, конечно, понимаю, что на самом нижнем уровне именно шейдеры используются: CUDA получает код шейдера и в дофига потоков обрабатывает его, в результате чего быстренько картинка и рисуется (ну или если нет видеокарты, то ЦП в несколько потоков тупит). Но вот самому писать то, что уже 100500 раз описано и расписано — ну уж, увольте!

про gstreamer не слышал? зачем тебе дергать opengl чтобы отобразить картинку?

Затем, что это самый простой и шустрый вариант. А всякое дерьмище вроде gstreamer'а я в свою систему ставить не собираюсь!

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

Ты сам-то рейтрейсинг хоть раз реализовывал умник? Подходы к реализации рейтрейсинга такие все одинаковые, что там уже можно что-то стандартизировать?

Рисовать для каждой задачи рейтрейсинг в шрейдерах вместо того, чтобы GLU/GLUT использовать — это идиотизм чистой воды!

универсального подхода к реализации рилтаймового рейтресинга не существует и тем более не существовало ранее, когда стандартизировался opengl.

вообще прекрати нести эту ахинею тут, смущаешь только своим невежством новичков.

Говорю же: в webGLU реализовывал простую трассировку. Знаю, что подходов много, но есть базовый (даем свойства материала, свойства и положение источника света и камеры — вуаля!).

Зайди сюда и посмотри скриншоты. Реализовано стандартным рейтрейсером, никаких шейдеров и прочей мутотени! А если бы мне ради такой картинки пришлось месяц трассировщик выдумывать, я бы плюнул нахрен на это дело!

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

Вот такое говно

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

Потом приведу старый и новый код.

OpenGL и шейдеры про растеризацию а не про рейтрейсинг. Привет.

Ты вместо 1-2 страниц кода напишешь 20, да еще и убьешь кучу времени!!!

Это скорее всего только по началу, потом будет база, от которой отталкиваться.

Между прочим шейдер для стандартного модельно-видового и проекционного преобразования из ffp вот:

#version 430 core


uniform mat4 CurrentMdMatrix; 
uniform mat4 CurrentPrMatrix; 

vec4 nvPosition;

layout (location = 0) in vec4 vPosition;

void main()
{
  nvPosition=vec4(vPosition);
  nvPosition=CurrentMdMatrix*nvPosition;
  nvPosition=CurrentPrMatrix*nvPosition;
  gl_Position=nvPosition;
} 

Забивать CurrentMdMatrix и CurrentPrMatrix в этот шейдер можно с помощью glGetUniformLocation и gluniformMatrix.

На что придется потратить время, это переписать функции glOrtho, glFrustum, glRotate, glTranslate, gluPerspective, а потом, уже можно написать мощную gluLookAt. именно это не так уж долго, тем более что исходники glu не трудно найти. Да, на этом месте ты только-только вернешь старый функционал установки камеры.Но остальное делается наверняка похоже.

Зато имея в распоряжении программирование конвеера рендеринга (чем шейдеры и являются), можно написать специальный шейдер чисто для умножения матриц, например чтобы полностью снять матричные вычисления с CPU и отдать GPU.Целесообразность зависит, конечно, от ситуации. Вызываться такое умножение будет с помощью команды отрисовки фиктивного массива вершин (поставить там какую-нить всего одну вершину с прозрачным альфа каналом).

Да нахрен мне маяться идиотизмом, если в GLU/GLUT уже все есть? Я просто использую эти библиотеки и не парюсь!

Это пованивает поцтеризмом: поцтеролизы тоже говорят, мол, чего тебе стоит все свои init-скрипты под ненужноD переписать да и отказаться от того, что не работает?

чтобы полностью снять матричные вычисления с CPU и отдать GPU

А они и так в опенгле на GPU пашут. А при желании можно куду подключить и напрямую буфер вершин править.

А они и так опенгле на GPU пашут

Это понятно.Но вот ,например,есть вычисления кватернионов для описания вращения камеры.Это ведь в целом тоже к графике относится.Вроде же сами кватернионы перемножаются, складываются и генерируют матрицу на стороне CPU, а уже матрица умножается на координаты на GPU. А с шейдером можно ВСЕ эти вычисления на GPU отправить.Мысли вслух

P.S Да делай ты че хочешь.

Чушь, если нужно подобное на GPU сделать, я просто привлеку куду!

А CUDA же от Nvidia, не?На AMD картах пахать-то будет?Нужно кроссплатформенное(точнее даже «кроссжелезное») решение.

На AMD картах пахать-то будет?

Наплевать, я эту дрянь не использую.

Нужно кроссплатформенное(точнее даже «кроссжелезное») решение.

Мне не нужно.

Там же нет рейтресинга а просто вертексное освещение через нормаль и вектор до источника света?