Ich bin gerade dabei eine einfache Engine zu schreiben. Dabei ist mir aufgefallen, dass sich das normale OpenGL - Licht bei mir sehr seltsam verhält, was die Farbüberläufe bei einzelnen Oberflächen betrifft. Das fällt z.B. bei den weißen Tischflächen auf, was man im angehängten Screenshot erkennen kann. Es kann ja normal nicht sein, dass eine Fläche vom Tisch am linken Rand dunkel ist und der nächste Tisch daneben wieder mit einer hellen Fläche beginnend gerendert wird - das fällt im Screenshot besonders bei den Tischen hinten in Richtung der Fenster auf.

Nun zu meiner Frage: Hab ich mich da irgendwie im Code vertan oder ist das bei dem normalen OpenGL - Licht immer so fehlerhaft?

Die Tische etc. sind Milkshape Models, d.h. mit Textur und Materialeigenschaften. Die ganzen Modelle werden geladen und anschließend in einer Displayliste gerendert, welche dann aufgerufen wird.

P.S.: Das OpenGL - Lightning ist echt lahm, ohne hab ich 112 FPS Würde eben aber doch gerne mal wissen, woran es liegt...

Moin.

Also mit den von dir berechneten Flächennormalen kannst du das OpenGL Licht beeinflussen. Und wenn ich ds richtig interpretiere, dann macht OpenGL das schon richtig. Dann liegt der Fehler in deiner Logik.

Bei den Tischen hat jeder Punkt eine eigene Flächennormale. Und die Normalen zeigen von dem Eigentlichen Objekt weg. So in etwa wie in dem Anhang die Linken normalen. Sehe ich das richtig?

Wenn dem so ist glaubt OpenGL, anhand der Normalen, dass deine Tische rund wären. Dadurch kommt dieses merkwürdige Lichtspiel in dem Bild zustande. Da die Normalen der Punkte die direkt aneinander liegen um 90 Grad unterschiedlich sein müssten sind sie auf der einen Seite so hell und auf der anderen so Dunkel.

Abschalten kannst dies indem du die Normal so ausrichtest wie in dem Anhang die Rechten. Für alle Punkte in die entsprechende Richtung nur gerade nach vorne oder hinten ausgerichtet. Außer an den Seitenflächen. Oder in dem du eine Normale pro Fläche nimmst. Wie bei den PCs.

Allerdings glaube ich mal sehr stark, dass du früher oder später um ein Shadow- und oder Lightmap nicht herum kommen wirst. Speziell, dann wenn es später komplexer wird. Da wäre es dann auch eine Überlegung wert, ob du bei den Level nicht auf ein bereits existierendes Mapformat zugreifst. Zum Beispeil das von Quake. Dafür gibt es ja auch reichlich brauchbare Editore. Aber da bin ich ein wenig der falsche Ansprechpartner für.

Irgendwas scheint da ohnehin faul zu sein - OpenGL Licht sollte auf T&L Karten kaum Leistungseinbußen nach sich ziehen (es sei denn, du aktivierst sehr viele Lichtquellen zur selben Zeit), zumal du bei den großen texturierten Flächen deiner Szene eigentlich nicht transformlimitiert sein solltest (es sei denn, Stühle/Tastaturen u.s.w. bestehen aus sehr viel mehr Polygonen, als es eigentlich sein müsste).
Überprüf doch mal (bezüglich Leistung) ob Backface Culling aktiviert ist.

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

Vielen Dank erstmal für die schnellen Antworten

Lossy Ex, wenn ich das richtig verstanden habe, gehst du davon aus, dass ich verschiedene normalen pro Tisch nehme. Das ist aber nicht der Fall, da es sich um ein Milkshape Modell handelt, welches einfach nur immer mit den selben normalen öfter gerendert wird. Vielleicht ist da der Fehler? Hatte bisher noch nicht soviel Zeit, mich mit Lichttheorie in OpenGL auseinander zu setzen.

@Mars: Ja, Backface Culling ist aktiviert, bringt aber lediglich 3 Frames mehr bei diesen hohen Polygonzahlen.

Ich hab nochmal ein Bild angehängt, dass das Problem nochmal verdeutlichen soll. Wenn man auf den Schatten bei den einzelnen Säulen achtet, fällt auf dass der teilweise von Polygon zu Polygon keine richtigen Überläufe hat (ähnlich wie bei den Tischen).

Wie oft du eine Model renderst sollte kein problem darstellen. Aber mal so Spaßeshalber. Was verwendest du denn für einen Milkshape loader? Evtl ist ja beim Speichern in Milkshape oder beim Laden mit dem Loader etwas nicht richtig.

Auf dem neuen Bild sieht man das sehr schön, dass bei sehr vielen Punkten anscheinend die Normalen (die mitgespeichert sind) wohl falsch geladen oder dargestellt werden. Ich kann mir dafür auch keinen anderen Reim drauf machen. Denn die Flächennormalen sind das einzigste was bei OpenGL Licht für so einen Effekt sorgen kann.

Für Level ist der Q3Radiant gut geeignet. Es gibt auch einen Map Konverter als Projekt hier auf dieser Seite. Damit kann man die typischer Level Geomtrie viel schneller als mit einem Modellierungsprogram erstellen und für kleine Objekte trotzdem noch MD3's einfügen.
Das OpenGL Licht kann man eigentlich generell vergessen und sollte lieber moderneres PerPixel Licht über Shader benutzen. Da gibt es aber viele Möglichkeiten und es hängt immer davon ab, welche älteren Karten man noch unterstützen möchte.

@ Lossy ex: Hm, als Modelloader nehme ich Lithanders ms3d-Loader von dieser Seite hier. Werde aber demnächst mal einen anderen testen, mal sehen ob der Fehler dann noch auftaucht.

@LarsMiddendorf: Ich weis, dass das normale OpenGL - Licht nichts taugt. Aber ich wollte sichergehen, dass ich nicht von vornerein Fehler einbaue und mich dann später wundere, wenn noch seltsamere Fehler auftauchen. Ich hab z.B. schon diverse Lightningmodelle mit glsl getestet, da hatte ich aber zum einen bei den Tischen ähnlich falsche Ausleuchtungen und zum anderen nur noch etwa 10 FPS....

Ich hab nochmal nen Bild von der Szene mit Pixel und Vertexshadern 2.0 drangehängt, das ist aber denke ich wohl noch nicht so repräsenativ, da wohl noch Fehler im Shadercode sind (manche Materialien werden nicht gerendert). Man sieht aber, dass hier immer noch Fehler bei der Ausleuchtung sind (Tische). Kann aber wie gesagt an den verwendeten Shadern liegen, da ich mir einfach die Normalenberechnung von einem Phong-Lightning Demo kopiert und dann eingebaut hab

Probier mal die Normale als Farbe im Shader auszugeben. Vielleicht hilft das um den Fehler bei den Normalen genauer zu erkennen.

Ok, hab ich gemacht. Da ich aber wie gesagt nicht weis, wie OpenGL die Normalen verwendet, kann ich den Screen nicht auswerten, bin also auf eure Hilfe angewiesen

Mir ist aufgefallen, dass selbst bei so einer simplen Anweisung die Frames auf 16 fallen. D.h. man kann quasi hohe Polygonzahlen mit Vertex und Pixelshadern vergessen, denk ich mal. Man braucht also alle möglichen Polygonreduzierenden Algorithmen und brauch VBOs praktisch gar nicht anzuwenden. Sehe ich das richtig?

Pixel Shader sind eigentlich von der Polygonzahl relativ unabhängig. Je länger ein Vertex Shader ist, desto langsamer dauert natürlich die Ausführung aber 200.000 Dreiecke sind für neuere Karte auch mit einem etwas kompleren Vertex Shader kein Problem. VBO sollte man auf jeden Fall verwenden, weil das extrem viel bringt. Allerdings gibt es bestimmte Vertex Formate die nicht von der HW unterstützt werden und daher sehr langsam sind. Vielleicht ist das ja bei dir sowas.
Die Normalen auf dem Bild sind insofern falsch, als daß sie eigentlich über eine Fläche hinweg konstant bleiben müßten. Vielleicht werden die Normalen auch über rechtwinklige Ecken gemittelt, was ja z.B. bei einem Würfel falsch ist. In Milkshape kann man extra einstellen welche Normalen zusammengehören.

Hm, wenn das so ist, muss wohl doch mehr als nur die Normalen faul in meiner Anwendug sein. Naja ich werd dann mal nen anderes Modelformat probieren, vielleicht fällt mir dabei der Fehler auf.

Trotzdem würde ich gerne wissen, ob die Normalen oben im Bild korrekt sind. Gibt es jemanden, der mir das sagen kann?

Nein, die Normalen sind definitiv falsch. Schau dir z.B. mal eine der Boxen an die nen Rechner darstellen soll. Bei einem Quader sollte jede Seite in einem Shader der die Normalen ausgibt die gleiche Farbe haben. Also die Seite die in Z-Richtung zeigt sollte total blau sein (Blau weil Z die dritte Normalenkomponenten ist und natürlich in Z-Richtung zeigt). Bei dir kann man aber klar sehen das die Vertices der Flächen die nur in eine Richtung zeigen (Seiten der Computer, Tische) unterschiedlich sind (->verschiedene Farben).
Milkshape macht also was falsch bei deinen Normalen. 3DS bietet für solche Fälle z.B. die Möglichkeit Normalen automatisch und v.a. korrekt zu generieren.

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

Ah, ok vielen Dank, dann werd ich wohl mal .3ds Models testen.

@Lars: Sorry, den 2. Teil deiner Antwort hatte ich glatt überlesen

Ok, ich hab mal wieder ne Frage

Vertexshadercode:

varying vec3 N;

void main(void)
{

N = normalize(gl_NormalMatrix * gl_Normal);

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}


Pixelshadercode:

varying vec3 N;

void main(void)
{
gl_FragColor=vec4(N.x,N.y,N.z,1);
}

erzeugt obiges Bild.

Änder ich aber nun den Vertexshadercode folgendermaßen ab:

void main(void)
{

N = normalize(gl_NormalMatrix * gl_Normal);

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}

Ensteht das angehängte Bild, wo die Normalen völlig korrekt sind.

Wie ist das zu erklären? Im Prinzip fällt doch nur die Texturabfrage weg...

Wenn du wirklich nur die Weitergabe der Texturkoordinaten weggelassen hast (sicher das du sonst nix gemacht hast?) ist das Verhalten sehr sonderbar. Aber alle bisherigen glSlang-Implementationen sind ja noch im Beta-Stadium, also evtl. ist das noch ein Bug. Sag mal bitte genauer welchen Treiber und welche Grafikkarte du benutzt.

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