CG/2015-Nachklausur, Aufgabe 10 (Bug) about kit-musterloesungen

[upsj]

Ich bin mir da nicht so ganz sicher. Mit fallen dazu zwei Argumente ein:

Einerseits würde niemand, der bei klarem Verstand ist, eine Lösung fordern, die für jedes Fragment die gleiche redundante Berechnung ausführt (inverse), andererseits ist die Matrix eine 3x3-Matrix, was eine lineare, keine affine Transformation bedeutet.

Sollte man vielleicht einen Hinweis dazu packen, dass die Aufgabe nicht eindeutig gestellt ist.

[crepererum]

Einerseits würde niemand, der bei klarem Verstand ist, eine Lösung fordern, die für jedes Fragment die gleiche redundante Berechnung ausführt (inverse),

Da bin ich voll und ganz mit dir. Implementierungstechnisch wäre das der totaler Unsinn. Hilft aber nix, denn vlt. wird die Transformation im Vertex-Shader dynamisch berechnet, womit du die Inverse dynamisch berechnen müsstest. Dazu kommt, dass scheinbar (habe nichts gegenteiliges gefunden) Matrizen auch interpoliert werden können, siehe https://www.opengl.org/wiki/Type_Qualifier_%28GLSL%29#Interpolation_qualifiers

andererseits ist die Matrix eine 3x3-Matrix, was eine lineare, keine affine Transformation bedeutet.

Foliensatz 3, Folie 57. Eine reine Skallierung, die unterschiedliche Werte für die beiden Achsen aufweißt, zerstört dir bereits die Normalen mit der falschen/simplen Implementierung völlig. Die 3x3 Matrix bedeutet hier lediglich, dass wir keine Translation vornehmen (und einige, eher theoretische Transformationen nicht durchführen können). Da eine Normale eine Richtung ist (w=0), reicht eine 3x3 Matrix allerdings für die "nicht-nur-theoretische" (s.u.) Transformationen auch aus.

Anmerkungen zu seltsamen Transformationen: Theoretisch könntest du eine Matrix bauen, die dir den w Wert auf dem x Wert addiert, womit eine "Richtung" dann doch wieder eine Position wird. Ich sehe aber keinen Grund, warum jemand so etwas machen sollte.

[vincent23]

Der Code-Kommentar auf dem Aufgabenblatt sagt eindeutig, dass die Matrix zur Transformationen von Positionen und nicht (wie hier verwendet) von Normalen dient.

Woraus liest du das? Aus dem "Koordinaten"? Der Kommentar sagt auch, dass die Normal Map "Normalen in Objektkoordinaten" enthält. Ich würde auch eher sagen, dass es nicht so ganz eindeutig ist.

[crepererum]

@vincent23 OK, guter Einwand. 👍

[StephanGocht]

Die Inverse von matO2W ist doch gerade matW2O, sie muss also nicht berechnet werden. Aber es ist wirklich nicht ganz klar ob das transformationsmatrixen für normalen oder vektoren sind.

[matthiasplappert]

In beiden Fällen sollte die Normale nach der Transformation noch normalisiert werden, oder?

[crepererum]

@matthiasplappert jup.