\ 1. Я понимаю, что OpenGL - это просто стандарт, а не часть программного обеспечения. Например, «получение» OpenGL на самом деле предполагает получение
сторонняя реализация, которая не обязательно должна быть
одобрен Хроносом.
Действительно.
\ 2. OpenGL обычно относится к комбинации утилит GL (GLU) и инструментария утилит GL (GLUT). У них есть методы, начинающиеся с
glu и glut, соотв. и «базовые» методы OpenGL, которые начинаются
с просто gl, реализуются теми, которые делают графические драйверы,
то есть NVIDIA?
Нет. OpenGL - это просто функции, начинающиеся с gl…. Все остальное (GLU, GLUT) являются сторонними библиотеками, не охваченными OpenGL.
\ 3. Я предполагаю, что методы glut являются специфичными для ОС помощниками, например, glutKeyboardFunc() должен интерпретировать клавиатуру. Так что если я
хотел более мощный альтернативный способ интерпретации ввода с клавиатуры, я
будет просто использовать OS API. Сам 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. Но это всего лишь инфраструктура, и это в основном просто написание стандартного кода. Будучи новичком, вы получаете очень мало, не используя установленную основу. Если ваша программа интенсивно использует графические виджеты, то разумным выбором будет использование Qt или GTK со встроенным виджетом OpenGL.
Однако некоторые проекты очень хардкорные и реализуют весь графический интерфейс с OpenGL. Blender - самый экстремальный пример, и мне это нравится.
Это кажется слишком простым и удобным, как будто скрывает многое из того, что происходит. я
подозреваю, что это также верно для C ++, поскольку обратные вызовы GLUT не дружелюбны
с методами в пространствах имен (как я видел в других вопросах).
Обратные вызовы GLUT хорошо подходят для пространств имен (пространство имен - это просто время компиляции C ++). Но то, что невозможно, это передать методы экземпляра класса как обратные вызовы GLUT / C.