Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

1

26.06.2014, 20:46

Shader-beschreibendes Dateiformat

Liebe Community,

anstatt mal wieder etwas zu fragen, möchte ich etwas vorstellen. Es ist kein Projekt, und daher gehört es meiner Ansicht nach nicht in die "Projekte und Stellenangebote" - Seite, weshalb ich es hier versuche.
Es handelt sich um ein Dateiformat, welches die Anbindung von Shadern an Renderer vereinfachen soll. Ich persönlich hatte zum Beispiel immer meine Probleme damit, dass es bei OpenGL keine effektive Lösung gibt, an welchen generischen Shader Parameter man Attribute, Matrizen, etc, etc. übergeben soll. Daher habe ich mir etwas eigenes ausgedacht, und versucht das umzusetzen. Mittlerweile habe ich das Format schon in mehreren Projekten erfolgreich verwendet, und habe mir gedacht: naja, schaden kann's nicht, also stell's doch einfach mal vor. Ich habe einer Speziifikation geschrieben, und werde sie im Anschluss auch verlinken. Es würde mich freuen eure Meinungen dazu zu hören, ob das Format sinnvoll ist, ob es eurer Meinung nach totaler Schwachsinn ist, oder was auch immer ihr davon haltet.

Das Format könnt ihr natürlich auch gerne selbst verwenden (vorausgesetzt natürlich es gefällt euch denn auch).

Link zur Spezifikation: http://dl.garishland.de/d2/EffectFile.pdf

Liebe Grüße,
~ EuadeLuxe ~

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

2

26.06.2014, 21:57

Das, was daran wirklich spannend und nützlich gewesen wäre, ist das, was fehlt. Der Parser mit einer passenden Bibliothek.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

3

26.06.2014, 22:14

Nun ja, ich könnte mal meinen Parser isolieren. Aber ich warne euch vor: Ist wirklich ziemlich rar bestückt: Fehlende Error-Recovery (er zeigt immer nur die Fehlermeldung des ersten Fehlers an), und wahrscheinlich ist er nicht sonderlich performant (müsste man mal testen). Aber ja, ich schaue mal, dass ich ihn in eine Bibliothek packe. Dann wird das ganze vielleicht auch noch jemand anderem helfen ;).

Beiträge: 1 223

Wohnort: Deutschland Bayern

Beruf: Schüler

  • Private Nachricht senden

4

26.06.2014, 23:23

Du fragst danach, was nach meiner Meinung nach völliger Schwachsinn ist...
Also wenn du mich fragst sind das beim Überfliegen des Dokuments vor allen Dingen die Shader-Parameter-Zuordnungen. Das ist ja eingeschränkter als
zu fixed Pipeline Zeiten und meiner Ansicht nach, naja, relativ überflüssig.

Ich habe in meiner Grafikhilfslib auch schon seit einiger Zeit etwas Ähnliches integriert. Als alternatives anregendes Beispiel kurz erläutert. Ich hatte mich außerdem dazu entschieden, die einzelnen Attribute mit dem @-Zeichen einzuleiten. Eine verkürztes Beispiel:

HLSL-Quelltext

1
2
3
4
5
6
7
8
9
@AllShaders-
    #version 330
@
@VertexShader-
    void main() { ... }
@
@FragmentShader-
    void main() { ... }
@

Das Zeichen habe ich gewählt, da es im GLSL Syntax nicht legal innerhalb von Code vorkommen kann und dort auch nicht versehentlich so schnell hinkommt. Deshalb ist es einfach und schnell zu parsen. Außerdem werden die Fehler beim Shader-kompilieren noch mit der richtigen Sektion und dem richtigen Shadertyp in Verbindung gebracht, auch wenn man mal eine geschweifte Klammer vergessen hat. Der Code innerhalb der "AllShader" Sektion wird automatisch vor allen anderen Shadertypen gesetzt. Sehr praktisch für einige Definitionen, Uniforms und Hilfsfunktionen wie ich finde.

5

27.06.2014, 15:47

Okay, danke erst mal für die Kritik.
Wie genau würdest du empfehlen, Attribute, wie etwa Position, Normale, Tangente, etc. an Shader-Parameter zu übergeben? Legst du einen gewissen Namen fest, der benutzt werden muss, damit ein bestimmtes Attribut übergeben wird? Oder legst du fest, welches Attribut an welche Location gebunden werden muss? Denn das ist das, was mir eigentliche Probleme bereitet hat, und weshalb ich die Parameter-Mappings genommen habe.

Man kann natürlich auch noch andere Attribute, und Uniforms übergeben. Lediglich für die Standard-Sachen soll das eine Hilfe darstellen.

Beiträge: 1 223

Wohnort: Deutschland Bayern

Beruf: Schüler

  • Private Nachricht senden

6

27.06.2014, 17:23

Ich habe die Attribute bis jetzt immer an feste Locations gebunden. Was hat dir daran Probleme bereitet? Theoretisch kann man sowohl mit blanken direkten OpenGL als auch mit meiner Hilfslib die Locations von OpenGL zuweisen lassen und dann herausfinden und auf die VAO Einträge anwenden, aber ich sehe dabei nur Nachteile wie mehr Schreibarbeit und kein Kompatibilität zwischen verschiedenen VAOs und Shadern.

7

27.06.2014, 17:35

Nun ja, generell fühle ich mich einfach nicht wohl damit. Ich habe immer den Eindruck, dass diese Lösung einfach nicht flexibel genug ist. Kann natürlich auch sein, dass das einfach nur ein riesiger Denkfehler meinerseits ist. Weißt du oder irgendjemand anderes zufällig, wie das in größeren Projekten gehandhabt wird?

Beiträge: 1 223

Wohnort: Deutschland Bayern

Beruf: Schüler

  • Private Nachricht senden

8

27.06.2014, 17:44

Normalerweise ist die Lösung mit festen Locations die Empfohlene. Und eigentlich auch die Flexibelste. Es ist nunmal OpenGL und GLSL. Was macht den deine Software intern, um das umzusetzen? Das muss ja auf die vorhandenen Möglichkeiten abgebildet werden und für mich sieht das nach reduzierten neuauflage(Wrapper) von festen IDs aus. Mindestens das Gleiche würde man auch erreichen, wenn man für die IDs in GLSL für Tangente, Normale und was weiß ich, einfach ein Define macht.

9

27.06.2014, 17:57

Jetzt wo du's sagst, hast du eigentlich Recht. Was mich allerdings noch interessieren würde: Ist es aber nicht etwas doof in der Rendering-Engine dann ein Set von Konstanten zu haben? Als Antwort auf deine Frage: Ich mache es bei mir so, dass beim Laden des Shaders die Locations der Parameter der Shader-Parameter-Mappings in Semantik-Location-Paaren in einer Map gespeichert werden, und die Rendering-Engine dann einfach mit der jeweiligen Semantik als Schlüssel sucht.

Und bei mir ging gerade ein Licht auf dank dir: Im Endeffekt hast du Recht, wenn du sagst, dass das, was ich hier mache einfach nur eine Verkomplizierung ist: Statt feste IDs festzulegen, erfinde ich ein neues Dateiformat, dass statt IDs Enumerations einsetzt, relativ aufwendig zu parsen ist, und am Ende das Gleiche Ergebnis bringt. Wie sinnvoll. :| . Danke dir ;). Nur noch eine Frage zu den Locations: Soweit ich weiß, gibt es diese Möglichkeit, die Locations im Shader-Code zu bestimmen mittels layout(location=0) oder etwas ähnlichem erst seit einer späteren GLSL-Version. Wie machst du das, bindest du sie erst zur Laufzeit, oder ist mein Wissen darüber gerade falsch, oder aber erlaubst du erst Shader ab einer gewissen Version? Würde mich interessieren, wenn du die Locations erst zur Laufzeit bindest, woher du dann den Parameter-Namen bekommst.

Beiträge: 1 223

Wohnort: Deutschland Bayern

Beruf: Schüler

  • Private Nachricht senden

10

27.06.2014, 18:18

Warum sollte es schlecht sein, Konstanten zu haben? Momentan hast du auch Konstanten bloß hinter den Bezeichnern etwas versteckt. Prinzipiell fände ich es gut, wenn eine Renderengine ein paar Standards für die gänigen Werte festlegt. Sonst gibt es am Ende noch verschiedene Shader mit inkompatiblen IDs für das Selbe.

Soweit ich weiß gibt es "layout(location=...)" seit OpenGL 3.3/GLSL 3.3. Das ist einer von vielen Gründe warum ich für mich persönlich beschlossen habe, doch die Abwärtskompatibilität zu ähnlichen Vorgängerversionen aufzugeben. (Andere sind zum Beispiel Core Profile, Texture Swizzle oder Geometry Shader ohne Extension...) Wenn du das nicht machen kannst, wäre ein entsprechender eigener Syntax dafür nicht schlecht. Wenn 3.3 allerdings vertretbar ist, ist es damit natürlich vieles viel einfacher machen, wie eigentlich jede neue Version... ^^
Von den Hardwarevoraussetzungen hält sich der Unterschied zwischen 3.0(GLSL 1.3) und 3.3(GLSL 3.3) soweit ich weiß einigermaßen in Grenzen.

Werbeanzeige