Чтобы добавлять сообщения и комментарии, .

@segfault:
segfault

hackage.haskell.org
Чет ржу ..

@gcc:
gcc

Симуляция спиральной галактики в QGalaxy youtube.com

@gcc:
gcc

QGalaxy. Добавлена возможность редактирования настроек генерации галактик, расстояния переведены в парсек.
GitHub: github.com
Бинарники под win32: drive.google.com

@den-po:
den-po

связка из двух тегов на самом деле связка из трёх тегов

@tzirechnoy:
tzirechnoy

Идиотов не сеют и не жнут.
Это я читал EGL specification.

Спек, напомню, должэн позволять получить OpenGL context для любой оконной системы, и дажэ для голого фрэймбуфера.

Вызов инита (eglGetDisplay) предусматривает передачу любого вида display_id в качестве единственного параметра: X display, win32 DC, gbm_device * ...
Но не предусматривает передачу того, какой именно вид display_id был передан.

Невозможные дебилы какие-то разрабатывали.

@akastargazer:
akastargazer

Группа Khronos запускает какой-то Vulkan. Эт чё? Всё?

@akastargazer:
akastargazer

Кто-нить представляет текущее состояние? Что устарело, можно ли юзать gluPerspective? А то пишут, что матрицу проекций вообще теперь лучше не трогать, типа deprecated. Я в прострации.

@Linda-chan:
Linda-chan

А что в Windows отвечает за OpenGL? Дрова видеокарт? Специальные системные дрова и библиотеки навроде DirectX? Или сам DirectX? Помнится, я видела хелп из DirectX SDK, в котором целый раздел был посвящён OpenGL.

@Shchvova:
Shchvova

в продолжение — если же хотите запилить сишечное кросплатформенное приложение лучше всего ипользовать
sdl2 — фреймворк с супер поддержкой на всех платформах — есть возможность достутачтся до gl контекста; используется великанами индустрии типа valve.
sfml — C++ легкий фреймворк для того же самого. Поддержка чуть меньше, тоже есть возможность получить контекст и работать с opengl напрямую.
glfw — сверхлегкий opengl фреймворк, позволяет только получить контекст и самые базовые события окна и инпута.
Хочу заметить что как sdl так и sfml это довольно развесистые фреймворки, которые можно использовать без привязки к opengl, при чем если делаете 2Д игру, то врядли нужно что то даже делать с GL. Что есть хорошо.

@Shchvova:
Shchvova

кто-то в жуке говорил что у него хелло ворлд на opengl на С++ жрет больше памяти чем на питоне в геймпае. Так вот, не используйте glut. GLUT — это не фреймворк, это штука для быстрого хакинга и написания графических демок. Делать софт или игры с ним не рекомендуется.

@tzirechnoy:
tzirechnoy

Некоторая часть glx-приложэний прямо сразу после запуска падали с воплями... эээ.. Ну, точно не записал — но в общем — Unsupported GLX Request Opcode major: 155 (GLX), minor: 16 (private vendor request). А, да, от всякого dri я избавился путём установки дефолтной libGL вместо nvidia. Ну, DRI тожэ запретил в конфиге — но как-то оно не всегда запрещается.

Выяснение через tcpdump показало, что это был vendor 65536 — т.е. на самом деле не vendor, а glXSwapIntervalSGI из GLX_SGI_swap_control.

Ъ, у него возможные ошыбки — только BadValue. Ну да, glx у nvidia как обычно никто не тэстирует, и работает оно из рук вон плохо.
Пока что заменил в /usr/lib/nvidia/legacy-304xx/libglx.so.304.123 все строки GLX_SGI_swap_control на GLX_SGI_twap_control. И всё заработало.

@gcc:
gcc

Жуйк, хочу поделиться вот такой вот программкой. По сути — симулятор гравитации. Использует OpenCL для расчёта, OpenGL для визуализации и Qt4 для GUI. Умеет генерировать спиральные галактики и сталкивать кучу оных друг с другом. :)
Гуглокод: code.google.com
Бинарники для венды: dl.dropbox.com

@fuze:
fuze

Круто у чувака получается жуков лепить habrahabr.ru "Шейдер для жука"

@Shchvova:
Shchvova

Наконец то кто-то сделал нормальные доки по OpenGL docs.gl

@akastargazer:
akastargazer

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

@Shchvova:
Shchvova

Кому лень читать — Open GL NG это новый модный апи с байткод шейдерами, апи которое не выносит от многозадачности, прозрачное управление состояниями конвеера, а главное, единый апи для десктопа и мобильных. А то смотришь на всякие директ х, мантлы, металы и понимаешь что говнецо это наше OpenGL...
Надеюсь и в браузер переползет.

@4DA:
4DA

opengl.org // 4.5 короче релизнули // как обычно больше всякого прямого доступа и контроля за пайплайном

@tzirechnoy:
tzirechnoy

Некоторое время назад обнаружыл, что glxgears, запущенные через честный nvidia glx — т.е. на удалённом хосте. Или на локальном, но через tcp/ip, а не unix domain и с export __GL_FORCE_INDIRECT=1 — так вот, запущенные безо всякого dri и shm — стоят на месте и вообще от них практически ничего не добьёшся. Притом пишут один раз какое-то невменяемо большое число fps. А вся система как-то ощутимо тормозит.

Сегодня разобрался детальней.
Во-первых, они -не тормоз, а медленный газ- не стоят на месте, а весьма медленно крутятся. Притом только новые, у которых видимо угол поворота вычисляется в зависимости от скорости в fps, чтобы они не крутились слишком быстро — у старых всё лучшэ с этим.
Во-вторых, вставленная отладочная печать обнаружыла следующую вещь: эта хрень пишэт в какие-то буфера (ну, в буфер приёма/передачи иксов, очевидно) сразу пачку команд на отрисовку фрэйма — пока не заткнётся. Около 15 тысяч фрэймов помещается.
Эти фрэймы рисуются со скоростью, определённой synctovblank. Т.е. около 60 fps. То есть минут 5 по-хорошэму.
При этом почему-то через несколько секунд проскакивает ещё один фрэйм, потому glxgears получает возможность написать свою дикую скорость да ещё и скорректировать скорость вращения.
И потом всё, на несколько минут оно затыкается.

Очевидный вариант решэния — XSync() или хотя бы XFlush() после каждого фрэйма. В общем, XFlush() почему-то работает дажэ лучшэ — в смысле — с ним — скорость 60 fps, а с XSync() — 30. Но это работает.
Ещё вариант — через nvidia-settings поставить nvidia-settings -a SyncToVBlank=0, тогда будет выдавать свои максимальные fps (у меня около 3000 при варианте через ssh на localhost), и особо не затыкаться, поскольку некогда.
Кстати, скорость через tcp/ip причти одинакова независимо от того, замаплено окно или нет — отличается вроде на 10%. Притом оно на 20% медленнее, чем через direct rendering если окно замаплено и в 3 по-моему раз медленнее если окно незамаплено.
Но вообще — надо с этим что-то делать, поскольку opengl-приложэния привыкли, что если SwapBuffers() прошло, то всё, пользователь ужэ видит на экране картинку — а тут такая херня творится.

@masai:
masai

Вода на webgl → madebyevan.com

@4DA:
4DA

Короче когда щас запустил свой велосипедодвижок, то при приближении к модельке (=> росту числа вертексный и пиксельных операий) усиляется высокочастотный шум.
Я слышу как работает GPU?
Если суспенднуть процесс, который рисует то шум продолжается.

@andreymal:
andreymal

Чё там Вентиль у себя наоптимизировал? При запуске стим жалуется, что юзает программный рендеринг, сам весь тормозит, GoldSrc тоже тормозит, Source и вовсе не запускаются. При этом всякий опенсорс типа OpenArena или Xonotic летает как ни в чём не бывало, поэтому на полетевшие драйвера не похоже.

@Applejack:
Applejack

Ой, какая няша! khronos.org

@4DA:
4DA

How Modern OpenGL Can Radically Reduce Driver Overhead
youtube.com

@4DA:
4DA

Иногда когда мне совсем нехер делать я хожу по разным старым проектам и пытаюсь их запустить.
На этот раз наткнулся на Unigine 0.2, последнюю опенсорсную версию. (Unigine потом стал закрытым и успешным).
OpenGL там конечно старый (1.4) и с кучей расширений, однако сама демка интересная, в т.ч увидел там:

* soft shadows
* портальный рендеринг с исползьванием bsp-trees
* система частиц
* зеркала
* автоматические тени от всех объектов
* простая rigid-body физика (даже с joint-ами)
* объемный туман
* просто скриптовый язык с консолькой по ~

Допинал исходники чтобы компилялись на современных линупсах.
github.com

@4DA:
4DA

yay, только щас узнал про OpenGL Bindless extensions.
Вкратце — снимается оверхед на последовательный биндинг наборов buffer objects
(и улучшается cache locality)

developer.download.nvidia.com

@4DA:
4DA

OpenGL ES Working Group plans to release a new version of OpenGL ES in 2014

The main features of the new API are:
— Backward compatibility with OpenGL ES 2.0 and 3.0
— Compute shaders, with atomics and image load/store capability
— Separate shader objects
— Indirect draw commands
— Enhanced texturing functionality including texture gather, multisample textures and stencil textures
— Enhanced shading language functionality

For clarification purposes the new API will not include:
— Tessellation and geometry shaders

Такие дела.

@alexst:
alexst

А вот если я хочу отрендерить в буфер, который в памяти CPU - то какие есть модные способы стащить результат, кроме glReadPixels?

@segfault:
segfault

youtube.com
картинкосмотрелка

@tzirechnoy:
tzirechnoy

Пытаюсь уяснить себе спеки OpenGL ES.
Читаю на сайте хроносов введение и описание версий: <<OpenGL ES 1.X For fixed function hardware:... OpenGL ES 2.X — for Programmable Hardware>>
Это заголовки мини-описаний соответствующих версий. То есть никто там не рефлексирует ужэ давно, что приличное functions API должно как раз абстрагировать жэлезо и позволять добиваться результата независимо от.

@4DA:
4DA

Чят, реквистирую людей с свежей видях nvidia и линуск.

Можете скомпилить это говно и посмотреть насколько будет грузиться CPU?
github.com

У меня есть подозрение что моя старая видяха/драйвер не умеют в нормальный Transform Feedback,
поэтому взвинчивают CPU до 100%, что смешно и нелепо.

Спс.

@mono:
mono

Котаны, скажите мне, а какие вы используете сущности для юнит-тестирования OpenGL-приложений?

@sss:
sss

radeonsi, xorg >=1.13 у кого нибудь работает ?, и еще немного не по теме, egl, openvg, gles в дэсктопном pc вобще нужно ?

@Equidamoid:
Equidamoid

Загуглил egl ( en.wikipedia.org ), гугл выдал:
Everything Girls Love
everythinggirlslove.com/‎

@tzirechnoy:
tzirechnoy

Пару дней назад до слоупока дошло, что единственное распространённое API для рисования 3d — это g-code.
Все остальные опенгли и директиксы до 3D пока сильно недотягивают. Ну, примерно как и API для рисования рамочек в windows 95. Разве что продвинулись несколько дальшэ.

@tzirechnoy:
tzirechnoy

Интересная презенташка по портированию игр под linux/opengl: developer.nvidia.com
via tos4 at ru-linux.livejournal.com

@yelbota:
yelbota

Можно наивный вопрос? Раньше всегда считал, что для производительности GPU-приложений самое главное это количество треугольников и сложность шейдеров. Сейчас вот, связавшись с этой темой по-настоящему, выясняю, что есть еще такая тема, как дроукол, и что если эти дроуколов дофига, то приложение будет тормозить, даже если каждый из этих дроуколов будет рисовать по два треугольника с примитивным шейдером. Так ли это?

@4DA:
4DA

Наговнокодил простой vector slime.
Вместо описания -> youtube.com
( en.wikipedia.org )

Образец говнокода тут -> github.com

Из планов на будущее: переписать все нах на шейдерах и заюзать нормальные буфера вершин и индексов, вместо deprecated GL_QUAD (хотя тут тоже плюсы — работает на опенсорсных дровах, лол).

@tzirechnoy:
tzirechnoy

По поводу современного состояния OpenGL:
Нет никакого нового OpenGL. Крайний OpenGL — OpenGL 1.2, да и то в некоторых аспектах лучшэ ориентироваться на 1.1. Всякие 2 и 3 сделаны исключительно для безсмысленного прожыгания времени, потому ни для чего кроме безсмысленного прожыгания времени они получились не пригодны. В общем, оно или сдохнет совсем или вся муть из 2 и 3 будет переделана кем-то вменяемым. Скорее, к сожалению, сдохнет, хотя я всё ещё надеюсь на что-то.

Третья и четвёртая версии окончательно перестали быть удобным языком трёхмерной графики. И вообще OpenGL перестало быть API трёхмерной графики, взамен оно стало набором команд для битстаффинга некоторого класса современных векторых процэссоров.
Довольно смешно правда, что при этом возможности делать на них что-то кроме графики так и не появилась — но это неважно.

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

То есть вот люди взяли, и понерфили освещение. Было — вполне рабочее. С пачкой довольно весёлых спец.эффектов. Стало — вот вам язык из 60-х годов, пишыте сами.
[продолжэние под катом]

@sss:
sss

blog.wolfire.com — интересно

@FIZZERS:
FIZZERS

*AGAL *FlasCC Есть надежда, что удастся скомпилировать шейдеры на OpenGL в AGAL при помощи FlasCC компилятора и/или GLS3D (https://github.com/adobe/GLS3D) или glsl2agal (https://github.com/adobe/glsl2agal). Кстати в последнем репо есть офигенная тема: agaloptimiser <github.com>.