Понимание OpenGL

У меня есть некоторые фундаментальные моменты/вопросы об OpenGL, не все из которых связаны с кодом, но и с концепциями. Буду признателен, если вы сможете ответить, подтвердить или расширить любой из них. Я предупреждаю вас, некоторые могут быть наивными, поэтому, пожалуйста, несите меня.

Я понимаю, что OpenGL - это просто стандарт, а не часть программного обеспечения. Например, "получение" OpenGL на самом деле предполагает получение сторонней реализации, которая не обязательно должна быть одобрена Khronos.
OpenGL обычно ссылается на комбинацию GL-утилит (GLU) и инструментария GL-утилиты (GLUT). У них есть методы, начинающиеся с glu и glut, соответственно. и "базовые" методы OpenGL, начинающиеся с просто gl, реализуются теми, которые делают графические драйверы, т.е. NVIDIA?
Я предполагаю, что методы glut - это помощники, специфичные для ОС, например glutKeyboardFunc() должны интерпретировать клавиатуру. Поэтому, если бы я хотел использовать более мощный альтернативный способ интерпретации ввода с клавиатуры, я бы просто использовал OS API. OpenGL сам по себе является чисто графикой, но glut имеет такие вещи, поскольку графика не сильно отличается от контроля в реальном времени.
Мне кажется, что методы glu могут быть идентичны вызову серии методов нижнего уровня gl. Одним из примеров, который я хотел бы назвать, является glOrtho() и gluPerspective(). Мне кажется, что у меня одинаковые способы работы, но расчет перспективы может быть более сложным, поэтому gluPerspective() для удобства, но может просто решить некоторые методы gl.
Я изучил базовый OpenGL, используя freeglut в университете, и у меня есть такое видение "хардкорного" способа использования OpenGL, используя только низкоуровневые методы. Я не знаю, является ли это абсолютно наивной мыслью, но есть ли "профессиональный" способ написать OpenGL, чтобы получить максимальную функциональность? Например, разработчики игр, например, не использовали бы glutPostRedisplay(), например, верно? Это кажется слишком простым и удобным, как будто он скрывает многое из того, что происходит. Я подозреваю, что это также верно для С++, поскольку обратные вызовы GLUT не дружат с методами в пространствах имен (как я видел в других вопросах).

Ответ 1

\ 1. Я понимаю, что OpenGL - это просто стандарт, а не часть программного обеспечения. Например, "получение" OpenGL на самом деле предполагает получение сторонняя реализация, которая необязательно должна быть одобренный Хроносом.

Действительно.

\ 2. OpenGL обычно относится к комбинации GL-утилит (GLU) и инструментария GL-утилиты (GLUT). У них есть методы, начинающиеся с glu и glut, соответственно. и "базовые" методы OpenGL, которые начинаются с просто gl, реализуются теми, которые делают графические драйверы, т.е. NVIDIA?

Нет. OpenGL - это просто функции, начинающиеся с gl…. Все остальное (GLU, GLUT) - это сторонние библиотеки, не покрываемые OpenGL.

\ 3. Я предполагаю, что методы glut - это помощники, специфичные для ОС, например glutKeyboardFunc() должны быть, чтобы интерпретировать клавиатуру. Так что если я хотел более мощный альтернативный способ интерпретации ввода с клавиатуры, я будет просто использовать API OS. OpenGL сам по себе является чисто графикой, но glut имеет такую вещь, поскольку графика не сильно отличается от в реальном времени человеческий контроль.

Правильно. GLUT - очень минимальная структура, поэтому настоятельно рекомендуется использовать что-то еще.

\ 4. Мне кажется, что методы glu могут быть идентичны вызову серии методов нижнего уровня gl. Один пример, который я хотел бы привести glOrtho() и gluPerspective().

Я думаю, вы ссылаетесь на gluOrtho2D, но да, вы правы. glOrtho - это истинная функция OpenGL-1. В некотором роде gluOrtho2D является одной из самых бесполезных функций:

void gluOrtho2D(GLfloat left, GLfloat right, GLfloat bottom, GLfloat top)
{
    glOrtho(left, right, bottom, top, -1, 1);
}

Они, похоже, мне похожи способы работы, но расчетная перспектива может быть более сложной, поэтому gluPerspective() для удобства, но может просто решить некоторые gl.

Справа снова, но на самом деле это довольно просто:

gluPrespective(GLfloat fov, GLfloat aspect, GLfloat near, GLfloat far)
{
    GLfloat a = 0.5 * atan(fov);
    glFrustum(-a*near, a*near, -a*near/aspect, a*near/aspect, near, far);
}

Начиная с ядра OpenGL-3, весь материал манипуляции с матрицей удален. В любом серьезном приложении это мало используется, так как вы сами будете управлять матрицами.

\ 5. Я изучил базовый OpenGL, используя freeglut в университете, и у меня есть это видение "хардкорного" способа использования OpenGL, используя только низкоуровневые методы. Я не знаю, абсолютно ли это подумал, но есть ли "профессиональный" способ создания OpenGL, чтобы получить его максимальную функциональность? Как, предположительно, разработчики игр не использовал бы glutPostRedisplay(), например, правильно?

Да, это возможно, и большинство игровых движков действительно делают всю работу ворчания. Существует libSDL, который также охватывает OpenGL. Лично я предпочитаю GLFW или сам делаю вещи. Однако это не меняет способ использования OpenGL. Но это всего лишь инфраструктура, и это в основном просто написание шаблона. Как новичок вы получаете очень мало, не используя установленную структуру. Если ваша программа сильно использует виджеты GUI, то использование Qt или GTK со встроенным виджетами OpenGL является разумным выбором.

Однако некоторые проекты очень хардкорны и реализуют весь графический интерфейс с OpenGL. Блендер - самый экстремальный пример, и мне это нравится.

Кажется, слишком легко и удобно, как будто он скрывает многое из того, что происходит. я Подозреваю, что это также верно для С++, поскольку обратные вызовы GLUT не являются дружественными с методами в пространствах имен (как я видел в других вопросах).

Обратные вызовы GLUT в порядке имен с пространствами имен (пространство имен - это всего лишь время компиляции С++). Но то, что невозможно, это передать методы экземпляров класса в качестве обратных вызовов GLUT/C.

Ответ 2

У вас, похоже, довольно хорошее понятие OpenGL и takeit. Не уверен, что еще сказать. Я предполагаю, что (5) действительно там, где можно прокомментировать.

В зависимости от того, какой тип приложения вы строите, вы правы, думая, что некоторые из них захотят создавать свое приложение только с помощью собственных вызовов GL.

Например, если вы создаете одно приложение для документов под окнами, имеющими представление OpenGl, но также стандартными меню и панелями инструментов, есть вероятность, что вы захотите перейти прямо на С++ и что вы называете "низким уровнем" api.

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

Тот факт, что вы используете вызовы GLut или low level непосредственно в одиночку, не делает приложение лучше или хуже:)

надеюсь, что это поможет