Erstma thx fürs Feedback...über sowas freu ich mich nämlich immer !

Zu den Macken :


Ist mir bekannt, aber fiel mir leider erst nach dem Hochladen dieser Version hoch.Wird aber im nächsten Release auf jeden Fall gefixt.

Nein, da gibts wirklich noch keine Funktion um die zu löschen, kommt aber auch noch.

Der Mesh iss aus ATIs Rendermonkey, stammt also nicht von mir.Bei mir macht der übrigens absolut keine Probleme (es sei denn man macht etwas im Shader das dazu führen könnte).

Da kümmer ich mich auch noch drum.

Ist mir auch bekannt, wird sich aber noch ändern.


Zu den Vorschlägen :

Das geht eigentlich schlecht.Wenn ein Vertexshader (Pixelshader können nicht per Software emuliert werden, abgesehen vom speziellen nVidia-Tool) emuliert wird, dann geschieht dies ja über den Grafikkartentreiber, in den ich nicht eingreifen kann...oder hab ich dich da falsch verstanden :unsure: ?

Ist geplant.In der finalen Version wird man wahrscheinlich auf acht Hardwarelichter über state.light[n] zugreifen können.Ausserdem wird man auch die anderen States (z.B. Material, Fog, etc.) ändern können.

Das passiert ja rein theoretisch schon, wenn du den Shader bereits einem Pass zugewiesen hast.

Ich prüf mal, ob das den Workflow verbessert...wenn das der Fall ist, dann kommt das auch im nächsten Release.


Mitgelieferte Shader :
Bitte vergiss die Dinger (bis auf die simplen) ganz einfach, da diese nicht fertig und auch unbrauchbar sind.Die meisten (ausser simple.fp und simple.vp) waren nur Tests von mir, die im Normalfall nicht funzen, aber ich hab sie halt für Interessierte einfach mit ins Packet gepackt.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Mit emulieren des Shaders mein ich, dass dein prog die aufgaben der HW übernimmt und die farben/positionen der fragments/vertices berechnet, also das program durch parst.
Aber wie gesagt, das vergrößert das Projekt doch noch mal um ein ganzes Stück, hätte aber den Vorteil, dass jeder das Programm nutzen kann.

Das mit dem Mesh liegt auf jeden Fall nich an einem selbstgeschriebenen Shader:) Aber evtl isses der Monitor, der macht auch schon bei den CPU Tests von 3D Mark 03 und bei GTA3 und Vice City scheisse, muss ich langsam mal umtauschen

mfg,
Dennis.

P.S.: Ich habe noch nen weiteren Bug entdeckt. Die Parameter funktionieren nicht. Ich habe einen Parameter definiert (program.env[0]) aber im Program hat er keinen Wert.

_________________
Bush's on a highway to hell with the whole world blind, leading it straight into the flames.

Naja.Mal davon abgesehen, das dass ein riesiger programmiertechnischer Aufwand für mich wäre, wär das Feature doch ziemlich nutzlos.Schliesslich könnte man die geschriebenen Shader dann ja nicht in seinen eigenen Programmen nutzen.
Ausserdem ist die Emulation von Pixelshadern (VS gehen ja noch) viel zu rechenintensiv.Wer mal auf ner GF2 PixelShader mittels der NV30-Emulationstreiber und des entsprechenden Tools von nVidia genutzt hat, der weiss was ich meine....langsam ist da noch weit untertrieben.


Komisch...bei mir funzt das ohne Probleme!Ich hab auch heute noch ein (funktionierendes) Bumpmapping-FP geschrieben, das diesen Parameter ausliest, und das klappt einwandfrei :blink:

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

@RichEdit
Ist wirklisch sinnvoll ein Richedit-Element zu verwenden? Diese sind halt langsam, da jedesmal der Text aus dem Buffer von Windows ausgelesen werden muss. Ich glaube, besser ist da SynEdit, welches bei Sourceforge zu bekommen ist. Dieser unterstuetzt auch Syntaxhighlighting und man kann eigene neue erstellen. Ein weiterer Vorteil ist, das sich der Editor ähnlich dem in Delphi verhält.

Gruß
KidPaddle

_________________
http://www.seban.de

Nochmal zu dem DebugModus, den Dennis angesprochen hat.
Ich glaube das war so gemeint, daß man sich eben nur in jeder Zeile die Werte der Variablen ansehen kann. Da das Program ja keine Schliefen haben kann, hat ja jede Variable in einer Zeile immer nur einen möglichen Wert, während eines Programdurchlaufes. Das wäre eine große Hilfe, weil man oft vor dem Problem steht, das irgendwas nicht funktioniert, aber man weiß nicht genau was. In Delphi kann man einfach im Einzelschritt durch das Program gehen, und sieht was schief läuft. Bei Shadern muß man dann z.B. umständlich den Wert in die Farbe schreiben, um einen Anhaltspunkt zu haben. Wenn man z.B. einfach mit der Maus auf die Variablen zeigen könnte und der Wert würde angezeigt, dann wäre das ziemlich hilfreich für die Fehlersuche.

@KidPaddle :
Ja, das RichEdit ist wirklich sehr sehr langsam.Selbst wenn ich vor dem ersten Syntaxmarkieren das Zeichnen ins Fenster via LockWindowUpdate deaktiviere, dauert das Markieren des Quellcodes wirklich recht lange.
Deshalb danke für den Tipp mit SynEdit...werds mir gleich mal ansehen, in der Hoffnung das es besser als dieses RichEdit ist.

@LarsMiddendorf :
Wenn ich dich richtig verstehe, dann meinst du also quasi ein Feature bei dem man sich z.B. die result-Werte eines FPs oder VPs für jede Zeile anzeigen lassen, oder?
Das wäre natürlich recht praktisch, aber allerdings auch ein riesen Aufwand für mich.Immerhin müsste ich ja dann erstmal nen Quellcodeparser für FPs und VPs schreiben (was anhand der recht simplen Assemblersprache allerdings nicht all zu schwer sein dürfte), und auch noch alle 50 Befehle (33 FP/27 VP) per Software emulieren, was auch wieder sehr umständlich und langsam sein dürfte.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ja genau sowas meinte ich. Die Geschwindigkeit dürfte vielleicht nicht so eine Rolle spielen, wenn man sich auf jeweils einen Vertex oder ein Fragment beschränkt. Es bräuchte auch nichts gezeichnet werden.
Man könnte die Eingabewerte des Programs(Position,Farbe,...) irgendwo im Debugger/Editor einstellen und dann in Echtzeit verfolgen, wie sich die Werte während des Programablaufes ändern. Das sind zwar 50 Befehle, aber die führen ja alle nur eine kleine Funktionalität aus. Zum Zerlegen in Token dürfte die Klasse TParser aus der Unit classes ausreichen. Das könnte man dann auch gleich mit einer Art Syntaxüberprüfung während der Eingabe(mit Unterstreichen der Fehler wie im JBuilder) und Autovervollständig von Variablen, und Befehlen kombinieren. Da zwischen Groß und Kleinschreibung unterschieden wird, passieren einem häufig mal Fehler, oder man muß extra drauf achten. Da könnte man doch automatisch so was in den Editor einbauen, daß die Variablenname automatisch richtig geschrieben werden. Das sind zwar eine Menge Ideen, die sich glaube ich aber lohnen einzubauen, um das Bearbeiten von Shadern zu vereinfachen.

Zu der Problematik hätte ich vielleicht auch noch eine Idee.
Ein Ehemaliger Kollege von mir hatte auf halsbrecherische Art und Weise einen Perldebugger geschrieben. Er hatte dort auch eine Methode implementiert mit der man sich die Werte der einzelnen Variablen anzeigen lassen kann (was normal nur sehr schwer möglich ist da das Programm auch woanders ausgeführt wird). Und zwar hat er sich in den Quelltext eingeklingt.
Wäre es möglich, dass in einem VP eine Zeile hinzufügst die den gesuchten Wert in eine Variable schreibt? Also ein Vertexparameter oder irgend so etwas, was du außerhalb lesen kannst. Die kannst du dann außerhalb des Programms auslesen. Das müsste ja vom Prinzip her nur ein einfachen simples mov sein und sollte so gut wie keine Leistung und Platz verbrauchen.
Ich kenne mich allerdings nicht so gut mit vp's aus also weiß ich nicht ob so etwas möglich ist.

@LossyEx :
Nein, es gibt leider keine Möglichkeit irgendwelche Daten von einem VP aus nach Aussen auszugeben.Das ist ja dann auch die größte Problematik, und ausserdem werden die VPs und FPs ja noch durch den Compiler des Grafikkartentreibers gejagt und optimiert (siehe dazu z.B. die 3D-Mark03-Cheatdebatte), was solche Aktionen dann vollkommen umöglich machen würde.

@LarsMiddendorf :
Die 50 Befehle sind leider nicht so simpel (siehe ja auch die Spezifikationen), weshalb es immernoch ne riesige Menge Arbeit wäre so nen Debugger zu schreiben, zumal ich dann ja auch Register, Variablen, etc. emulieren müsste...ich glaube deshalb nicht das der Aufwand lohnen würde, denn schliesslich hat man bei VPs und FPs im Gegensatz zu z.B. ner Rechenoperation auf der CPU immernoch einen visuellen Output, anhand dessen man erahnen kann was schiefläuft.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Was ist mit dem Feedback buffer?
Kommt das nicht alles zu guter Letzt da rein?

Leider bringt mir der Feedback-Buffer in diesem spezifischen Fall nix.Die einzige bereits erwähnte Möglichkeit einen solchen Debugger zu schreiben, wäre die komplette Funktionalität von VPs und FPs per Software zu emulieren.Das ist mir allerdings erheblich zu viel Aufwand, weshalb in der Richtung wohl auch nichts kommen wird.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Um den Wert einer Variablen zu erhalten, könnte man das Program an der Stelle abscheiden und den Wert der Variablen als Farbe in eine Texture rendern. Da bräuchte man dann allerdings für ein Program mit n Befehlen und m Variablen, n*m verschiedene Variationen des Programs, die man intern erzeugen müßte. Sehr schnell wäre das bestimmt nicht,aber man könnte zumindest Schritt für Schritt sehen, was gemacht wird. Dieser Vorgang müßte ja auch nicht in Echtzeit durchgeführt werden, sondern könnte einmal beim Umschalten in den Debugmodus geschehen.

Die Idee eine Shader-IDE für fxPascal zu schreiben ist ausgezeichnet (und fxPascal ist es garantiert Wert - insbesondere als fxPascal in Zukunft evtl. auch HLSL als Zielsprache akzeptiert).
Ob GL_ARB_vertex_program und GL_ARB_fragment_program mit HLSL ausgedient haben werden, bin ich übrigens auch nicht sicher - ich denke wenn ein Grafiktreiber HLSL unterstützt, ist es auch kein Problem diese Extensions zu implementieren (und sei es nur aus Legacy-Gründen) - weswegen diese wahrscheinlich auch erhalten bleiben werden.

Leider hab' ich zur Zeit nur mein Notebook zur Verfügung, das nur Vertexprogramme unterstützt, die Hilfe zu den fxPascal Befehlen gefällt mir aber schon mal gut (wenn eine Grafikkarte übrigens Vertexprogramme unterstützt, stürzt das Programm bei Fragmentprogrammen zumindest nicht ab, womit du evtl. SETH mit einer entsprechenden Warnmeldung dennoch starten lassen könntest).

In Mcad hab' ich ja auch eine kleine Shader-IDE für fxPascal integriert- (die allerdings auch noch ziemlich ausbaufähig ist), wobei insbesondere für diejenigen, die fxPascal-Code in völlig eigenständige Projekte integrieren wollen, ein Tool wie SETH garantiert praktischer ist, da hier entsprechender Code nicht erst aus irgendeinem Sourcecodeprojekt herauskopiert werden muss.

Von einem direkten Export eines Szenarios nach Delphicode würde ich übrigens eher abraten: ursprünglich wollte ich mit Mcad auch "reinen" OpenGL Code generieren - du kommst dann aber garantiert nicht drum herum, wenigstens einen "kleinen" Szenegraphen zu schreiben - wenn nicht jede etwas komplexere Szene megabyteweise Code erzeugen soll - der wird dann mit jeder Erweiterung noch etwas komplexer (gibt ja allerhand Sachen, die verwaltet werden wollen) - und schließlich endest du mit einer Library wie Ogl, womit du, ähnlich wie Mcad, den Anwendern wieder deinen eigenen Basecode aufs Auge drückst (nicht dass ich dies prinzipiell schlecht finde - es ist aber, denke ich mal, nicht in deinem Sinn)

Ich bin übrigens gerne bereit an SETH mit zu arbeiten, zumal in meinen Augen fxPascal für OpenGL Programmierer eine echte Arbeitserleichterung darstellt.
Ich zähle jetzt einfach mal auf, was mir konkret an Funktionalität einfällt, vielleicht geben dann noch andere ihre Ideen dazu ab - dann kann man sich überlegen, wohin sich Seth konkret entwickeln sollte.
Also meiner Ansicht nach sollte SETH beeinhalten (alles kann allerdings noch nicht realisiert werden):

* eine große Sammlung an Shadereffekten für alle möglichen Anwendungen, die sofort ausgewählt und abgespeichert werden können.
* eine einfache Möglichkeit lokale und Umgebungsparameter von Programmen zu verwalten (am Besten über Variablennamen)
* eine einfache Möglichkeiten Matrizen für Vertexprogramme zu erstellen (am Besten interaktiv über die Angabe von Position, Rotation und Skalierung (evtl. mit Schiebereglern) - aber auch Komponentenweise)
* eine Möglichkeit Matrizen für Vertexprogramme mit der Transformationsmatrix eines sichtbaren Objektes zu verknüpfen
* eine Möglichkeit auf halbwegs intuitive Weise automatisch sinnvolle Vertexparameter, Texturkoordinaten für mehrere Textureinheiten, primäre und sekundäre Farbe, Normalvektoren sowie Nebelkoordinaten zu generieren (wobei mir hierzu auch nur ein Funktionsparser einfällt, der aber auch nicht wirklich intuitiv sein dürfte).
* Parametern können Variablentypen gegeben werden (Farbe, Vektor, "Skalar") - die Eingabemöglichkeiten sind vom Typ abhängig
* Wenn möglich (Lars hat ja sowas angedeutet) sollten Programme schrittweise getraced werden können
* Programme können als OpenGL Assembler code oder aber fxPascal Code gespeichert werden.
* Multipass-Szenen können als Pseudocode (von mir aus auch in Delphi - wenn es aber lauffähige Programme werden sollen, artet das Ganze fast garantiert aus, weil immer "noch mehr" hinzukommen soll - und reines OpenGL halt schon sehr "basic" ist) gespeichert werden, der einfach in eigene Programme integriert werden kann)
* eine Möglichkeit das Ganze auch ohne Hardwareunterstützung zu testen (vielleicht erbarmt sich Brian Paul ja mal und baut Fragmentprogrammunterstützung in MesaGL ein - die nächste Version sollte dann ohnehin HLSL unterstützen, da die OpenGL 1.5 kompatibel sein wird).
* das Ganze sollte halbwegs intuitiv gehalten werden, dass nicht nur OpenGL Gurus was davon haben.

Tja, das wär's erstmal von meiner Seite, bin mir noch nicht sicher, wo ich mich dabei ins Spiel bringen könnte bzw. sollte, biete dir aber auf jeden Fall meine moralische Unterstützung an , aber vielleicht ergibt sich ja was (zumindest hast du schon mal einen kritischen Betatester)

P.S.: Wenn du nichts dagegen hast, würde ich deine dynamische Hilfe zu den fxPascal Befehlen gerne in eine compiled HTML Datei umwandeln, und in den fxPascal Editor von Mcad einbauen (bis jetzt kann dort nur das Programmierhandbuch aufgerufen werden) - aber die Idee ist gut, vor allem weil sich damit auch recht einfach kontextsensitive Hilfe (F1 unter Schlüsselwort) realisieren lässt (evtl. sollte noch eine kurze Beschreibung der möglichen Datentypen dazu, das kann aber auch ich machen).

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Der "Quellcode"export soll auch bei weitem nicht so komplex sein wie der in MCAD.Es werden dann also keine Objektdaten von genutzten 3D-Modelle o.ä. exportiert,sondern nur der Quellcode für die einzelnen Renderpasses und z.B. das Laden ver VPs/FPs und deren Quellcode.Ziel ist es da nicht,die komplette Szene renderfertig nach Delphi zu exportieren,sondern dem Programmierer das Nutzen der Renderpasses in seinem Programm zu vereinfachen.


Das kommt defintiv.Ein paar Effekte sind ja schon drin,für andere werden aber noch Parameter und Einstellungen benötigt,die man in SETH momentan noch nicht vornehmen kann.Aber die Sammlung soll mal mindestens auf den Umfang der in Rendermonkey mitgelieferten Shader anwachsen.


Kannst du da bitte mal genauer drauf eingehen?So wie es momentan ist,klappts nämlich ganz gut.Man lädt seinen Shader zur GPU hoch und schon werden die Paramternamen in der Combobox an die im Programm verwendeten Namen angepasst.


Das darf in einem solchen Programm natürlich nicht fehlen,kommt also definitiv!


Dürfte auch machbar sein.Mal sehen wie man das am besten realisiert.


Da liegt wie du festgestellt hast wirklich ein Problem.Solange man nicht ein extra Dateiformat verwendet,wird das zuweisen von Nebelkoordinaten oder Vertexattributen wirklich ne komplexere Sache.Evtl. könnte man da ganz einfach einen kleinen Objekteditor integrieren,mit dem man z.B. ein 3DS-Objekt laden kann und diesem dann über Selektion Attribute auf einer Vertexbasis zuordnen kann.


Sollte auch noch rein,wird also kommen.


Darüber haben wir auch schon gesprochen.Das überlass ich dann aber mal Lars,der kennt sich ja mit fxPascal etwas besser aus


Ist für Leute die kein fxPascal in ihren Programmen verwenden wollen sicher ne nützliche Funktion.Wird dann wohl auch implementiert.


Siehe Punkt 1.Es soll also kein lauffähiger Quellcode exportiert werden,sondern nur der OpenGL-Code,den man dann in sein Programm übernehmen kann.


Das wäre sicher toll,allerdings überlass ich das dann mal lieber Brian Paul.Momentan animiert mich nichts dazu ne komplette Software-Implementation für GL zu schreiben


Seh ich auch so.RenderMonkey ist ja auch für z.B. die Grafiker eines Projektes gedacht.Genauso soll sich SETH auch ohne GL-Kenntnisse (fxPascal sollte man natürlich drauf haben) nutzen lassen.Später werden (bei Erfolg) auch noch Tutorials folgen,in denen auf die Benutzung des Programmes eingegangen wird.


Ich hab da nix dagegen,aber frag lieber mal Lars,denn ich hab nix weiter gemacht als die Befehle aus dem Programmierhandbuch in einzelne HTML-Dokumente zu verwandeln.


P.S. : Da ich defintiv vor hab SETH auf sourceforge.net als OpenSource laufen zu lassen,wollt ich mal anfragen ob jemand nen brauchbaren CVS-Client für Delphi kennt.Ich hab bisher nur BorCVS gefunden,das anscheinend ganz brauchbar ist.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich finde die Idee und die neue Umsetzung klasse. Wenn ich das dann irgendwann mal brauchen werde, dann werde ich sicherlich auf Seth zurück kommen. Aber eine Sache die mir persönlich nicht so ganz gefällt. Ich weiß auch nicht, obs schon angesprochen wurde (bin ein bisschen Faul alles genau zu lesen). Und zwar hätte ich die MDI Fenster wie die fxPascal Hilfe gerne schließbar. Bzw. von Anfang an geschlossen und per Menü aufrufbar. Meiner Meinung nach verwirrt das nur zu sehr wenn die immer da sin.

Zum Thema CVS kenne ich etwas, was sich zwar nicht in Delphi integriert. Dafür aber Problemlos in den Windows Explorer.
http://www.tortoisecvs.org/