Je commence par la programmation des shaders GLSL et j'ai étudié RenderMonkey . Malheureusement, AMD ne le prend plus en charge. Pourquoi? Y a-t-il un successeur?
Je commence par la programmation des shaders GLSL et j'ai étudié RenderMonkey . Malheureusement, AMD ne le prend plus en charge. Pourquoi? Y a-t-il un successeur?
Réponses:
La majeure partie de cette réponse sera une réponse au "Pourquoi?" une partie de votre question, hélas.
Eh bien, il y a FX Composer , de NVIDIA, qui est un produit similaire - il ne prend pas en charge GLSL mais les langues qu'il prend en charge sont assez similaires. Mais il a été mis à jour pour la dernière fois en 2009 et je ne pense pas avoir l'intention de le mettre à jour davantage. La plupart des packages de modélisation 3D haut de gamme contiennent également des outils de construction de matériaux, qui peuvent ou non prendre en charge GLSL.
Je pense que la raison pour laquelle vous voyez ces produits arriver en fin de vie (et rien ne sort pour les remplacer) est que la direction prise par le développement des shaders ne se prête pas bien aux IDE généralisés comme celui-ci.
Même à l'époque où nous venions d'avoir des vertex et des pixel shaders, il y avait généralement un fort couplage entre les formats de données côté jeu / moteur (et comment ces données sont traitées) et les mises en page d'entrée et les opérations programmées dans les shaders - au moins pour les effets plus intéressants et complexes.
Considérez les effets liés à l'eau, par exemple, qui impliquent souvent de déformer légèrement la géométrie en réponse à des sommes d'ondes sinusoïdales (en plus d'exécuter un calcul qui additionne des vagues similaires dans une texture à lier au pipeline comme une carte de relief), comme ainsi que d'avoir besoin de textures de copie de framebuffer pour se lier afin de réfléchir à la simulation, etc. La plupart de ces données proviennent du processeur et ne sont pas intégrées au shader lui-même.
À mesure que la nature de ce couplage augmentait (en raison de l'augmentation du parallélisme du côté du processeur, ce qui nous permet d'équilibrer plus équitablement les calculs intéressants entre le processeur et le GPU), il est devenu de plus en plus difficile de concevoir un IDE de shader à usage général, car cet IDE a également doit avoir un moyen de script et de répliquer le pipeline de données qu'un jeu va envoyer au shader - essentiellement, il devait être un plugin pour un moteur. Comme nous avons ajouté des étapes programmables supplémentaires au pipeline - shaders de géométrie, shaders de coque, et cetera - cela n'a fait qu'aggraver le problème.
D3D a essayé de résoudre le problème avec SAS , mais je ne pense pas que cela ait vraiment pris de l'ampleur et il n'a certainement pas évolué avec les progrès de la technologie GPU.
En conséquence, des outils internes ou intégrés spécialisés pour la construction de shaders ont évolué, et des outils comme FX Composer et RenderMonkey sont tombés en désuétude et ont finalement été abandonnés.
Pirate GLSL. C'est votre réponse http://www.geeks3d.com/glslhacker/