Hey,

als ich grade einen Shader für diffuse Lichter benötige, hab ich mich vom Tutorial glsl2 inspirieren lassen, indem es über Punktprodukt zwischen Oberflächennormale und Vektor zum Licht realisiert ist.
Allerdings gab es da schon immer etwas, was mich sehr verwirrte, denn selbst, wenn das Licht hinter dem Objekt ist, wird das Dreieck ausgeleuchtet; zumal die Mathematik ja sagt, dass nachgeprüftermaßen 1*1*cos(a) für 180° > a > 90° nicht größer als 0 sein kann... und eben fiel mir der simple Fehler auf:

Wenn im Tutorial der Vektor vom Vertex zum Licht berechnet wird:

Ist Position bereits so definiert:


Und in der Tat, wenn ich auf die Lichtquellenposition auch die ModelViewMatrix anwende, habe ich nur noch eine korrekte Beleuchtung, dh. wenn der Winkel <= 90° ist.
Von daher: War das beabsichtigt, und wenn ja warum, oder sollte ich tatsächlich als Erster diesen Fehler nach Jahren entdeckt haben?

MfG

Ja das ist genau der Fehler den ich auch ständig habe und ich weiß nicht, woran es liegt
Mein Cel-Shader macht es scheinbar richtig.

Ich bin mir eigentlich ziemlich sicher, dass der Code hier stimmen muss: http://www.ozone3d.net/tutorials/glsl_l ... _phong.php
Der entspricht nämlich ziemlich genau dem OpenGL Licht.

mfg

Die modelview matrix definiert doch das lokale Koordinatensystem deines Objekts. Die Position der Lichtquelle sollte dagegen in globalen Koordinaten erfolgen.

_________________

Hast du die Lichtquelle vor oder nach der Kamerabewegung positioniert?

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Ein ziemlich gute Frage. Ich hab das damals nur mal kurz innen ShaderDesigner eingetippt.

Mein letzter Versuch, das offizielle FP-OpenGL-Licht gemäß den Specs (http://www.opengl.org/registry/doc/glsp ... 061201.pdf, S. 60ff, PDF-S. 74ff) zu coden, endete in einem ineffizienten, total unterschiedlichen, aber eigentlich ganz ansehnlichen Ergebnis.

Interessanterweise scheint das FP-OpenGL-Licht aber auch nicht halt davor zu machen, auch entgegengesetzte Normalen auszuleuchten. Laut den Specs dürfte das aber doch gar nicht sein...

Werde mal schauen, ob sich noch was rausfinden lässt.

MfG

Doch das FP Licht beleuchtet entgegengesetzte Normalen nicht.
Aber man muss auch aufpassen bzgl Backfaceculling.

Die Lichtposition wird beim aufruf von glLight() mit der aktuellen Modelviewmatrix multipliziert. Andersrum kann es schon komische Effekte hervorrufen.
Könnte man auch im Shader machen. Aber das halte ich für überflüssig. Der Shader kann in der Zeit besseres tun.

Ich habe mittlerweile einen leicht erweiterten FP-Shader gebastelt, der die verschiedenen Lichttypen, sowie Texturen (ColorMap, NormalMap, GlowMap, AmbientOcclusionMap) miteinander kombiniert. Wenn ich ihn abschalte sieht es fast identisch aus, nur dass Normalmapping und so Zeug fehlt.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Bwaaah, da nehm ich mal hurtig alles zurück, was ich hier seltsames verzapft habe und entschuldige mich dafür.


Genau das hat mich schon stutzig gemacht. In der Tat liefert bloß dieser dumme ShaderDesigner seine Lichter untransformiert in globalen Koordinaten.
Wenn man nicht alles selbst macht...
gut, apropos selbstmachen, dafür hab ich jetzt nen unoptimierten PPL-Shader xD...

und ansonsten... Danke für die Aufklärung

MfG