Почему советуют не использовать glu/glut?

Оно все под opengl < 3 (устарело).

Отдельные части типа gluTess (не трогает opengl вообще) можно, конечно, использовать.

GLUT это лишь прослойка, пригодная для быстрого старта изучения. Многих фич в ней нету, поэтому серьёзные приложения не используют GLUT, а используют SDL, Qt и ещё кучу всяких более заточенных под создание игр/приложений библиотек, в том числе и чисто голых системных GLX, EGL или WGL.

По поводу GLU, её стараются избегать потому, что она есть не на всех платформах. К примеру, в Android используется OpenGL|ES и GLU не входит в NDK (насколько я помню), поэтому при портировании движка или приложения на мобильные платформы будут затруднения.

http://open.gl

Непортабельно. Попробуй это дело на андройд портировать, поймёшь почему.

Почему советуют не использовать glu/glut?

Потому что дебилы. Точка.

Используй. Это очень удобно.

В жопу ондроед. Это вообще жалкое подобие пускалки для игорей. Не дотягивает оно до мастдайки. А работать в нем нельзя. Ну и нахрен это дерьмище???

Мастдайку в ту же степь.

В общем, априори считаем, что у всех людей стоит линукс. А у кого не стоит, пусть виагру жрут!

ну допустим, ондройд вжопу. Ставим вместо него линух. Драйвер умеет только gl es. Приехали, да? Куда там глу всунуть? А глут?

gl es на пука? opengl for embedded systems на стационарном компьютере для тяжелых игр? Смешно.

Речь шла о том что на андройд можно наплнвать. Так и выходит что на андройд наплевать можно, а на opengl es нет.

Еще одно. Использую glLight, glBegin/end, ибо в туториалах было только это. Щас пытаюсь вникнуть в vbo, vao... Чето совсем не прикалывает, что эта же моя программа будет в 2 раза больше по объему «благодаря» vertex буферам. Плюс шейдерный язык учить... Мда.

gl es потом, щас бы разобраться с opengl 2, а потом vbo, vao, шейдеры... Тогда гляну что из себя представляет opengl es

GLU в стандартной поставке, конечно нету на Android/iOS, но на OpenGL|ES он давно портирован:

https://github.com/lunixbochs/glues

Так что подрубить можно и на мобильники и на Linux. А вот с GLUT будут на смартфонах будут траблы, да.

glBegin/end

Забудь их как страшный сон.

Универсальный софт, который работает везде, как правило и плох везде. Особенно когда мобильная и ПК версии имеют слишком много общего между собой.

да не будет она больше. Всё равно в драйвере точно такой же буфер строится. А так ты его сразу в gpu передаёшь.

Эти библиотеки обычно не используются для написания новых приложений, ибо там уже шейдеры да GLES 2, GLES 3 во все поля. Только для портирования существующих.

Универсальный софт, который работает везде, как правило и плох везде.

Да. Это хороший камень в сторону тех же IDE от JetBrains и Java в целом. Плохо работает и тормозит везде.

ТС, если надо что-то очень простое и более современное (не такой монстр, как SDL2 или Qt), посмотри на GLFW.

https://youtu.be/2oIgG-KLKcE Программа, рисующая треугольник, на 151 строку + 2 шейдерных файла на совершенно новом, ранее неизвестном мне языке. Вот это - страшный сон, как по мне.

Может, я чего-то не понимаю?

Как я понял, ТС учиться компьютерной графике решил и начал с какой-то устаревшей книжки или how-to.

Gles1 это как opengl1 без glBegin, рисовать надо всё через drawElements
Gles2 это как opengl2, но тут не доступны возможности из gl1 и всегда надо делать шейдер (т.к матричные операции недоступны)

Именно

Вот это - страшный сон, как по мне.

А ты думал, что будет легко? Современная компьютерная графика это же не какой-то там PHP. Она активно развивается и одна технология другую подгоняет. Раньше все писали на glBegin/glEnd, потом все начали работать с VBO/VAO да шейдерами, а теперь вообще на VulkanAPI перелазят.

А чего тут понимать? SDL2 тянет с собой работу со звуком, текстурками и кучей всего, на нем можно пилить большой движок, в котором большая часть его функционала будет использоваться. Qt вообще монстр, основная задача которого не связана с рисованием OpenGL-ем. А GLFW вполне нормальная библиотечка, которая делает только минимально необходимые вещи (даже шрифты надо прикручивать дополнительно, через FreeType, например).

Короче, согласно современным стандартам, я должен юзать glfw для инициализации opengl, взаимодействия с мышью и клавиатурой, и использовать vbo, vao и glsl?

begin-ы и end-ы можно смело забывать (разве что у тебя в универе их будут спрашивать, т.к. там вечно устаревшему учат). Начинай минимум с OpenGL версии 3.3, а лучше 4+. Vulcan пока сыроват (в плане книжек и доступности информации для новичка).

Скоро и это исчезнет, т.к. вулкан во все поля уже на за горами.

ну и ладно, главное пережить glsl, остальное вроде не так уж и сложно.

Ну он на C похож. Могло быть и хуже.

Драйвер умеет только gl es

Этого физически быть не может!

glBegin/end

Забудь их как страшный сон.

Ты ебанутый долболоид!

Не надо говном обмазываться!

Это не я обмазываюсь, а индустрия.

Эдик, ты зачем опять выходишь на связь?

Еще одно. Использую glLight, glBegin/end, ибо в туториалах было только это. Щас пытаюсь вникнуть в vbo, vao... Чето совсем не прикалывает, что эта же моя программа будет в 2 раза больше по объему «благодаря» vertex буферам. Плюс шейдерный язык учить... Мда.

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

На кой черт шейдеры втыкать туда, где нужно какую-нибудь элементарщину нарисовать?

Скажем, хочет человек смотрелку картинок сделать. Зачем ему там шейдеры? GLUT'а за глаза хватит!!! Заодно и упомянутую недавно аппроксимацию b-сплайнами можно элементарно в глуте сделать. Конечно, сплайны Акимы были бы более рациональны, но и даже их можно реализовать, если куду прикрутить.

Почитал на сайте steps3D о вертексных буферах... Я правильно понимаю, что glBegin/End больше использует обычную ОЗУ для хранения данных для прорисовки, что сказывается на производительности видео, а vertex buffers используют видеопамять, что улучшает быстродействие и меньше нагружает ОЗУ?

Почитал на сайте steps3D о вертексных буферах... Я правильно понимаю, что glBegin/End больше использует обычную ОЗУ для хранения данных для прорисовки, что сказывается на производительности видео, а vertex buffers используют видеопамять, что улучшает быстродействие и меньше нагружает ОЗУ?

Скорей всего да, если ты не используешь glList (или как там его).

там где элементарщина шейдеров не надо.

Это с использованием vertex буферов можно без шейдеров элементарщину делать?

Это с использованием vertex буферов можно без шейдеров элементарщину делать?

? Вообще, насколько я понимаю вершинные буфера могут и без шейдеров использоваться, не?

Я не в курсе, я только сегодня попробую впервые нарисовать треугольник через vertex буфера

Я не в курсе, я только сегодня попробую впервые нарисовать треугольник через vertex буфера

Вообще прикольная шняга. Я раньше не умел (да и вообще не занимался этим 3Д), а потом как-то подвернулся случай выучить немного тему, мне понравилось.

мало того, что быстрее, так еще и код красивее и компактнее выходит намного.

Для этих задач есть Qt, GTK, Clutter в конце-концов. Если человек лезет в внутренности opengl, значит ему что-то простое уже не надо, а там можно и SDL изучить по ходу дела.

Qt, GTK, Clutter

Ужас ужасный же! Культи-говнотыки — совершенно не то, что нужно для гуи использовать. Clutter с его GObject в ту же задницу! А уж если тупо картинку показать надо, OpenGL'я за глаза!

SDL

Перебор. Нафиг не нужно.

А вот с GLUT будут на смартфонах будут траблы, да.

Более года назад загрузил FreeGLUT, собрал с помощью NDK. На Android 4.4 работало.

Смотри выше. FreeGLUT уже несколько лет как портировали. В итоге одно приложение работает на GNU/Linux, MacOS, Android (а также Windows и даже BlackBerry).

Да, это тогда Google постарался и портанул для libliquidfun:

https://github.com/google/liquidfun/tree/master/freeglut

Интересно, но не вижу, чтобы upstream FreeGLUT упоминал в коммитах, что они пользовались наработками с liquidfun.

А самому первому коммиту «Add base Android and EGL code» уже 5 лет 11-го марта исполнится.

Зачем нужен вообще голый OpenGL если GLU умеет отлично рисовать чайники

https://www.opengl.org/resources/libraries/glut/spec3/node89.html