Свежие комментарии

Ну я скорее к тому, что на 2.x может быть можно смело забить и смотреть на 3.x (а может и 4.x).

C OpenCL в том что мне надо в дальнейшем (не сейчас) - все тоже банально, OpenCL генерирует текстуру, OpenGL - натягивает на экран.

Ясно.
Есть треугольник в каких то координатах например как в моем темплейте -1..1. Его надо нарисовать. Что бы понять где рисовать нужно преобразовать координаты треугольника в экранные координаты. Для этого нужно собрать матрицу. В матрица представлены: перемещение, вращение, увеличение. То есть умножая вектор на матрицу мы преобразовывает одни координаты в другие. Есть еще перспектива, она тоже всовывается в матрицу. Про перспективу лучше картинку посмотреть.

Каждый фрейм в опенгл начинается с очистки буферов - glClear. Буфера бывают разные, есть экранный буфер, есть стенсил буфер, есть буфер глубины и т.д. Как минимум нужен экранный буфер. Он опять таки хитрожопо мапится на окошко в виндовз или там линуксе. QT это лучше сделает.
Дальше начинаем рисовать. У нас есть геометрия: вершины треугольника, цвет в каждой вершине, и например координаты текстуры для каждой вершины. Вызывая glColor и glVertex мы засылаем данные в драйвер. Драйвер строит разные буфера которые потом отдаст карте. Карта начинает это все считать когда вызывает glSwapBuffers.

С каждой вершиной ассоциируется пакет аттрибутов: цвет, текстурные координаты и т.д. Это все передается геометрическому шейдеру. В шейдере как я уже говорил как минимум перемножается матрица проекции 3д координаты вершины в экранные координаты. После чего карта растеризует треугольник и вызывает пиксельный шейдер. Пиксельный шейдер должен вернуть цвет, именно его и положит карта в графическую память.

Еще больше запутался? :)

Мне непонятна именно целостная картина.

Т.е. почти про каждую строчку кода в Qt-шных примерах - я понимаю что она делает.

А вот почему делается именно это и в таком порядке - не понимаю.

Соответственно, и вопрос задать не могу т.к. надо знать половину ответа.

Qt-шные - на макоси успешно собираются, как и на винде.

Линукс меня слабо интересует пока.

> Но она 2004-го года, я так подозреваю, что с тех пор наука шагнула очень далеко вперед.
Я бы не сказал. Ну то есть наука конечно шагнула, но той книжки хватит что бы сделать вполне приличный движек.

А что именно не понятно? Обычно после описания проблемы, и решение как то сразу приходит.
Там немножко все запутанно из за того что:
В OpenGL до шейдеров был фиксированный pipeline. То есть надо было задавать матрицы преобразования координат вершин через спец комманды https://github.com/dubik/OpenGLTemplate/blob/shaders/glwindow.cpp#L40 потом загружая геометрию в в драйвер https://github.com/dubik/OpenGLTemplate/blob/shaders/glwindow.cpp#L52 оно тупо перемножалось. Цвет и текстурка бралась из других спец комманд https://github.com/dubik/OpenGLTemplate/blob/shaders/glwindow.cpp#L51. К тому же есть комманды которые включают освещение.

После того как появились геометрические шейдеры, это можно делать в коде шейдера, без спец комманд. То есть матрицу можно передать геометрическому шейдеру в виде аттрибута и он уже будет перемножать ее (и не только) с геометрией https://github.com/dubik/OpenGLTemplate/blob/shaders/shaders/solidColor....
после того как отрабатывает геометрический шейдер, запускаются пиксельные. Карта растеризует треугольник и для каждого пикселя вызывает main https://github.com/dubik/OpenGLTemplate/blob/shaders/shaders/solidColor....
самая засада тут понять какие переменные входят в шейдер а какие выходят. Меня в свое время это жутко бесило. При линковке шейдеров, компилятор или драйвер хитрожопо выясняют могут ли они выходные аттрибуты одного соединить со входными аттрибутами другого. К тому же есть встроенные выходные аттрибуты типа gl_FragColor. Это цвет выходного пикселя. Кстати в этом случае освещение надо считать самому. В книжке написано как именно, но идея в том что передаеш координаты лампочки в геом шейдер и он может посчитать светимость в каждой вершине, потом он передаст эти аттрибуды в пиксельный шейдер. Пиксельный шейдер можно просто проинтерполировать или посчитать свет уже в каждом пикселе.

Кстати еще про входные аттрибуты. В геометрическом шейдере
varying vec4 vColor;

void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
vColor = gl_Color;
}

gl_ModelViewProjectionMatrix - это встроенный аттрибут, в который запихнулась матрица после вот этого
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(45, (GLdouble)w / (GLdouble)h, -10, 10);
glMatrixMode(GL_MODELVIEW);

gl_Color - это то что приходит из glColor3f(1.0f, 0.0f, 0.0f);

В opengl обычно более одного способа сделать одно и тоже, можно задавать геометрию одним массивом. Но glVertex и glColor самый простой и самый медленный с точки зрения производительности способ.

Книжку спиратил, спасибо.
Но она 2004-го года, я так подозреваю, что с тех пор наука шагнула очень далеко вперед.

А темплейт - я на даче примерно такой же написал (копипастом из qt-шных примеров) и понял, что не понимаю базы.

Ну да.
Только пусть Qt этим всем управляет - чтобы не возиться напрямую с gl кодом.

Я тут налабал темплейт https://github.com/dubik/OpenGLTemplate/ . Там еще есть бранч с шейдером. А вот мега книжка по шейдерам http://www.amazon.com/Shaders-Programmers-Artists-Premier-Development/dp... есть в электронном виде. Шейдеры лучше в рендермонкей делать, ну если простые то можно и в коде.

Оно не нафига, а отчего.

Какой был php.ini, такое в ем expose_php

It is no security threat in any way, but it makes it possible to determine whether you use PHP on your server or not.

Тоже мне секрет, что в друпале используется PHP....

Фикус тут в том, что у ICAO есть множество всяких правил, которые приличные люди выполняют, а неприличные - не торопятся. Одни неоригинальные запчасти чего стоят.
Так что если законопослушную USPS или еще там кого можно обязать проверять, то (условно) какая-нибудь Гонконгская ограничится тем, что напишет в своих правилах "низзя", а проверять реально будет далеко не всегда - это же от конечных исполнителей зависеть должно, т.е. тех самых пофигистов-приемщиков.

Да, по разнице, в теории, можно. В практике - 2 (и даже 20) граммов лития ловить в контейнере - бессмысленно.
А вот если отдельный пакет досматривать, то можно и без рентгена, сказано же "батарейки нельзя"

https://shopfans.ru/faq.html?section=11:

Товары, запрещенные к пересылке в международных почтовых отправлениях:
...
батареи (батарейки разрешены к пересылке только в составе приборов. Аккумуляторы разрешены к пересылке, кроме аккумуляторов с жидким электролитом и с содержанием ртути.);

Старый уже пост, но я тут пишу следующий пасквиль на тему - и с палочками тоже разобрался.

Палочки - при более-менее ярком (дневном) освещении насыщаются и все.