huhu dgl freunde,

ich bin langsam am verzweifeln, oder zumindest erkenne ich den baum im wald nicht mehr. seit geraumer zeit versuche ich einen einfachen würfel in einem gl3+ context zu gesicht zu bekommen (so ansich ist das ja auch kein thema, und es funktioniert auch mit der 0815 position 0,0,0 und der fixen kamera die genau davor hockt auch - so wie in den tonnenweise vorhandenen tutorials/demos die man so findet... aber aus irgendeinem grund funktionierts bei mir nicht mit meinem "setup" ... entweder sind die shader falsch (was ich nicht glaube) oder der mathe matrix code :/

meine frage an euch - wäre es möglich das ihr das projekt das ich euch hier mit ranklemme einem review unterzieht?
vielleicht könnt ihr mir ja sagen was ich falsch mache/machte "du trottel die matrix so und so is falsch und muss so aussehen"

danke schon mal im vorraus ._.

Ich bin jetzt gerade nicht motiviert mir den Code anzusehen, aber hast was mir so einfällt ist, dass man bei OpenGL nicht zeilenweise sondern spaltenweise durch die Matrizen geht und dass man die Projektion vergessen könnte. Ich mache es momentan so, dass ich eine fertige Matrix mit Drehung, Verschiebung und Projektion (2D oder 3D) in den Vertex-Shader reiche und die Punkte damit multipliziere. Sicher ist es aber auch gut, zumindest die Projektion separat zu übergeben. Wenn du deine Matrizen in-place multiplizierst also A := A*B, dann achte auch darauf keine Werte in A zu überschreiben, die ein paar Zeilen weiter noch in eine Berechnung einfließen. Das ist mir z.B. passiert.
Multiplizierst du die Matrizen in der richtigen Reihenfolge? Veränderst du die Richtung der Koordinaten-Achsen, zum Beispiel, weil du X und Y auf den 'Boden' legst und Z nach oben zeigen soll?

Ansonsten sind die Matrizen in OpenGL 3 letztlich die selben wie in OpenGL 1, also kannst du zum Debuggen den Code mit glRotate und Co schreiben und die MODELVIEW- und PROJECTION-Matrix mit glGet auslesen.

du mutmaßt also nur so vor dich her ohne dir die wurst mal angeschaut zu haben?
ich dachte ich hätte bisher soweit alles beachtet...

._.

Ja, und das kannst du eben prüfen, in dem du die Daten deiner OpenGL 3 Matrix mit der OpenGL 1 Matrix vergleichst. Wenn sie übereinstimmen liegt der Fehler nicht in der Matrixberechnung, von der du selbst annimmst, das sie korrekt ist. Oder ist es jetzt gerade aufwändig einen OpenGL 1 Pfad zu testen? Dann musst du vielleicht bis morgen warten, bis jemand sich die Zeit nimmt

Im shader:
Sieht so aus, als ob da was mit der Reihenfolge nicht stimmt. Soweit ich weiß ists normalerweise Model * View * Projection. Wobei ich mir da nicht sicher bin. Aber es ist mit Sicherheit nicht sinnvoll, die Matrizen einzeln an den Shader zu übergeben, wenn die dann eh nur zusammenmultipliziert werden. Sind mehr Berechnungen und mehr Daten.

Also, den restlichen Code hab ich mir nicht alles angeschaut, aber ich hab zumindest nix gefunden. Wobei eine Beschreibung des Problems auch nicht schlecht wäre. Also, was soll aufs Bild, und was ist da. Kann man nämlich vielleicht darauf schließen, wo der Fehler (ungefähr) liegt. (ich weiß schon, dass es nicht unbedingt immer leicht ist, einen Fehler zu beschreiben. Besonders wenns was mit Matrizen zu tun hat)

ähm, ja. Mein Beitrag scheint sich in der Zwischenzeit erübrigt zu haben... Naja, egal.

bin grad dabei das mitnem 2er context zu testen ob die matrizen stimmen oder nicht.
prinzipiell geb ich euch auch recht das es evtl sinnvoller is gleich eine konvolute matrix an den shader zu reichen...... komischweise sehe ich grad das im vertex shader 2 klammern fehlen, da matrizen nicht distributiv sind ..... projection * (view * model) * pos ......

was zu sehen sein soll schrub ich bereits, ein würfel, den ich in TModel.LoadFromFile dummymäßig zusammenfummle.

danke erstmal euch beiden.

Ich habe mir dein Programm mal angeschaut. Tja, da fliegen einem die OpenGL Fehler nur so um die Ohren.

1. Das Linken des Shaders schlägt fehl weil die Namen des Varyings der Textur-Koordinaten nicht übereinstimmen.
Wenn du im Vertexshader

schreibst, musst du im Fragmentshader auch den selben Namen verwenden.

2. In der Funktion TModel.Draw verwendest du beim Setzten einer Uniformmatrix, den Namen "WorldMatrix". Im Shader Sourcecode steht aber "ModelMatrix".

Möglich das noch mehr Fehler vorhanden sind (habe keine Zeit mehr ).
Ich würde das Programm noch einmal auseinander nehmen, Stück für Stück wieder zusammen setzt und zwischendurch immer prüfen ob es noch funktioniert.
Hoffe ich konnte dir helfen.

MFG
humflo

Also eigentlich sind sie das schon. Kommutativ sind sie nicht, aber das hat nix mit distributiv zu tun

Ich bin Seher ! Nein, nicht wirklich, aber es ist auf alle Fälle sinnvoll auf Fehler zu prüfen. Gerade die Shader-Compiler und -Linker geben gute Textnachrichten bei Fehlern raus. Manche sind anfangs kryptisch, aber das ist ja bei jedem Compiler so
Die restlichen GL-Funktionen geben nur allgemeine Fehlercodes raus. In welchen Situationen sie das tun steht aber in der API-Dokumentation (z.B. hier im DelphiGL in deutsch) und dann wird meist aus dem Zusammenhang klar was nicht stimmt.
Wenn ich mich richtig erinnere muss man aber beachten, dass der Fehlercode nicht zwingend von der letzten Funktion gesetzt worden sein muss. Es empfiehlt sich also mit der Fehlersuche möglichst weit 'vorne' im Programm zu beginnen.

glFunktion1() - löst Fehler aus
glFunktion2() - läuft sauber durch
glFunktion3() - läuft sauber durch
Fehlercode auslesen -> Ein Fehler ist aufgetreten

Hier könnte man glauben Funktion3 hätte den Fehler ausgelöst. (Stimmt doch so oder?)

Korrekt, glGetError gibt nur den zuletzt aufgetretenen Fehler zurück (nicht den der letzten Funktion).
Was man auch beachten sollte, bei einem Fehler kann es sich um einen Folgefehler handeln weil eine vorhergehende Funktion fehlgeschlagen ist.

was hab ich denn da für einen scheiß zusammengezippt ^^

merkwürdigerweise erhalte ich keinen einzigen fehler beim compilen, linken oder validaten der shader....

jo, da ich nicht jeden tag son mathegeraffel mache..... ich verwechsle ich das öfter ich meinte natürlich das sie nicht kommutativ sind.....

Ich hatte am Anfang auch einige Probleme beim erstellen des Matrix Codes für Normal, Projection und so weiter, als ich auf OGL3 umgestiegen bin.
Du kannst ja recht schnell deine Matrizen mit OpenGL2 prüfen, da du ja dort beide Varianten Problemlos nutzen kannst.

Man muss für die Berechnung eines Punktes folgende Reihenfolge einhalten.
Vec3f gl_Position=ProjectionMatrix*ModelView*VecPosition;

Auch wenn das Teil ModelViewProjectionMatrix genannt wird tut man diese genau anders rum multiplizieren.
http://wiki.delphigl.com/index.php/Tutorial_OpenGL3_Lineare_Algebra#Projectionview <- erster Abschnitt

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

gl_Position = ProjectionMatrix * (ModelMatrix * ViewMatrix) * vertexpos; wenn man die matrizen einzeln rüberschiebt sollte auch das gleiche sein wie Projection * ModelView * vertexpos, nech?

weil du eure tutorials grad ansprichst...... das viel mir neulich hier beim durchstöbern auf.... alles is irgendwie wild aus c/c++ code zusammengeschoben, ich dachte das wäre hier nen delphi forum (und ja ich weiß das bisschen c kann man auch einfach nach delphi umbasteln..... finds nur komisch/schade )

und danke

Das mit dem C++ Code liegt daran, dass ich C++ Programmierer bin und wenn jemand Delphi Code haben will, dann müsste sich jemand erbarmen und mal den Code nach Object Pascal portieren.

Zur sache mit DelphiGL, das Thema Name und Inhalt sind mitlerweile 2 verschiedene dinge.
Wir haben mitlerweile eine Mischung aus Delphi, FreePascal, Java, C, C++, C#, Scala und bestimmt auch noch 1-2 weiteren Sprachen.
Also der Name entspricht nicht mehr dem wirklichem Inhalt aber wir wollten ihn auch nicht ändern, da DelphiGL mitlerweile eine Marke ist und wir diese nicht zerstören wollen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004