OpenGL

[Nikich]

Как передать в шейдер множество текстур?
У меня есть большой массив vertexData, в котором хранятся координаты вертексов и координаты текстуры. Рисуется это всё дело за один glDrawArrays(верно ли?). И мне нужно на каждую пару треугольников(квад) наложить свою текстуру. Как это лучше всего сделать?

[HolyDel]

GL_ARB_BINDLESS_TEXTURE - лучший вариант, но ето только на кеплере и выше. Тут у каждого пикселя может быть своя текстура, что очень круто. Тебе нужно будет лишь добавить к вершине аттрибут - 64битный хэндл текстуры на гпу.

если текстуры одинаковые по формату и размеру - texture array.

если разные - пакуй в атлас.

вообще последний вариант самый неприхотливый

[Nikich]

А как быть с контекстом постарее?

[HolyDel]

атлас - хоть на 1.0.

[Nikich]

gl_Position = vec4(vposition*mat2(cos(angle),-sin(angle),sin(angle),cos(angle)),0.0,1.0);

vpostion - 2D вектор с координатами точки.
Решил вращать на гапи, передавая в шейдер угол поворота. Матрица проверенная, точно работать должна, однако результат дает очень странный, получается дикое искажение примитива, а не вращение. Как будто используется ещё и z ось. В чем может быть проблема?
Про оптимизацию не надо говорить, написал так здесь для краткости кода.

[moka]

В гапи ожидается screen space матрица, или ты умножаешь на viewport projection матрицу до твоего поворота?

[Nikich]

Нет, больше на матрицы я не умножаю. Можно подробнее? Это вообще необходимо при жестком 2D?

[moka]

Ну прежде чем отдавать в шейдере позицию вершины во фрагментный конвеер ты должен её умножить на матрицу камеры (viewproj).

[ABTOMAT]

Сообщение от moka

Ну прежде чем отдавать в шейдере позицию в конвеер ты должен её умножить на матрицу камеры (viewproj).

Не обязательно. Центр экрана - 0,0, углы - +/- единица. Можешь сам к этому масштабу приводить как хочешь.

[moka]

Сообщение от ABTOMAT

Не обязательно. Центр экрана - 0,0, углы - +/- единица. Можешь сам к этому масштабу приводить как хочешь.

Ну если заранее умножаешь объект на матрицу viewproj, то следственно и затем трансформируя его на свои повороты - не ожидай адекватного результата.

Ты пытаешься повернуть вершину уже в скрин-спейсе, и тут два варианта - либо ты в шейдере перед этим множишь на viewproj либо ещё до шейдера это делаешь (на CPU).

[pozitiffcat]

Сообщение от Nikich

gl_Position = vec4(vposition*mat2(cos(angle),-sin(angle),sin(angle),cos(angle)),0.0,1.0);

vpostion - 2D вектор с координатами точки.
Решил вращать на гапи, передавая в шейдер угол поворота. Матрица проверенная, точно работать должна, однако результат дает очень странный, получается дикое искажение примитива, а не вращение. Как будто используется ещё и z ось. В чем может быть проблема?
Про оптимизацию не надо говорить, написал так здесь для краткости кода.

mat2 rotationMat = mat2(cos(angle),-sin(angle),sin(angle),cos(angle));
gl_Position = vec4(vposition*(projMat*viewMat*modelMat*rotationMat));

projMat, viewMat и modelMat - юниформы приезжающие с движка. Проекция, камера и положение объекта на сцене.

и вообще вскрой любой движок, так никто не делает. Обычно это на ЦПУ делается. modelMat должен приехать уже с поворотом, а вместо двух projMat, viewMat можно в шейдер отдавать уже перемноженый projViewMat, актуально для батчей, чтоб не перемножать на каждую вершину.

[Nikich]

А почему тогда отображение без вращения верно?
И если всё же нужны матрицы, как её рассчитать вручную, без GLM? Просто как-то не ахти подключать дополнительную библиотеку для одного расчета, а гугл явно твердит, что следует использовать GLM.

[pozitiffcat]

Сообщение от Nikich

А почему тогда отображение без вращения верно?
И если всё же нужна viewproj матрица, как её рассчитать вручную, без GLM? Просто как-то не ахти подключать дополнительную библиотеку для одного расчета, а гугл явно твердит, что следует использовать GLM.

да используй GLM. Там cpp-шников нет, библиотека построена на шаблонах, точно будет лучше, чем изобретать велосипед. Ну если так хочешь сам, то кури перемножение матриц. Вообще, рано или поздно, тебе придется использовать математическую библиотеку.
Можешь еще спросить у HolyDel, он реализовывал без GLM. Только вроде для mat4x4

p.s. если верно без вращения, значит ты уже в скрин спейсе формируешь и отправляешь в шейдер, тогда поворот будет работать относительно не своего центра, а точки 0.0 на экране, это центр

зачем тогда вообще на матрицу умножать?
вот на, кусок с моего движка

point BatchOpenGL::rotatePoint(float cx, float cy, float angle, point p)
{
    float s = sin(angle);
    float c = cos(angle);

    // translate point back to origin:
    p.x -= cx;
    p.y -= cy;

    // rotate point
    float xnew = p.x * c - p.y * s;
    float ynew = p.x * s + p.y * c;

    // translate point back:
    p.x = xnew + cx;
    p.y = ynew + cy;

    return p;
}

учти что angle может быть в углах или радианах. в чем точно не помню. Формула такая: Угол = Радиан * (180 / Пи)

[Nikich]

У HolyDel же с 3D, мне оно вообще не нужно и не планируется, поэтому камера всегда будет в одном и том же положении, значит и матрица проекции на камеру тоже всегда будет одна и та же.

[pozitiffcat]

Сообщение от Nikich

У HolyDel же с 3D, мне оно вообще не нужно и не планируется, поэтому камера всегда будет в одном и том же положении, значит и матрица проекции на камеру тоже всегда будет одна и та же.

короче, можешь попробовать прилепить в шейдер код, что я дал.