Por que não devo usar o glTools / glut ao desenvolver aplicativos completos?

Comecei a aprender a usar o OpenGL há algum tempo, usando o OpenGL SuperBible, quinta edição , e tive pessoas discutindo sobre o fato de que o livro não ensina realmente como usar o OpenGL, mas ensina como usar duas das bibliotecas de wrapper relacionadas a ele, glut e glTools.

Também me disseram que o excesso nunca deve ser usado para projetos completos, mas não havia nenhuma razão válida fornecida com o argumento.

Minha pergunta é por que e quando não devo usar as bibliotecas glTools / glut e o que devo usar?

GLTools e GLUT não são a mesma coisa. O GLUT é responsável por lidar com coisas fora do OpenGL. GLUT cria e gerencia uma janela e um contexto OpenGL; o material real que se passa dentro desse contexto (aka: OpenGL) não é de responsabilidade da GLUT.

Maik já abordou os motivos pelos quais você não vê GLUT em aplicações sérias. O GLTools é outra questão.

O GLTools é apenas uma estrutura, um invólucro do OpenGL. Existem muitas razões para não usá-lo em trabalhos sérios:

1. É ineficiente. Se o desempenho importa, você vai querer evitá-lo.
2. Não é muito bom. Veja o GLShaderManager, por exemplo. Ele carrega os sombreadores ou retorna 0. Se houver um erro do compilador / vinculador, ele não fornece informações sobre isso. Sim, ele grava o log no stderr, mas nem todo mundo o stderr canalizou para algum lugar visível. Exceções são um pouco mais difíceis de ignorar.

Eu tive pessoas discutindo sobre o fato de que o livro não ensina realmente como usar o OpenGL, mas ensina como usar duas das bibliotecas de wrapper relacionadas a ele

Isso é um aparte, mas geralmente o problema com relação a isso é bastante simples. 5 ensina você a usar a estrutura antes de explicar o que essa estrutura está fazendo. Então você aprende como usar seu carregamento de malha, como usar seu código de geração de matriz de perspectiva, seus sombreadores padrão, etc, tudo antes de aprender o que é um sombreador, quais são os atributos de vértice e assim por diante.

É basicamente programação de função fixa para a primeira parte do livro. Ele apenas usa seu próprio código de função fixa em vez do OpenGL.

Não é que ele use uma estrutura que é o problema. O problema é que ele usa a estrutura para ocultar detalhes que não foram explicados, em vez de ocultar detalhes que não são importantes para a lição atual. Depois de ver o shader carregando o código algumas vezes, você não precisa vê-lo novamente, para que ele possa ser uma função de biblioteca.

Uma maneira melhor de estruturar o livro seria usar as partes da estrutura depois de mostrar as chamadas subjacentes ao OpenGL que a estrutura está fazendo. O conjunto padrão de shaders é bom, mas deve usá-los somente depois que o usuário vê os shaders em ação manualmente. O mesmo vale para carregamento e manuseio de malhas, texturas etc.

O argumento contra o excesso em grandes projetos é que você não tem acesso ao loop do aplicativo, portanto não pode alterá-lo para atender às suas necessidades. Tudo o que tem são alguns retornos de chamada que são acionados por excesso, mas você não tem muito controle sobre isso.

No entanto, o objetivo do glut é criar demos e testar aplicativos com facilidade e multiplataforma, sem a necessidade de lidar com o código feio do sistema operacional para criar janelas, é apenas uma questão de algumas linhas de código usar o glut.