DGL
https://delphigl.com/forum/

GLSL Shader IDE
https://delphigl.com/forum/viewtopic.php?f=20&t=3230		 Seite 1 von 1
Autor:  Mars [ Mo Sep 06, 2004 17:48 ]
Betreff des Beitrags:  GLSL Shader IDE
In der neuesten Caradversion (http://www.basegraph.com/bg/CaradNext/index.html) gibt es eine IDE für GLSL Shaderprogramme, für die ich ein kleines Tutorial geschrieben habe:
http://www.basegraph.com/bg/CaradNext/tutor_shaderanalyse/shaderanalyse.htm

Wer es durchexerziert wird mit einem (IMHO) durchaus interessanten, selbst erstellten Demo mit Metaballs und einem importierten Shader belohnt, außerdem ist es ein nützliches Werkzeug, um bestehende Shader zu analysieren bzw. neue Shader zu entwerfen.

Feedback über die Bedienung an sich, wo es hakelt und was verbessert werden könnte, wäre mir sehr recht.

Das Demo, wie es im Tutorial erstellt wird:
Bild
http://www.basegraph.com/bg/CaradNext/tutor_shaderanalyse/BallShader.zip
Autor:  LarsMiddendorf [ Mo Sep 06, 2004 19:04 ]
Betreff des Beitrags: 
Ich weiß nicht ob es der richtige Weg ist direkt die Shader zu bearbeiten:
-Ein Material besteht außer in Demos immer aus mehreren Shadern.
-Manche Shader müssen für jedes Licht wiederholt werden und andere werden nur für einen Renderpass benötigt.
-Viele Shader unterscheiden sich nur an wenigen Stellen.
-Das Erstellen von Shadern erfordert Programmierkenntnisse.

Daher denke ich, dass es sinnvoller ist die Materialien und nicht die Shader auf höherer Ebene zu bearbeiten, so wie es auch in 3D Programmen üblich ist. Die Shadern müßten dann automatisch generiert werden.

Shadersprachen vereinfachen die Programmierung von Shadern, aber das Problem wird dadurch nur verschoben. Bei FarCry gibt es z.B. ziemlich viele Cg Programme für alle möglichen Kombinationen von Materialien und Lichtern. Bei HL2 hat man fast 2000 Shader, dann allerdings automatisch durch IFDEF's, vorher erzeugt. Das Problem ist dabei natürlich, dass man bei seinen Materialien dann beschränkt ist. Man kann nicht für jede Änderung einen kompletten Satz von Vertex und Fragment Shadern programmieren, nur weil man plötzlich eine zweite Bumpmap auf der Fläche oder Ähnliches haben möchte.

In meinem Material Editor kann man das Material hierachisch aus Komponenten zusammensetzen. Die entsprechenden Shader(ARB_fp,ARB_vp) werden dann automatisch, aber nur intern für das Material, erzeugt. Es gibt die verschiedensten Komponenten vom Combiner oder Modifier bis zur Texture Animation und jede Komponente kann man noch detailiert einstellen.Überall kann man auch Funktionen eintragen.

http://www.3d-seite.de/shader1.png
http://www.3d-seite.de/shader2.png
http://www.3d-seite.de/shader3.png
http://www.3d-seite.de/shader4.png

[/list]
Autor:  Mars [ Di Sep 07, 2004 00:22 ]
Betreff des Beitrags: 
Dein Materialeditor schaut sehr gut aus, und ich bin überzeugt, dass deine Engine mit "kommerziellen" locker mithalten kann.

Der Grundgedanke der mir bei BaseGraph vorschwebt, ist allerdings weniger eine Engine zu schreiben, die ihre Funktionalität bietet und die Implementierung vor dem Benutzer versteckt - vielmehr soll es ein Werkzeug sein, Techniken auszuprobieren (am besten interaktiv) und dann, mit den gewonnenen Erkenntnissen und nicht einmal notwendigerweise auf BaseGraph selbst aufbauend eine eigene "Engine", die eventuell einer bestimmten Problemstellung angemessen ist, zu entwickeln.

In BaseGraph besteht ein "Material" eigentlich aus einer Shaderliste, wobei eine Shaderliste eine beliebige Zusammenstellung von Texturen, Textureinstellungen, OpenGL Rendereinstellungen und Shaderprogrammen (ARB oder GLSL) sein kann - allerdings ist das Ganze eine Ebene tiefer als bei dir angesiedelt, da man praktisch direkt die OpenGL Einstellungen bearbeitet, ohne eine weiteres Abstraktionslayer dazwischen zu haben (dies ist auch so beabsichtigt, da ich in BaseGraph alle möglichen Topologien simulieren können möchte), wobei es am Benutzer liegt etwa Zusammenstellungen von Shadern zu finden, die das machen, was gewünscht wird (oder in einem späteren Zug entsprechende Multipassverfahren zu entwickeln).

Wenn ich BaseGraph wirklich für konkrete Anwendungen (etwa 3D-Shooter) auslegen möchte, würde ich genau deine Vorgehensweise wählen - also (durchaus auch flexible) Funktionalität vorgeben, die jedoch abstrakt genug ist, um auf der "Engine"-Ebene auf unterschiedliche Weise je nach Bedarf umgesetzt zu werden. So aber ist es mir eher wichtig, dass Carad möglichst wenigen Einschränkungen unterworfen ist - es ist dann Aufgabe des Anwenders z.B. eine Shaderverwaltung aufzustellen, die "genau" seinen Bedürfnissen entspricht.
Autor:  LarsMiddendorf [ Mi Sep 08, 2004 15:00 ]
Betreff des Beitrags: 
Wie verwaltet denn ihr anderen eure Materialien bzw. Shader? Da die Shader ja wegen GLSL usw... nicht mehr schwer zu programmieren sind, ist die Herausforderung ja jetzt die Materialien sinnvoll zu integrieren, aber gleichzeit auch noch sehr flexibel zu belassen. Doom3,HL2, UE3, FarCry gehen da ja alle verschiedene Wege.
Autor:  lithander [ Do Sep 09, 2004 13:07 ]
Betreff des Beitrags: 
Würde mich mal interessieren, welche Wege die Großen nehmen. Hast du da lesenswerte Quellen?

-lith
Autor:  LarsMiddendorf [ Do Sep 09, 2004 14:42 ]
Betreff des Beitrags: 
Das HL2 Materialsystem wird in diesem PDF ziemlich detailiert erläutert: http://www2.ati.com/developer/gdc/D3DTu ... hading.pdf


Auf dem Screenshot kann man sehen, dass beim Unreal Editor das Material aus Komponenten zusammen gebaut wird: http://www.unrealtechnology.com/html/te ... ue30.shtml

HL2 hat sicherlich keine sehr gute Lösung, weil man da nur aus einer Anzahl von Shadern auswählen kann.
Bei Unreal kann man ja beliebige Materialien zusammenbauen. Man sieht auf dem Bild auch, dass man dort keinen Shader sondern ein Material baut. Die Ausgänge sind die Normale, diffuse Farbe, speculare Farbe usw... Das Material als Netz ist natürlich aus den ersten Blick flexibler, als eine reine Baumstruktur. Allerdings muß man sich dann bei dem Erstellen auch um die Position der Knoten kümmern. Dadurch ist es hier ein wenig aufwändiger Materialien zu entwerfen. Bei dem Material als Baum muß es sich nicht zwangsläufig intern auch um einen Baum handeln. Die Struktur kann auch nur zur einfacheren Bearbeitung verwendet werden und beim Generieren kann man dann durch Zusammenfassen von gleichen Knoten auf unterschiedlichen Ästen ebenfalls einen Netzwerk erzeugen.
Autor:  Mars [ Sa Sep 11, 2004 09:21 ]
Betreff des Beitrags: 
Die Screenshots des Unreal Editors schauen gigantisch aus, allerdings zeigen sie auch auf, wo die Grenzen für Hobbyentwickler liegen, da bereits das Erstellen der Modelle und Texturen weit jenseits von Gut und Böse liegt. Die Engine hingegen, so technisch ausgereift wie sie sein mag, liegt hingegen eher im Bereich des machbaren (was eventuell auch daran liegt, dass dies eher ein Programmiererforum ist) - immerhin zeigt es wieder mal, dass man als Hobbyentwickler besser gar nicht versucht, grafisch das selbe Level wie die "ganz Großen" zu erreichen.
Spieltechnisch hingegen könnte man den Fehdehandschuh durchaus aufnehmen (mit genügend Engagement und Begeisterung) - ich finde es z.B. schade, dass eine so großartige Engine und die ganze Arbeit an einen "Shooter" verschwendet wird, und es erst Jahre später wirklich spielenswerte Produkte geben wird, die darauf aufbauen (wenn ich z.B. an Gothic 3 denke, so ist dessen Technik sehr viel weniger ausgereift, das Spiel selbst allerdings IMHO sehr viel interessanter)
Autor:  LarsMiddendorf [ Sa Sep 11, 2004 13:41 ]
Betreff des Beitrags: 
Zitat:
ich finde es z.B. schade, dass eine so großartige Engine und die ganze Arbeit an einen "Shooter" verschwendet wird, und es erst Jahre später wirklich spielenswerte Produkte geben wird, die darauf aufbauen (wenn ich z.B. an Gothic 3 denke, so ist dessen Technik sehr viel weniger ausgereift, das Spiel selbst allerdings IMHO sehr viel interessanter)


Das ist reine Ansichtssache. Ich spiele z.B. ausschließlich Shooter, weil es einfach Spaß macht durch großartige Level zu laufen, die Grafik zu bewundern und nebenbei noch ein wenig Action zu haben.
Autor:  Mars [ Di Sep 14, 2004 11:01 ]
Betreff des Beitrags: 
Das ist richtig - ich habe im obigen Post auch nur für mich persönlich gesprochen.
Seite 1 von 1 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/