Hallo DelphiGler!

Also ich hab folgendes seltsames Problem:
Ich möchte zwei Lichter platzieren.
Wenn ich nur eines platziere (GL_LIGHT0), dann ist eigentlich alles so, wie es sein soll.
Das Licht kriegt den richtigen attenuation factor und die Objekte werden mit konstant der selben Helligkeit angezeigt, egal wo ich mich als Betrachter befinde.
Wenn ich aber statt GL_LIGHT0 mit GL_LIGHT0+1 arbeite, dann ist alles sehr seltsam.
Ich nehme exakt die gleichen Prozeduren und ersetze einfach nur den Namen.
Ich bekomme dann den Effekt, dass alle Flächen wesentlich dunkler sind, und sie alle darauf reagieren, wenn ich auf sie draufgucke.
Undzwar reagieren die Oberflächen sprunghaft. Das bedeutet, dass, wenn ich mich langsam zu einer fläche hindrehe, die Fläche ab einem bestimmten Winkel auf einmal "angeschaltet" wird, also sprunghaft heller wird.
Und das obwohl ich am source nicht mehr als den Namen der Lichtquelle geändert habe.
Was genau mache ich hier falsch?

Gruß
Jan

Grundlegend muss man erstmal sagen, dass Licht0 und Licht0+x sich wesentlich unterscheiden. Licht0 hat nämlich standardwerte die sinnvoll sind. Die anderen lichter sind nicht initialisiert. Das heißt, sie leuchten wahrscheinlich mit schwarzem Licht

Wenn du ihnen bereits eigenschaften zugewiesen hast, dann zeig mal einen Screenshot. Wichtig dabei ist das du die Lichtpositionen irgendwie Kenntlich machst.

Ist dieses Springen nur bei 2 Lichtern?
Wenn du mit Licht0+x durch die Lichter itterierst musst du aufpassen, dass dein x vom Typ byte ist.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich glaube das Problem hat sich gelöst.
Es stand noch ein glEnable(GL_LIGHT0) an anderer Stelle, welches dann Probleme ergab, weil diese Lichtquelle nirgends definiert war.

Jetzt aber zu einem eher theoretischen Problem:
Wenn ich meine Lampe an eine lange Wand stelle, dann wird diese Wand nicht beleuchtet, bei kurzen Wänden allerdings schon.
Ich weiß jetzt nicht genau, wie OpenGL die Beleuchtung für jeden Wandpixel berechnet, besonders wenn ich mich attenuation arbeiten, aber ich nehme mal an, es hat was damit zu tun, dass der Normalvektor der großen Fläche, die nur aus 2 triangles besteht sehr weit entfernt ist, und daher einen hohen Winkel zur Lichtquelle hat.
Wie kriege ich es jetzt hin, dass die wand trotzdem an der richtigen Stelle hell ist ohne die Wand in jede Menge ungewollte polygone aufzuteilen?
Denn, dass mit dem abklingenden Licht auf große Polygone fließend schattiert werden, sehe ich ja an den Wänden, die nicht ganz so lang sind.

Gruß
Jan

Der Normalenvektor spielt da Entfernungstechnisch keine Rolle.

OGL berechnet die Lichtintensität für jeden Vertex, und interpoliert die dann über die Fläche. Wenn deine Lichtquelle genau im Zentrum steht, dann ist die Intensität für die Vertices sicherlich dank Attenuation 0. Und wenn man zwischen 0 und 0 interpoliert wirds finster.

Wenn du sowas machen willst ohne mehr Polygone zu benutzen, dann guck dir mal Lightmaps an. Du schaltest einfach das Licht für die Wand aus, und mapst dann per Multitexturing Licht und Schatten auf die Wand. Siehe dazu da Tutorial_MultiTexturing von Sascha.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

versuchs mal mit glEnable(GL_NORMALIZE);
Ich hatte mal ein ähnliches Problem und da hats geholfen.

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

Ja multitexturing ist natürlich schon eine Möglichkeit, aber im Grunde bringt das doch keinerlei Vorteil.
Ich muss dann ja eigentlich auch die Wand in kleinere Polygone unterteilen, da ich sonst eine riesige Textur brauche, nur um die Beleuchtung der Wand realistisch darzustellen.
Ich hatte mir das mehr so vorgestellt, dass man vielleicht die Berechnung der Helligkeit an jedem Pixel vielleicht nicht über die interpolation zwischen den Eckpunkten macht, sondern mehr so, dass man einen Beleutungshöhepunkt emittelt (niedrigste Entfernung zwischen Ebene und Punkt) und diesen Punkt mit in die Interpolationsgleichung einbindet. Damit wäre das problem dann behoben. Gibt es dafür in OpenGL nicht vielleicht schon eine Implementation?
Gruß
Jan

@sidorion:
Normalization kostet in diesem Fall nur Rechenpower wie wahnsinnig.
Die Normalen werden ja schon von 3DSM in den models gespeichert und auch (so weit ich weiß) vom Loader übernommen.
Da diese Normalen schon auf Einheitslänge sein dürften, bringt Normalisieren natürlich wenig.
Hab's trotzdem mal ausprobiert, und es hat sich auch nix geändert.

Gruß
Jan

Ja sowas gibts. Nennt sich Shader und dürfte wesentlich aufwendiger sein.

Das Problem ist folgendes: Um mit einfacher GL-Beleuchtung eine Wand schön(!) zu Beleuchten, ist nur Möglich wenn du die Wand enorm(!) häufig unterteilst. Richtig oft! Lightmaps sind da schon ein Vorteil. Da must du nur den Bereich der Wand extra Modellieren, der auch beleuchtet ist. Bei den restlichen Teilen kannst du Licht wieder anschalten und per Ambientlicht und einer großen Textur den Rest bauen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Das mit dem Licht ist irgendwie komplizierter als man zunächst denkt.
Ich hab mal nen Screenshot hochgeladen.
Warum kriege ich diese Helligkeitskanten zwischen zwei Dreicken, die genau nebeneinander liegen und den selben winkel haben?
Gruß
Jan

Hab mir den Thread net durchgelesen, aber der Screenshot sieht aus, als wäre die Normale dieses Dreiecks falsch berechnet worden bzw. das Dreieck einfach "falsch herum".

Jo...könnte sein. Wenn du Backface-Culling aus hast, dann musst du mal die 2-Seitige Beleuchtungsberechnung einschalten. Mal sehn, ob das was bringt.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Also backface culling ist an.
Daher denke ich nicht, dass das Dreieck falsch rum definiert ist.
Wie würde ich denn die Normale wieder richtig biegen, wenn sie falsch von 3sdm berechnet ist?
mit normalize geht's nicht.
Gruß
Jan

Kannst du mal eine Linie von der Lichtquelle zum Dreieck einzeichnen? Eventuell liegts am Winkel und es sind Rundungsfehler verantwortlich.
Wenn tatsächlich 3DSMax geschlampt hat, dann versuch mal mit den Smoothing Groups rumzuspielen, und es erneut zu speichern.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich vermute du nutzt das 3DS-Format. Soweit ich weiß speichert das 3DS-Format in keinem der Standardchunks Normalen. Vermutlich hast du gar keine Normalen gesetzt.
Du kannst ja einfach mal deine Normalen mittels GL_LINES ausgeben um sicher zu gehen. Wenn der Fehler dort nicht liegt füge einfach mal eine Kugel z.B. mit Hilfe von Quadrics ein und schau ob diese korrekt beleuchtet wird.
Wenn ich den Screenshot richtig interpretiere so hast du größeres vor und in diesem Fall empfehle ich dir Lightmaps. Den Vertexcount musst du nicht verändern, wenn du sie selbst berechnest und du hast gleich statische Schatten mit dabei. Damit kannst du dann bestimmte Räume oder Gebiete gesondert beleuchten. Außerdem stößt du nicht auf die Einschränkung von maximal 8 Lichtern.

_________________
Nichts auf der Welt ist so gerecht verteilt wie der Verstand. Denn jederman ist überzeugt, dass er genug davon habe.
Rene Descartes, frz. Mathematiker u. Philosoph, 1596-1650

@Flash: Das mit den smoothing groups hab ich schon probiert, aber das bringt alles nix.
Ich versteh nicht ganz, warum ich die Linie malen soll. Der Winkel ist doch bei beiden Flächen fast identisch.

@magellan: Wie kann man denn die Normalen per Linie darstellen lassen?



Ich hab leider keine Ahnung wovon du redest. Was selber berechnen? Das mit Lightmaps, da habe ich bisher versucht mich drum zu drücken, da ich nicht weiß, wie ich die Texturierung der Objekte noch manuell machen soll.
Bislang wird vom 3ds model loader einfach die vorgegebene Texturierung übernommen und das ganze dann in Displaylisten gespeichert. Wie ich da jetzt selber noch dran rumfummel ist mir ein rätsel.
Oder stellt man das dann auch alles in 3DSM ein?
Weiterhin weiß ich auch nicht, wie ich auf die OpenGL Lichter verzichten soll, schließlich habe ich ja auch bewegliche Objekte, die dann ja auch dynamisch angeleuchtet werden müssen, Lichter brauche ich also trotzdem.

Gruß
Jan