Also als Müll würde ich das OpenGL Licht wirklich nicht bezeichnen.
Immerhin dürfte es recht schwierig werdem, bei echter dynamischer Beleuchtung von Objekten die T&L-Fähigkeit moderner Grafikkarten unter OpenGL voll zu nutzen, ohne dabei OpenGL Licht zu verwenden.

Man könnte natürlich direkt Vertex Shader einsetzen, die es ja ab OpenGL 1.4 als ARB Funktionsblock gibt, aber erstens ist das recht aufwendig - und zweitens nicht von jeder Grafikkarte unterstützt. Also bis Vertex Shader als Standardfunktionen im OpenGL ICD implementiert sind, und es einem dann egal sein kann, ob die Grafikkarte dies tatsächlich kann, oder der Treiber halt die CPU heranzieht (wahrscheinlich in Version 2.0) wird glLight durchaus von Nutz und Frommen sein (und auch dann könnte ich mir vorstellen, dass bei einem gut programmierten OpenGL Treiber die Beleuchtungsroutinen optimierter sein werden, als irgendwelche selbst gestrickten Progrämmchen - allerdings eröffnet sich dann natürlich ein neuer Horizont für Special Effects).

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

Die oben erwähnte Demo ist zwar ganz nett, aber in der Praxis für ein großes Level unbracuhbar da der Speicherbedarf und die Geschwindigkeit (vor allem aber der Speicherbedarf!) von 3D-Texturen eine Realisierung in Großen Mase (also für mehr als nur 'ne Demo) eher unwahrscheinlich macht. Zumindest vom aktuellen Zeitpunkt.

Für Effekte wie z.B. Flackern kann man auch animierte Texturen verwenden. Einfach mehrere Lightmaps pro Polygon (an den Stellen an welchen es flackert) berrechnen und diese in gewissen abständen duchschalten um eine Animation zu erhalten! Für so nette sachen wie einen fliegenden Feuerball bleiben einem dann aber wahrscheinlich nur dynamische Lightmaps oder gar irgend welche Stencil-Buffer tricksereien übrig!

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Dynamisches Licht mit Hifle von 3D-Texturen ist kein Problem. Für die Lichtintensität reicht eine Auflösung von 64*64*64 aus. Man benötigt nur einen Kanal und nimmt dann z.B. Luminance als Format. Dann braucht die ganze 3D-Texture nur 256kB. Das sind soviel wie eine RGBA Texture mit der Auflösung von 256*256. Die 3D-Texture benötigt man ja auch nur einmal. Eventuell kann man auch noch verschiedene 3D-Texturen für Spotlights oder so machen. Eine ganz andere Idee das Licht zu berechnen ist mit Hilfe der PixelShader. Ab einer GF% oder Radeon 9700 ist es kein Problem mehr die Rechnung 1-(x^2+y^2+z^2) direkt ohne Texture zu berechnen, was für eine höhere Rechengenauigkeit sorgt. Auch auf einer GF4 kann man über die Texture-Shader diese Rechnung ausführen. Das Skalarprodukt wird dabei sogar auf der GF4 mit Gleichkommagenauigkeit berechnen.
Zusätzlich zur 3D-Texture empfielt es sich noch eine Cubemap für ein Licht-Muster wie z.B. ein Gitter oder einen Kreis zu projektieren um das Licht interessanter erscheinen zu lassen.
Wer keine 3D-Texturen verwenden kann (GF1/GF2), kann die 3D-Texture auch durch eine 2D und eine 1D Texture ersetzten. Dann teilt man den Term 1-(x^2+y^2+z^2) einfach in x^2+y^2 und z^2 auf.

Da Du Ahnung von der Materia zu haben scheinst rekrutiere ich Dich hiermit zu einem freiwilligen Tutorial über das Thema

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Ich kann auch mal, wenn der Befarf besteht, ein Tutorial schreiben.

Gerne, jeder Zeit. was den Bedarf angeht: der besteht auf jeden Fall

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Jow, tät mich nämlich auch mal interessieren. Also immer ran da

_________________
Thunderman
Bei schwierigen Problemen entscheiden wir uns einfach für die richtige Lösung. Klar?

Lars hab mir mal deine Seite angeschaut,
also deine Engine hat Doom3 Qualitäten.
Die Bumpmaps sind so perfect... Respekt und das Pixelshader wasser erste sahne.

Ich hatte dir mal vor langer zeit ne Mail geschrieben, bekam als Antwort nen Link zu Nvidia.de.
Hab natürlich jeden Source den ich gefunden habe im Nvidia dev networt runtergeladen und mir mal genauer angeschaut... ich peil so gut wie nix davon... Liegt wohl am C++ Syntax...

Du kennst doch sicherlich Sulaco.co.za, da gibts nen Source für "Pixel shader for geforce 1 and up".
Ich hab mal versucht das nachzurekonstruieren und mir nen Sample gemacht.
Einfach nen Quad mit ner Steintexture und dann hab ich mit dem Normal Map filter von NVIDIA ne Bumpmap gemacht und halt das ganze zeugs "Register Combiners" und so reinkopiert.

Ich verstehe eins nicht, wieso braucht das teil GL_LIGHTING ???
wenn ich GL_LIGHTING abschalte dann funzt das bumpmapping nich mehr so wies soll

Ich will eigentlich nur wissen, welche Position zum Beispiel ne Lichtquelle (Mehrere lichtquellen ??) haben muss... das es richtig gut aussieht so wie in deiner Engine.
Und was ich noch gemerkt habe, die Position von den Lichtquellen wird irgendwie über den Farb wert gemacht... das peil ich mal überhaupt nicht.

Ich wäre echt dankbar wenn du mir das mal mit dem Bumpmapping genauer erklären könntest und nicht wieder auf <a href='http://developer.nvidia.com' target='_blank'>http://developer.nvidia.com</a> schickst.

Danke,
matane,
Final

Warum die Sulaco-Demo von GL_LIGHTING ab hängt weiß ich nicht. Normalerweise wird das OpenGL Licht nicht für Bummapping benutzt.
Den Lichtvektor in die Farbe zu packen ist eigentlich falsch, weil Farbwerte immer auf den Bereich 0..1 begrenzt werden.

Normalerweise verwendet man für das Bumpmapping eine Normalisationscubemap und die Bumpmap.
Die Cubemap enthält für jeden Punkt(s,t,r) den zugehörigen Vektor als Farbe (r,gb). Denn Lichtvektor gibt man dann als Texturekoordinaten für die Cubemap an. Dadurch wird der Lichtvektor über der Fläche interpoliert. Die Cubemap sorgt dafür, dass der Vektor immer die Länge 1 hat.

Texture0: Cubemap
Texture1:Bumpmap

Man braucht eigentlich keine Register-Combiner sondern kann Bumpmapping auch mit den gltexenv-Funkionen einstellen. Es muß ja im Grund genommen nur ein Scalarprodukt berechnet werden.

const
GL_DOT3_RGB_ARB = $86AE;

glActiveTextureARB(gl_texture1_arb);
glTexEnvi(GL_TEXTURE_ENV,GL_TEXTURE_ENV_MODE,GL_COMBINE_EXT);
glTexEnvi(GL_TEXTURE_ENV,GL_COMBINE_RGB_EXT,GL_DOT3_RGB_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_SOURCE0_RGB_EXT,GL_TEXTURE0_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_OPERAND0_RGB_EXT,GL_SRC_COLOR);
glTexEnvi(GL_TEXTURE_ENV,GL_SOURCE1_RGB_EXT,GL_TEXTURE1_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_OPERAND1_RGB_EXT,GL_SRC_COLOR);

Farbe=Texture0 . Texture1

Die Normalizations-Cubemap kann man so erstellen:
Eventuell muß man bei den Konstanten EXT durch ARB ersetzen.

Also ich möchte auch nochmal bekräftigen, das ein Tutorial zu diesem Thema super wäre! Grade was die komplizierteren Dinge der CG angeht haben wir noch einen großen Bedarf!

-lith

_________________
Selber Denken macht klug!

Ok, dann mache ich mir mal Gedanken zu einem Tutorial über Bumpmapping. Ich könnte auch noch etwas zur neuen ARB_VERTEX_BUFFER_OBJECT Erweiterung schreiben. Damit kann man nämlich ohne großen Aufwand die Dreiecksanzahl enorm steigern. Der Vorteil dieser Erweiterung ist, daß sie auf NVidia und ATI Karten unterstützt wird. Da die Erweiterung erst vor drei Wochen veröffentlicht wurde, kann es sein, daß der ein oder andere sie noch nicht kennt.

Hallo!

Ich greif das Thema jetzt einfach mal wieder auf, statt ein neues dafür zu eröffnen. Ich habe gerade noch ein paar Probs, wie ich den Lichtvektor beim Bumpmapping übergeben muss. Ich hab ein Beispiel mir von ATI angesehen und nachprogrammiert, dass den Lichtvektor als Vertexfarbe übergibt und durch das Smoothshading über die Fläche interpoliert statt mit einer Cubemap. Da hab ich es aber auch nicht wirklich hinbekommen
Irgendwie ist der errechnete Lichtvektor immer falsch. Ich muss ja wohl die Rotation und Translation des Objektes berücksichtigen, etc... aber wie genau?

_________________
Thunderman
Bei schwierigen Problemen entscheiden wir uns einfach für die richtige Lösung. Klar?

Da gibt es 2 Probleme:
1. Die Vertexfarbe wird ja auf einen Bereich von 0..1 beschränkt, deshalb kann man Punktlichter, bei denen der Lichtvektor zu einem Vertex jeden beliebigen Wert annehmen kann schlecht damit berechnen.
2. Da die Normalmap so berechnet wird, als würde sie in der Z-Ebene liegen, sind die Vektoren natürlich für alle Flächen, die nicht in der Z-Ebene liegen und einen Normalvektor von 0,0,1 haben falsch. Jede Fläche oder jeder Vertex bekommt einen eigenen Raum zugeordnet, den man als Tangent Space bezeichnet.
Jede Normale aus der Normalmap muß aus dem Tangent Space in den normalen Raum transformiert werden, damit sie korrekt auf der Fläche liegt. Angenommen die Fläche hat die Normale (0,1,0) und die Normale aus der Normalmap (0,0,1) dann soll die endgültige Normale an diesem Punkt ja (0,1,0) sein und nicht (0,0,1) sein.
Es ist aber wesentlich schneller den Lichtvektor in den Tangent Space pro Vertex zu transformieren als bei jedem einzelnen Pixel die Normale.
Dafür braucht man pro Vertex zusätzlich zu dem Normalvektor noch einen Tangenten und Binormalvektor. Zusammen bilden diese 3 Vektoren eine Matrix.
T.x,t.y,t.z
B.x,b.y,b.z
N.x,n.y,n.z

Pro Vertex muß der Lichtvektor,aber nicht die Lichtposition, einfach mit dieser Matrix multipliziert werden.
Lichtvektor im TangentSpace=(Lichtposition-Vertex)*TangentSpaceMatrix

Die Tangente und die Binormale sind die Normalen der Ebenen an denen die u und v Koordinaten der Fläche ausgerichtet sind.
Wenn man z.B. eine Fläche hat, die auf der Z-Ebene liegt und man generiert die u Koordinaten der Texture anhand der X Position und die v Koordinaten anhand der Y Position, dann gilt ja:
u=Entfernung von Ebene mit Normale (1,0,0) und d=0
v=Entfernung von Ebene mit Normale (0,1,0) und d=0

Also gilt Tangente=1,0,0 und Binormale 0,1,0. Die Matrix ist dann
1,0,0
0,1,0
0,0,1
also die Einheitsmatrix. Das ist natürlich klar, denn genau für in diesem Fall ist die Normalmap berechnet worden und braucht nicht mehr transformiert zu werden.

Zum Thema Tangent Space gibt es ein gutes PDF:
<a href='http://developer.nvidia.com/docs/IO/1294/ATT/GDC01_PerPixelLighting.pdf' target='_blank'>http://developer.nvidia.com/docs/IO/1294/A...xelLighting.pdf</a>

Wenn man die Texturekoordinaten selber generiert, dann sollte man sie anhand von Ebenen generieren und hat dann gleich die entsprechenden Vektoren.
Auch bei Bezierkurven und bei allen parametrischen Flächen ist die Sache auch noch einfach. Hier gilt Tangent=normalisieren P(i,j)-P(i-1,j) und Binormale=normalisieren P(i,j)-P(i,j-1), wenn man die Texturekoordinaten u,v anhand der Koordinaten i und j berechnet.

Bei völlig freien Flächen berechnet man zuerst die Tangentvektoren für jede Fläche und bildet dann wie bei den Normalen für jeden Vertex den Durchschnitt der Tangenten von den Flächen zu denen der Vertex gehört.
Die Binormale sollte, wenn die Texture nicht verzerrt ist das Kreuzprodukt aus Normale und Tangente sein. Das ganze Verfahren ist aber nicht so sicher, wie wenn man die Tangenten beim Generieren der Texturekoordinaten erzeugt, weil es viele Sonderfälle gibt. Es kann z.B. passieren, das zwei Tangenten deren zugehörige Punkte an einer Kante liegen in zwei verschiedene Richtungen zeigen und beim Interpolieren dann an einer Stelle 0 herauskommt. Oder bei einem Zylinder kann es vorkommen, das es an einer Stelle eine Naht gibt, weil die Tangent nicht übereinstimmen. Zu diesen Problemen gibt es von NVidia ein PDF
<a href='http://www.nvidia.com/dev_content/gdc2002/texture_space_on_real_models.htm' target='_blank'>http://www.nvidia.com/dev_content/gdc2002/...real_models.htm</a>

So kann man die Tangentvektoren für beliebige Flächen ausrechnen.