Soweit ich weiß, sollte man statt einem (oder bei dir halt mehreren) Uber-Shadern lieber mehrere kleine haben.
Ich glaube zwar, dass das Problem mit den If-Abfragen bei Shadern inzwischen nicht mehr so akut ist, aber ich denke schon, dass
ein größerer Shader zu weniger Performance führt.

So wie ich das verstanden hab schmeißt er vor dem an OpenGl senden alles aus dem Uber-Shader raus was er nicht braucht, und hat dann nen schlanken Shader ohne ifs - schlauer Ansatz wie ich finde.

Die Screenshots sehen wirklich toll aus und das Spielkonzept hört sich auch sehr interessant an.

_________________
2+2=5
For extremely large values of two

Wilson hat schon recht, hier mal ein kleines Beispiel

Vertex Shader ("Mega Shader")


Fragment Shader ("Mega Shader")


Jetzt gibt es für jedes Material einen einzelnen Shader, so ungefähr so aussieht:
Vertex Shader für ein spezielles Material


Fragment Shader für ein spezielles Material


Das hat nen riesen Vorteil: ich kann die Shader beliebig zusammensetzen und muss bei einer Optimierung/Verbesserung nur eine Shader-Datei ändern. Da OGL zwar #include für den späteren Gebrauch schon mal reserviert hat, es aber noch nicht funktioniert, hab ich das selbst bei mir in die Shader-Klasse eingebaut. Die ganzen #ifdef - Sachen (also der Preprozessor) funktioniert jedenfalls prächtig. Die ganzen #if... statements übergebe ich so an OGL, so dass der sich dann raussuchen darf, was er braucht. Da alles unbenutzte schon zu Compile-Time rausgeschmissen wird, ist der final ausgeführte Shader je nach Material sehr schlank.

@Wilson:
danke für dein Feedback - da ist man doch gleich motivierter

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com

Das ist ja mal cool, das hört sich sehr performant an. Zumindest glaub ich das, weil der shader wird ja erst nachdem laden compiliert, wobei dann doch alle undefinierten Sachen raußfliegen und somit im eigentlichen Shader nicht mehr auftauchen, oder? Wie ist das in dem Fall mit der maximalen Zeilenlänge? Gab es das nicht bei Shadern? Wie wird die dort berücksichtigt? Es könnte ja sein, dass der Shader beim laden bereits eine maximale Länge nicht überschreiten darf, oder muss erst der compilierte Shader eine maximale Länge einhalten?

_________________
Klar Soweit?

Hi!
Echt eine tolle Idee. Erinnert mich aber doch sehr an Thief: Dark Project.
Das ist nicht zufällig das, woran du gedacht hattest?
Ist aber nicht schlimm, ich hab Thief geliebt und finde, es gibt viel zu wenige Stealth-Shooter dieser Sorte!
Ich freu mich auf das Spiel!

achja, mich würde mal interessieren wie genau du die Schatten machst! Sind das Stencilschatten?

Oh, da ist ja noch nen offener Post

Also von einer maximalen Zeilenlänge in nem Shader hab ich noch nichts gehört, wäre ja komisch. Also dass man keine 2 GB Shader-Code hochladen kann, ist ja irgendwie klar. Der GLSL-Compiler liegt doch im Treiber und ist somit erstmal nicht von der Grafikhardware beschränkt. Der Output des Shaders ist dann aber Grafikkartenhardware-beschränkt (z.B. maximale Anzahl von varyings).

Bei den Preprozessor-Anweisungen liegt der Vorteil darin, dass die #if-#else-#endif im Shader-Code nicht mehr auftauchen, da diese vom Preprozessor vorher bereits komplett aus dem Shader rausgeworfen werden. Man kann (wie beim Preprozessor normal) bei den #ifs natürlich keine Variableninhalte überprüfen, dafür ist der Preprozessor jedoch nicht da.


Ich benutze Shadow Textures als Schattenmethode. Ich hab mich dafür einfach entschieden. Die haben den Vorteil, dass ich keine Kenntnisse über die Geometrie brauche um Schatten zu erstellen. Außerdem hab ich den Vorteil, dass ich für halb-transparente Objekte (z.B. einen Zaun), ebenfalls sehr einfach Schatten erstellen kann. Das Anti-Aliasing-Problem ist natürlich ein Nachteil, jedoch wird der bei mir nicht so groß, da ich keine sehr weit reichenden Lichtquellen haben werden (bzw. benutzen will). Die Punktlichter sind auch nicht mehr so das Problem, da diese intern nur 6 Spot-Lights mit einem FOV von 90° sind.
Ich weiß nicht, ob es bei Stencil-Schatten auch mögich ist, jedoch hab ich mit dem Shadow Textures auch noch die Möglichkeit, die Shadows ebenfalls durch den Parallax-Shader zu schicken. Dadurch werden die Schatten an Objekten sehr schön angepasst, wodurch die Oberfläche noch realistischer wirkt. Das kann man im neusten Video sehr gut an der hinteren Wand sehen.

Für Soft-Shadows benutz ich nen einfachen Blur-Filter. Dadurch entstehen etwas weichere Schatten. Die Schatten werden ebenfalls noch durch den DoF-Post-Filter nochmal etwas "weicher" gezeichnet.

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com

Basiert dein Spiel auf der sysygy Engine? Oder ist Sysygy=Gael?

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Für Schatten habe ich in der Unreal Engine 3 einmal ein sehr interessanten Ansatz gelesen. Dort wird mit zwei depthcubemaps gearbeitet, die eine ist etwas höher auflösend und die andere ist niedrig in der Auflösung und mit einem Blur filter verschommen. Anschließend wird der Vergleichswert als interpolation aus den beiden Texturen gebildet, wodurch Schatten entstehen die weicher werden, je weiter sie sich von dem angestrahlten Objekt entfernen. Im ungefähren stell ich mir das so vor wie auf dem Bild im Anhang. Nachteil ist natürlich, dass man doppelt so viele Cubemaps braucht und somit auch doppelt so viele renderpasses, aber dafür siehts garantiert noch cooler aus. In deinem Fall muss du natürlich die erschummelte Tiefe durch das Parallaxmapping berücksichtigen.

Edit: Ich würd das alles gerne selbst mal ausprobieren, aber ich schaffe es einfach nicht nen vernünftigen Renderbaum zusammen zu tüffteln, der mir erstmal alles an Daten in ein FBO schiebt. Meine Lichtquellen zeichne ich als billboarded quads über die szene , aber da die Daten im FBO falsch ankommen und ich nicht weiß was ich falsch mache kann ich das alles nicht ausprobieren. Auch habe ich ein Probleme Tiefenwerte in texturen zuspeichern, bzw. im Shader auszulesen. Wäre klasse, wenn du mir dabei etwas helfen könntest per pn oder so, da sich das was du beschrieben hast sehr stark nach dem anhört, was ich auch umsetzen möchte.

Edit2: kann auch sein, dass man den maximalen Beleuchtungsradius der Lichtquelle verwenden muss anstelle des roten Vektors, wie gesagt, das sind nur gedanken gänge, prüfen kann ich das nicht

_________________
Klar Soweit?

Gael ist im Moment der Name der Engine - da ich für das Spiel noch keinen Namen habe, heißt es im Moment auch noch Gael.

Die Engine erstelle ich komplett neu, da ich in meiner alten Engine ein paar Ansätze drinnen habe, die mir nicht gefallen und nicht flexibel genug waren. Ein paar Code-Fetzen übernehm ich schon (z.B. die komplette Vektor-Geometry-Unit oder die FBO-Unit), ein Großteil ist jedoch komplett neu geschrieben.

Das liegt vor allem daran, dass ich komplett dynamisches Licht einbauen will und fast die komplette Render-Pipeline mit Shadern realisiert wird. Im moment gibt es z.B. nur einen Render-Pass, der ohne Shader realisiert wird - das ist der Pre-Depth-Pass, bei dem nur die Tiefenwerte geschrieben werden. Der Rest ist komplett mit Shadern. Daher wird auch eine OpenGL 2.0-Grafikkarte Vorraussetzung sein.

Zudem arbeite ich nicht mehr mit Display-Listen sondern mit VBOs, dadurch hätt ich soviel ändern müssen, dass es sich nicht lohnt, alte Code-Fragmente zu benutzen.


Das hab ich auch schon gesehen - aber nur als Video (YouTube Link). Jedoch ist das eine relativ gute Idee, aber der Speicherverbrauch ist jedoch relativ hoch - und die 6 zusätzlichen RenderPasses für jedes weitere Punktlicht sind schon sehr hoch. Vielleicht bau ich sowas mal ein - jedoch mit sehr niedriger Priorität.

Ich schau mal, dass ich in nächster Zeit mal ne Demo fertig stelle und diese mal hochlade - damit jeder mal ein wenig rumspielen kann . Jedoch will ich vorher noch ein paar Features einbauen, die jedoch noch einiges an Zeit dauern. Die aktuelle Demo könnt ich zwar schon hochladen, jedoch bin ich mit der noch nicht so zufrieden.



Also mein Render-Baum schaut wie folgt aus (dargestellt als XML):
Kurze Erklärung

• RenderPass Enabled: Wenn 0, wird der Pass vom Renderer nicht automatisch ausgeführt, sondern von anderen Objekten (beim Depth:Lighting z.B. jedes Licht)
• RenderElements: was für Mesh-Typen gezeichnet werden sollen
• VBO-Binds: welche VBO-Streams benutzt werden sollen
• DepthMask, ColorMask, DepthFunc: wie glDepthMask, glColorMask, glDepthFunc
• PolygonOffset: wie glPolygonOffset
• Type="RenderToTexture": zeichnen die Child-Passes in ein FBO, der dann am Ende per Fullscreen-Quad ausgegeben wird

Vielleicht hilft das ein wenig

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com

Hallo LittleDave,


Vielleicht das alte Problem mit den Normalen?


Das versteh ich nicht. Du machst doch die Lichter mit Texturen, oder? Die VBOs sind doch bloße Formen, warum müssen die neu erstellt werden, wenn Du die Texturen änderst?


Das ist wahrscheinlich ein statistisches Problem (Mittelwert/Varianz der Farbe) und man könnte es vielleicht mit Stichproben in den Griff kriegen. Und O,Mann! Was ist "eine winzige LED"???

Viele Grüße,
Traude

Eine winzige "Licht emmitierende Diode" Siehe Wikipedia.

Und da hat er schon recht, mit dem Helligkeitsproblem. Eigentlich ist das jetzt so eine Raytracing Problematik, da du nicht nur die direkte Sichtlinie zu den Leuchten beachten musst, sondern auch die gesamte indirekte Beleuchtung.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Wegen dem Licht: Ich würde vielleicht nur das Licht speichern, an das sich der Spieler gewöhnt hat und das dann als Faktor oder Summand verwenden um die Szene zu skalieren (schon im Shader). Damit dürftest du den realistischsten Wert erhalten. Die aktuelle Helligkeit brauchst du aber dennoch, um nämlich den Anpassungswert zu korrigieren. Dafür fällt mir ganz Spontan glHistogram ein. Nie damit gearbeitet, aber es scheint mir hilfreich.

Wenn du es ganz krass machen willst, kannst du noch nen FBO oder so erstellen, wo du die inverse der Szene reinrenderst, und zwar additiv (ok, da wäre der Accumulation-Buffer eher angebracht, da musst du dann auch nur einmal rendern). Das kopierst du dann in eine Textur / du benutzt diese Textur dann als multiplikatives Blending über der Szene und simulierst damit die dunklen Flecken die man sieht, wenn man in überstrahltes Licht geschaut hat (überreizte Nervenzellen oder so war das). Natürlich müsstest du diese Textur jeden frame etwas gen weiß verschieben, damit der Effekt nachlässt. Wäre aber ziehmlich cool.

Weiter so!

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Coole Idee.

Das mit glHistogram ist tatsächlich ein Ansatz. Man müsste halt nur wissen ob das auf der GraKa läuft oder ob da der Treiber in den "jag die Frames in den Keller"-Modus wechselt.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ne, um Beleuchtung geht es noch nicht. Es geht darum, Meshes zu skalieren - und zwar nicht mit glScale sondern manuell - also Vertex für Vertex. Ist nur ein internes Problem. Aber trotzdem danke


Es geht dabei immer noch um den Editor. Es ist jetzt so, dass jedes Material nen eigenen VBO hat, der speziell für das Material angefertigt wird (Anzahl Texturkoordinaten werden z.B. beachtet). Jetzt müsste ich bei einem Material-Wechsel und bei jedem Verschieben, Skalieren, Rotieren mindestens zwei VBOs neu erstellen (Material: 2 VBOs, Transformieren: 1 VBO). Zudem sind die Materials noch extrem mit dem Renderer und noch speziell mit den Shadern verknüpft. Wenn ein Level jetzt einmal geladen ist und nicht mehr verändert wird, dann ist das sehr einfach beim Zeichnen - im Editor leider nicht. Daher hab ich für den Editor ja auch nen extra Render-Pfad


Danke für den Tip mit dem glHistogram, kannte ich bisher überhaupt nicht . Mal schauen, wie das so funktioniert ...


Hört sich interessant an - ich zeichne eh schon in nen FBO, den ich dann per Post-Shader anzeige. Somit wäre da nicht mehr viel zu ändern. Zudem hat jedes Material auch noch nen eigenen Shader. Somit hab ich bereits überall nen aktiven Shader (bin ja fast schon OGL 3 - kompatibel ), was das Leben schon extrem erleichtern kann.


Mal schauen wenn ich es so implementiere, dann werd ich natürlich auch dazu Feedback geben

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com

Wenn ich dich richtig verstanden habe erstellst du bei jedem Transformationsforgang das VBO neu.... warum speicherst du nicht eine Matrix zu den Vertex Daten und veränderst nur die???
Ich meine es würde ja schon mal verhindern das du ständig das VBO neu füllen müsstest...

Was sich mir nicht erschließt ist warum du bei Verschieben, Skalieren, Rotieren etwas an den Material VBO ändern musst ...