Hallo, jemand da Oder ist deine Technik so revolutionär das du auf meinen letzten Post nicht antworten willst?
Würde mich doch schon interessieren wie sich das was du machst im Gegensatz zum Detailtexturing via Multutexturing schlägt (vor allem visuell).

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

Hi,

sorry... total vergessen, war gestern nacht zu faul zum antworten

Also, ok.. eventuell hab ich es ein wenig unglücklich ausgedrückt
Natürlich ging ich nicht davon aus das man ne 512x512 Textur mit lauter 32x32 Detailmaps kachelt, sondern ich dachte in meinem Beispiel jetzt eher daran, das ich eine 512x512 grundtextur habe, und dort halt div. andere 512x512 Texturen draufblende um z.B. nen Schriftzug auf die Grundtextur zu bekommen...

und, ich kenne genug die das dann so machen, das sie ihre wände im Level mit der Grundtextur vollpflastern, und wenn halt irgendwo z.B. irgendwo was anders aussehen soll, nehmen sie ne andere Textur und blenden sie via MultiTexturing darüber und das umgehe ich halt einfach...

Natürlich iss das schwachsinn wenn man 32x32 Detailmaps verwendet, allerdings benutzt man sicherlich auch oft genug mal größere...

Au'revoir,
Aya~

PS: Wegen dem Lightmapper nochmal.. .also ich bin soweit fertig, hab auch die Lightmaps schon alle in eine große datei gepackt, aber ein problem is da... du meintest man könne immer 2 Texturen in ein Quadrat packen, also 2 Dreiecke... das kann nicht gehen
Denn wenn du z.B. ne Sphere hast, dann nimmt da ein Triangle nicht immer ein rechtwinkliges Dreieck der Textur, sondern evtl mal nen total schiefes Dreieck in der Mitte der viereckigen Textur...

Dann haken wir das mal als Missverständnis ab.Ich hab schon gedacht du hättest ne revolutionäre Technik erfunden die z.B. beim Detailtexturing die 2.TMU überflüssig macht...


Schau dir mal folgendes Bild an, das aus dem Dokument stammt das ich gepostet hab :

Der Autor schreibt auch , das man es so machen sollte...ansonsten reicht aber ne 1024er Textur (am besten mit DXTC) auch aus wenn du nur quadratische Lightmaps speicherst.

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

Hi,

also das mit der großen Textur... wenn ich in meiner Scene nur Würfel etc habe, ist das garkein problem... aber wenn ich ne Sphere benutze.. ai ai...

Ich poste gleich mal nen Bild, in 2-3min, moment

Au'revoir,
Aya~

EDIT:

Das ist ein Ausschnitt meiner Sphere-Lightmap... du siehst, die Triangle-TextureKoordinaten können durchaus total wirr sein, das macht ein anordnen von 2 Triangles zu einem Quad unmöglich...

Sieht lustig aus...rein theoretisch wärs sogar möglich die Dreiecke und entsprechend die Texel der Lightmap so zu rotieren und anzuordnen das mein zwei Dreiecke auf eine Lightmap bekäme.
Allerdings steht der riesige mathematische Aufwand wohl kaum im Vererleich zum erreichten Ziel, weshalb das keine Alternative darstellt.

Lass die Lightmaps also doch besser in quadratischer Form, und nutz dann 1024er Texturen und DXTC um deine Lightmaps zu speichern.Wenn du nicht zu viele große Lightmaptexturen nutzt, dürfte das kein Problem werden.

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

Jep, denke ich auch...
Wobei ich noch eine optimierung vorhabe... auf dem auschnitt siehst du ja das sehr sehr viele Dreiecke einfach nur schwarz sind... (in echt sind das noch viel mehr *g*), deswegen hab ich mir überlegt, ich werde bevor ich eine neue Lightmap in die große packe erstmal schauen ob diese nicht evtl schonmal so drinen ist... dadurch hätte ich dann nicht 1000 Schwarze Quads, sondern nur eines.. dürfte kein problem sein, und müßte ne menge probleme lösen in sachen zuwenig platz in der Textur (Natürlich das gleiche auch mit nich komplett Schwarzen Lightmaps..)

Dadurch dauert zwar die erstellung ein paar sekunden länger, aber ich denke da slohnt sich allemal

Au'revoir,
Aya~

Die Idee an sich ist wirklich nicht schlecht, und im Anbetracht der Tatsache das die Lightmaperstellung besonders für größere Maps sowieso recht lange dauert (ganz besonders wenn man noch Schatten mitberechnet), dürfte die im Vergleich recht kurze Zeitspanne zum Auffinden gleicher Lightmaps nicht besonders störend wirken, zumal man Lightmaps ja nicht permanent berechnen muss.
Und an deiner Stelle würde ich mir diese Technik als Option in die Engine einbauen, und diese deaktivieren solange man nicht die finale Lightmapberechnung durchführen will, sondern nur mal kurz nen Test machen möchte.

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

Stimmt... Optional hat was

Hi,

hab es hinbekommen
Bin von 720 Lightmaps dadurch auf 166 runtergekommen, und die Zeit für's berechnen zusätzlich is vieleicht 1 Sekunde.. kaum spürbar 8)

Au'revoir,
Aya~

Das kann sich ja schonmal sehen lassen, obwohl das Ergebnis wohl stark von der Beleuchtung (je mehr Lichtquellen, desdo schlechter wohl das Ergebnis) und der Szene an sich abhängt.

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

Jep, klar.. aber ich denke mal ein wenig wird man immer sparen damit

Au'revoir,
Aya~

Holla...ich hab grad mal meinen Lightmapper ganz brutal beschleunigt, und bin selbst noch ein wenig von dem starken Geschwindigkeitszuwachs schockiert.

Bis eben hab ich die Schattenberechnung ja noch so gemacht, das ich jeden Lichtstrahl einfach gegen alle Dreiecke aller Meshes in der Szene teste um festzustellen ob eine Kollision und damit Schattenwurf stattfindet.
Angeregt durch die AABB-Diskussion im anderen Thread von Aya hab ich dann mal jeden Mesh mit ner OOBB versehen und teste jetzt nicht mehr blind alle Polygone eines jeden Meshes gegen den Lichtstrahl, sondern schaue erstmal ob der Lichtstrahl überhaupt mit der OOBB des Meshes kollidiere, und prüfe erst bei einer Kollision mit jener den Lichtstrahl gegen die Polygone dieses Meshes.
Das "schockierende" Ergebnis : Um eine weniger komplexe Szene zu beleuchten und schattieren (860 Polygone, 13 Meshes) hat mein Lightmapper ohne diese Optimierung bei einer Lightmapgröße von 16x16Pixeln 1 Minute und 7 Sekunden gebraucht, nach der Optimierung sinds nur noch (konnts selbst kaum glauben, aber die visuelle Ausgabe ist die selbe) knappe 10 Sekunden...jetzt bin ich doch ein wenig stolz auf mich

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

Hi,

*g* Jep.. das mit den BoundingBoxen bringt ne menge.. hab's bei mir auch schon eingebaut

Allerdings steh ich grad vor nem anderen Problem...

Schau dir mal dieses Bild an:

http://www.Koshigaya.de/DelphiGL/LMDemo2.jpg

ist ja alles korrekt soweit... gut, wenn ich die Scene nun ein wenig von einer anderen stelle betrachte, wie z.B. hier:

http://www.Koshigaya.de/DelphiGL/LMDemo1.jpg

kommen plötzlich so komische schwarze streifen in die Textur, als ob die sich bewegen würde oder so... hat jemand ne ahnung woran das liegen kann???

Au'revoir,
Aya~

Das liegt garantiert daran das du deine Lightmaps mit dem falschen Textureclamp-Modus generierst.Während man für normale Texturen folgenden Clampmodus nutzt :

Muss man für die Lightmaps folgenden Clampmodus verwenden :

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

Hi,

ne.. das hab ich schon so eingestellt, daran liegt's net

Hier nochmal nen beispiel wo man es besonders schön sieht:




Diese "kanten" sind genau an der stelle wo die Triangle verlaufen.. also von links nach rechts sind es 10 Triangle Bahnen.


Das ist die dazugehörige Lightmap.

Der grund warum da keine schwarzen linien zwischen sind is ganz einfach:
Eine Lightmap ist z.B. 32x32 groß. auf der großen Lightmap nimmt sie 34x34 Pixel ein. 32x32 davon ist die Lightmap, und sie wird nochmal umranded von den rändern der lightmap.. denn als ich Schwarze striche gemacht hatte, liefen die schwarzen striche manchmal in die Lightmap mit rein.. ka wie ich das genau erklären soll

Au'revoir,
Aya~