ZFX + Developia

Hallo,

wie kann man gutes Lightmapping erreichen?
Real Time Lighting ist einfach für meine Zwecke zu langsam.
Problem:
Erstelle ich die Lightmaps per Objekt kann es sein, dass ein Objekt (z.B. ein Raum) so groß ist, dass die Lightmap zackelig und blockig aussieht.


Hat jemand eine Idee für Lösungsansätze? ´Habe schon Google benutzt, jedoch keinerlei wirklich gute Ansätze dazu gefunden.

Ich hatte es bei mir damals so gelöst, dass ich zunächst geschaut habe, welche Dreiecke miteinander verbunden sind... die wurden dann zu Dreiecksgruppen zusammengefasst. Allerdings wurden Dreiecke ausgeschlossen, dessen Winkel nicht zu den anderen passte... sprich, einen kleinen Toleranzwert überschritten haben. So das man z.B. für Wände, Boden usw. eigene Gruppen erhielt. Dann hab ich geschaut, zu welcher Achse jede Dreiecksgruppe gehört. Und diese dann versucht auf eine Textur zu mappen. Wobei alles an der Welt festgemacht wurde. Also wenn die Dreiecksgruppe sehr klein ist, gabs dafür auch nur kleine Texturbereiche... bei sehr großen Gruppen wurde das ganze entsprechend auf einer großen Textur abgebildet. Wobei ich da keine Begrenzungen oder Sicherrungen drin hatte, damit das nicht zu groß werden kann... hätte man noch reinbauen sollen...

Für Dreicksgruppen, die zu klein für eine bestimmte Anzahl Texel der Lightmaps waren, hab ich dann einfach Vertexlicht benutzt.

Ich hab relativ spät mit Lightmaps angefangen... war erst ende letzten Jahres... und eventuell werde ich wieder auf diese zurück kommen. Man kann halt mit keiner anderen Variante, so geiles Licht darstellen und dann noch mit so hohen Frameraten.

Das Problem was ich habe ist, dass ich teilweise sehr große Räume habe (z.b. mit einer größe von 50 x 20 x 10 "Metern") und z.B. der Boden einfach nur aus 2 Dreiecken besteht. Es gibt keine Lightmap in einer Auflösung, die das ohne Zacken darstellen würde...

Daher suche ich nach Lösungen...

Warum sollte es die nicht geben? Mit einer 2048er hast Du pro Meter 40 Texel, also 2,5cm Lightmap-Auflösung - das ist das Vielfache von dem, was normale LightMap-Implementationen pro Meter verbraten.

Oder um das ganze nochmal visuell zu untermauern:
Das war eigentlich für die Fachhochschule gedacht. Bin mir nicht mehr wegen der Größe sicher, aber ich meine, es waren in der Länge etwa 200 Meter.
Die größte Lightmap dort, für den Boden die, hat eine Auflösung 2640x2016. Da geht also noch viel mehr. Die Texturen sind im Gleitkommaformat gespeichert mit 32Bit pro Kanal. Die Szene verbraucht etwa 178 MB an Texturspeicher für die Lightmaps.

Ich würde empfehlen, die Lightmaps wesentlich grober zu machen, und dort nur das indirekte Licht zu speichern. Oder du wagst dich an SH heran.

Das direkte Licht sollte man eigentlich schon über die Echtzeitvarianten machen. Wenn du viel an komplexer Geometrie hast, bieten sich Shadow Maps an...

Und wie hast du die Lightmap errechnet? Mit einem eigenen Algorithmus?

Raytracing

Dann würde ich hier gerne noch das altbekannte Radiosity einschmeißen, welches bessere Ergebnisse erzielt als Whitted-Raytracing. Die ganz Harten können natürlich Monte-Carlo-Raytracing nehmen, aber wenn man nur diffuse Flächen betrachtet ist das natürlich Overkill ;)

Wie sieht das denn bei Lightmapping eigentlich mit Normal-Mapping oder so aus?

Kannst du natürlich kombinieren, wie du willst. Problematisch kann nur werden, dass Light-Maps üblicherweise signifikant geringerer Auflösung sind als die anderen Texturen – also auch als die Normal-Maps. Wenn ein Lightmap-Texel am Ende 8×8 Normalen-Texel groß ist, gehen die Details, die man per Normal-Mapping ausdrücken will, natürlich den Bach runter.

Bevor man sich mit sowas beschäftigt, sollte man überlegen, wie man solche Dinge wie spekuläre Highlights in Light-Maps kodiert (Spherical-Harmonics?) … das ist imho das größere Problem, denn Details hinzufügen bringt nichts, wenn man schon im Groben keinen realistischen Eindruck erzeugen kann …

Fast alle Light-Maps, die ich bisher gesehen habe, sehen nur auf komplett matten Oberflächen und mit einer einzigen Lichtquelle wirklich gut aus … da ließe sich noch viel mehr rausholen.

Krishty hat geschrieben:Fast alle Light-Maps, die ich bisher gesehen habe, sehen nur auf komplett matten Oberflächen und mit einer einzigen Lichtquelle wirklich gut aus … da ließe sich noch viel mehr rausholen.

Dann schau dir mal Spiele mit Unreal Engine 3 an. Gerade Mass Effect bietet sehr viele metallische Oberflächen, wo die Lightmaps mit specular highlights gut aussehen :)

Genau... und HL2 benutzt das auch. Die haben da auch so ne Präsentation, da sieht man dann auch, wie das gemacht wird.

Zudomon hat geschrieben:Genau... und HL2 benutzt das auch. Die haben da auch so ne Präsentation, da sieht man dann auch, wie das gemacht wird.

Ja die Unreal Engine verwendet exakt das gleiche Prinzip. Drei Basisvektoren die gleichschenklig aufgestellt sind. So benötigt man natürlich auch drei Lightmaps. Die Ergebnisse sprechen aber für sich. Wer Normalmaps mit Lightmaps kombinieren möchte, kommt an dieser oder einer ähnlichen Technik nicht vorbei.

Richard Schubert hat geschrieben:

Zudomon hat geschrieben:Genau... und HL2 benutzt das auch. Die haben da auch so ne Präsentation, da sieht man dann auch, wie das gemacht wird.

Ja die Unreal Engine verwendet exakt das gleiche Prinzip. Drei Basisvektoren die gleichschenklig aufgestellt sind. So benötigt man natürlich auch drei Lightmaps. Die Ergebnisse sprechen aber für sich. Wer Normalmaps mit Lightmaps kombinieren möchte, kommt an dieser oder einer ähnlichen Technik nicht vorbei.

Kann man über diese Technik irgendwo etwas erfahren?

http://www.valvesoftware.com/publications.html - "Shading in Valve’s Source Engine"

Und hier noch ein Bild vom Lightmapping + Bumpmap + Specular :D

Wie man sieht ist die Lightmaptexelgröße irrelavant, weil die Bumpmap das Detail bringt.
Also hier ist das auch mit den 3 Basisvektoren umgesetzt. Für Specular hatte ich da wie bei HL2 einfach
ne Cubemap verwendet.

Und wie kann man am besten runde Objekte (Rohre, Türme, etc.) Lightmappen?

Entweder per Vertex, oder du bräuchtest vernünftige Texturkoordinaten, wo man dann wieder bei der UV-Atlaserzeugung wäre.

Per Vertex-Beleuchtung ist keine Option...
UV-Atlas... findet man da in Google was?

Ich beschäftige mich gerade auch (ein wenig) mit dem Thema und hab zu dem Thema letztens noch bei gamedev.net geantwortet, vielleicht hilft dir das als Basis: http://www.gamedev.net/community/forums ... 1&#3513551

DomiOh hat geschrieben:Und wie kann man am besten runde Objekte (Rohre, Türme, etc.) Lightmappen?

Genauso, wie man auch runde Objekte texturieren würde: Durch Zuweisung "guter" Texturkoordinaten. Grade bei Röhren ist ein Zylinder-Mapping sinnvoll.

Genau, letztlich geht es ja nur darum, die Texturkoordinaten korrekt zu vergeben.

Warum ist per Vertex keine Option? Wenn die Geometrie detaillierter als die Lightmap ist? Das einzig blöde daran ist, dass die Dreiecke dann schön aufgeteilt sein müssen, weil sonst durch die Interpolation hässliche Kanten entstehen.

Hier hab ich mal ein Bild, wie ich das meine. Auf den großen Flächen sind Lightmaps, aber die kleinen runden Seitenflächen sind zu schmal für eine vernünftige Lightmap. Da wird dann einfach das Licht in die Vertexfarbe reingerechnet.

Die Frage ist nur, wie ich dann die Lightmap erstelle, wenn ich zylindrisches UV-Mapping verwende...
Mein Problem ist, dass ich z.b. einen großen Kühlturm habe, da ist die geometrie nicht detailiert genug für Vertex-Lighting.
Im Moment habe ich das schonmal so gemacht, dass alle Coplanaren Flächen eines großen Objekts eine Lightmap bekommen, z.B. für große Wände oder Böden.
Mein Problem ist jetzt, würde ich das auch für den Kühlturm so machen, würde daraus plötzlich einige DrawCalls mehr, die dann darin resultieren, dass die Performance total einbricht - schon allein durch die DrawCalls selbst...

Für dynamisches Lighting ist die Szene allerdings zu komplex.

Ich habe mir die Papers von HL2 durchgelesen, frage mich dennoch, wie es die programmierer dort schaffen, große Objekte (auch runde Dinge) so optimal mit Lightmaps zu rendern.

Wieso brauchst du mehr Drawcalls? Du nimmst einfach einmal normale Texturkoordinaten und einmal Extra texturkoordinaten für die Lightmap. Haust dann die Texturen + Lightmap in den Shader und raus kommt das Fertig texturierte und belichtete Model. Alles in einem Draw-Call.

Ja, das ist klar. Wenn ich es schaffe, entweder die Texturkoordinaten ordentlich zu berechnen oder die einzelnen Texturen ordentlich auf eine einzige Textur anzuordnen.
Ich habe bei meinem Kühlturm ansonsten 104 einzelnen Lightmaps - und dementsprechend dann 104 Draw-Calls (derzeit)

Benutzt du eigentlich einen eigenen Editor oder ein bereits bestehendes Produkt? Denn normalerweise generieren die meisten 3D Toolkits schon ziemlich gute UV-Koordinaten... Bezügl. des Kühlturms kann man doch einfach eine fläche um den Turm legen... Normalerweise sollte man schon beim Editieren der Levels gute UV-Maps haben, um vernünftig Texturen drauflegen zu können. Das einzige Problem, was ich mir bei der ganzen Geschichte vorstellen kann, ist - wie du schon sagst - das Unterbringen dieser 2D-Texturraum-Flächen auf möglichst wenig Platz und möglichst wenig Texturen, oder? Und da wäre bei einem zylindrischen Objekt doch die Mantelfläche als rechteckige Fläche optimal für...

Im Moment ist es so, dass das Objekt zwar in einem externen Editor erstellt wird, ich aber Lichtberechnungen und somit auch das UV-Mapping selber berechne.
Ich muss mal suchen gehen, ob ich irgendwo infos über das Zylindrische Mapping finde.

Mein Problem besteht im Moment eher noch darin, wenn ich meine Lichtberechnung mache, die richtige Position in der Textur zu finden, wobei das auch nicht schwer sein sollte, wenn ich weiss auf welchem Punkt eines Dreiecks der Lichtstrahl auftrifft.

Ich muss mal suchen gehen, ob ich irgendwo infos über das Zylindrische Mapping finde.

Assimp hat eine Implementierung in ComputeUVMappingProcess.cpp:250.

Bist du dir sicher, dass du nicht das UV-Mapping für die normale Texturierung benutzen kannst? Schließlich müsstest du dann nur noch alle UV-Flächen so anordnen, dass sie sich nicht überschneiden, was wesentlich einfacher wäre...

Also: In der Regel hat ma ja einen Editor, in dem man geeignete Geometrien erstellt. Dabei gibts ja häufig Grundkörper (Quader, Zylinder, Pyramiden, etc.), bei denen man genau weiß, wie man die UV-Koordinaten erstellen muss (beim Zylinder das besagt Zylindermapping bzw. Mantelflächenmapping).

Das heißt, man kann sehr häufig gute UV-Koordinaten für die Geometrie erstellen. Das Problem ist jetzt nur noch, diese "lokalen" UV-Koordinaten so abzuändern, dass man mehrere "kleine Lightmaps" in eine "große Lightmap" mit "globalen" UV-Koordinaten zusammenfassen kann (der oben benannte Texturatlas bzw. "Lightmap-Packing").
Nun ja, dieses Packproblem ist ein wohlbekannten algorithmisches Problem (two dimensional bin packing problem - 2BP). Es geht einfach darum, bestimmte zweidimensionale Rechtecke auf möglichst wenig Raum unterzubringen.

Ein guter Link dazu wurde schon oben gepostet. Hier noch ein anderer:
http://www.devx.com/dotnet/Article/36005/1954?pf=true

Schwierig wird das ganze, weil man ja bilineare Interpolation auf den Texturen anwendet. Da muss ich zugeben, dass ich mich nicht all zu gut damit auskenne. Aber zwei Lösungen die mir auf Anhieb einfielen:

- Möglichst viele benachbarte Lightmaps zusammenclustern und an den noch freien Kanten 1px-Ränder in Nachbarfarbe einfügen (Problem dabei ist: Wie kann man solche ja nicht-rechteckigen Cluster gut in eine Lightmap packen? 2BP liefert darauf keine Antwort ...)
- Dito, nur ganz ohne clustern und überall 1px-Ränder in Nachbarfarbe einfügen.

So weit erstmal meine Ideen dazu.