OpenGL: GLSL Shader, nur für Programmierer?

[DaBrain]

Ich weiss nicht so genau ob das hier das richtige Forum ist, aber es geht wohl hauptsächlich ums Programmieren.

GLSL Shader schreiben scheint mir nichts anderes als OpenGL Coding zu sein.

Ich bin kein Programmierer, sondern Hobbygrafiker. Trotzdem würde ich gerne Shader schreiben können.

Meine Frage ist: Macht es Sinn das ohne Progammierkentnisse zu lernen?

Und wie wird das in professionellen Spielen gehandhabt? Ist der Grafiker oder der Programmierer dafür zuständig?

[ShadowXX]

Ich weiss nicht so genau ob das hier das richtige Forum ist, aber es geht wohl hauptsächlich ums Programmieren.

GLSL Shader schreiben scheint mir nichts anderes als OpenGL Coding zu sein.

Ich bin kein Programmierer, sondern Hobbygrafiker. Trotzdem würde ich gerne Shader schreiben können.

Meine Frage ist: Macht es Sinn das ohne Progammierkentnisse zu lernen?

Und wie wird das in professionellen Spielen gehandhabt? Ist der Grafiker oder der Programmierer dafür zuständig?
Normalerweise der Programmierer, den die Shader die heutztage verwendet werden sind ja mehr "Effekt-" und "Beleuchtungsshader" (wenn man es sehr sehr allgemein definiert) und weniger Grafik (im klassischen sinne).

[ollix]

Ich bin kein Programmierer, sondern Hobbygrafiker. Trotzdem würde ich gerne Shader schreiben können.

Meine Frage ist: Macht es Sinn das ohne Progammierkentnisse zu lernen?

Und wie wird das in professionellen Spielen gehandhabt? Ist der Grafiker oder der Programmierer dafür zuständig? Imho beides. Ein Shader zu schreiben, der über Trivialfunktionen hinausgeht, ist IMHO ohne Programmierkenntnisse nich sinnvoll. Wenn man aber mit den Grundzügen linearer Algebra (und bissle Bildverarbeitung) noch vertraut ist, kann etwas Ausprobieren ja nicht schaden :)

Der Grafiker würde evtl. eher den Einsatz verschiedener Shader zu einem Material machen bzw. die parametrisierte Gestaltung über eine Art Effektframework. Aber ich denke das ist sehr vom Team abhängig.

[Gast]

Probier mal RenderMonkey (gibt's bei ATI) aus. Damit kann man sich Shader "zusammenklicken", soweit ich das verstanden habe. Ist für GLSL und HLSL.

[tokugawa]

Als Schnittstelle zwischen Shaderprogrammierer und Content Artists hat sich eigentlich FX Composer etabliert, das ist dafür recht gut, unterstützt aber derzeit nur HLSL (FX Composer 2.0 soll dann auch GLSL unterstützen).

ATI RenderMonkey ist bezüglich Bedienung nicht so ausgefeilt und wirklich mehr ein "Programmierer-Werkzeug".


Wenn man wirklich selbst Shader schreiben will, kommt man um Programmierkenntnisse nicht herum.

In einem echten Spieleprojekt werden Tools wie FX Composer (entweder wirklich FX Composer, oder was hausgemachtes) verwendet: der Shaderprogrammierer schreibt die (HLSL-)Shader und integriert die Annotationen so, dass der FX Composer dafür ein komfortables Interface (speziell diese Properties-Liste) bereitstellen kann, und die Content Artists können dann mittels dieses User Interfaces bequem die Shaderparameter kontrollieren.

Ich empfehle ausdrücklich nicht, GLSL zu lernen wenn man kaum Programmierkenntnisse hat. Einige Dinge wie bestimmte erzwungene Typecasts (trotz theoretisch klarer impliziter Konvertierung), oder dass man bei floats immer .0 dazuschreiben muß (und z.b. 15 nicht als "float" gilt), sind definitiv Stolpersteine für Leute, die noch nie programmiert haben. Wobei hier die NVIDIA-GLSL-Implementierung "laxer" ist und mehr eigentlich falschen Code toleriert (es aber wirklich Sinn macht, im Gegensatz zur strengen GLSL-Spezifikation).

HLSL+Effektframework ist wegen FX Composer zu empfehlen; sehr nett ist auch Cg (welches ebenfalls ein Effektframework hat, und außerdem eine Obermenge von HLSL darstellt).

Die "Starting Points" sind auf jeden Fall:
http://developer.nvidia.com
http://www.ati.com/developer

[Gast]

In einem echten Spieleprojekt werden Tools wie FX Composer (entweder wirklich FX Composer, oder was hausgemachtes) verwendet: der Shaderprogrammierer schreibt die (HLSL-)Shader und integriert die Annotationen so, dass der FX Composer dafür ein komfortables Interface (speziell diese Properties-Liste) bereitstellen kann, und die Content Artists können dann mittels dieses User Interfaces bequem die Shaderparameter kontrollieren.
Nicht zu vergessen sind die 3DS/Maya-Plugins für .fx-Files. Damit können die Artists schon gleich die Shader auf die Objekte legen und die Parameter ungefähr festlegen. Eigentlich braucht damit ausser dem Shaderprogrammierer keiner mehr FX Composer oä..
Sehr interessant in dem Zusammenhang ist auch Collada FX. Ein gemeinsamer Standard für Modelling-/Shadertools und Engines. Hoffentlich kommt bald das Update auf 1.4.2 damit auch HLSL unterstützt wird...

[DaBrain]

@tokugawa

Mit Rendermonkey kann ich in der Tat kaum etwas anfangen.

Der FX Composer klingt ansprechender. Leider kommt HLSL nich in Frage. :(

Nicht zu vergessen sind die 3DS/Maya-Plugins für .fx-Files. Damit können die Artists schon gleich die Shader auf die Objekte legen und die Parameter ungefähr festlegen. Eigentlich braucht damit ausser dem Shaderprogrammierer keiner mehr FX Composer oä..
Sehr interessant in dem Zusammenhang ist auch Collada FX. Ein gemeinsamer Standard für Modelling-/Shadertools und Engines. Hoffentlich kommt bald das Update auf 1.4.2 damit auch HLSL unterstützt wird...

Zu den Plugins: Kann man damit die Shader auch selber machen, oder nur importieren?

Collada FX scheint interessant zu sein. Darüber werde ich mich mal genauer informieren.

@ollix
Danke. Das hat mich wirklich interessiert.
Was würde denn z.B. gerade so über die Trivialfunktionen hinausgehen?

@ShadowXX
Ich meine besonders Material Shader und Fullscreen Effekte, die über Shader dargestellt werden.

[Gast]

Zu den Plugins: Kann man damit die Shader auch selber machen, oder nur importieren?
Nur parametrisieren.
Artists lässt man nur ungern an Shadercode. Wenn da einer nicht aufpasst, kann es unschöne Folgen (z.B. Renderstates nicht zurückgesetzt im Effektfile) haben, deren Debugging lange und damit teuer sind.
Ausserdem sind sie halt performancekritisch.

Collada FX scheint interessant zu sein. Darüber werde ich mich mal genauer informieren.
http://www.khronos.org/developers/library/siggraph2006/COLLADA_Tech_Talk/NVIDIA_-_COLLADAFX_FXComposer.ppt
http://www.khronos.org/collada/presentations/collada_siggraph2005.pdf
http://www.khronos.org/developers/library/gdc_2006/COLLADA/

[DaBrain]

Nur parametrisieren.
Artists lässt man nur ungern an Shadercode. Wenn da einer nicht aufpasst, kann es unschöne Folgen (z.B. Renderstates nicht zurückgesetzt im Effektfile) haben, deren Debugging lange und damit teuer sind.
Ausserdem sind sie halt performancekritisch.


Jetzt fühle ich mich ein Stück weit zurückgesetzt.
Vielleicht ist es auch besser so. Ich habe alleine schon mit ein paar animierten Texturen für Performance Probleme gesorgt... Natürlich waren die nicht für Low-End Rechner gedacht, aber darauf wollte ja niemand hören... :rolleyes:

http://www.khronos.org/developers/library/siggraph2006/COLLADA_Tech_Talk/NVIDIA_-_COLLADAFX_FXComposer.ppt
http://www.khronos.org/collada/presentations/collada_siggraph2005.pdf
http://www.khronos.org/developers/library/gdc_2006/COLLADA/

"Who is it for?"
Ganz oben Graphic Prorgammer und ganz unten Artist.
Sogar bei den Tools möchte man die Artists also raus haben.

So langsam verstehe ich was Collada wirklich ist. Danke für die Links.

[Monger]

Langfristig geht der Trend wohl ganz klar dahin, Shader vom Grafiker machen zu lassen. Da bin ich mal sehr auf den UT2007 Editor gespannt, der Shader Editor darin sah ganz vielversprechend aus.

Momentan müssen halt erstmal die Grundlagen dafür geschaffen werden, und dafür braucht man halt die Programmierer. Mal sehen wie es in 5 Jahren aussieht...

[Arokh]

Ich weiss nicht so genau ob das hier das richtige Forum ist, aber es geht wohl hauptsächlich ums Programmieren.

GLSL Shader schreiben scheint mir nichts anderes als OpenGL Coding zu sein.
ich weiß nicht, ob dir das bewußt ist (mir war es das bis vor kurzem nicht), es gibt bei den Shadern eine Spezialität: der Shadercode ist gar nicht Teil der Anwendung (z.B. eines Spiels), die den Shader benutzt. Wenn du deine Anwendung compilierst, wird der Shader-Sourcecode gar nicht mitcompiliert, sondern ist für deine Anwendung einfach nur ein String. Compiliert wird der Shadercode erst zur Laufzeit durch den Grafikkartentreiber, wenn eine entsprechende OpenGL-Funktion aufgerufen wird.
Ich weiß noch, wie ich, als ich gelesen hatte, daß Shaderprogramme in Assembler (später dann in Cg) geschrieben werden sollen, mich gefragt habe, ob dann die ganze Anwendung in Assembler (bzw. Cg) geschrieben werden muß, oder nur derjenige Programmteil, der den Shadercode enthält. Jetzt weiß ich natürlich, daß diese Frage Unsinn ist, da es gar keinen solchen Programmteil gibt.

Das heißt natürlich, daß das Shaderprogramm ziemlich stark vom gewöhnlichen OpenGL Code, der ja Teil der Anwendung ist, getrennt ist.
Z.B. könntest du den Shader-Sourcecode einfach in eine Textdatei schreiben, die deine Anwendung zur Laufzeit in einen String ausliest.

[DaBrain]

So ungefähr hatte ich mir das vorgestellt. Ich wollte nicht den Shader Code, sondern nur diese abgetrennten Datein selber schreiben.

[Arokh]

So ungefähr hatte ich mir das vorgestellt. Ich wollte nicht den Shader Code, sondern nur diese abgetrennten Datein selber schreiben.ich weiß allerdings nicht, wie es um die Möglichkeit steht, die Shader zu testen, ohne die Anwendung, die sie verwenden soll, laufen zu haben...