nein, wenn ich das licht vor dem aufruf der kamera translation setze habe ich das licht immer auf kameraposition, was ich aber nicht möchte, denn das licht soll statisch in der szene stehen, was es eigentlich auch tut, aber eben dieser effekt stört mich, hier mal die komplette unit bzgl 3d aus meinem neuen projekt:

(das backface culling wurde aus versehen zum frontface culling, hatte net gemerkt, dass ich zu testzwecken auf front gestellt habe ^^)


das ist der komplette unzensierte code.

mfg

Bitte mal durchlesen:
http://wiki.delphigl.com/index.php/Tuto ... sen_finden

Ist nicht böse gemeint( ), aber im günstigsten fall sollte eine Klasse nicht mehr als 2 DIN-A4 Seiten füllen( Dies kann man zwar nicht immer erreichen, aber... ).

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.

darum geht es hier aber nicht, ich hätte natürlich alles auslagern können, dann hätte ich hier aber 3 units anhängen müssen und keiner würde das blicken.

Damit jetzt mal wirklich klar wird wo das Licht hinfällt, mach doch mal das Bodengitter feiner. Am besten so, dass die Polygone ~10 Pixel auf dem Bildschirm groß sind. Dein Screenshot zeigt zwar mehrere Lichtpunkte, das heißt aber noch nicht, das bei genügend vielen Zwischenvertices nicht doch ein Zusammenhang entsteht.
Also Screenshot-Update biddö!
Wenn sich jetzt rausstellt, dass alles in Ordnung ist lach ich mich schepp ^^.

Also bei mir kenne ich den Fehler schon lange. Er liegt im Lichtmodell für spiegelndes Licht. Dort wird mit dem Halfway Vektor gearbeitet, was allenfalls eine Näherung ist, aber nur bei bestimmten Objekten (z.b. Kugeln) realistisch wirkt. Wenn man den spiegelnden Anteil realistisch darstellen will, muss man auf die Lichtreflektion zurückgreifen:
Einfallswinkel = Ausfallswinkel
Ich habe die Lösung für den spiegelnden Anteil nicht im Kopf, ich schaue aber nochmal nach und poste sie. Sie müsste aber in die Richtung Reflexionswinkel dotproduct Normale laufen, evtl. zusätzlich mit nem Glanzpunktfaktor.
Definitiv kann ich aber sagen, dass auch mit korrekter Berechnung das ganze nicht realistisch ist, da bei OpenGL auch der Specular-Anteil eine Abschwächung ist.
Richtig wäre, zuerst ambient und diffuse zu berechnen, dann mit additiven Blending den spiegelnden Anteil hinzufügen.

_________________
"Wer nicht arbeitet, kann auch nichts falsch machen"

ich hab aber keine spiegelungen Oo

(der gepostete source ist von dem projekt hier http://www.exec-dev.de/editor2.jpg), die bilder aus einem anderen

2 neue screenshots: 128*128 polygone auf dem boden:

Du irrst dich, du benutzt den specularen Anteil des Lichtes. Das ist ja praktisch eine Art spiegelnder Anteil (Glanzlichter). Das ist auch der Grund, warum bei shininess auf 0 der Fehler verschwindet (es reduziert die Größe der Glanzlichter auf absolut 0).

_________________
"Wer nicht arbeitet, kann auch nichts falsch machen"

und was kann ich genau dagegen tun, und warum bin ich scheinbar der einzige (außer dir) dem der fehler bekannt ist Oo sowas muss doch afaik häufig auftreten Oo

mfg

Nicht zwingend. Du benutzt nun mal das OpenGL Licht und das wird wiederrum eher sehr selten verwendet, da es Vertexbasierend ist. Häufiger Anwendung finden Shader und dabei wird dann nur genau das benutzt was auch im Shader steht. Oder eben Lichtsimulierende Techniken wie Lightmaps oder ähnliches um dynamisches Licht zu ermöglichen. Und das ist nicht mal Licht im klassischen Sinn.

Aber wie LBF sagt benutzt du Specular bei deinem Material. Setzt die Werte einfach mal alle auf 0. Dann sollte es rein theopraktisch weg sein. Evtl genügt es auch, wenn du das Setzen des Speculars weglässt. Allerdings könnte das auch dazu führen, dass der Treiber dort freie Hand hat und es wieder setzt.

ohne specular gehts, danke, mit shadern kenn ich mich leider net so aus, bzw hab ich noch nie damit gearbeitet.

mfg

Aha, wie ich es mir dachte. Und da ich mich ja schepp lachen wollte:
Unter anderem aus dem Grund, dass bei groben Polygonen das Licht mieserabel aussieht hatte ATi der Radeon 8500 die Fähigkeit verpasst in Echtzeit grobe Meshes (wie bei dir der Boden) in feinere Polygone zu unterteilen. Das Resultat waren glatter wirkende Objekte und knackiges specular lighting wie du es verwendest.
Also der 'Fehler' ist auch der Industrie bekannt. Seit Shader mehr Anwendung gefunden haben, hat ATi den Hardware-Support allerdings wieder entfernt. Wie Lossy schon sagte: Wenn man sich jedes erdenkliche Licht Pixelgenau selber programmieren kann, warum dann Ressourcen in genaueres Per-Vertex-Licht stecken?

Falls du ohne Shader weitermachen willst, da fallen mir noch zwei Einstellungen ein, die ich 'damals' genutzt habe.
Die eine lässt den Glanzpunkt nach der Texturierung auftragen, statt einfach die Textur mit maximaler Helligkeit zu zeichnen, was meist besser aussieht: http://www.opengl.org/resources/code/sa ... ode63.html
Die andere erzeugt Glanzpunkte genau an der Stelle wo das Licht besonders hell ist, anstatt den Einfallswinkel und Ausfallswinkel zu berücksichtigen. Das würde dann bedeuten, dass der Glanzpunkt sich nicht mit dem Betrachter bewegt, falls du sowas suchst. Den GL-Befehl weiß ich aber nicht mehr.

Viel Spaß noch beim Erleuchten/erleuchtet werden

danke, wenn ich ahnung von shadern hätte, würde ichs ja auch über shader machen

mfg

Mit shadern geht es relativ einfach, ich poste einfach mal einen für ganz einfache punktlichtquellen:

!!ARBvp1.0
OPTION ARB_position_invariant;
TEMP refl_vec,view_vec,light_dir,h1,h2,temp_col;

# Pass texture coordinates to result
MOV result.texcoord[0],vertex.texcoord[0];
MOV result.texcoord[1],vertex.texcoord[1];
MOV result.texcoord[2],vertex.texcoord[2];
MOV result.texcoord[3],vertex.texcoord[3];

# Calc light dir and normalize it
SUB light_dir,state.light[0].position,vertex.position;
DP3 h1,light_dir,light_dir;
RSQ h1,h1.x;
MUL light_dir,light_dir,h1;

# Calc view vector
SUB view_vec,program.env[0],vertex.position;
DP3 h1,view_vec,view_vec;
RSQ h1,h1.x;
MUL view_vec,view_vec,h1;

# Calc reflection vector
DP3 h1.x,vertex.normal,light_dir;
MUL h1.x,h1.x,2;
MAD refl_vec,h1.x,vertex.normal,-light_dir;

# Lit
DP3 h1.x,light_dir,vertex.normal;
DP3 h1.y,refl_vec,view_vec;
MOV h1.w,state.material.shininess.x;
LIT h1,h1;
MUL temp_col,state.material.diffuse,state.light[0].diffuse;
MUL h2,temp_col,h1.y;
MAD h2,state.material.ambient,state.light[0].ambient,h2;
MUL temp_col,state.material.specular,state.light[0].specular;
MAD h2,temp_col,h1.z,h2;
MOV result.color.xyz,h2;
MOV result.color.w,vertex.color.w;

END

Specular basiert hier einfach nur auf dem winkelunterschied zwischen reflektionsvektor und vektor zum betrachter.
Dazu muss man natürlich vor jedem renderingaufruf dem programm die kameraposition mitteilen
gls1->glext_man->glProgramEnvParameter4fARB(GL_VERTEX_PROGRAM_ARB,0,
gls1->camera.pos[0],
gls1->camera.pos[1],
gls1->camera.pos[2],0.0f);
Jede Lichtquelle muss aber einzeln gerendert werden, wenn man das vertex program modular halten will. Für den specular anteil rendert man zuerst ambient und diffuse (also diese farben ungleich 0.0f setzen), dann mit additiven blending den specular teil. Dafür setzt man die farben für ambient/diffuse auf 0, von specular auf ungleich 0. Das ist kein besonderes vertex program, nur ein einfacher standart zum rumprobieren und testen, wie per-vertex lighting funktioniert (praktischerweise lässt sich natürlich so die lichtquelle bewegen).

_________________
"Wer nicht arbeitet, kann auch nichts falsch machen"