Quais são os prós / contras dos três?
Quais são os prós / contras dos três?
Respostas:
O coderanger está certo quanto ao direcionamento HLSL ao DirectX, ao GLGL aberto ao OpenGL e ao CG estar disponível nas duas interfaces.
No entanto, há outras coisas a considerar (aprendidas no fórum OGRE):
Portanto, se você não estiver usando os últimos recursos de sombreador, o CG parece ser uma boa escolha. O GLSL parece um apostador se você estiver usando o OpenGL completo. HLSL se você estiver indo exclusivamente nas plataformas Microsoft.
Agora, o primeiro desenvolvimento no HLSL para Windows para usar o DirectX e depois converter no GLSL para Linux e Mac pode ser a melhor solução para garantir o desempenho e ter o maior conjunto de recursos de sombreador disponíveis. No entanto, pode ser muito trabalhoso (não fiz isso sozinho, então não sei dizer). O mecanismo de gráficos OGRE (e outros mecanismos) permite o uso de qualquer API (DirectX ou OpenGL ou outros), portanto ajuda, mas ainda há código de sombreador a ser convertido se você seguir esse caminho.
Essas são as informações que reuni ao escolher meu idioma de sombreador (ainda não tomei minha decisão).
Atualização: a Valve fez a conversão de um de seus jogos para o OpenGL e não encontrou maneira de tornar a versão do DirectX mais rápida que a do OGL . Portanto, lembre-se de que o estado de implementação do driver, a qualidade da API etc. muda muito a cada ano para que você confie totalmente no desempenho bruto como argumento para escolher um ou outro. Com isso em mente, escolha OpenGL / GLSL para simplificar sua vida ao trabalhar (ou ter planos ou esperanças de trabalhar) com outras plataformas que não o Windows, use o DirectX / HLSL se você realmente quiser usar apenas plataformas e foco da Microsoft e talvez tenha algo de bom. API mais rápida que o OpenGL (isso está revertendo agora, então não conte com isso); use CG se desejar fornecer as duas possibilidades ao usuário, mas se você tiver a força de trabalho (e as ferramentas) para fazer isso, usar o GLSL e o HLSL também pode ser uma solução viável.
Atualização (2012): É importante observar que o CG foi descontinuado e não é mais suportado ou trabalhado ativamente pela Nvidia. A Nvidia recomenda que todos os usuários alternem para uma combinação de GLSL e HLSL, ou uma biblioteca mais recente, como o nvFX (no github). Isso ocorre porque era muito difícil manter a compatibilidade de recursos entre GLSL e HLSL.
Só posso falar sobre CG vs HLSL porque esses são os 2 que usei até agora.
Cg não é o mesmo que HLSL.
Em Cg, a NVIDIA fez um excelente trabalho ao criar uma sintaxe de shader muito limpa. É muito semelhante ao HLSL.
Porém , a ligação com o D3D9 / D3D11 (código init, código de compilação do shader) é muito mais limpo no HLSL do que no Cg. -1 Cg. O Cg possui um pouco desagradável de código de inicialização que você nem precisa ter para o HLSL sobre D3D.
Em Cg, você precisa "cgGetNamedParameter" para todas as uniform
variáveis de sombreador que deseja definir / modificar. E você deve manter uma CGparameter
referência em seu código para essa variável
// C++ code to interact with Cg shader variable (shader language independent)
CGparameter mvp = cgGetNamedParameter( vs, "modelViewProj" );
CG::getLastError("Getting modelViewProj parameter"); // check for errors
cgSetMatrixParameterdr( mvp, &modelViewProj._11 ) ; // setting the matrix values
No HLSL, isso acaba sendo muito mais limpo - apenas uma linha, e você não precisa manter essa CGparameter
variável.
// D3D9 C++ code to interact with HLSL shader variable
DX_CHECK( id3dxEffect->SetMatrix("modelViewProj", &mvp._11 ), "Set matrix" ) ;
Acima, DX_CHECK
é apenas uma função simples que verifica o HRESULT que é retornado da SetMatrix
chamada. O código acima é d3d9 . D3D10 e 11, é claro, são muito mais dolorosos (já que não há um objeto ID3DX11Effect).
Antes de começar a usar o HLSL, eu olhava esse código e ficava com ciúmes .
Embora NVIDIA fez o seu melhor para fazer uma interface comum para Cg entre OpenGL / D3D, praticamente falando a sua não dessa maneira, e você tem cgGL*
, cgD3D9
, cgD3D10
,cgD3D11
grupos de funções de enfrentar. Então, isso funciona para OpenGL e D3D !! reivindicação só vai tão longe. Você ainda precisa agrupar tudo em #ifdef
grupos do tipo OpenGL / D3D para fazê-lo funcionar em plataformas diferentes. -2 Cg.
Além disso, recentemente tive uma experiência ruim com placas Cg / ATI, que tenho certeza de que não é ruim. (Alguém mais experimentou?). Acho que pode ser verdade que a NVIDIA não teste completamente as placas ATI, como afirma Klaim. Ou que a ATI não teste em CG. De uma maneira ou de outra, há uma incompatibilidade e algum tipo de conflito de interesses. -3 Cg.
Apesar de tudo, eu preferia Cg. A sintaxe e a nomeação do código do sombreador são limpas, doces e arrumadas. É uma pena que tenha esses outros problemas.
Meu entendimento muito básico é que HLSL é apenas para DirectX e GLSL é apenas para OpenGL. O CG é basicamente o mesmo idioma do HLSL, mas pode ser usado com o DirectX ou o OpenGL (embora via código de tempo de execução diferente).
Outra diferença crucial entre HLSL e GLSL (eu não conheço o CG, portanto não posso falar por isso) é que, com o HLSL, a Microsoft fornece o compilador de sombreador como parte do tempo de execução do D3D, enquanto que com o GLSL, o fornecedor do hardware o fornece como parte de seu motorista.
Isso tem vantagens e desvantagens de ambos os lados.
Com o método GLSL, o fornecedor pode ajustar o compilador aos recursos de seu hardware. Eles conhecem melhor seu próprio hardware, sabem o que fazer e o que não fazer. Por outro lado, a desvantagem é que - em um mundo onde há vários fornecedores de hardware - você tem uma situação em que pode haver inconsistências entre os compiladores de shader, e o fornecedor também tem total liberdade para estragar tudo.
Com o método HLSL, a Microsoft controla o compilador. Todo mundo está em uma base tecnológica consistente e, se um shader for compilado com êxito em um local, pode-se razoavelmente compilar em qualquer lugar. O mesmo sombreador produzirá a mesma saída compilada, independentemente do fornecedor (todas as outras coisas são iguais, é claro). Por outro lado, o compilador HLSL deve ser uma coisa "funciona consistentemente em tudo", portanto, não é possível extrair nenhum truque específico do fornecedor para obter as últimas gotas de suco do tanque.
Se isso aparece como se eu tivesse uma preferência pela visão HLSL do mundo, é porque sim. Eu já fui mordido muito antes por um comportamento totalmente inconsistente em diferentes plataformas e, em um caso, até precisei reverter uma carga de GLSL de volta ao ARB ASM apenas para obter uma linha de base que funcionasse. O compilador GLSL da NVIDIA pode ser visto como particularmente notório aqui - ele até aceita sintaxe e palavras-chave HLSL, o que significa que, se você não tomar cuidado, poderá acabar produzindo shaders que só funcionarão na NVIDIA e nada mais. É uma selva lá fora.
Você também pode procurar no RTSS (Run Time Shader System) que acompanha o Ogre. É relativamente novo, mas você basicamente escreve shaders no código em vez de arquivos externos. Ainda não o implementei, mas definitivamente planejo usar isso quando chegar a hora.
Aqui está uma enorme série de tutoriais no wiki do Ogre, bem como para escrever shaders. http://www.ogre3d.org/tikiwiki/JaJDoo+Shader+Guide
Quanto à sua pergunta original, como Praetor disse, não é realmente uma questão de prós / contras, é uma questão de qual sistema de renderização você deseja usar. Como o uso do DX / OpenGL com o Ogre é apenas uma questão de carregar o plug-in, você provavelmente desejará usar o formato .cg.