Hi,

also ich hab mich jetzt nochmal an die VertexShader gesetzt... so 100%ig ist mir zwar immernochnicht klar was ich damit machen können soll, was nich auch ohne geht, aber ok.. *g*

Aufjedenfall... SoS, du schreibst in dem Tutorial dass das eine Script da das kürzeste was möglich ist sei... aber, ist nicht das kürzeste so?? -->



Den der umweg über die Temp-Variable is doch irgendwie überflüssig.. oder sehe ich das falsch???

Und, die sache mit dem Fehlerfinden... klappt zwar, allerdings bekomme ich da immer nur "invalid parameter"... steht nix von ner line oder so da... hab ich da jetzt was verkehrt gemacht, oder liegt das einfach an meiner GraKa?

Au'revoir,
Aya~

Ja, eigentlich muss man die Temp-Variablen nicht nutzen, da das ARB dies aber so vorschlägt hab ich mich halt daran gehalten, zumal es der Überischtlichkeit zugute kommt.


Ja, die Fehlerausgabe bei einem Vertex-/Fragmentprogramm ist Sache des Grafikkartentreibers.Anscheinend habens nVidia mal wieder nicht hinbekommen hier brauchbare Infos zu geben.Meine ATI-Treiber liefern auf jeden Fall (wie im Tut ja zu sehen) neben dem Fehler auch noch die Zeile in der dieser aufgetreten ist mit.

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

Mich würde mal interessieren, ob das mit der Tempvariable nicht auch ein wenig langsamer sein würde.
Es ist ja auch so, wenn man sauber und strukturiert programmiert (oop), dann kann dadurch ein overhead entsteht. Mich würde mal interessieren wie sich so etwas bei der Grafikkarte verhält. Wenn man dort nämlich ein wenig zu viel macht, dann bremmst man damit ja so ziemlich alles aus.

Also wenn ich persönlich mich zwischen Übersichtlichkeit und Geschwindigkeit entscheiden müsste (wenn der Geschwindigkeitsgewinn nur marginal wäre), dann würd ich in jeder Situation Übersichtlichkeit wählen.Lieber ein paar FPS weniger, aber dafür Programmstrukturen die sich leicht lesen und verändern lassen.
Bei nem Vertex-/Fragmentprogramm bin ich mir allerdings fast schon sicher, das der Treiber (wenn er denn gut programmiert) ist, das VP/FP beim Hochladen nochmal durchläuft und optimiert, so wie das mit Displaylisten auch geschieht.Ich bin mir deshalb auch fast sicher, das die übersichtlichere Variante nicht langsamer ist.

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

Wo die nützlich sind durfte ich vor kurzem ausprobieren
Wenn Du deine Objekte als Vertex-Array oder Vertexbuffer hast, kannst Du diese dann mit einem Vertex-Program ändern, anstatt die Daten im Vertex-Array jeden Frame zu aktualisieren, wodurch ja der Vorteil des Vertex-Arrays nahezu aufgehoben wäre.
Das nur mal so als ein Anwendungsgebiet.

_________________
Thunderman
Bei schwierigen Problemen entscheiden wir uns einfach für die richtige Lösung. Klar?

@SOS: Keine Frage ich ziehe Übersichtlichkeit der Geschwindigkeit auch vor. Sofern der Geschwindigkeitseinbruch vertretbar ist. Und eine Variablenzuweisung ist im Vergleich zu einer Berechnung eh kein Aufwand. Aber Interessieren würde es mich dennoch. Bin ja nicht neugierig oder so.

@Aya: Mit VP's kannst du alle Dinge (z.B.: Oberflächen) simulieren die per Formel erechenbar sind. Bestes Beispiel dafür ist Wasser (Wellen). Du brauchst dann lediglich eine Fläche machen die in einzelne Stückchen unterteil ist (Heightmap mit höhe 0) und berechnest dann darauf deine Wellen. Und siehe da schon hast du 100% Hardwarebeschleunigtes Wasser.
Charakteranimationen sind damit nur bedingt realisierbar, da die meistens nicht berechenbar sind.

Ich habe das mal ausprobiert und der Treiber scheint bei beiden ARB_** Programmen das Programm so zu optimieren, daß unnötige Zuweisungen wegfallen. Jedenfalls konnte man das anhand der Geschwindigkeit sehen, wenn man die entscheidenden Befehle, die das Ergebnis einer langen Berehnung verwenden auskommentiert, dann wurde das Programm so schnell als wenn diese Berechnung überhaupt nicht ausgeführt worden wäre. In so einem PDF von ATI habe ich auch mal gelesen, daß der Treiber die Befehle auch umordnet, damit die Hardware besser ausgelastet ist. Diese Programme haben zwar die Form von Assembler, aber sie sind nicht mit dem normalen Assembler zu vergleichen, bei dem jeder Befehl genau so umgesetzt wird. Deshalb glaube ich auch nicht, daß es durch die tmp Variable langsamer wird.


Die Fehlerposition wird in einer zusätzlichen Variable zurückgegeben.
Mit glGetIntegerv(GL_PROGRAM_ERROR_POSITION_ARB,@i) kann man sich auch auf NVida Karten die Fehlerpositino anzeigen lassen.

Ich glaube das Programm wäre so richtiger:

Oh.. danke

Das dumme an GL_PROGRAM_ERROR_POSITION_ARB ist allerdings die Tatsache das die zurückgegebene Fehlerposition nicht die Zeile in der er auftrit zurückliefert, sondern den Byteoffset an dem der Fehler auftrat, sprich das Zeichen im Programmstring an dem der Fehler liegt.So muss man recht umständlich noch ausrechnen in welcher Zeile man suchen muss...

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

Nu ja, ganz so umständlich ist's ja nu auchnet ...



Au'revoir,
Aya~

Hi nochmal,

eine kleine frage hätte ich noch...

mit glGenProgramARB reservier ich mir speicher für das Programm.. aber wie geb ich des wieder frei?? Also wie lösch ich das generierte wieder???

Au'revoir,
Aya~

Konsequenterweise mit glDeleteProgramsARB.Steht übrigens in den Spezifikationen zu GL_ARB_VERTEX_PROGRAM.

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

Hi,

muß man irgendwas beachten wenn man glProgramStringARB benutzen möchte???

Ich bastle grad an nem kleinen Editor für die VertexShader rum, und bin total verwirrt..
Bei glProgramStringARB gibt es immer ne AccessViolation... hab die Extension aber geladen und InitOpenGL von OpenGL12 gemacht...

bei meinem Spiel hab ich die Shader ja schon implementiert, da geht es... aber ich hab KA was ich da jetzt vergessen haben könnte...

Ich benutz z.B. hier in dem Editor kein OpenGL Fenster, also hab kein OpenGLContext.. aber auch wenn ich einen erstelle geht es net
Und ich hab KA was ich hier andersgemacht haben soll als bei meinem EngineEditor..

Au'revoir,
Aya~

Stell sicher, das die mittels glGenProgramsARB erstellte ID für dein Programm auch gültig ist.Ansonsten dürfte es keine Probleme beim Übergeben des ProgramStrings an die Graka geben.Falls doch, dann schau dir die Spezfikation an, denn dort steht alles wichtige drin.

P.S. : Ohne Quellcode wird das Helfen schwer...

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

Hi,

war nen dummer fehler *g* Ich hab total vergessen gehabt erstmal ne VP mit genPrograms zu erstellen

Ich hab mir für meinen VP Editor in meinem EngineEditor gestern eine art CodeInsight und SyntaxHighlighting gebastelt.. daraus hab ich vorhin nochmal nen kleinen StandAlone Editor gemacht

Runterladen könnt ihr euch den hier:
http://www.koshigaya.de/DelphiGL/VertexShaderSFX.exe

Das CodeInsight funktioniert genauso wie in Delphi.. mit STRG+Leertaste wird er aufgerufen.

Mit F9 wird der Code auf fehler überprüft.

Sollte interresse bestehen, kann ich den Editor gern noch ein wenig weiterentwickeln (Würde ich so nicht machen, da ich das ja wie gesagt direkt in meiner Engine eingebaut habe).

Au'revoir,
Aya~