LINUX.ORG.RU
ФорумTalks

Классический OpenGL, OpenGL 3.0+, Vulkan, что дальше?

 ,


0

4

В отличии от «обычного» программирования, где чем дальше, тем более высокоуровневые языки стараются использовать, в графике все наоборот. Чем дальше, тем более низкоуровневые движки для графики. Когда ждать программирования видеокарт в машинных кодах либо конфигурирования встроенных (в будущем) FPGA для того, чтобы отрисовать простейшую сцену?

★★★★★

чтобы отрисовать простейшую сцену

И что бы простейшая сцена выглядела хорошо? Или как? Что значит простейшая сцена? Дай картинку

Чем дальше, тем более низкоуровневые движки для графики.

Потому что надо впихивать невпихуемое

Когда ждать программирования видеокарт в машинных кодах

Ну, так уже, шейдеры же пишем с неочень то большой абстракцией, считай таже сишка слава те хоспади хоть так

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

OpenGL 2.1 самый топ. Всё что выше это куча нашлёпок и всё. Потому-что мне осиливать версии выше лень :D

LINUX-ORG-RU ★★★★ ()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 3)

В отличии от «обычного» программирования, где чем дальше, тем более высокоуровневые языки стараются использовать

И потом пишут для них модули на более низкоуровневых языках, ога.

Ну вот у тебя есть массив xyz значений и массив rgba цветов, это всё что есть в графике. Точки в пространстве и картинки что для этого высокоуровневого придумывать? Ну вот придумали сначала машину состояний, затем придумали шейдеры что-бы каждую точку и каждый цвет читать, преобразовывать и записывать. Что там у тебя за точки, что бы с ними делаешь, что у тебя в текстурах хрен его знает. А высокоуровневые вещи подразумевают что делаются однитипные действия которые можно скомпоновать, что ты скомпонуешь в графике? Не ну есть что конечно. Но, для этого уже движки сделали, где мышкой клацаешь и всё ваще не паришься чтооо там как там и зачем да почему.

LINUX-ORG-RU ★★★★ ()
Ответ на: комментарий от LINUX-ORG-RU

для остальных геморой который обходят обуртками

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

И что бы простейшая сцена выглядела хорошо?

Ну например сцена это просто визуализация некоторых математических данных, вычисляемых «на ходу». Там особой красоты и не надо. И классическим opengl это зачастую рисуется элементарно.

cvs-255 ★★★★★ ()
Ответ на: комментарий от cvs-255

На самом деле, для всех практических нужд достаточно готового движка и разбираться, где там opengl, а где vulkan вообще не нужно

next_time ★★★★★ ()
Ответ на: комментарий от Darth_Revan

Там ES кастрированный, но хоть что-то. Благо пока ненужно пока OGL2+ жив и поддерживается

LINUX-ORG-RU ★★★★ ()
Ответ на: комментарий от LINUX-ORG-RU

это годнота, компромисс

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

Если тебя интересует обёртка - берёшь обёртку, этой middleware не место в драйвере.

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

OpenGL 2.1

Compute нет -> в топку. У нас же всё таки программируемый пайплайн а не конец 90х.

nvidia ()

К сожалению OpenGL всё. Для тех, кто не хочет красноглазить и писать софт/игруху и так использовали GUI приложения типа редактора/игрового движка, а те кто пишут этот софт получили больше контроля над графикой. Vulkan победил.

OpenMind ★★★★ ()
Ответ на: комментарий от nvidia

У нас же всё таки программируемый пайплайн а не конец 90х.

кому программируемый пайплайн, а кому просто по-быстрому отрисовать картинку

cvs-255 ★★★★★ ()
Ответ на: комментарий от LINUX-ORG-RU

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

peregrine ★★★★★ ()
Ответ на: комментарий от cvs-255

Берешь сишку/раст/любой другой низкоуровневый ЯП в руки, пишешь батарейку и погнали. И да, оптимизация узких мест таким образом гораздо быстрее чем писать весь проект на сишке/расте.

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от cvs-255

Если тебе хватает «классического opengl+glu+glut», то тебе вероятно хватит core opengl + нескольких функций из glm+glfw/аналогов. Если не устраивают внешние зависимости - копипасты нужного в свой код.

nvidia ()
Последнее исправление: nvidia (всего исправлений: 1)

API Open GL-я оказалось не на нужном уровне абстракции. На практике выиграло сочетание очень низкого уровня API (Vulkan, Metal, Direct X12) и очень высокого уровня готовых движков.

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

Joe_Bishop ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)