Урок 2 - Рисуем первый треугольник (комментарии) (3 стр)

Я понимаю, что бессмыслица (плоскость отсечения за спиной наблюдателя), однако при zNear <= 0 получаю отсечение.

DimaO
> f := 1/Tan(fovy*Pi/(360));

  f := 1/Tan(fovy*(Pi/360));
?

Executor
Ой, точно. Но это результат не меняет, впрочем.

Погадаю. :) Может матрицу надо транспонировать?

DimaO
> Я понимаю, что бессмыслица (плоскость отсечения за спиной наблюдателя), однако при zNear <= 0 получаю отсечение.
И о чем нам это говорит? :)

Все, разобрался, спасибо. С матрицами все в порядке. Отображается корректно, только немножко не влезает в Viewport. Но это уже не в матрицах дело.

Нубские вопросы, я как понимаю glxext.h - Linux, wglext.h - Windows, glex.h - объединение glxext.h и wglext.h? И еще какой реализации соответствует glext.h на официальном сайте opengl, 4.1? Т.е. glext.h поддерживает 2.0?

registr
> я как понимаю glxext.h - Linux, wglext.h - Windows, glex.h - объединение glxext.h и wglext.h?

Нет.
glext.h это расширения, которые не привязаны к какой либо платформе, то бишь мультиплатформенные.

> И еще какой реализации соответствует glext.h на официальном сайте opengl, 4.1?

Да.

> Т.е. glext.h поддерживает 2.0?

Да.

Executor
> Нет.
Уж очень похоже glxext на GLX,  wglext на WGL

Странно, но всё работает даже так:

glUniformMatrix4fv(projectionMatrixLocation, 0, 0, mvpMatrix.getArray());

registr
> Уж очень похоже glxext на GLX, wglext на WGL

Я "нет" сказал только на вопрос. Первую часть ты правильно сказал. Я только про объединение ответил нет.

Pixar
А что должно не работать?

Executor
> А что должно не работать?
А у меня везде матрицы транспонированные передаются в уроках, потому что хранятся как row-major, для удобства. А у него тут не транспонируются. А то что все "работает и так" это заблуждение, либо порядок умножения в шейдере поменян, ибо матрицы хранятся сразу как column-major. Вобщем чудес не бывает :)

KpeHDeJIb
> порядок умножения в шейдере поменян
В шейдере всё нормально. Просто любое изменение одной из матриц Model, View, Projection, в данном случае, сказывается так, что в шейдер отправляется вся эта перемноженная компания. С параметрами glUniformMatrix4fv() я игрался в инициализирующем коде. Мои издевательства над функцией (вроде передачи параметров 100500 или -100500), оказывается, приводили к выводу ошибки в логе, но я об этом даже не думал, так как все матрицы целиком грузились в методе draw(), и картинка появлялась без искажений. Когда я убрал транспонирование в самом методе draw(), то получился интересный эффект, как будто объект спроецировался на поверхность шара :)

Вопрос, может быть, некорректный, но ошибка уже достает. Упаковал работу с шейдерами в класс. Есть private поле FShaderProgram, содержащее индекс шейдерной программы. В вершинном шейдере есть два in атрибута "vertexposition" и "vertextexcoord" позиции и текстурной координаты соответственно. VBO общий для всех атрибутов. Теперь проблема:

PositionLocaion := glGetAttribLocation(FShaderProgram,'vertexposition');
if PositionLocaion <> -1 then
begin
  glVertexAttribPointer(PositionLocaion,2,GL_FLOAT,false,4*SizeOf(GLfloat),pointer(0));
  glEnableVertexAttribArray(PositionLocaion);
end else ProgramLogFile.AddEntry('Can''t get "vertexposition" attribute');

этот код возвращает PositionLocation = 0, то есть верный результат. Следом

А fragTexCoords в фрагментном шейдере юзается вообще? Если нет, то компилятор просто выкинул его за ненадобностью.
А вообще я бы не рекомендовал городить такой огород. Куда проще сделать так:

glEnableVertexAttribArray(0);
glEnableVertexAttribArray(1);
glVertexAttribPointer(0,2,GL_FLOAT,false,4*SizeOf(GLfloat),pointer(0));
glVertexAttribPointer(1,2,GL_FLOAT,false,4*SizeOf(GLfloat),pointer(2*SizeOf(GLfloat)));

#version 330 core

layout(location = 0) in vec2 vertexposition;
layout(location = 1) in vec2 vertextexcoords;

out vec2 fragTexCoords;

void main(void)
{
  gl_Position = vec4(vertexposition,0.0,1.0);
  fragTexCoords = vertextexcoords;
}