OpenGL 3 (2 стр)

>>• Update to reflect hardware changes: - This isn’t 1992
йопт!

former MessiaH
>Вроде скоро, в сентябре уже должна пройти утверждение в Khronos.
Было бы не плохо... старая архитектура GL давно отжила свой век.

А драйвера наверное уже вовсю пишутся :)

id-alex
Да ничёрта ещё не пишется, API даже ещё не утверждён. Может наброски какие-то и всё.
А оно вам так быстро надо? Я лично ещё долго буду юзать OpenGL 2.0. Просто важен сам факт выхода новой версии, поскольку это здоровая конкуренция с Direct3D и вообще облегчение жизни всем.

Юзать думаю можно будет только в следующем году.

>старая архитектура GL давно отжила свой век.
нормальная архитектура была :\
Надеюсь OpenGL не собираються сделать ООП... А то я повешусь |х

Джо
>Я лично ещё долго буду юзать OpenGL 2.0. Просто важен сам факт выхода новой версии, поскольку это здоровая конкуренция с Direct3D и вообще облегчение жизни всем.
Как оно облегчит жизнь тем, кто им не пользуется? :)
Пользователи старых интерфейсов ничего не выигрывают.

>Да ничёрта ещё не пишется, API даже ещё не утверждён. Может наброски какие-то и всё.
Он конечно не утвержден, но какая-нибудь закрытая alpha версия оного уже точно есть.

FedeX
>Надеюсь OpenGL не собираються сделать ООП... А то я повешусь |х
Что ж так? Не умеешь ООП?

>нормальная архитектура была :\
Тысяча малосовместимых extension'ов и пятьдесят разных шейдерных языков - это НЕ нормальная архитектура.
Как следствие - периодически наблюдаемые мной надписи "Идите в попу, наша прога у вас не запустится, поскольку нету такого-то расширения, и вообще driver mismatch :)".

id-alex
Что ж так? Не умеешь ООП?
Нет - ненавижу когда его навязывают. Когда предлагают свою в 90% случаев нелогичную с остальным ООП кодом структуру. К примеру у меня в движке есть свой класс меша и он просто вызывает необходимые ГЛ команды в своих методах. А к примеру в ДХ-е мне приходилось делать класс, в него вкладыватиь интерфейсы и обращаться к ним длинными нечитабельными вызовами, что очень портило код.

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

FedeX
Т. е. у вас меш рисует сам себя, не отправляет поверхности в некую очередь рендеринга для сортировки?
Некрасиво и медленно...

FedeX
>Нет - ненавижу когда его навязывают. Когда предлагают свою в 90% случаев нелогичную с остальным ООП кодом структуру.
Это ты к чему? Что люди, стандартизирующие OpenGL3 не умеют делать логичное ООП? :) Я думаю они еще как умеют ))

>А к примеру в ДХ-е мне приходилось делать класс, в него вкладыватиь интерфейсы и обращаться к ним длинными нечитабельными вызовами, что очень портило код.
Это все субъективно.
ООП модель в общем случае удобнее. При условии грамотной реализации, конечно.

>В большинчтве игрушек делается возможность отключать ресурсоёмкие и малоподдерживаемые эффекты. А ещё надо просто в движке реализовывать такие эффекты разными способами, чтоб двиг сам обнаруживал что есть на компе у пользователя и только это и использовал.
Ага. Имхо, в DX это сделано грамотнее: можно получить device capabilities - полное описание возможностей видеокарты, выраженное не в форме абстрактных экстеншнов разных вендоров, а количественно - сколько чего как и в каких режимов поддерживается.

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

В общем, очень хочется грамотный кроссплатформенный -современный- стандарт.

FedeX
id-alex
>Надеюсь OpenGL не собираються сделать ООП....
А разве OpenGL 1.x был не ООП? Мда.......
Почему под ООП всегда подразумеваются С++сные классы...

Наверное FedeX имел в виду что АПИ ОГЛ3.0 будет на чистом С, без всяких С++ и СОМ-интерфейсов...

Да, API  OpenGL 3.0 будет на том же С, хотя у него будет еще более развитая объектная модель

*vmr
>Наверное FedeX имел в виду что АПИ ОГЛ3.0 будет на чистом С, без всяких С++ и СОМ-интерфейсов...
Ну это скорее всего...

>Да, API OpenGL 3.0 будет на том же С, хотя у него будет еще более развитая объектная модель
Очень хочется надеяться, да... А потому и хочется как можно скоре ознакомиться со стандартом.

ЗлобныйШкольнег
Ну у меня так рисуется, ну и что? У меня, например, вся нагрузка идёт на пиксельный шейдинг, и какие-либо сортировки по текстурам и буферам просто бессмысленны. Зато с точки зрения кода хорошо - всё в одном месте.

id-alex
Dev caps хорошо для DX, но для мультиплатформенного API - это сложновато. Сколько платформ, сколько железа - этих капсов может стать столько со временем, что утонешь. Во первых в GL нельзя вводить структуры, разве только для фиксированных объектов, вроде Viewport или там Scissor Rect. В DX структура тех же Caps меняется от версии к версии, чего не сделать в GL. И вообще все эти Caps - это что-то из раздела "Хочу иметь возможность определять кол-во доступной видеопамяти". Уверенно могу сказать что последнего в OGL 3 не будет.

Вообще я немного боюсь за новый API - проектируют его уже не те люди, которые проектировали OpenGL 1.0. Интерфейсы многих расширений от NVidia кривоваты, особенно взять последний пучок к G80. В них как-то нет духа базового OpenGL, одним словом - пристройки к красивому дому. Мне интересно как же в новом пространстве имён они разрулят имена всех функций, чтобы они были логичными и удобно читались.

Вот взять например Widget. Если будет какой-нить glCreateWidget() - это же страшненько. Я бы не хотел видеть какие-нить Object в именах функций (glCreateShaderObject -> glCreateShader). Полезно было бы ввести кроме приставки glGet*() ещё и glSet*() - если уж делаем настоящий ООП.
Ещё жаль что уберут glBegin()/glEnd() я думаю это можно было оставить в ядре как средство рисования простых фигур. Скажем, сделать команды для задания только вершин, нормалей и текстурных координат - и всё. Чтобы что-то простенькое можно было в коде ими нарисовать. Может, это вынесут в прослойку и у нас будет gluBegin()/gluEnd().

Джо
>Во первых в GL нельзя вводить структуры
В чем припятствие?

>В DX структура тех же Caps меняется от версии к версии, чего не сделать в GL.
Видеокарты из года в год тоже обрастают новыми возможностями.
Ничто не мешает увеличивать объем структуры device caps из года в год - обратная совместимость при этом сохраняется полностью.

>Вообще я немного боюсь за новый API - проектируют его уже не те люди, которые проектировали OpenGL 1.0. Интерфейсы многих расширений от NVidia кривоваты, особенно взять последний пучок к G80. В них как-то нет духа базового OpenGL, одним словом - пристройки к красивому дому.
Господи, но ведь дом уже банально устарел для сегодняшних задач :) Улучшения необходимы. Не вижу в них ничего плохо, особенно если обратная совместимость сохраняется полностью.

>Вот взять например Widget. Если будет какой-нить glCreateWidget() - это же страшненько. Я бы не хотел видеть какие-нить Object в именах функций (glCreateShaderObject -> glCreateShader). Полезно было бы ввести кроме приставки glGet*() ещё и glSet*() - если уж делаем настоящий ООП.
У меня сегодня тоже не возникает ощущения, чтоли, Монолитности архитектуры OpenGL2. Как будто разные части интерфейса придумывали разные люди...
Тоже хочется чтобы команды были собраны в логичные пары Read/Write, Get/Set, Create/Delete а не представляли из себя сборище Read/Copy/Get/Load или Create/New/Disable/Delete...

id-alex
>В чем припятствие?
Не гибко.
Как ты думаеш? почему первое поле всех структур в WinAPI(в ДХ думаю тоже) имеет название StructSize или StructVersion?

*vmr
>Не гибко.
А как гибко? Получать значение каждого члена структуры отдельным вызовом функции?
Структура позволяет хранить подструктуры и массивы данных внутри себя; к ней удобно обращаться; она расширяема.
Единственная плата за расширяемость структуры device capabilities - это строка dc.size = sizeof(dc); в коде программы.

пожалуйста, не надо обсуждения какой префикс круче, device-> или gl*(GL_, и C++ vs C.