Da hier im Forum (wie in anderen GL/DX-Foren auch) öfters mal ne Frage zum Thema Lightmapping (da die OpenGL-Beleuchtung oft nicht ausreichend ist) auftaucht und wohl auch noch auftauchen wird; hab ich mich dazu entschieden hier mal ein kleines Posting zu diesem Thema inklusive einer Beispielanwendung (+Quellcode) zu machen.

Resourcen :
Gute, und vor allem leicht verständliche Informationen zum Thema Lightmapping sind leider immernoch (trotz der recht häufigen Verwendung) recht spärlich gesäht.Neben den entsprechenden Artikeln bzw. Tutorials auf flipcode und gamedev, die leider recht unverständlich oder zu kurz sind, ist mir vor etwas längerer Zeit folgendes PDF-Dokument aufgefallen : http://users.pandora.be/BluePrint/thesis/Website/files/THESIS_English.pdf.
Hier wird besonders Lightmapping auf recht einfache und leicht nachvollziehbare Art- und Weise beschrieben, so dass dessen Implementation kaum noch Probleme machen sollte.
Edit am 07.08.2003 : Unter diesem Link gibt es ein sehr leicht verständliches Tutorial zum Thema Lightmapping, welches sich alle Interessierten auch zu Gemüte führen sollten.

Beispielanwendung :
Bereits vor einigen Wochen hab ich als Antwort auf ein Radiosity-Posting eine Beispielanwendung gepostet die anhand von in einer einfachen Textdatei angegebenen Szenengeometrie Lightmaps erstellt hat.Damals war dieser Lightmapper allerdings noch stark in meiner Engine verankert, weshalb ich auch keinen Quellcode veröffentlichen konnte (wollte).Ich hab diesen Lightmapper dann in den letzten Tagen von der Engine losgerissen und eigenständig gemacht, so dass ich ihn nun im Anhang komplett mit Quellcode veröffentlich um jedem Interessierten den Einstieg etwas einfacher zu machen.
Beachtet werden sollte allerdings, das dieser Lightmapper nur eine Basis darstellt und noch stark ausbaufähig ist (z.B. mit Kollisionsabfrage zur Schattenberechnung).Als Basis ist er allerdings recht nützlich und der Quellcode sollte recht einfach zu verstehen sein.

Der Download der alten Version wurde entfernt!Hier gibts die (finale, trotzdem beta) V2 des Lightmappers!

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

Hi,

hab mir das mal runtergeladen, und muß sagen.. hat mir grad schonmal ein bisschen weitergeholfen (Bastel ja auch an so nem Dyn. Lightmapping)

Ist es denn eigentlich sehr schwer zu machen, dass wenn da z.B. 2 Wände hintereinander sind die hintere Wand nicht beleuchtet wird???

Au'revoir,
Aya~

Nein, das ist sogar recht einfach zu implementieren wenn du bereits irgendwo in deiner Engine ne Ray-Triangle-Intersektionsabfrage eingebaut hast.Denn beim Lightmapping hast du ja die Position des Lumels und die Position der Lichtquelle.Dann ziehst du ganz einfach eine Linie zwischen dem gerade zu beleuchtenden Lumel und der Lichtquelle und prüfst mittels der Ray-Triangle-Intersektion ob diese Linie irgendwo eines deiner Dreiecke (oder wie deine Szene sonst aufgebaut ist) durchschneidet (sprich intersektioniert).Wenn dies der Fall ist, dann liegt etwas (z.B. ne Wand) zwischen deiner Lichtquelle und dem Lumel, und das Lumel wird dann nicht beleuchtet.
Wie du siehst ist das recht einfach zu implementieren, und so hast du dann ja auch quasi Schatten mit in deinen Lightmaps drin.Es lohnt sich auf jeden Fall.

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

mh... stimmt, danke *weiterbastelt*

Um zu verdeutlichen, wie sich die von mir an Aya gerichtete Methode des in das Lightmapping implementierten Shadowmappings auf die Szene auswirkt, hab ich mich heute mal dazu entschlossen das Ganze in meinen Lightmapper zu implementieren.Die Geometrie hab ich übrigens aus NapalmEdit heraus exportiert.
Wie hier im Thread erwähnt, lässt sich Shadowmapping recht einfach ins genutzte Lightmapping integrieren, denn um einen Lichtpunkt zu berechnen (auch Lumel genannt) muss man fürs Lightmapping ja dessen Weltkoordinaten kennen.Wenn man dies gemacht hat, muss man fürs Shadowmapping ganz einfach nur noch prüfen ob irgend ein Polygon die Linie zwischen diesem Lumel un der Lichtquelle schneidet.Ist dies der Fall, bleibt der Lumel schwarz (=Schatten).Dies zu implementieren ist recht einfach, und bringt einen riesigen visuellen Qualitätssprung, den ich mal anhand folgender Screenshots verdeutlichen will :

Die Szene ohne Lightmaps :


Selbige Szene MIT Lightmaps (sieht schon weitaus stimmiger und realisitischer aus!) :


Die Lightmaps (64x64 Pixel) :


Andersfarbige Variation, rein theoretisch kann man ja jeden Lumel beliebig beleuchten :


Hoffe mal das jetzt einige auf den Lightmapping-Zug aufspringen und ihren 3D-Awendungen so das passende Ambiente verpassen!

Edit : Hab neue Bilder hochgeladen (1-3), da die von mir zuerst geposteten Bilder noch minimale Fehler enthielten.

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

Hi,

hab mich grad mal durch deinen Code durchgelesen... mir ist alles soweit klar wie das funktioniert etc.. ähnelt auch dem was ich bisher schon gebastelt hatte (Hat mir aber schon bei einer sache weitergeholfen )

Aber eine sache ist mir grad ein wenig unklar...

In QuadList sind ja deine Quads die aus der DAtei geladen werden gespeichert, ja???

<!--pas--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>Delphi-Source </td></tr><tr><td id='CODE'><!--pas1--><pre><span class='reserved'>for</span> i := <span class='integer'>0</span> <span class='reserved'>to</span> High(QuadList) <span class='reserved'>do</span>
<span class='reserved'>begin</span>
SetLength(TriList, Length(TriList)+<span class='integer'>1</span>);
TriList[High(TriList)].Vertex[<span class='integer'>0</span>] := glVertex(QuadList[i].Vertex[<span class='integer'>0</span>][<span class='integer'>0</span>], QuadList[i].Vertex[<span class='integer'>0</span>][<span class='integer'>1</span>], QuadList[i].Vertex[<span class='integer'>0</span>][<span class='integer'>2</span>]);
TriList[High(TriList)].Vertex[<span class='integer'>1</span>] := glVertex(QuadList[i].Vertex[<span class='integer'>1</span>][<span class='integer'>0</span>], QuadList[i].Vertex[<span class='integer'>1</span>][<span class='integer'>1</span>], QuadList[i].Vertex[<span class='integer'>1</span>][<span class='integer'>2</span>]);
TriList[High(TriList)].Vertex[<span class='integer'>2</span>] := glVertex(QuadList[i].Vertex[<span class='integer'>2</span>][<span class='integer'>0</span>], QuadList[i].Vertex[<span class='integer'>2</span>][<span class='integer'>1</span>], QuadList[i].Vertex[<span class='integer'>2</span>][<span class='integer'>2</span>]);
TriList[High(TriList)].LightMapNr := i;
TriList[High(TriList)].CalcUV;
// Generate lightmap
<span class='reserved'>if</span> Length(LightMap) = i <span class='reserved'>then</span>
SetLength(LightMap, Length(LightMap)+<span class='integer'>1</span>);
LightMapSystem.CalculateLightMap(TriList[High(TriList)]);
// Load lightmap <span class='reserved'>to</span> texture
LoadTexture(IntToStr(TriList[High(TriList)].LightMapNr)+'.bmp', LightMap[High(TriList)], False);
glBindTexture(GL_TEXTURE_2D, LightMap[High(TriList)]);
<span class='reserved'>end</span>;</pre><!--pas2--></td></tr></table><span class='postcolor'><!--pas3-->

Hier machst du aus jedem Quad nen Triangle und berechnest dafür die Lightmap...
Aber... *guckt unsicher* Nen Quad besteht doch aus min. 2 Dreiecken... wieso berechnest du da dann nicht für jedes der beiden Dreiecke die Lightmap??? Oder steh ich da grad auf dem schlauch und hab was übersehen??? :unsure:

Au'revoir,
Aya~

Ich berechne die Lightmap deshalb nur für ein Dreieck pro Quad, da ich momentan einfach davon ausgehe, das die zwei Dreiecke des Quads eine plane Fläche geben.Wenn dies nicht so wäre, dann müsste man natürlich für beide Dreiecke des Quads jeweils eine seperate Lightmap erstellen.(Die Dreiecksliste wäre dann quasi doppelt so groß).
Ich mach das momentan deshalb so, weil ich den Lightmapgenerator für die Maps aus NapalmBomber3D nutzen will, und es dort ja nur "plane" Quads gibt.Der Vorteil dieser Methode ist halt die Tatsache, das ich pro Quad nur eine Lightmap brauche (weniger Speicherplatz) und dadurch auch die Berechnungsdauer stark verringert wird, die besonders durch die per-Lumel stattfindende Kollisionsabfrage für die Schatten recht lange dauert.

Wenn du den Lightmapper in deiner Anwendung einbauen willst und diese nur auf Dreiecken basiert (also nicht auf Quads simplifiziert werden kann), dann musst du halt den Szenenloader verändern, so dass er die Dreiecke direkt in die TriList lädt.Durch die Quad-Simplifikation verringert sich halt ganz einfach nur der Rechen- und Speicheraufwand.

Hoffe mal das hört sich jetzt plausibel an

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

Hi,

ok.. klingt logisch

Aber ich hab nochne frage mehr

Das ding generiert jetzt also für jedes Triangle eine Textur... aber, was wenn man z.B. ne DisplayList mit z.B. 100 Triangles hat...??

Muß ich da jetzt 100 kleine Texturen erstellen und die zu einer großen zusammenkleben, oder gibt es da ne bessere methode??? (Mal von der möglichkeit die Texturen in die DisplayList zu integrieren abgesehen)

Au'revoir,
Aya~

EDIT:
Nochne frage..
Hat es nen ganz tiefsinnigen Grund das du TexturCoordinaten in deiner TriList speicherst??? Denn verwendet werden die nie.. oder benutzt du die für dein Bomberman und hast die hier einfach nich rausgemacht?

Oben die Szene hat z.B. 569 Quads, also 569 kleine Bitmaps.Wie du bemerkt hast ist das batürlich sehr unpraktisch und diese alle in größere Texturen zu packen, so dass man am Ende nur noch einige wenige große Texturen hat in denen die LMs gespeichert sind ist natürlich keine schlechte Idee.
Allerdings wirds da dummerweise Probleme mit dem Texturefiltering geben wenn mehrere LMs nebeneinander in eine Textur gepackt werden, so dass es vorkommen kann das die Ränder verfälscht werden.Das ist der Grund warum ich das so nicht mache.

Ich arbeite aber just in diesem Moment an einer anderen Lösung (die allerdings immernoch auf jede Menge Texturen für die Graka hinausläuft) : Nachdem der Lightmapper die LMs für alle Quads generiert hat, werden die Bitmaps einfach in eine einzige Datei reingepackt und beim Laden werden diese Bitmaps halt direkt aus dieser Datei wieder herausgenommen.Da die LMs ja alle gleichgroß sind, ist das recht einfach.Ich finde das ist die beste Lösung, da man so im Endeffekt nur ein File hat in dem alle LMs sind, aber das Problem mit dem Texturenfiltering einer großen, alle LMS enthaltenen Textur umgeht.Nachteil ist halt die Sache mit den recht vielen Texturenwechseln, welche je nach Graka recht viel Leistung kosten können.


Wenn du TTriangle.TexCoord meinst, dann ja.Die stammen noch aus der alten Verwendung des Lightmappers in meiner ZornGL-Engine, genauso wie einige andere Variablen, die ich einfach nur zu faul war zu entfernen.

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

Hi,

mh... das problem sind ja nich unbedingt die vielen Texturen (Ich pack bei meiner Engine ja sowieso alle Texturen in eine große Datei, deswegen speichere ich die LMTexturen auch als Stream, nicht als Datei ).

Sondern das problem is einfach, das wenn ich ne DisplayList habe, ich pro DisplayList halt nur eine Textur benutzen kann.. ich hab zwar für jedes Triangle in der DisplayList ne Textur erstellt, kann aber halt der DisplayList nur eine Textur zuweisen..

Gibt es da vieleicht ne super methode für???

Oder sollte man da einfach jedesmal wenn sich die Texturen ändern die DisplayList neu generieren und halt die Texturen mit eincompilieren??

Au'revoir,
Aya~

Bei Quake 3 werden die Lightmaps immer ijeweils in eine 128*128 große Texture gepackt und um jede einzelne Lightmap wird ein Rand gezogen, damit es keine Probleme mit dem Filtern gibt.

So wies Lars beschrieben hat (á la Quake3) wäre in deinem Falle natürlich die beste Lösung, wobei du ruhig Texturen > 128x128 nutzen kannst.Pack deine Lightmaps für jede Displaylist in ne große Textur und lass um jede Lightmap dann nen schwarzen Rand herum.Dann musst du die Textur innerhalb der DL nicht mehr wechseln, sondern nur noch die Texturkoordinaten entsprechend anpassen.

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

Hi,

also dank deines Codes hab ich meinen Code jetzt auch fertig bekommen

Allerdings ein Fehler hat das ganze noch:

Stellen wir mal ein Licht an die Position 50,50,50
und erstellen ein Würfel dessen mittelpunkt bei 0,0,0 ist und der zu jeder Seite +/- 100 ist.

Die Berechnung macht ja nun bei der Distanz keinen unterschied zwischen + oder - (Sqr von ner Minus zahl is immer Positiv), daher zeichnet es den Lichtfleck 4x.. in jede ecke der Textur

Ist zwar nich weiter tragisch, bzw sollte sich leicht lösen lassen, aber ich wollte dich nurmal darauf hinweisen

Au'revoir,
Aya~

Hmm...ich versteh jetzt das Problem an der sache nicht...wenn ich dich richtig verstehe, dann wird auf jeder Seite des Würfels dann ein Lichtfleck gezeichnet, der innen hell bis aussen dunkel geht, oder?
Das ist aber doch richtig so, denn schliesslich handelt es sich um Pointlights, und die sind nunmal ungerichtet...

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

Nein nein, es sind dann auf einer Textur 4 Lichtpunkte, obwohl nur ein Licht da ist.
Teste es einfach mal

Mach einen Würfel mit ner Breite, Höhe und Tieve von -100 bis +100 und setzt dann bei den Koordinaten 50,50,50 ein Licht hin.

Au'revoir,
Aya~